Integración y modelado de datos
Caso documentadoEnterprise Data Platform
Migración del Data Warehouse desde SAP Datasphere hacia Microsoft Fabric: integración desde SAP HANA, capas Lakehouse y Warehouse, tablas materializadas y modelos listos para Power BI.
Caso sanitizado a partir de trabajo real en una empresa de retail: diseño de la arquitectura Lakehouse + Warehouse en Microsoft Fabric y migración del Data Warehouse desde SAP Datasphere / BW Bridge, en 3 meses. Los nombres de tablas y columnas están anonimizados.
Resultado: −83%en tiempo de procesamiento: la actualización de reportes críticos bajó de 30 a 5 minutos.
- SAP HANA
- SQL
- Microsoft Fabric
- Power BI
Arquitectura
- OrigenTablas del ERP: documentos, maestros y ventasSAP HANA
- ExtracciónConsultas SQL con columnas explícitas y filtros por fechaFabric Pipelines
- StagingDatos crudos por carga, en modo appendLakehouse
- WarehouseHechos, dimensiones y tablas materializadasFabric Warehouse
- ConsumoModelo semántico y reportesPower BI
Decisiones de modelado
- Separar staging de Warehouse: la carga cruda no se mezcla con la lógica de negocio.
- Materializar las tablas de consumo para no recalcular joins pesados en cada consulta del reporte.
- Definir el grano de cada tabla de hechos antes de construir medidas en Power BI.
- Seleccionar columnas explícitas en lugar de SELECT * para reducir lectura y transferencia.
Estrategia de carga e incrementalidad
- Clasificar las tablas según la frescura que necesita cada una antes de cambiar su estrategia de carga.
- Reemplazar cargas completas diarias por extracción incremental con marca de agua sobre las fechas de creación y modificación.
- Cargar el delta en staging (append) y aplicar el MERGE en un paso separado, sobre un volumen chico.
- Mantener una recarga completa periódica para reconciliar los cambios que no actualizan las fechas de cabecera.
Problemas técnicos y soluciones
- Problema
- Una carga diaria completa sobre una tabla grande de interlocutores de documentos tardaba demasiado para una capa analítica que necesita actualizarse durante el día.
- Solución
- Extracción incremental unida a la cabecera del documento y filtrada por fecha de creación o modificación, con columnas explícitas y staging en modo append.
Diagnóstico y enfoque documentados
- Problema
- Un UPSERT sobre millones de filas es costoso aunque cambien pocas.
- Solución
- Calcular primero el delta y aplicar el MERGE solo sobre ese conjunto, optimizando la tabla Delta de destino por sus claves de negocio.
Enfoque documentado
- Problema
- Un incremental basado en fechas de cabecera puede perder cambios que no modifican esas fechas.
- Solución
- Reconciliación completa periódica además del incremental diario.
Riesgo identificado y mitigación definida
Código de ejemplo
-- 1. Extract only documents created or changed since the last watermark
SELECT p.document_id, p.item_id, p.partner_role, p.customer_id
FROM erp.document_partners AS p
JOIN erp.document_headers AS h
ON h.document_id = p.document_id
WHERE p.partner_role IN ('SHIP_TO', 'BILL_TO')
AND (h.created_on >= :watermark OR h.changed_on >= :watermark);
-- 2. Apply the small delta to the warehouse table
MERGE INTO wh.document_partners AS t
USING stg.document_partners_delta AS s
ON t.document_id = s.document_id
AND t.item_id = s.item_id
AND t.partner_role = s.partner_role
WHEN MATCHED THEN UPDATE SET t.customer_id = s.customer_id
WHEN NOT MATCHED THEN
INSERT (document_id, item_id, partner_role, customer_id)
VALUES (s.document_id, s.item_id, s.partner_role, s.customer_id);Límites del caso
- Los nombres de tablas y columnas están anonimizados.
- No se publican volúmenes ni datos de negocio; el único tiempo publicado es la mejora en la actualización de reportes.
- El diagrama resume la arquitectura; no representa cada objeto del modelo.