Curado de datos

Ya hemos visto como en Big Data manejamos una gran cantidad de datos que se generan de manera constante a gran velocidad. Datos que además provienen de distintas fuentes, con distintas estructuras, organizadas de distintas maneras. La curación de datos es la actividad por la que organizamos todos estos datos de la misma manera, dejándolos preparados para su posterior análisis y extracción de información.

Procesos ETL

Cuando nos planteamos el tratamiento de los datos, nos vemos en la necesidad de definir algún tipo de metodología que nos ayude a estructurar el trabajo y evite que nos perdamos entre tanto dato. Estos son los procesos ETL, del inglés: E: extract, T: transform y L: load.

Los nombres de las fases de este proceso ya nos dan una ligera idea de la acción a realizar en cada una de ellas. En cualquier caso, veámoslas con un poco más de detalle.

Extract (Extracción)

El proceso de extracción consiste en ir a las distintas fuentes que manejemos y traernos los datos. Normalmente manejaremos varias fuentes, que además tendrán distintas estructuras.

La calidad de las fuentes también será diferente, por lo que al capturar los datos, realizaremos una serie de comprobaciones sobre los mismos.

Estas fuentes suelen tener una documentación explicativa de la estructura de datos, un fichero que normalmente podremos encontrar con el nombre “Readme” o similar. Básicamente, comprobaremos que cumplen con un conjunto de pautas definidas en dicha documentación, desechando aquellos datos que no cumplan.

Transform (Transformación)

He comentado antes que las distintas fuentes de datos pueden tener distintas estructuras. Para poder tratar conjuntamente los datos de todas las fuentes, tendremos que adaptarlos a una misma estructura de datos final. La etapa de transformación es la que se ocupa de este cometido.

Pongo un ejemplo, para que se entienda mejor. Imaginemos que estamos recopilando datos de posibles votantes en las elecciones presidenciales de EEUU, queremos hacernos una lista de emails para enviarles nuestro programa. Resulta que los datos que obtenemos de la fuente 1, tienen los campos: [nombre] , [primer apellido], [segundo apellido] y [email]. Mientras que los datos de la fuente 2 tienen: [nombre], [apellidos] y [email]. Y en nuestra estructura final, queremos tener sencillamente dos campos: [nombre y apellidos] y [email]. Tendremos que transformar los datos de ambas fuentes a la estructura final que nos interesa.

Load (Carga)

Finalmente, almacenamos los datos en alguna Base de Datos o repositorio, con la estructura final que definimos. De esta forma, tendremos todos los datos curados y transformados a la misma estructura. Listos para poder trabajar con ellos.

Este almacenamiento deberá cumplir con todos los estándares de seguridad e integrad de los datos. Copias de respaldo, gestión de permisos de acceso, etc.

Herramientas ETL

Existen varias herramientas que ayudan a implementar los procesos ETL. Normalmente, las vamos a encontrar agrupadas en tres categorías:

• Herramientas de empresa: Son los desarrollos comerciales que compran las empresas. Y algunos ejemplos son: Oracle Data Integrator, SAP Data Services, IBM Infosphere DataStage o Microsoft SQL Server Integration Services.
• Open Source: Son los productos de código abierto. Y entre ellos podemos encontrar:  Pentaho Data Integration o Talend Open Studio.
• Cloud: Aquí agrupamos las soluciones que proveen los servicios en la nube. Y entre ellas podemos destacar: Amazon AWS Glue, Microsoft Azure Data Factory o Google Cloud Dataflow.

Para empezar a practicar, y hacerte una idea de como funcionan estas herramientas, mi recomendación es que pruebes con Pentaho Data Integration. Es posible que la encuentres como Kettle, pues así era denominada anteriormente.

Formatos de datos más habituales

Los datos, los vamos a encontrar disponibles en varios formatos. Los más habituales son estándares abiertos de entre los que yo destacaría : CSV, JSON y XML.

CSV (Comma Separated Values)

Simplemente leyendo el nombre de este formato, no hay que ser un fiera para imaginar que en CSV, los datos los tendremos separados por comas.

Vamos a disponer de una primera línea o cabecera, con los títulos de los datos separados por comas. Sería algo así como los nombres de los campos de una tabla. Y luego, el resto de líneas, son los datos propiamente dichos, separados por comas.

Un ejemplo podría ser el siguiente:

Echando un vistazo al formato CSV, se hace evidente asimilarlo a las bases de datos relacionales. La primera línea sería la lista de los nombres de los campos, y el resto de las líneas seria cada una un registro, con los valores para en cada campo, separados por comas.

Si lo que queremos es capturar los datos de una base de datos relacional, la elección más obvia es usar CSV como formato para el intercambio de datos. Sencillamente, guardaríamos cada tabla con todos sus datos, siguiendo el esquema de arriba.

JSON (JavaScript Object Notation)

Este formato de intercambio de datos, nos permite trabajar con estructuras más complejas que con CSV. Admite dos tipos de estructuras básicas: parejas nombre-valor y listas de valores, estructuras de datos ampliamente usadas en programación: Objetos, arrays, etc.

Internet está repleto de ejemplos de JSON, aquí te reproduzco uno cualquiera, con la idea de que te hagas una idea de la apariencia de estos formatos:

Seguro que si has programado con un lenguaje de programación orientado a objetos, esta estructura de datos te habrá resultado familiar. JSON lo vamos a utilizar mucho cuando estemos compartiendo y capturando datos directamente de una aplicación o de bases de datos NO relacionales.

XML (Extended Markup Language)

Es un lenguaje de marcado, por lo que vamos a trabajar con etiquetas. Abriremos una etiqueta, pondremos un valor y cerraremos la etiqueta. Por supuesto, podemos complicar la estructura anidando todas las etiquetas que queramos.

Aquí os dejo un ejemplo de XML para que podáis haceros una idea de su apariencia:

Recuerda bastante a html, por su uso de etiquetas. No obstante, no es tan usado para guardar datos en fuentes abiertas, sino que se emplea fundamentalmente para intercambiar datos entre programas.

NOTA:

Este post es parte de la colección “Entornos Big Data”. Puedes ver el índice de esta colección aquí.