¿Qué es un conjunto de datos? Explicación para principiantes

Nuestro punto de vista, que es bastante modesto, es el siguiente: somos Geonode y vendemos servidores proxy a personas que recopilan datos de la web, por lo que vemos muchos conjuntos de datos en el momento mismo en que se crean. La observación que merece la pena compartir es que los errores más costosos se producen en el momento de la recopilación y no se descubren hasta meses después. No anotar cuándo se recopilaron los datos, no registrar qué campos podrían faltar, no conservar las respuestas sin procesar… Ninguna de estas cosas supone un problema el primer día, pero todas ellas hacen que un conjunto de datos resulte inutilizable cuando alguien plantea una pregunta que no habías previsto. Nada de lo que se explica en este artículo requiere comprar nada; los buenos hábitos son gratuitos y la mayoría de ellos solo llevan unos minutos.

La estructura básica

La mayoría de los conjuntos de datos tienen la misma estructura, independientemente del formato.

Registros: los elementos individuales. Filas en una tabla, objetos en un array JSON, archivos en un directorio. Un registro es una cosa que estás describiendo: una persona, una transacción, un producto, una fotografía.

Campos: los atributos de cada registro. Las columnas de una tabla, las claves de un objeto. Nombre, precio, fecha, categoría.

Valores: lo que contiene un campo determinado para un registro concreto.

Esquema: la descripción de qué campos existen, qué tipos de datos contienen y cuáles son obligatorios. A veces es formal y se aplica de forma estricta; otras veces, se trata de un acuerdo informal; y, en ocasiones, no existe nada en absoluto —lo cual es precisamente lo que causa problemas más adelante—.

Metadatos: datos sobre el propio conjunto de datos. Cuándo se recopilaron, quién los recopiló, de dónde proceden, bajo qué licencia y con qué limitaciones conocidas.

Este último es el aspecto que los principiantes suelen pasar por alto y en el que insisten los profesionales con experiencia. Un conjunto de datos sin metadatos es un conjunto de números sin forma alguna de juzgar si responden a tu pregunta.

Datos estructurados, semiestructurados y no estructurados

Una distinción útil en tres categorías, ya que determina lo que se puede hacer sin necesidad de preprocesamiento.

Los datos estructurados tienen un esquema fijo y tipos coherentes. Una tabla de base de datos, un archivo CSV con un encabezado estable, una hoja de cálculo. Se pueden consultar, filtrar y agregar directamente.

Los datos semiestructurados están organizados, pero no tienen un esquema rígido. Por ejemplo, JSON, donde los registros pueden tener campos diferentes; XML; o líneas de registro. Hay una estructura que analizar, y varía entre los distintos registros.

Los datos no estructurados carecen de una estructura de registros inherente. Documentos de texto, imágenes, audio, vídeo. No es que no haya información, sino que extraer campos de ellos requiere un modelo o la intervención humana.

En la práctica, los límites se difuminan. Un directorio de imágenes con un archivo CSV que enumera nombres de archivo, dimensiones y etiquetas es contenido no estructurado con un índice estructurado, lo cual es la disposición estándar para los conjuntos de datos de aprendizaje automático y, en general, una buena práctica.

La mayor parte del trabajo real consiste en convertir entre ambos tipos. El scraping convierte páginas web no estructuradas en registros estructurados; la conversión es donde se producen la mayoría de los errores, y por eso es importante conservar la fuente sin procesar.

Formatos y lo que te cuestan

La elección es más importante de lo que parece.

Tres puntos que determinan la mayoría de los casos.

El CSV no tiene una especificación formal. El RFC 4180 lo reconoce, describiendo lo que «parece seguir la mayoría de las implementaciones». Esa es la causa de los problemas con los delimitadores, la codificación y las comillas con los que todo el mundo se ha topado. Además, es compacto y universalmente legible, razón por la cual sigue utilizándose.

