ETL transforma los datos antes de cargarlos en el destino analítico; ELT los carga antes de realizar allí la transformación. Esa diferencia describe el orden del trabajo, pero no basta para decidir una arquitectura.
La elección práctica depende de qué datos pueden entrar en cada entorno, dónde se puede ejecutar la lógica y cómo se corregirá una carga equivocada. Un mismo proyecto puede combinar ambos patrones sin que eso sea una incoherencia.
Empieza por una restricción, no por una herramienta
Supongamos una empresa ficticia que necesita combinar pedidos, información de catálogo y solicitudes recibidas por un canal comercial. Los pedidos llegan de una base de datos, el catálogo se entrega en archivos y las solicitudes incluyen texto libre.
El equipo de BI necesita fechas, productos e importes; no necesita conservar el texto completo de las conversaciones en el almacén analítico. Cargar todos los campos por comodidad ampliaría el conjunto de datos al que hay que gestionar acceso y conservación.
En este caso, una transformación previa puede seleccionar los campos necesarios y separar el texto que no debe llegar al destino. Después de cargar, otras transformaciones pueden construir dimensiones y agregados reutilizables. La frontera se decide por cada dato y operación.
La guía de Microsoft sobre ETL y ELT explica que en ELT la transformación utiliza la capacidad del almacén de destino, mientras que ETL la realiza antes de la carga. Esa distinción técnica permite formular preguntas concretas sobre dónde ejecutar cada paso.
Una matriz para una reunión de arquitectura
| Pregunta | Favorece transformación antes de cargar | Favorece transformación en el destino |
|---|---|---|
| ¿Puede entrar el dato original en ese entorno? | Hay campos que deben eliminarse o transformarse previamente | La zona de entrada está autorizada y controlada |
| ¿La lógica necesita librerías especializadas? | Requiere un motor externo específico | Se expresa de forma mantenible con las capacidades del destino |
| ¿Se necesitan nuevas interpretaciones del origen? | Se conserva una copia recuperable en otro lugar | Una capa de entrada permite reconstruir varios modelos |
| ¿Qué capacidad existe durante la ventana de carga? | El destino tiene restricciones que aconsejan preparar fuera | El destino dispone de capacidad y controles para transformar |
| ¿Quién operará el proceso? | El equipo domina y mantiene el motor de integración | El equipo puede mantener modelos y pruebas en el almacén |
La matriz no asigna una puntuación universal. Una restricción de acceso puede descartar una opción aunque las otras filas la favorezcan. Documenta los criterios obligatorios antes de valorar conveniencia o rendimiento.
La capa de entrada también necesita un contrato
ELT no equivale a cargar sin controles. La entrada debe poder identificarse, reconciliarse y aislarse si es defectuosa. Un contrato de datos entre productor y consumidor permite acordar qué significa una entrega válida. En nuestro ejemplo, cada archivo de catálogo tendrá un identificador de lote, fecha de recepción y referencia a su versión.
Si se carga un catálogo incompleto, el sistema no debería presentarlo como una actualización válida de todos los productos. Hace falta conocer si el origen entrega una instantánea completa o un conjunto de cambios. Confundir ambos significados puede eliminar productos o duplicar estados.
También conviene distinguir entre conservar el dato original y permitir que cualquier usuario lo consulte. Una capa restringida de entrada puede alimentar modelos publicados con permisos distintos. Los controles deben comprobarse en los accesos reales, no solo en el nombre de las carpetas o esquemas.
Diseña la corrección antes de la primera ejecución
La pregunta decisiva suele ser: ¿qué ocurrirá si mañana descubrimos que una regla era incorrecta?
Si la transformación previa descartó información necesaria y no existe una copia recuperable, habrá que extraerla de nuevo del origen. Eso puede ser inviable si el sistema solo conserva el estado actual. Conservar todo indefinidamente tampoco es una respuesta automática: requiere propósito, permisos y una política de conservación.
En el ejemplo de pedidos, el equipo descubre que trató como euros un importe expresado en otra moneda. Para corregirlo necesita identificar los lotes afectados, la moneda original y la regla aplicada. Tener únicamente el total diario limita la reconstrucción.
Define qué insumos hacen falta para repetir la transformación, cómo se versionan las reglas y cómo se sustituye el resultado sin crear duplicados. Después ejecuta una corrección sobre una muestra y comprueba el informe que consume el dato.
No compares solo el tiempo de ejecución
Dos alternativas pueden completar la carga en una ventana aceptable y tener costes operativos muy distintos. Incluye extracción, almacenamiento intermedio, transformaciones, transferencia de datos, observabilidad y trabajo de mantenimiento.
En un diseño híbrido, presta especial atención a las transferencias entre entornos. Una transformación previa que produce archivos pequeños puede ser útil; varias idas y vueltas entre servicios pueden complicar la recuperación y la trazabilidad.
La decisión documentada debería indicar el patrón elegido por etapa, sus restricciones, la persona responsable y la prueba de aceptación. Evita concluir “ELT porque el destino es cloud”: la ubicación del servicio no resuelve por sí sola la política de acceso ni la calidad del modelo.
Para cerrar la evaluación, entrega un flujo de un lote realista desde su recepción hasta un indicador de negocio, incluyendo un dato inválido y una reejecución. Ese recorrido descubre más problemas que una comparación abstracta de siglas.
Si necesitas revisar una integración de datos o plataforma Big Data, contacta con Nexeus Big Data con las fuentes, ventanas de carga y restricciones conocidas. Son la base para elegir dónde debe ocurrir cada transformación.