La evolución del Datawarehouse, ETL vs ELT

Una de las definiciones más conocidas del datawarehouse incluye tres componentes claves:

  • ETL (Extracción Transformacion y Loading/Carga)
  • Reportería
  • Minería

Durante años la forma tradicional de realizar la ingesta de datos al warehouse fue el proceso de ETL.

Pero en los últimos años con la llegada del “Big Data” de la mano de herramientas como Hadoop, BigQuery, y otras tecnologías que permiten tener el datawarehouse en la nube, este concepto tradicional que tenemos de ETL está cambiando hacia otra metodología mejor adaptada a los tiempos, en la cual las transformaciones suceden directamente en el datawarehouse, y no antes.

Esta metodología es conocida como ELT (Extracción, Carga y Transformación).

Originalmente el ETL surgió como una forma de resolver el problema de organizar la información del negocio en un lugar centralizado, donde la información estuviera lista para ser analizada y consultada. Se eliminaba así todo dato irrelevante y se transformaba, enriquecía y re-modelaba sólo lo que servía. Un ejemplo de esto es por ejemplo la mensualización de consumos del cliente, para verlos ya agrupados por mes y por categoría, y facilitar las comparaciones entre diferentes meses.

El proceso de ETL es complicado, especialmente la parte de la Transformación. Incluso cuando hablamos de empresas pequeñas (con menos de 500 empleados) se requieren al menos varios meses para tener todo listo y corriendo, y una vez que se implementaron los procesos iniciales de transformación, empiezan los cambios y mejoras constantes sobre esos procesos, porque los datos y el negocio cambian constantemente.

Otro problema muy común con el ETL es que durante la transformación modelamos los datos en una forma especifica. Un modelo que a menudo tiene mayor agregación (menos detalle) que los datos reales y que no incluye aquellos datos que en ese momento se consideran innecesarios. Pero sucede a menudo que estos datos “innecesarios” terminan volviéndose “útiles”. Por ejemplo si tus usuarios te piden información diaria en lugar de mensual, es necesario corregir el proceso de transformación, remodelar los datos, y volver a cargar todo. Esto puede tomar semanas o meses, e incluso más.

Cuanto más datos se tienen, mas tarda el proceso de transformación. Las reglas de transformación suelen ser bastante complejas, incluso si solo se tienen unos pocos Terabytes de datos, cargar todo suele tomar varias horas. Dado el tiempo que tarda transformar y cargar un set de datos, es posible que tus usuarios nunca obtengan datos frescos. “Hoy” se transforma en hoy pero de la semana pasada, y “Ayer” en ayer de hace una semana. A veces toma varias semanas o meses realizar una nueva actualización de los procesos. Y los cierres de mes pueden no estar el primer día hábil sino una, dos o hasta tres semanas después de cerrado el mes.

En resumen, algunas de las contras del ETL son:

  • Costoso de implementar, incluso para Pequeñas y Medianas empresas.
  • Costoso de mantener.
  • Se pierde el acceso a los datos crudos.
  • Toma mucho tiempo. Los usuarios deben esperar a que las transformaciones terminen antes de poder consumir los datos.

Viendo esta lista, podemos preguntarnos las razones por las que llegamos a un proceso así.

La respuesta es simple, las generaciones de datawarehouse anteriores no podían trabajar ni con el tamaño ni con la complejidad de los datos crudos. Así que era necesario transformar los datos antes de poder consumirlos.

Los últimos avances en tecnologías de bases de datos hicieron que los warehouse sean muchísimo más rápidos y baratos. El almacenamiento se vuelve más accesible cada día, e incluso algunos datawarehouses dividen su precio entre el almacenamiento y el poder de procesamiento. Por ejemplo los precios de almacenamiento de BigQuery son tan baratos que es cómodo guardar todos tus datos crudos ahí.

Algunos de estos avances tecnológicos que hacen que podamos hablar de ETL en lugar de ETL son:

Optimización para las operaciones analíticas. Los warehouse modernos tienen a ser orientados a columnas y estar optimizados para agregar y procesar datasets enormes.

Almacenamiento barato. Ya dejamos de preocuparnos por lo que almacenamos, podemos simplemente tirar todos nuestros datos en el datawarehouse.

Basados en la nube/cloud. O en servidores distribuidos, con fácil escalamiento y de capacidades prácticamente infinito, en los casos de cloud esto sucede bajo demanda, así que es posible tener la performance que necesitamos en el momento en que la necesitamos.

Si bien las nuevas tecnologías son mucho mas rápidas, permitiéndonos realizar transformaciones en el momento de la consulta, sin procesar antes, hay muchos casos donde las transformaciones son complejas y pueden tomar bastante tiempo. Así podemos, en lugar de realizar las transformaciones en el momento de la consulta, dejar que las haga el warehouse, pero en un segundo plano, luego de cargar los datos.

Una vez que los datos crudos se encuentran cargados en el warehouse, se pueden realizar las operaciones de transformación más pesadas. Hoy por hoy todavía tiene sentido tener tanto procesos de transformación en tiempo real como en segundo plano. Los usuarios pueden consumir y operar en el nivel de definición de negocios al consultar los datos, y el BI transformar en el momento o consultar los datos ya transformados de forma transparente por detrás.

Este enfoque nos da buena flexibilidad y agilidad para el desarrollo de una capa de transformación.

Hoy en día los ingenieros de software implementan varias veces al día y tienen metodologías de entrega continua de mejoras. Deberíamos adaptar el mismo principio en nuestro enfoque sobre la transformación de datos. Si una definición de métricas cambia o si se requieren más datos, se pueden realizar cambios fácilmente en horas, ya no en semanas o meses. Este enfoque es particularmente valioso para las startups que crecen rápidamente, donde los cambios suceden a diario y los equipos de datos tienen que ser flexibles y ágiles para poder cumplir con las necesidades de negocio y desarrollo de producto.

A medida que los warehouses avancen más y más, estoy seguro de que veremos cómo las transformaciones en el momento de la consulta reemplazan por completo a aquellas realizadas en un segundo plano. Pero mientras esperamos que eso suceda, podemos hacer algunas transformaciones utilizando ELT. Y ya que esto mismo corre en SQL y en el mismísimo datawarehouse, el cambio final debería ser fácil y sin problemas.

Dejá una respuesta