JSON Lines está infrautilizado y suele ser adecuado para la recopilación de datos. Un documento JSON por línea: se procesa en memoria constante, se añade de forma segura y un archivo truncado sigue proporcionando todos los registros completos. Una matriz JSON no hace nada de eso, y un proceso de recopilación que se cuelga deja un archivo imposible de analizar.

Parquet es el destino adecuado para cualquier tarea de gran volumen y de carácter analítico. El almacenamiento en columnas significa que una consulta que afecte a tres de cuarenta columnas solo lee esas tres; la compresión es mucho mejor que la del texto porque los valores similares se agrupan, y los tipos se conservan con exactitud. No es legible para los humanos, y esa es la contrapartida.

Un proceso sensato recopila los datos en JSON Lines porque tolera las interrupciones y, a continuación, los convierte a Parquet por lotes para su análisis. Hemos comparado los formatos de texto en detalle en JSON vs CSV.

Qué hace que un conjunto de datos sea utilizable: FAIR

La comunidad científica ha formalizado este concepto, y el marco de referencia se aplica mucho más allá de la investigación.

Los principios FAIR, publicados en 2016, establecen cuatro propiedades.

Localizable. F1 exige que «a los (meta)datos se les asigne un identificador único a nivel mundial y persistente»; F2, que «los datos se describan con metadatos detallados»; F3, que los metadatos «incluyan de forma clara y explícita el identificador de los datos que describen»; y F4, que estén «registrados o indexados en un recurso en el que se puedan realizar búsquedas».

Accesible. A1 exige la recuperación «mediante su identificador utilizando un protocolo de comunicaciones estandarizado». A2 es la que sorprende a la gente y podría decirse que es la más valiosa: «Los metadatos son accesibles, incluso cuando los datos ya no están disponibles». La descripción de un conjunto de datos debe perdurar más allá del propio conjunto de datos, de modo que quien lea un artículo años más tarde pueda saber qué se utilizó.

Interoperable. I1 exige «un lenguaje formal, accesible, compartido y de amplia aplicación para la representación del conocimiento»; I2 exige vocabularios que, a su vez, sigan los principios FAIR; I3 exige «referencias cualificadas a otros (meta)datos».

Reutilizable. R1 exige que los datos estén «descritos de forma detallada con una pluralidad de atributos precisos y relevantes».

Traducido a la práctica para un proyecto habitual: asigna a tu conjunto de datos un identificador estable, anota qué contiene y de dónde procede, utiliza nombres de campos y unidades estándar cuando existan, indica la licencia y conserva la documentación aunque elimines los datos.

Documentación de un conjunto de datos

Los principios FAIR establecen que la documentación es importante. El documento «Datasheets for Datasets» indica qué hay que incluir en ella.

Esa propuesta de 2018 se inspira en la industria electrónica, donde cada componente se suministra con una ficha técnica. Sostiene que cada conjunto de datos debería ir acompañado de documentación que abarque «su motivación, composición, proceso de recopilación, usos recomendados, etc.», con el fin de «facilitar una mejor comunicación entre los creadores y los usuarios de los conjuntos de datos, y animar a la comunidad de aprendizaje automático a dar prioridad a la transparencia y la rendición de cuentas».

La lista de verificación práctica que se deriva de ello:

¿Por qué existe esto? ¿Qué pregunta se pretendía responder al recopilarlo? Esto determina si responde a la tuya.

¿Qué contiene? Registros, campos, tipos, unidades y qué se considera dato faltante.

¿Cómo se recopiló? Método, fechas, fuentes, muestreo. Un conjunto de datos extraído de un sitio web en una semana es un objeto distinto de uno agregado a lo largo de un año.

¿Qué no es? Lagunas conocidas, sesgos, poblaciones excluidas, períodos que faltan. La sección más valiosa y la que suele faltar con mayor frecuencia.

¿Cómo debe utilizarse y cómo no? Aplicaciones previstas y aquellas que se sabe que no son adecuadas.

¿Cuál es la licencia? Y a quién dirigirse.

¿Cómo se mantiene? Si se actualizará y cómo se identifican las versiones.

