ETL o ELT en un equipo mediano, y cómo saber cuál necesitas
ELT es el consejo por defecto y no siempre acierta. Dónde encaja cada patrón, qué esconde la factura del warehouse y la restricción que decide por ti.
La respuesta moderna es ELT: carga el dato crudo en el data warehouse primero y transfórmalo ahí con SQL. El almacenamiento es barato, el cómputo es elástico, y la lógica de transformación en SQL es más fácil de revisar que un pipeline dentro de la herramienta de ETL de alguien.
Esa respuesta acierta lo bastante seguido como para ser un buen valor por defecto. No acierta siempre, y los casos donde falla son predecibles.
La diferencia que importa
Ambos patrones extraen de las fuentes y entregan datos analizables. La pregunta es dónde ocurre la transformación y qué se guarda por el camino.
ETL transforma antes de cargar. El warehouse recibe el dato ya moldeado. El dato crudo o no se retiene, o vive fuera del warehouse.
ELT carga crudo y después transforma dentro del warehouse, por capas. El dato crudo queda retenido, así que puedes reprocesar cuando una transformación resulta estar mal.
Esa última propiedad es por la que ELT ganó en analítica. Las transformaciones siempre acaban estando mal, y reprocesar desde el crudo retenido es mucho más barato que pedirle dos años de historia otra vez al sistema de origen.
| Restricción | Patrón | Por qué |
|---|---|---|
| Datos regulados que no pueden aterrizar crudos | ETL | Enmascarar o tokenizar antes de cargar es un requisito, no una preferencia |
| Analítica sobre datos de negocio, fuentes cooperativas | ELT | El crudo retenido abarata el reprocesamiento y hace recuperables los errores |
| La fuente solo exporta archivos por la noche | Cualquiera | La ventana de lote decide la frescura, no el patrón |
| Se exige frescura por debajo del minuto | Ninguno: streaming | Ambos patrones son de lote; forzarlos aquí produce un sistema frágil |
| El cuello de botella presupuestario es el warehouse | ETL | Transforma donde el cómputo cuesta menos que el del warehouse |
| La lógica de transformación cambia seguido | ELT | SQL versionado gana a reconfigurar una herramienta de pipeline |
La factura que nadie prevé
ELT mueve el costo de tiempo de ingeniería a cómputo de warehouse, y el cómputo de warehouse se mide.
El patrón que produce facturas sorpresa es directo: una capa de transformación que reconstruye todo desde el crudo en cada ejecución, programada cada hora, sobre una tabla que crece. Funciona bien el primer mes y cuesta dinero de verdad al sexto, sin que nada del código haya cambiado.
Tres hábitos lo mantienen bajo control:
- Modelos incrementales por defecto. La reconstrucción total debe ser una elección deliberada con una razón, no el valor por defecto que nadie revisó.
- Particiona y agrupa por lo que filtras. La mayor parte del costo de warehouse es escanear datos que la consulta no necesitaba.
- Atribuye costo por modelo. Si no ves qué transformación cuesta más, no puedes optimizar la que importa.
Dónde se atascan los equipos de verdad
En la práctica, ninguno de los dos patrones es la parte difícil. Otras tres cosas lo son.
Extracción de fuentes poco cooperativas. Una fuente sin API, sin captura de cambios y sin una columna fiable de actualización determina todo tu diseño. Vas a consultar y comparar, recibir archivos o leer una réplica. Ese es el trabajo real, y por eso a veces cabe una capa anticorrupción delante de la fuente.
Deriva de esquema. Alguien añade una columna, renombra otra o cambia un tipo aguas arriba. Sin pruebas de contrato en la fuente, esto aparece como un panel silenciosamente equivocado y no como un trabajo fallido.
Propiedad de la capa semántica. "Cliente activo" significa una cosa para finanzas y otra para ventas. Ese desacuerdo no lo resuelve ningún patrón; se resuelve nombrando un dueño para cada definición. Los pipelines que se saltan esto producen números todos defendibles y mutuamente inconsistentes.
Un valor por defecto razonable para un equipo mediano
Si nada de la tabla de restricciones fuerza tu mano:
- Carga crudo en el warehouse, retenido, particionado por fecha de ingesta.
- Transforma en SQL versionado, con capas que separen crudo, limpio y definiciones de negocio.
- Corre pruebas sobre las tablas de salida, no sobre el pipeline: unicidad, no nulo, integridad referencial, variación del conteo.
- Alerta por frescura, no solo por fallo. Un trabajo que dejó de correr en silencio se ve idéntico a uno sin datos nuevos.
- Enmascara o tokeniza los campos regulados en la ingesta, antes de que aterricen, que es donde esto se vuelve ETL para un subconjunto de columnas, discretamente.
Ese último punto es la respuesta práctica en la mayoría de los entornos regulados: ELT para el grueso de los datos, ETL para las columnas que no pueden aterrizar crudas. Cuáles son esas columnas, si manejas datos de salud, se deriva de las salvaguardas técnicas.
Si el "pipeline" que te proponen es en realidad un robot leyendo pantallas porque la fuente no tiene interfaz, la decisión es otra: mira RPA o integración por API.
Esto es el núcleo de nuestro trabajo de datos y operaciones con IA, y cómo tratamos el acceso a datos de cliente está en nuestras prácticas de seguridad.