Los pipelines de datos solían seguir una secuencia muy estricta: extracción de los datos de los sistemas de origen, transformación a un formato estructurado y limpio, y carga del producto terminado en una base de datos. Dicha secuencia (extraer, transformar, cargar o ETL, por sus siglas en inglés) tenía sentido cuando el almacenamiento era costoso y los sistemas de destino no eran lo suficientemente potentes para llevar a cabo procesos de gran intensidad computacional.

Sin embargo, los almacenes en la nube lo cambiaron todo, y el proceso de ELT (extracción, carga y transformación) se convirtió en el patrón predeterminado para muchos equipos de análisis. Si bien el tradicional ETL conserva casi una cuota de mercado del 40 %, está perdiendo rápidamente terreno en favor de otro tipo de pipelines de datos, como los ELT.

A continuación, abordaremos qué es el proceso de ELT, cómo funciona y cuáles son los casos de uso adecuados o no adecuados para él.

Aspectos destacados

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

• Los almacenes en la nube son idóneos para un proceso de ELT, ya que separan el almacenamiento del procesamiento, se pueden ampliar de manera elástica y permiten a los analistas redactar lógica de transformación en un lenguaje de consultas estructuradas (SQL).

• Trabajar con un proveedor de pagos que sincroniza la información directamente con tu almacén en la nube, sin pasar por infraestructuras de terceros, reduce la complejidad del pipeline y la exposición a riesgos de seguridad.

¿Qué es ELT y cómo funciona?

El proceso de ELT (extracción, carga y transformación) es un modelo de integración de datos basado en tres pasos: extraer datos de sistemas de origen, cargarlos en bruto en un destino centralizado y transformarlos dentro de él para facilitar su análisis, reportar la información y aplicar técnicas de machine learning.

En la práctica, un flujo de trabajo típico de ELT se ejecuta de la siguiente manera:

• Extraer: un conector o trabajo de pipeline extrae registros de un sistema de origen (de forma incremental, en función de un programa temporal o según eventos activadores) y los copia en el destino, conservando la estructura original.

• Cargar: las tablas en bruto llegan al almacén, a menudo dentro de un esquema dedicado, y conservan los nombres de campos, tipos de datos y relaciones de la misma manera que en el origen.

• Transformar: la lógica de transformación se ejecuta dentro del almacén como herramientas basadas en SQL, como la de compilación de datos (dbt), que permite a los equipos controlar las versiones de dichos modelos, probarlas y crear conjuntos de datos sobre la capa en bruto.

Dado que primero se descargan los datos en bruto, los analistas pueden consultarlos de inmediato y se pueden crear múltiples vistas descendentes desde una sola fuente, sin necesidad de extraerlos de nuevo. Si un modelo de transformación no es el adecuado, lo puedes reescribir y volver a ejecutar con respecto a datos que ya están en el almacén.

¿Cuál es la diferencia entre un proceso de ELT y uno de ETL en la práctica?

La diferencia fundamental de arquitectura entre el modelo ETL y el ELT radica en dónde se lleva a cabo la transformación: fuera del destino (ETL) o dentro de él (ELT).

A continuación, se indican las mayores diferencias entre un proceso de ETL y de ELT:

• Disponibilidad de los datos: en un pipeline de ETL, los datos no se pueden consultar hasta que no se han transformado y cargado. En un proceso de ELT, los datos en bruto llegan primero, de modo que los analistas puedan trabajar con ellos mientras se ejecutan los trabajos de transformación de manera separada.

• Velocidad de mejora: realizar cambios a una transformación en un pipeline de ETL a menudo supone tener que volver a crear el pipeline por completo. En el proceso de ELT se actualiza el modelo de SQL y se vuelve a ejecutar con datos que ya están en el almacén.

• Dónde reside el procesamiento: las transformaciones de ETL se ejecutan en la infraestructura del pipeline (un servidor o servicio independiente que suministras con este fin). Las transformaciones de ELT se ejecutan en el procesamiento de un almacén de datos, un recurso que crece de forma elástica y que ya se ha pagado.

• Retención de datos sin formato: el ETL suele descartar los estados intermedios una vez generado el resultado transformado. El ELT conserva la capa en bruto por defecto, lo que te permite volver a procesar datos históricos cuando cambian los requisitos.

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

Las siguientes propiedades hacen que ELT sea una opción natural para los almacenes en la nube:

• Almacenamiento y computación separados: Las plataformas como Snowflake y BigQuery realizan cargos por separado por almacenar datos y consultarlos. Puedes introducir la cantidad de datos sin procesar que desees, y los trabajos de transformación solo consumen computación cuando se ejecutan.

• Escalado elástico: Puedes crear la capacidad de computación que necesites, ejecutar el trabajo y reducirla nuevamente. 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 establecido 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 administrar los modelos de transformación directamente.

¿Cuándo es adecuado un proceso de ELT?

Un proceso de ELT no es la respuesta correcta para cualquier pipeline de datos, pero es idóneo para un conjunto de condiciones fácilmente reconocible.

A continuación, se indican los casos en los que suele funcionar un proceso de ELT:

