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

La elección determina la rapidez con la que los analistas pueden acceder a los datos sin procesar, cuántos recursos informáticos utilizas y dónde, y con qué facilidad puedes adaptarte cuando cambia tu modelo de datos. Se proyecta que el mercado de herramientas de canalización de datos a nivel mundial tendrá un valor de USD 48,330 millones para 2030, y el ETL está perdiendo terreno frente a ELT y otros tipos de canalizaciones.

A continuación, repasaremos cómo funciona cada modelo, cuándo el método ETL o ELT es más lógico, y cómo se adaptan los conectores diseñados a la medida en ambos enfoques para fuentes de datos específicas.

Aspectos destacados

• ETL transforma los datos antes de que lleguen al destino. ELT carga datos sin procesar y los transforma dentro del almacén utilizando sus propios recursos de computación.

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

• Los conectores diseñados para fuentes de datos específicas pueden reducir el riesgo de que haya problemas con la calidad de los datos que a veces presentan los conectores genéricos.

Canalizaciones ETL y ELT: ¿cuál es la diferencia?

ETL significa «extraer, transformar, cargar». En un modelo ETL, extraes datos de un sistema de origen, los pasas a través de una capa de transformación que los limpia, reestructura 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. Reprocesar desde el origen significa volver a extraer o mantener una copia separada sin procesar en otro lugar.

ELT, que significa «extraer, cargar, transformar», invierte los dos últimos pasos. Los datos sin procesar llegan al destino primero y luego las transformaciones se ejecutan dentro del almacén utilizando sus propios recursos informáticos.

Ese cambio se volvió práctico cuando los almacenes de datos en la nube hicieron que fuera económico y rápido ejecutar transformaciones en el Lenguaje de Consulta Estructurado (SQL) en grandes conjuntos de datos. En lugar de un motor de transformación independiente ubicado entre el origen y el destino, tu almacén es el entorno de transformación.

¿Cómo funciona ETL?

Una canalización ETL se ejecuta en tres etapas, cada una con una responsabilidad diferente.

Así es como funciona ETL:

• Extraer: un conector o trabajo de ingesta extrae datos del 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 maneja la autenticación, la paginación, la lógica de actualización completa en contraposición a la incremental y los límites de tasa.

• Transformar: los datos extraídos pasan a una capa de procesamiento en la que se depuran (p. ej., control de nulos, tipos de conversión), se reestructuran (p. ej., uniones, agregaciones, cambio de nombre de columnas), se filtran y, a veces, se enriquecen con datos de referencia de otras fuentes.

• Cargar: el conjunto de datos procesado se carga en el destino como una sobrescritura completa, un upsert o un anexo, dependiendo de cómo se haya configurado la canalización.

Todavía tiene sentido usar ETL en estas situaciones específicas:

• Destinos limitados: los almacenes de datos más antiguos o los sistemas en las instalaciones con recursos de computación limitados no pueden ejecutar de manera eficiente grandes transformaciones in situ, por lo que cargar datos previamente transformados es la única opción realista.

• Requisitos estrictos de control: algunas organizaciones deben asegurarse de que la información personal identificable o los datos financieros confidenciales nunca lleguen al almacén en formato sin procesar. La transformación y el enmascaramiento antes del almacén satisfacen ese requisito de la arquitectura.

• Entornos de perímetro: la internet de las cosas (IoT) y los sistemas integrados que envían datos a la infraestructura central a menudo no pueden enviar grandes cargas útiles sin procesar, lo que hace que la transformación local antes de la transmisión sea una necesidad práctica.

• Deuda de la canalización heredada: muchas organizaciones consolidadas tienen canalizaciones ETL que han funcionado de manera confiable durante años. Reconstruirlas como ELT conlleva un riesgo que podría no valer la pena asumir.

¿Cómo funciona ELT?

Las canalizaciones ELT extraen y cargan datos de origen sin procesar o con un formato ligero directamente en el destino. Las transformaciones se ejecutan después, se activan de forma programada o a pedido, utilizando los recursos informáticos del propio almacén.

