Si estás creando un pipeline de datos para proveer de datos a una herramienta de inteligencia de la empresa o entrenar a un modelo de machine learning, una de las primeras decisiones que debes tomar es dónde ocurre la transformación: antes de que los datos lleguen a tu almacén o después. Esto significa que tienes que elegir entre pipelines de extraer, transformar, cargar (ETL) y extraer, cargar, transformar (ELT).

La opción que elijas determinará la rapidez con la que los analistas puedan acceder a los datos sin procesar, cuánta capacidad de procesamiento estás gastando y dónde, y la facilidad con la que puedes adaptarte cuando cambia el modelo de datos. Se prevé que el mercado mundial de herramientas para pipelines de datos alcance los 48.330 millones de dólares en 2030, y ETL está perdiendo terreno frente a ELT y otros tipos de pipelines.

A continuación, repasaremos cómo funciona cada modelo, cuándo ETL o ELT tiene más sentido y cómo los conectores de propósito específico encajan en ambos enfoques para orígenes de datos concretos.

Destacados

• ETL transforma los datos antes de que lleguen al destino. ELT carga datos sin procesar y los transforma dentro del almacén usando su propia capacidad de procesamiento.

• ELT es el patrón predeterminado para la mayoría de los equipos de datos modernos. ETL sigue siendo popular para los destinos limitados, los requisitos de gobernanza estrictos y los pipelines heredados.

• Los conectores de propósito específico para orígenes de datos concretos pueden reducir el riesgo de que haya problemas de calidad en los datos que los conectores genéricos introducen en ocasiones.

Pipelines ETL frente a ELT: ¿cuál es la diferencia?

ETL significa «extraer, transformar, cargar». En un modelo ETL, haces un Pull de los datos de un sistema de origen, los ejecutas a través de una capa de transformación que los limpia, remodela y filtra, y luego cargas el resultado procesado en un destino, como un almacén de datos o mercado de datos.

Con ETL, un motor de procesamiento independiente hace el trabajo pesado antes de que los datos lleguen al destino. El almacén recibe datos estructurados que están listos para ser consultados en lugar de los registros de origen sin procesar. Volver a procesar desde el origen significa volver a extraer o mantener una copia sin procesar independiente en otro lugar.

ELT, que significa «extraer, cargar, transformar», invierte los dos últimos pasos. Los datos sin procesar llegan primero al destino y luego las transformaciones se ejecutan dentro del almacén usando su propia capacidad de procesamiento.

Ese cambio se hizo práctico cuando los almacenes de datos en la nube consiguieron que fuera barato y rápido ejecutar transformaciones en lenguaje de consulta estructurado (SQL) en grandes conjuntos de datos. En lugar de tener un motor de transformación independiente entre el origen y el destino, tu almacén es el entorno de transformación.

¿Cómo funciona ETL?

Un pipeline ETL se ejecuta en tres etapas, cada una con una responsabilidad distinta.

Así es como funciona ETL:

• Extraer: Un conector o trabajo de ingesta hace un Pull de los datos desde el origen, como una base de datos, una interfaz de programación de aplicaciones (API) de pagos, una plataforma de software como servicio (SaaS) o un archivo plano. Este paso gestiona la autenticación, la paginación, la lógica de actualizar de forma incremental frente a una completa y los límites de tasa.

• Transformar: Los datos extraídos pasan a una capa de procesamiento donde se limpian (p. ej., se gestionan los valores nulos, se convierten los tipos), se remodelan (p. ej., uniones, agregaciones, cambio de nombre de columnas), se filtran y, en ocasiones, se enriquecen con datos de referencia de otros orígenes.

• Cargar: El conjunto de datos procesado se carga en el destino como una sobrescritura completa, una inserción o actualización (upsert) o un anexo, dependiendo de cómo esté configurado el pipeline.

Aún tiene sentido usar ETL en estas situaciones específicas:

• Destinos restringidos: Los almacenes de datos más antiguos o los sistemas en las instalaciones con capacidad de procesamiento limitada no pueden ejecutar grandes transformaciones de manera eficiente en su lugar, por lo que cargar datos pretransformados es la única opción realista.

• Requisitos estrictos de gobernanza: Algunas organizaciones necesitan garantizar que la información de identificación personal o los datos financieros confidenciales nunca lleguen al almacén en formato sin procesar. Transformar y enmascarar en una etapa anterior cumple de forma arquitectónica ese requisito.

• Entornos perimetrales: El Internet de las cosas (IoT) y los sistemas integrados que hacen un Push de los datos a la infraestructura central a menudo no pueden enviar grandes cargas útiles sin procesar, lo que convierte a la transformación local antes de la transmisión en una necesidad práctica.

• Deuda heredada en pipelines: Muchas organizaciones consolidadas tienen pipelines ETL que se han ejecutado de forma fiable durante años. Reconstruirlos como ELT conlleva un riesgo que podría no merecer la pena correr.

¿Cómo funciona ELT?

Los pipelines ELT extraen y cargan datos de origen sin procesar o con un formato ligero directamente en el destino. Las transformaciones se ejecutan después, activadas de forma programada o bajo demanda, usando la capacidad de procesamiento del propio almacén.

