Las canalizaciones de datos solían seguir una secuencia estricta: hacer un Pull de datos de los sistemas de origen, transformarlos a un formato limpio y estructurado y, a continuación, cargar el producto final en una base de datos. Esa secuencia (extraer, transformar, cargar o ETL) tenía sentido cuando el almacenamiento era caro y los sistemas de destino no eran lo bastante potentes para hacer cálculos pesados.

Pero los almacenes en la nube lo cambiaron todo, y ELT (extraer, cargar, transformar) se convirtió en el modelo que muchos equipos de análisis usan ahora por defecto. Aunque ETL tradicional mantiene casi el 40 % de la cuota de mercado, está perdiendo terreno rápidamente frente a otros tipos de canalizaciones de datos, como ELT.

A continuación, explicamos qué es ELT, cómo funciona y dónde encaja y dónde no.

Destacados

• Un proceso ELT (extraer, cargar, transformar) carga primero los datos sin procesar en un almacén en la nube y luego los transforma. Esto ofrece a los analistas un acceso más rápido a los datos y más flexibilidad para mejorar los modelos.

• Los almacenes en la nube se adaptan bien a ELT porque separan el almacenamiento de la computación, crecen de forma elástica y permiten a los analistas escribir la lógica de transformación en lenguaje de consulta estructurado (SQL).

• Trabajar con un proveedor de pagos que se sincroniza directamente con tu almacén sin usar una ruta a través de infraestructuras de terceros reduce la complejidad de la canalización y la exposición de seguridad.

¿Qué es ELT y cómo funciona?

ELT (extraer, cargar, transformar) es un modelo de integración de datos basado en tres pasos: extraer datos de sistemas de origen, cargarlos sin procesar en un destino centralizado y, después, transformarlos dentro del destino para su análisis, elaboración de informes o machine learning.

Así es como funciona un flujo de trabajo ELT habitual en la práctica:

• Extraer: Un conector o un trabajo de canalización hace un Pull de registros desde un sistema de origen (de forma incremental, en un horario establecido o por eventos) y los escribe en el destino con su estructura original.

• Cargar: Las tablas de datos sin procesar llegan al almacén, a menudo en un esquema específico, y se mantienen los nombres de los campos, los tipos de datos y las relaciones tal y como estaban en el origen.

• Transformar: La lógica de transformación se ejecuta dentro del almacén, ya que las herramientas basadas en SQL, como la herramienta de compilación de datos (dbt), permiten a los equipos controlar las versiones de esos modelos, probarlos y compilar conjuntos de datos sobre la capa sin procesar.

Como los datos sin procesar llegan primero, los analistas pueden hacer una consulta inmediata y pueden crearse múltiples vistas descendentes desde un único origen sin volver a extraerlos. Si un modelo de transformación es incorrecto, lo reescribes y lo vuelves a ejecutar con los datos que ya están en el almacén.

¿En qué se diferencia ELT de ETL en la práctica?

La principal diferencia de arquitectura entre ETL y ELT es el lugar donde se produce la transformación: fuera del destino en ETL y dentro del destino en ELT.

Estas son las principales diferencias entre ETL y ELT:

• Disponibilidad de los datos: En una canalización ETL, no se puede hacer una consulta de los datos hasta que se han transformado y cargado. En ELT, los datos sin procesar llegan primero, por lo que los analistas pueden trabajar con ellos mientras los trabajos de transformación se ejecutan por separado.

• Velocidad de mejora: Cambiar una transformación en una canalización ETL suele implicar reconstruir la propia canalización. En ELT, se actualiza un modelo SQL y se vuelve a ejecutar con los datos que ya están en el almacén.

• Dónde reside la computación: Las transformaciones ETL se ejecutan en la infraestructura de la canalización (un servidor o servicio independiente que aprovisiones con ese fin). Las transformaciones ELT se ejecutan en los recursos informáticos del almacén de datos, que escala elásticamente y ya está pagado.

• Retención de datos sin procesar: Por lo general, ETL descarta los estados intermedios una vez se produce el resultado transformado. ELT conserva la capa sin procesar por defecto, lo que significa que puedes volver a procesar datos históricos cuando cambian los requisitos.

¿Por qué ELT se adapta a los almacenes de datos modernos en la nube?

Las siguientes propiedades hacen que ELT encaje de forma natural en los almacenes en la nube:

• Almacenamiento y computación separados: Plataformas como Snowflake y BigQuery cobran por separado el almacenamiento de los datos y sus consultas. Puedes alojar tantos datos sin procesar como quieras, y los trabajos de transformación solo consumen computación cuando se ejecutan.

• Escalado elástico: Puedes crear la computación que necesites, ejecutar el trabajo y volver a reducirla. El almacén se encarga de la paralelización.

• Almacenamiento en columnas: Los almacenes en la nube almacenan los datos en formato de columnas, lo que hace que las consultas analíticas (agregaciones, filtros, uniones en grandes conjuntos de datos) sean mucho más rápidas que el almacenamiento basado en filas.

