Definición / Qué es
ETL (Extract, Transform, Load) es el patrón clásico para mover datos entre sistemas: primero se extrae información desde uno o varios orígenes (ERP, CRM, ficheros planos, APIs, bases de datos), después se transforma aplicando reglas de limpieza, normalización, deduplicación, cálculo de campos derivados y conversión de tipos, y finalmente se carga en el sistema destino, que típicamente es un data warehouse, un data lake o un cubo analítico. El término lo acuñó la comunidad de Business Intelligence en los años 70 con productos como Informatica PowerCenter, IBM DataStage o Microsoft DTS (antecesor de SSIS).
Hoy conviven dos variantes. El ETL tradicional transforma antes de cargar, lo que requiere un servidor de transformación intermedio (SSIS, Talend, Pentaho) y procesos batch nocturnos. El ELT moderno carga primero en bruto al data lake y transforma después usando la potencia del propio motor analítico (Snowflake, BigQuery, Synapse, Fabric, Databricks). El cambio se debe al abaratamiento del almacenamiento y al auge de motores SQL columnares masivamente paralelos: ya no merece la pena transformar antes de cargar.
La distinción importa porque condiciona la arquitectura: en ETL los errores de transformación se detectan antes de tocar el destino; en ELT se cargan datos sucios y se limpian después con vistas y modelos semánticos. Davisa, como Microsoft Solutions Partner BC desde 2003, ha vivido las tres generaciones —DTS, SSIS y ahora Fabric/Dataflows— en proyectos de cliente.
Por qué importa
Sin ETL, los datos viven en silos. El ERP tiene los pedidos, el CRM tiene las oportunidades, el e-commerce tiene el comportamiento web, el SAT tiene las incidencias y el GMAO tiene las averías. Cada uno responde preguntas parciales y nadie responde la pregunta interesante: ¿qué cliente compra más después de una incidencia bien resuelta? ¿Qué producto genera más mantenimiento correctivo respecto a su margen? La respuesta exige unir datos de cuatro fuentes, y eso es un pipeline ETL.
El segundo motivo es la calidad del dato. Los sistemas operativos están optimizados para transacciones, no para análisis: el mismo cliente puede aparecer con tres razones sociales, los códigos postales no están normalizados, los importes mezclan divisas, las fechas vienen en formatos distintos. Sin una capa de transformación que homogenice, los informes mienten. La regla del 80/20 en analítica dice que el 80% del esfuerzo de un proyecto BI se va en ETL; eso no ha cambiado con la nube.
El tercero es la trazabilidad y auditoría. Un buen pipeline ETL registra qué se extrajo, cuándo, con qué transformación, qué filas fallaron y por qué. Es la base para responder auditorías regulatorias (LOPDGDD, NIS2, normas sectoriales) y para reproducir cifras históricas cuando alguien pregunta “¿por qué este informe daba otro número hace seis meses?”.
Aplicación en Business Central
Business Central, al ser SaaS y multitenant, no permite el clásico “SSIS contra la base de datos SQL” que se hacía en NAV on-premise. Microsoft ofrece varios canales para construir ETL sobre BC:
- API REST y OData v4: la vía estándar para extraer datos de BC. Filtrado y paginación nativos. Es el canal que usan los conectores de Power BI, Power Query y Fabric.
- Dataverse Virtual Tables: BC se proyecta como tablas virtuales en Dataverse, permitiendo lecturas y escrituras desde Power Platform sin replicar datos.
- Synapse Link for Dataverse (y su evolución Fabric Link): replicación incremental de Dataverse —y por tanto de BC— en un data lake con formato Delta Parquet. Es la base recomendada para data warehousing moderno sobre BC, sin batch nocturnos y sin impactar el rendimiento del ERP.
- Power Query / Dataflows Gen2: capa de transformación visual, sin código, que orquesta la T de ETL y publica datasets reutilizables.
- Azure Data Factory: el orquestador empresarial cuando el pipeline cruza múltiples sistemas (BC + SAP + ficheros + APIs externas).
En proyectos de cliente de Davisa, el patrón más habitual es: BC → Fabric Link → Dataflows → semantic model → Power BI. La extensión dvdata-analysis preempaca este pipeline con catálogo de tablas críticas (ventas, compras, stock, contabilidad, partes de producción) y modelo semántico listo, para que el cliente no parta de cero.
Errores frecuentes
- Extraer todo, todas las noches. Replicar la base entera cada 24 h es lento, caro y rompe en cuanto el ERP crece. Lo correcto es CDC (Change Data Capture) o lectura incremental por
SystemModifiedAt. - Confundir ETL con copia. Cargar tablas tal cual sin transformación entrega los problemas de calidad del operativo al analítico. La T no es opcional.
- No versionar las transformaciones. Las reglas de negocio cambian (cómo se calcula el margen, qué cuenta entra en EBITDA, qué clientes son “activos”). Sin versionado, los informes históricos pierden comparabilidad.
- Ignorar la zona horaria. BC almacena en UTC. Si la transformación no convierte explícitamente a la zona del cliente, los informes de “ventas de ayer” cortan a las 02:00 locales.
- Saltar la capa de staging. Cargar directo a la tabla de hechos sin staging intermedio impide detectar inconsistencias antes de que contaminen el modelo.
- No medir frescura del dato. Un dashboard que muestra ayer las cifras de anteayer sin avisar genera decisiones equivocadas. Todo pipeline necesita un sensor de “última carga exitosa”.