Redactar esto lleva una hora cuando el conjunto de datos es reciente, pero resulta casi imposible dieciocho meses después, cuando la persona que lo recopiló ya se ha marchado.

Evaluación de la calidad

Seis dimensiones, y para cada una hay una comprobación que puedes realizar.

Exhaustividad. ¿Cuánto falta y es aleatoria esa falta de datos? Cuenta los valores nulos por campo. Un campo que está vacío en un 40 % te está diciendo algo: o bien un fallo en la recopilación o bien que se trata de un campo opcional que deberías documentar.

Exactitud. ¿Reflejan los valores la realidad? Es difícil de verificar en general, pero factible en casos concretos: compara manualmente una muestra aleatoria con la fuente. Veinte registros llevan quince minutos y permiten detectar la mayoría de los errores sistemáticos.

Coherencia. ¿Aparecen las mismas cosas de la misma manera? Fechas en formatos mezclados, países tanto como «UK» como «United Kingdom», precios con y sin símbolos de moneda. Cuenta los valores distintos por campo categórico: un campo con trescientos «países» distintos tiene un problema de normalización.

Actualidad. ¿Cuándo se recopilaron los datos y es eso relevante para tu pregunta? Los precios del último trimestre son historia, no datos.

Representatividad. ¿La muestra se corresponde con la población que te interesa? Un conjunto de datos de reseñas es un conjunto de datos de personas que escriben reseñas.

Procedencia. ¿Puedes rastrear cada registro hasta su fuente? Esto es lo que te permite volver a derivar, auditar y corregir —y es por eso por lo que merece la pena el espacio de almacenamiento que supone conservar las respuestas sin procesar junto con los registros analizados.

Realiza estas comprobaciones antes del análisis, no después. Descubrir un problema de normalización en un gráfico es considerablemente más costoso que descubrirlo en un recuento de valores.

División de datos para el aprendizaje automático

Si el conjunto de datos se destina al entrenamiento de un modelo, la división es tan importante como los propios datos.

Conjunto de entrenamiento: aquello de lo que aprende el modelo. Suele constituir la mayor parte. Conjunto de validación: se utiliza para ajustar y elegir entre distintos modelos. Conjunto de prueba: se mantiene al margen por completo y se utiliza una sola vez para estimar el rendimiento en el mundo real.

Hay tres formas en las que esto puede salir mal, todas ellas habituales.

Fuga de información. La información del conjunto de prueba influye en el entrenamiento. La versión clásica consiste en escalar o imputar utilizando estadísticas calculadas sobre todo el conjunto de datos antes de la división, lo que infla los resultados de forma silenciosa.

Registros duplicados entre las divisiones. Los elementos casi idénticos tanto en el conjunto de entrenamiento como en el de prueba significan que el modelo ya conoce la respuesta. Los datos recopilados de la web son especialmente propensos a esto, ya que el mismo contenido aparece en varias URL.

Fuga temporal. En el caso de datos ordenados cronológicamente, una división aleatoria permite que el modelo aprenda del futuro. En su lugar, divide por fecha.

El principio general: el conjunto de prueba debe parecerse a la situación a la que te enfrentarás realmente. Si vas a predecir el mañana a partir de hoy, divide por tiempo. Si vas a recibir nuevos usuarios, divide por usuario.

Las licencias: lo que determina lo que puedes hacer

Un conjunto de datos que no puedes utilizar legalmente no es un conjunto de datos que tengas. Las licencias se comprueban con mucha menos frecuencia de lo que deberían, normalmente porque resultan aburridas hasta el punto de que acaban siendo lo único que importa.

Licencias de datos abiertos. Creative Commons es la familia más común. La licencia CC0 sitúa las obras en el dominio público en la medida en que lo permita la ley y no impone condiciones. La licencia CC BY exige la atribución. La licencia CC BY-SA añade una condición de «compartir igual», lo que significa que las obras derivadas deben llevar la misma licencia, lo cual puede ser incompatible con un producto comercial. CC BY-NC prohíbe el uso comercial, y el término «no comercial» se define de forma lo suficientemente imprecisa como para suponer un riesgo real si tu uso es ambiguo. Los portales gubernamentales suelen utilizar licencias abiertas a medida que, en la práctica, son permisivas; léelas una vez en lugar de dar nada por sentado.