• Nativo de SQL: La mayoría de los analistas y los ingenieros de análisis ya conocen SQL. Ejecutar transformaciones dentro del almacén significa que las personas que entienden la lógica de la empresa pueden escribir y gestionar los modelos de transformación directamente.

¿Cuándo es adecuado usar ELT?

ELT no es la respuesta adecuada para cualquier canalización de datos, pero se adapta a un conjunto de condiciones fácilmente identificable.

Aquí es donde ELT suele funcionar bien:

• Conjuntos de datos grandes o en rápido crecimiento: Si sincronizas millones de eventos al día, ejecutar las transformaciones antes de la carga requiere una gran infraestructura de canalización. Cargar los datos sin procesar y transformarlos dentro del almacén resulta más práctico al escalar.

• Lógica de transformación que cambia a menudo: Si las transformaciones residen en el almacén como modelos SQL, actualizar los requisitos de análisis no requiere volver a implementar la infraestructura de canalización.

• Múltiples casos de uso descendentes: Los datos sin procesar del almacén pueden alimentar de forma simultánea un panel de inteligencia de empresa, un almacenamiento de funciones de machine learning y un informe de operaciones. Solo compilas una canalización y modelas los datos de distinta forma para cada usuario.

• Equipos con funcionalidad de ingeniería analítica: ELT traslada la propiedad de la transformación a la capa de análisis. Los equipos que usan herramientas como dbt son ideales para esto.

ELT no es adecuado en las siguientes circunstancias:

• Restricciones normativas sobre datos sin procesar: Algunos entornos de datos sanitarios y datos financieros prohíben la entrada de datos confidenciales antes de su enmascaramiento o filtrado. En esos casos, las transformaciones deben producirse antes.

• Esquemas de destino rígidos: Si tu destino no admite datos sin procesar o semiestructurados, el enfoque de ELT de cargar primero crea más problemas de los que resuelve.

• Conjuntos de datos pequeños y estables: Si una canalización ETL sencilla es suficiente, añadir una infraestructura de transformación al almacén supone un coste adicional sin apenas beneficios.

¿Qué desafíos presenta ELT?

Cargar datos sin procesar en un almacén es útil, pero puede presentar desafíos de gobernanza y costes.

Ten en cuenta estos posibles desafíos de ELT.

Control de acceso

Las tablas de datos sin procesar suelen contener datos que no deberían ser accesibles de forma generalizada, como información de identificación personal (PII), registros financieros o identificadores internos. En ETL, los campos confidenciales se pueden ocultar o eliminar antes de que los datos lleguen al destino. Pero en ELT, los datos llegan primero. Sin seguridad a nivel de fila, enmascaramiento de columnas o roles de almacén estrictamente definidos, los analistas pueden hacer una consulta de campos que no deberían poder ver.

Calidad de los datos

Los datos incorrectos de orígenes ascendentes llegan a tu almacén antes de que se ejecuten las comprobaciones. Los campos nulos, los registros duplicados, los cambios de esquema y las discrepancias de tipos pueden propagarse a los modelos descendentes si no integras pruebas de calidad en la capa de transformación con el marco de pruebas de dbt o funciones de calidad de datos nativas del almacén.

Gestión de costes

Los trabajos de transformación se ejecutan en los recursos informáticos del almacén, y un código SQL mal escrito (como análisis ilimitados, falta de filtros de partición o actualizaciones redundantes de tablas completas) puede generar costes considerables. Desde el principio, vale la pena integrar en tu flujo de trabajo límites en los costes de las consultas, usar modelos incrementales cuando sea posible y supervisar el consumo de recursos informáticos.

¿Cómo maneja los datos de pagos un flujo de trabajo ELT?

Muchos equipos compilan una integración personalizada frente a la API de su proveedor de pagos, o bien usan un conector de terceros. Pero las integraciones personalizadas requieren un mantenimiento constante a medida que la API cambia, y los conectores de terceros suponen enviar datos financieros confidenciales a través de la infraestructura de un proveedor adicional.

Stripe Data Pipeline es una opción nativa integrada directamente en el Dashboard de Stripe. Sincroniza los datos e informes de Stripe con Snowflake, Databricks, Amazon Redshift y muchos otros con un par de clics. Se hace sin programación, no requiere configuración del conector ni gestionar credenciales por separado. La sincronización se ejecuta usando la propia infraestructura de Stripe, por lo que ningún sistema de terceros maneja tus datos financieros en tránsito.

Algunos detalles que vale la pena saber:

• Cobertura histórica: Stripe Data Pipeline incluye datos históricos desde el inicio de tu cuenta de Stripe en lugar de desde el momento en que activas la sincronización.

• Esquema: Los datos llegan a tablas que reflejan el modelo de datos de Stripe (p. ej., cargos, clientes, suscripciones), lo que facilita la creación de modelos de transformación sin tener que hacer una limpieza exhaustiva de la capa sin procesar.

• Integridad de los datos: Además de los datos de los objetos sin procesar, Stripe Data Pipeline incluye acceso a informes financieros preconfigurados y a conjuntos de datos seleccionados, lo que puede acelerar los informes y reducir el trabajo de transformación en casos de uso comunes como los ingresos recurrentes mensuales (MRR) y el análisis de fraude.