Por ejemplo, un conector puede extraer datos de una fuente y escribirlos en un esquema sin procesar en tu almacén. Un ingeniero de análisis escribe modelos de herramientas de creación de datos (dbt) que leen desde ese esquema sin procesar, aplican la lógica empresarial y crean tablas depuradas que las herramientas de inteligencia empresarial (BI) pueden consultar. Cuando la lógica necesita cambiar, simplemente actualizan el modelo y lo ejecutan nuevamente con los datos que ya están ahí.

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 comenzar a explorarlos y validarlos antes de que termine la capa de transformación.

• Mejoras más económicas: cambiar una transformación en ETL a menudo significa modificar una canalización, reprocesar y recargar. En ELT, simplemente actualizas un modelo SQL y lo ejecutas nuevamente con los datos que ya tienes.

• Computación a escala de almacén: los almacenes en la nube están diseñados para procesar grandes conjuntos de datos rápidamente, lo que significa que estás aplicando una computación importante a la transformación en lugar de aumentar una capa de middleware independiente.

• Historial completo sin procesar: como los datos sin procesar siempre están en el almacén, puedes derivar cualquier tabla posterior desde cero nuevamente, lo que importa cuando las definiciones empresariales cambian o cuando tienes que depurar un problema de calidad de datos.

¿Cómo elegir entre ETL y ELT?

Por lo general, las grandes organizaciones ejecutan 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 adecuado.

A continuación, te indicamos lo que debes tener en cuenta.

Volumen y velocidad de los datos

Los datos de alto volumen y alta frecuencia generalmente favorecen un canal de datos ELT. Los almacenes en la nube lo manejan bien, y el costo de ejecutar un motor de transformación pesado en las primeras fases crece rápidamente. Como contrapartida, la factura de procesamiento de tu almacén aumenta cuando las transformaciones son pesadas, y almacenar datos sin procesar conlleva costos.

Los canales 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 existente.

Acceso a datos sin procesar

Si los analistas necesitan acceso a los datos de origen sin procesar (p. ej., para exploración ad hoc, auditoría o porque la lógica de transformación aún se está desarrollando), ELT es la mejor opción predeterminada. Los canales de ETL que no conservan los datos sin procesar hacen que ese tipo de acceso sea difícil de readaptar.

Gobernanza y cumplimiento de la normativa

Si se deben enmascarar o anonimizar datos específicos antes de que lleguen a un destino compartido, ETL te brinda la aplicación arquitectónica de ese requisito.

ELT puede cumplir 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 difiere y vale la pena revisarla en relación con 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 en torno a dbt extraerá más valor de una configuración ELT que de mantener un canal de ETL personalizado que no crearon. La compatibilidad con la forma de trabajar de tu equipo es un factor legítimo.

¿Cómo se adaptan los conectores de datos a las canalizaciones ETL y ELT?

Las herramientas genéricas de ETL y ELT manejan una amplia gama de fuentes mediante conectores configurables. Esa amplitud es útil, pero tiene sus ventajas y desventajas.

Los datos de Payments son un buen ejemplo. El modelo de datos de Stripe abarca eventos, cargos, reembolsos, disputas, transacciones de saldo, clientes, suscripciones y facturas. Un conector genérico que no sigue el ritmo de las versiones de la API de Stripe o que no maneja correctamente la lógica de sincronización incremental puede producir errores que son difíciles de detectar hasta que afectan a un Dashboard o a una conciliación financiera.

Stripe Data Pipeline aborda esto directamente:

• Creado y mantenido por Stripe: dado que Stripe es propietario del conector y refleja directamente la infraestructura interna de Stripe, puedes sincronizar los datos de manera confiable de forma continua y, al mismo tiempo, garantizar su integridad y precisión, independientemente de la cantidad de datos que tengas y sin límites de frecuencia de la API.

• Sincronización directa del almacén: los datos se mueven a Amazon Redshift, Snowflake, Databricks y más, sin enrutamiento a través de un conector de terceros, lo que mantiene los datos financieros confidenciales fuera de la infraestructura de otros proveedores.

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

• Configuración ligera: la conexión se configura en el Dashboard de Stripe y no requiere programación. Si ya ejecutas canalizaciones ELT para otras fuentes, los datos de Stripe adoptan el mismo patrón.