Los derechos sobre las bases de datos son independientes de los derechos de autor. En la UE y el Reino Unido, un derecho sui generis protege la inversión sustancial realizada en la obtención, verificación o presentación del contenido de una base de datos, independientemente de si cada registro individual es susceptible de ser protegido por derechos de autor. Un conjunto de datos compuesto únicamente por hechos puede seguir estando protegido como base de datos, que es precisamente la situación en la que se encuentran los proyectos de agregación.

Las condiciones de uso son contractuales. Un conjunto de datos recopilado de un sitio web cuyas condiciones prohíben el acceso automatizado plantea ese problema, independientemente de cuál sea el contenido de los registros individuales. Se trata de una cuestión distinta de los derechos de autor y se aplica incluso cuando los hechos en sí mismos no están protegidos.

Los datos personales conllevan su propio régimen. Si los registros identifican a personas —ya sea directamente o en combinación—, la legislación en materia de protección de datos se aplica a la conservación y el tratamiento de los mismos, y no solo a su recopilación. Esto implica una base jurídica, límites de conservación y derechos que los interesados pueden ejercer frente a ti. «Era de acceso público» no constituye por sí solo una base legal.

Y los conjuntos de datos derivados heredan las restricciones. Entrenar un modelo con un conjunto de datos de «compartir igual» o agregar varias fuentes con licencias diferentes genera obligaciones que son la unión de las condiciones de las fuentes, en lugar de la más permisiva.

La práctica habitual consiste en registrar la licencia en la documentación del conjunto de datos en el momento de la recogida, junto con un enlace a las condiciones tal y como estaban redactadas ese día. Las licencias cambian, las páginas de condiciones se reescriben, y poder demostrar lo que aceptaste en el momento de la recogida tiene más valor que recordarlo.

De dónde proceden los conjuntos de datos

Cinco fuentes, ordenadas de mayor a menor según el esfuerzo que requiere cada una.

Conjuntos de datos abiertos publicados. Portales gubernamentales, repositorios de investigación, archivos institucionales. Son gratuitos, están documentados y, con frecuencia, ofrecen una calidad suficiente. Compruébalo primero: la cantidad de datos que ya existen públicamente y que no es necesario volver a recopilar es considerable.

API. Estructuradas, autorizadas y estables. Si una fuente publica una, casi siempre es la opción más adecuada.

Proveedores de datos comerciales. Con licencia, soporte técnico y un precio acorde. A menudo resultan más baratos que crear lo mismo desde cero, una vez que se tiene en cuenta el tiempo de desarrollo.

Tus propios sistemas. Registros, transacciones, telemetría. Suelen ser los datos más valiosos de los que dispone una organización y los más descuidados.

Recopilación web. Lo que comercializamos. Adecuada cuando los datos son visibles públicamente y no existe una vía autorizada, aunque conlleva obligaciones: «robots.txt», condiciones de servicio, derechos de autor, derechos sobre bases de datos y, cuando se trata de datos personales, la legislación en materia de protección de datos. También es la fuente que más requiere documentación, ya que un conjunto de datos extraídos sin un registro de cuándo y de dónde proceden es muy difícil de defender o reproducir.

Preguntas frecuentes

¿Qué es un conjunto de datos en términos sencillos?

Una colección de datos relacionados entre sí, organizada de tal forma que se pueda trabajar con ella como una unidad; normalmente se trata de registros (los elementos) con campos (sus atributos), además de una descripción del significado de dichos campos. Una hoja de cálculo, una tabla de base de datos y una carpeta de imágenes etiquetadas son, todas ellas, conjuntos de datos.

¿Cuál es la diferencia entre datos y un conjunto de datos?

