Big Data

Qué es ETL

Los ETL son procesos de integración que permiten obtener información de diferentes fuentes. Son utilizados para unificar los datos de varios sistemas en un mismo lugar y poder hacer análisis sobre ellos. Se dividen en 3 etapas:

• Extract
• Transform
• Load

Hoy en día es inevitable haber escuchado en una reunión o leído como parte de una oferta laboral a los procesos ETL. Son procesos que están en el interior mismo de la operativa diaria de la infraestructura de TI, son responsables de que los diferentes sistemas compartan información y en muchos casos, son los que proveen la información para que los modelos de machine learning cuenten con los datos para hacer sus procesos.

Pero antes de profundizar sobre qué son y para qué sirven, se debe hacer un viaje al pasado, para entender cómo surgen y analizar su evolución en el tiempo. Después se verá cómo se relacionan con las diferentes áreas de TI, particularmente con la ingeniería de datos.

Historia de los ETL

La historia de los ETL está fuertemente relacionada con la evolución de las bases de datos y más cerca en el tiempo, también con las metodologías ágiles y la arquitectura de microservicios. Antes de entrar en más detalle sobre los ETL, repasemos un poco esta historia conjunta.

Primera etapa

En la década de 1960 se venía dando un incremento de los sistemas informáticos en las empresas. Esto trajo aparejado el hecho de que se estaban generando datos en ellos y los mismos debían ser conservados de alguna forma. Hasta 1970 esto era hecho en archivos de texto o archivos binarios y traía varios problemas de rendimiento e integridad de datos. Fue entonces que ese año IBM publicó un paper titulado A Relational Model of Data for Large Shared Data Banks Un modelo relacional para grandes bancos de datos compartidos, en él se describía lo que se conocería de ahí en adelante como base de datos relacionales, porque todo su manejo interno de datos estaba basado en la teoría de conjuntos matemáticos, y definiendo un estándar para abstraer la forma en que los datos eran almacenado catapultando la adaptación de bases de datos.

Unos años más tarde, en 1979, Oracle liberó el que es hasta hoy el motor de base de datos comercial más usado en el mundo y en la década de los 80 otros tantos harían lo mismo, por ejemplo Microsoft en 1989 con lo que serían los cimientos para SQL Server. Éste uso más generalizado permitió un enorme avance en materia de TI en las empresas porque ahora no solo tenían capacidad de cómputo, sino también la posibilidad de almacenar la información con una cierta estructura.

Fue así como cada área de las empresas empezó a desarrollar sus sistemas internos para hacer seguimiento y tener un mejor control de su operativa almacenando diferentes tipos de información comercial. Esto generó que cada área tuviera su propio silo de datos y la necesidad de integrar los datos dispersos creció rápidamente.

Todo esto dio paso a que en los 80 y los 90 la dispersión de los datos y la necesidad de integrarlos fuera tan grande que surgió un nuevo concepto en base de datos, los almacenes de datos o datawharehouse. Un Data Warehouse es una base de datos relacional donde a la información se le aplican ciertas reglas de negocio. Además, estos sistemas están construidos sobre la base de una arquitectura de multicapas, la información es copiada de una capa a la siguiente, y transformada en el proceso, hasta que está disponible para el análisis.

Para poder consolidar todo en un único lugar surgieron primero los procesos por lote o también llamados batch. Estos procesos generalmente se corrían al finalizar la operativa del día ya que sobrecargaban los sistemas y generaban una degradación de servicios. En los procesos batch son recopilados los datos de diferentes sistemas y copiados en el almacén de datos. Esta práctica primero comenzó con simples script que combinaban BASH junto con código SQL, pero enseguida fueron evolucionando y pasaron a ser herramientas más robustas para ajustarse a la creciente necesidad, agregando control de error, por ejemplo.

Otro concepto creció junto con los almacenes de datos y las bases de datos relacionales que es el esquema al escribir, en inglés schema-on-write. Esto significa que antes de que podamos empezar a escribir datos en nuestro almacén, primero necesitamos definir el o los esquemas, las tablas y los tipos de datos de sus columnas. Lo cual quiere decir además que necesitamos saber previamente los datos que vamos a recibir de las diferentes fuentes.

Todo esto llevo a que el proceso obtuviera el nombre en base a los pasos que ejecutaba. Obtener los datos, también llamado extraer, aplicar el esquema se separó en 2 etapas, primero al proceso de adaptar los datos se lo llamó transformar y el paso final de enviar los mismos al almacén se llamó cargar, load en inglés, lo que dio nombre al Proceso: ETL.