• Conjuntos de datos de gran volumen o en rápido crecimiento: si sincronizas millones de eventos cada día, para ejecutar las transformaciones antes de su carga necesitarás una infraestructura de pipelines importante. Es mucho más práctico, a nivel de escala, cargar la información en bruto y realizar la transformación dentro del almacén.

• Lógica de transformación que cambia a menudo: si las transformaciones residen dentro del almacén en forma de modelos de SQL, para actualizar los requisitos de los análisis no hace falta volver a desplegar la infraestructura de pipelines.

• Múltiples casos de uso descendentes: con los datos en bruto de un almacén, se pueden nutrir al mismo tiempo un Dashboard de inteligencia empresarial, un almacén de funcionalidades de machine learning y un informe de operaciones. Puedes crear un único pipeline y modelar los datos de manera distinta en función de cada usuario.

• Equipos con capacidades de ingeniería analítica: en un proceso de ELT, la propiedad de la transformación se traspasa a la capa de análisis. Los equipos que utilizan herramientas como dbt están muy preparados para ello.

Un proceso de ELT no es la respuesta adecuada en las siguientes circunstancias:

• Restricciones regulatorias sobre los datos en bruto: en el entorno de la atención médica y los datos financieros, no está permitido aterrizar datos confidenciales antes de ocultarlos o filtrarlos. En estos casos, las transformaciones se deben llevar a cabo de manera ascendente.

• Esquemas de destino rígidos: si en tu destino no se pueden ubicar datos en bruto o semiestructurados, el enfoque que se centra en la carga propio del proceso de ELT generará más problemas de los que soluciona.

• Conjuntos de datos pequeños y estables: si un pipeline sencillo de ETL hace el trabajo, el hecho de añadir infraestructura de transformación del almacén supone un gasto que no reportará demasiados beneficios.

¿Qué desafíos presenta el proceso de ELT?

Aterrizar datos en bruto en un almacén es eficaz, pero puede presentar desafíos en cuanto a la gobernanza y los costos.

Ten en cuenta los siguientes posibles desafíos de un proceso de ELT.

Control de accesos

A menudo, las tablas sin formato contienen datos a los que no debería poder acceder todo el mundo, como la información personal identificable (PII), registros financieros o identificadores internos. En ETL, los campos confidenciales se pueden ocultar o eliminar antes de que los datos lleguen al destino. Sin embargo, en ELT los datos llegan primero. Sin una seguridad a nivel de filas, ocultamiento de columnas ni roles de almacén estrictamente definidos, los analistas podrían consultar campos que no deberían poder ver.

Calidad de los datos

Los datos erróneos provenientes de fuentes previas llegan a tu almacén antes de que se ejecute ninguna comprobación. Los campos nulos, registros duplicados, cambios de esquema y discrepancias de tipo pueden propagarse a modelos posteriores si no incluyes pruebas de calidad en la capa de transformación con un framework de pruebas dbt o funcionalidades de calidad de los datos del propio almacén.

Gestión de los costos

Los trabajos de transformación se ejecutan en el procesamiento del almacén y el uso de código SQL mal redactado (como escaneos sin límites, falta de filtros de partición o actualizaciones redundantes de toda la tabla) puede generar costos muy altos. Es recomendable fijar desde el principio límites a los costos de las consultas, usar modelos incrementales siempre que sea posible y monitorear el consumo de procesamiento dentro del flujo de trabajo.

¿Cómo se procesan los datos de los pagos en un flujo de trabajo de ELT?

Hay muchos equipos que crean una integración personalizada para la API (del inglés «Application Programming Interface», interfaz de programación de aplicaciones) del proveedor de pagos, o utilizan conectores de terceros. No obstante, las integraciones personalizadas requieren un mantenimiento continuo debido a los posibles cambios en la API, y el uso de conectores de terceros implica enrutar datos financieros confidenciales a través de la infraestructura de otros proveedores.

El Stripe Data Pipeline es una opción nativa integrada directamente en el Dashboard de Stripe. Sincroniza datos e informes de Stripe a Snowflake, Databricks y Amazon Redshift, entre otros, con unos pocos clics. Funciona sin necesidad de programar, configurar conectores ni gestionar credenciales por separado. La sincronización se efectúa con la propia infraestructura de Stripe, de manera que tus datos financieros no transitan en ningún momento por sistemas de terceros.

Cuestiones específicas que vale la pena conocer:

• Cobertura del historial: en el Stripe Data Pipeline se incluyen datos del historial desde la apertura de tu cuenta de Stripe, no desde que habilitas la sincronización.

• Esquema: los datos se depositan en tablas que simulan el modelo de datos de Stripe (p. ej., cargos, clientes, suscripciones), lo que simplifica la creación de modelos de transformación sin tener que realizar una extensa labor de limpieza en la capa base.

• Completitud de los datos: además de los datos de los objetos en bruto, en el Stripe Data Pipeline se incluye el acceso a los informes financieros pregenerados y a los conjuntos de datos depurados. Esto puede acelerar los procesos de creación de informes y reducir las labores de transformación para los casos de uso más comunes, como los Ingresos Recurrentes Mensuales (MRR) y el análisis de fraude.