Los datos son la materia prima; un conjunto de datos es una recopilación delimitada y organizada de los mismos, reunida con un fin concreto. La organización y los límites son lo que lo hacen utilizable: se pueden contar los registros de un conjunto de datos, describir sus campos e indicar su procedencia.

¿Qué son los datos estructurados y no estructurados?

Los datos estructurados tienen un esquema fijo y tipos coherentes, como una tabla de base de datos. Los datos no estructurados carecen de una estructura de registros inherente: texto, imágenes, audio. Los datos semiestructurados se sitúan a medio camino, con organización pero de forma variable, como JSON o los archivos de registro.

¿Qué formato debo utilizar para un conjunto de datos?

CSV para tablas planas que se importan a hojas de cálculo o a un cargador de bases de datos. JSON Lines para cualquier cosa recopilada de forma incremental, ya que se transmite en flujo continuo y resiste el truncamiento. Parquet para grandes volúmenes de datos analíticos, ya que el almacenamiento en columnas y la tipificación de datos hacen que las consultas sean mucho más eficientes.

¿Qué hace que un conjunto de datos sea de buena calidad?

La exhaustividad, la precisión, la coherencia interna, la actualidad, la representatividad de la población que te interesa y la trazabilidad de su procedencia. Cada uno de estos aspectos tiene una comprobación concreta: recuentos de valores nulos, una muestra verificada manualmente, recuentos de valores distintos por campo categórico.

¿Cómo debo documentar un conjunto de datos?

Registra por qué existe, qué contiene, cómo y cuándo se recopiló, cuáles son sus lagunas y sesgos conocidos, cómo debe y no debe utilizarse, su licencia y cómo se mantiene. La propuesta «Datasheets for Datasets» es la referencia estándar al respecto.

¿Qué son los principios FAIR?

Localizables, accesibles, interoperables y reutilizables: un marco para la gestión de datos publicado en 2016. El requisito más infravalorado es que los metadatos deben seguir siendo accesibles «incluso cuando los datos ya no estén disponibles», de modo que la descripción perdure más allá del propio conjunto de datos.

¿Cómo divido un conjunto de datos para el aprendizaje automático?

En conjuntos de entrenamiento, validación y prueba (reservado), utilizando el conjunto de prueba una sola vez. Realiza cualquier transformación únicamente a partir del conjunto de entrenamiento, elimina los casi duplicados entre las divisiones y, en el caso de datos ordenados cronológicamente, divide por tiempo en lugar de hacerlo aleatoriamente; estas tres prácticas son fuentes habituales de resultados inflados de forma imperceptible.

Conclusión

Un conjunto de datos está formado por registros, campos y valores, además de la descripción que les da sentido. La descripción es la parte que determina si alguien podrá utilizarlo dentro de seis meses, incluido tú mismo.

Los formatos importan menos que los hábitos. CSV cuando sea adecuado, JSON Lines para cualquier cosa que se recopile de forma incremental, ya que sobrevive a una interrupción del proceso, y Parquet cuando los datos son voluminosos y las consultas son analíticas. Cualquiera de estas opciones funciona; el error es elegir una matriz JSON para una recopilación de larga duración y encontrarse con un archivo imposible de analizar tras un fallo del sistema.

Lo que más esfuerzo merece la pena es la documentación, redactada mientras el conjunto de datos aún está fresco. Por qué existe, cómo y cuándo se recopiló, qué falta y para qué no debería utilizarse. Los principios FAIR lo expresan de manera formal, la propuesta «Datasheets for Datasets» te ofrece una lista de comprobación, y ambos apuntan en la misma dirección: los metadatos deben sobrevivir a los datos.

Y comprueba la calidad antes de analizar. Los recuentos de valores nulos por campo, los valores distintos por campo categórico y veinte registros verificados manualmente con respecto a la fuente permitirán detectar la mayoría de los problemas sistemáticos en menos de una hora, lo cual resulta mucho más económico que encontrarlos en una conclusión.