Hay un problema inherente a esta forma y es que no se pueden cargar los datos hasta que no hayamos creado el esquema de destino y no podemos crear dicho destino hasta que no entendamos todas las entidades, de los diferentes orígenes y cómo se relacionan entre ellos. Otro problema es que, si cambian los orígenes, tenemos que hacer un ajuste en el proceso para que el cambio sea correctamente manejado.

Una vez finalizado este proceso, la lectura de los datos es rápida y confiable, todo el que consulte va a tener el mismo esquema de datos. Un tercer problema es que los datos del origen fueron modificados para cumplir un objetivo específico definido de antemano y es poco probable que podamos reutilizar el mismo en otros casos a futuro que no fueron contemplados.

Segunda etapa

Llegó el nuevo milenio y con él, el boom de internet. Un montón de datos semiestructurados (JSON, XML) o no estructurados (audios, videos, fotos) empezaron a generarse en los diferentes sistemas. Además, los datos empezaron a cumplir las 3 V de Big Data: Variedad, Velocidad y Volumen. Hasta ese entonces la mayoría del almacenamiento de los datos y procesamiento era hecho en ambientes on-premise, en los centros de datos las empresas y el costo operativo de manejar estas grandes cantidades de datos era muy elevado.

Se empezó a trabajar en una nueva forma de almacenamiento y allí surge en el 2009 el concepto de NoSQL, cuya principal ventaja es el no requerir una estructura fija. En 2005 es creada CouchDB por parte de IBM y en 2008 surge Cassandra de la mano de Facebook como grandes hitos de la revolución NoSQL.

Aparecen en lagos de datos, en inglés data lakes. Primero basados en Apache Hadoop en nuestra infraestructura local y con diferentes productos en la nube. Esto permitió almacenar todos los datos en el mismo lugar sin necesidad de preprocesarlos. A nivel de almacenamiento, se guardan los datos en crudo, es decir en sus formatos originales (CSV, JSON, TSV, parquet, etc.).

Se comienza a utilizar entonces el acrónimo ELT ya que la trasformación ahora estaba a cargo del usuario que quería hacer un análisis de los datos. Los datos son cargados como vienen de las fuentes lo que permite procesar una gran cantidad de datos a mucha velocidad. Entonces se pasó de procesos por lote a procesos continuos, en inglés stream processing, esto posibilitó el realizar acciones basándose en datos casi que en tiempo real.

Tercera etapa

El volumen de datos ha crecido de forma exponencial y las empresas que quieren explotar esos datos a su favor cada vez son más. En los últimos tres años se empezó a visualizar que los lagos de datos carecían de varias características con las que contaba su antecesor el almacén de datos. Si bien eran ideales para almacenar datos, carecían de capacidades esenciales. Por ejemplo: la necesidad de tener datos de calidad para poder elaborar análisis que sean confiables; el soporte de transacciones permitiendo la concurrencia de lecturas y escrituras y demás características de SQL; la posibilidad de asegurar un mejor gobierno reduciendo la cantidad de herramientas ya que unifican.

Surge entonces la necesidad de un sistema que permita el almacenamiento desacoplado del procesamiento, dando una flexibilidad que habilite mayor cantidad de usuarios concurrentes y mayores volúmenes de datos. Por lo anterior nombrado, fueron surgiendo diferentes productos en la nube.

Estos sistemas son llamados casa del lago, en inglés Lakehouse. El nombre es propio de databricks y su equipo de marketing cuando estaban buscando explicar qué problema resolvía su solución llamada delta lake. Con el paso del tiempo, el termino Lakehouse empezó a ser ampliamente aceptado en la industria y ahora sirve para describir una arquitectura y no solo un producto o empresa.

Existen otros productos como Apache Iceberg, Apache Hudi, Amazon Athena, Azure Synapse, Snowflake, Google BigQuery y Amazon Redshift que cumplen la misma función.

Estos productos soportan de forma nativa diferentes herramientas de Business Intelligence e Inteligencia Artificial permitiendo en un mismo lugar hacer diferentes tipos de análisis.

Fases del proceso ETL

Entonces, las diferentes partes que conforman el proceso son básicamente 3 y como ya fue mencionado son las que le dan el nombre:

• Extract: La E hace referencia a la operación de extracción de datos, significa que existe un dato y se extrae de un origen.
• Transform: La T hace referencia a la operación de transformación. Es decir, cambiar el dato de alguna manera, en general son operaciones simples.
• Load: La L por load en inglés, hace referencia a la operación de carga del dato al almacén, acá se habla de almacén de datos y no específicamente de qué tipo porque eso depende de la estrategia que defina la organización.

Ahora bien, el orden puede variar dependiendo en qué paradigma estemos parados y en los últimos años se empezó a ver que la Transformación ahora se divide en 2 partes creando lo que se conoce como ETLT. En la primera T aplicamos operaciones sobre nuestros datos que son de un costo computacional bajo. Por ejemplo sustitución de elementos vacíos, ofuscar o anonimizar datos PII y cumplir con diferentes regulaciones internacionales como RGPD, etiquetarlos para mejorar los metadatos de los mismos. La segunda transformación es aplicada a más de un origen a la vez y pueden ser operaciones más complejas como obtener valores utilizando funciones de agregación: mínimos, máximos, promedios, etc.

Casos de uso (aplicaciones de proceso ETL)

Volviendo un poco atrás entonces vale hacerse la pregunta ¿Para qué sirven los procesos ETL? Y la realidad es que hay un sin fin de problemas que resuelven, pero los más comunes son:

• Integrar diferentes sistemas: Como explicamos antes, el objetivo de los procesos es eliminar los silos de datos por lo tanto el principal uso es unificar los datos de diferentes sistemas.

• Consolidar datos para elaborar un almacén de datos o un lago de datos: De la mano del anterior, se puede generar conocimiento una vez que se cuenta con todos los datos juntos.

• Primeras etapas de proyecto de ML o ingeniería de datos: En esta primera etapa pueden ser los procesos que nutran nuestro modelo de Machine Learning con los diferentes orígenes para entrenarlo.

• Automatizar parte de un proceso de negocio: Nutrir de información complementaria a algunos de nuestros sistemas obteniendo datos de otros orígenes. Por ejemplo, el CRM con las oportunidades en los diferentes canales, puede obtener datos del sistema central para saber qué clientes son potenciales compradores de ciertos productos (préstamos hipotecarios, tarjetas, seguros de vida, etc.) y poder aumentar la taza de oportunidades que se concretarán en ventas.

• Calidad de los datos: Estos procesos nos aseguran que los datos son de buena calidad. Realizando transformaciones para eliminar valores vacíos o que estén dentro del esperado y con el tipo correcto.

• Migraciones: Hoy en día es muy común ver el uso de herramientas propias de un proveedor de nube pública como es ADF para migrar datos de una infraestructura on-premise a Azure.

Cuándo usar cuál

Habiendo visto las diferentes etapas que lo componen y cuáles son algunos de los usos que le podemos dar tenemos que ver qué tipo de proceso se ajusta mejor a nuestras necesidades.

• EL: Cuando los datos ya cuentan con buena calidad y comparten una normalización entre los sistemas de origen y destino.

• ETL: Nos importa la calidad de los datos que estamos almacenando y sabemos de antemano el esquema y la relación en la que queremos almacenar los datos.

• ELT: Cuando el volumen de datos ingresados es mayor a nuestra capacidad de procesarlos y corremos riesgo de perder datos. También puede ser cuando queremos tener más datos para crear o mejorar los modelos de ML o poder detectar relaciones que no son visibles desde un punto de vista humano.

• ETLT: Cuando la primera transformación es simple o sencilla, por ejemplo, enmascarado de datos u operaciones simples, agregar un pre o post fijo a una cadena y la segunda transformación pueden ser agrupaciones complejas o detección de anomalías en los conjuntos.

Conclusiones

El proceso de ingesta de datos es una etapa de la ingeniería de datos que se encarga de obtenerlos desde los diferentes sistemas dentro de nuestra organización. La ingeniería de datos busca consolidar los mismos en un lugar para su posterior procesamiento. Esto nos proporciona un origen único de verdad, single source of truth en inglés, desde la cual las diferentes áreas de nuestra organización pueden obtener información para desarrollar actividades variadas dirigidas por datos, data driven development en inglés.

Por último, el hecho de que haya un sin fin de casos de usos y su capacidad de adaptarse a los cambios hacen que, si bien internamente el proceso sea diferente, los procesos ETL van a seguir entre nosotros por muchos años más.