Por ejemplo, un conector puede extraer datos de un origen y escribirlos en un esquema sin procesar en tu almacén. Un ingeniero de análisis escribe modelos de herramientas de compilación de datos (dbt) que leen de ese esquema sin procesar, aplican la lógica de la empresa y crean tablas limpias que las herramientas de inteligencia de la empresa (BI) pueden consultar. Cuando la lógica necesita cambiar, simplemente actualizan el modelo y lo vuelven a ejecutar en los datos que ya están allí.

ELT es una opción inteligente por estos motivos:

• Acceso más rápido a los datos sin procesar: Los datos llegan al almacén rápidamente, por lo que los equipos pueden empezar a explorarlos y validarlos antes de que termine la capa de transformación.

• Mejoras más baratas: Cambiar una transformación en ETL suele implicar modificar un pipeline, volver a procesar y volver a cargar. En ELT, solo tienes que actualizar un modelo SQL y volver a ejecutarlo con los datos que ya tienes.

• Capacidad de procesamiento a escala de almacén: Los almacenes en la nube se han diseñado para procesar grandes conjuntos de datos de forma rápida, lo que significa que estás aplicando una gran capacidad de procesamiento a la transformación en lugar de hacer crecer de forma independiente una capa de middleware separada.

• Historial sin procesar completo: Como los datos sin procesar siempre están en el almacén, puedes volver a derivar cualquier tabla descendente desde cero, lo cual es importante cuando cambian las definiciones de la empresa o cuando tienes que depurar un problema en la calidad de los datos.

¿Cómo elegir entre ETL y ELT?

Las grandes organizaciones suelen ejecutar ambos modelos de procesamiento de datos en paralelo para diferentes fuentes. Las necesidades de tu organización te ayudarán a decidir qué método es el más adecuado.

Esto es lo que debes tener en cuenta.

Volumen y velocidad de los datos

Los datos de gran volumen y alta frecuencia suelen favorecer un pipeline de datos ELT. Los almacenes en la nube los manejan bien, y el coste de ejecutar un motor de transformación potente al inicio del proceso crece rápidamente. Como contrapartida, la factura de computación de tu almacén aumenta cuando las transformaciones son complejas, y el almacenamiento de datos sin procesar conlleva costes.

Los pipelines de menor volumen con una lógica de transformación estable y bien definida podrían mantenerse en ETL sin muchos problemas.

Propiedad de la transformación

Si tus transformaciones se basan en SQL y son propiedad de ingenieros de análisis que necesitan adaptarse rápidamente, es probable que ELT con dbt o una herramienta similar sea la mejor opción.

Si tus transformaciones están codificadas en Python o Java, y son propiedad de un equipo de ingeniería de datos, es posible que ETL encaje de forma natural en tu cadena de herramientas actual.

Acceso a los datos sin procesar

Si los analistas necesitan acceder a los datos de origen sin procesar (p. ej., para exploraciones ad hoc, auditorías o porque la lógica de transformación aún está en desarrollo), ELT es la mejor opción por defecto. Los pipelines ETL que no conservan los datos sin procesar dificultan la readaptación de ese tipo de acceso.

Gobernanza y cumplimiento de la normativa

Si se deben enmascarar o anonimizar datos concretos antes de que lleguen a un destino compartido, ETL te ofrece una aplicación arquitectónica de ese requisito.

ELT puede satisfacer muchos de los mismos requisitos a través de la seguridad a nivel de columna y los controles de acceso a nivel de almacén, pero la implementación es diferente y vale la pena revisarla frente a tus obligaciones de cumplimiento de la normativa.

Flujo de trabajo del equipo

Un equipo con gran fluidez en SQL y hábitos de control de versiones con dbt extraerá más valor de una configuración ELT que de mantener un pipeline ETL personalizado que no ha creado. La compatibilidad con la forma de trabajar de tu equipo es un factor que se debe tener en cuenta.

¿Cómo encajan los conectores de datos en los pipelines ETL y ELT?

Las herramientas ETL y ELT genéricas gestionan una amplia gama de orígenes a través de conectores configurables. Esa amplitud es útil, pero tiene sus inconvenientes.

Los datos de pagos son un buen ejemplo. El modelo de datos de Stripe abarca eventos, cargos, rembolsos, disputas, transacciones de saldo, clientes, suscripciones y facturas. Un conector genérico que no se mantiene al día con las versiones de la API de Stripe o que gestiona la lógica de sincronización incremental de forma incorrecta puede producir errores que son difíciles de detectar hasta que afectan a un Dashboard o a una conciliación financiera.

Stripe Data Pipeline soluciona esto directamente:

• Creado y mantenido por Stripe: Dado que Stripe es el propietario del conector y refleja directamente la infraestructura interna de Stripe, puedes sincronizar datos de forma fiable de forma continua a la vez que garantizas su integridad y precisión, independientemente de la cantidad de datos que tengas y sin límites de tasa de API.

• Sincronización directa en el almacén: Los datos se mueven a Amazon Redshift, Snowflake, Databricks y más, sin utilizar una ruta a través de un conector externo, lo que mantiene los datos financieros confidenciales fuera de la infraestructura de otros proveedores.

• Conjunto de datos completo de Stripe: La sincronización abarca objetos de Stripe, informes financieros prediseñados y conjuntos de datos organizados para acelerar el análisis y la creación de informes.

• Configuración ligera: La conexión se configura en el Dashboard de Stripe, sin programación. Si ya estás ejecutando pipelines ELT para otros orígenes, los datos de Stripe adoptan el mismo patrón.