Data integration and modeling
Documented caseEnterprise Data Platform
Data Warehouse migration from SAP Datasphere to Microsoft Fabric: integration from SAP HANA, Lakehouse and Warehouse layers, materialized tables, and models ready for Power BI.
A sanitized case based on real work at a retail company: designing the Lakehouse + Warehouse architecture in Microsoft Fabric and migrating the Data Warehouse from SAP Datasphere / BW Bridge in 3 months. Table and column names are anonymized.
Outcome: −83%processing time: the refresh of critical business reports went from 30 to 5 minutes.
- SAP HANA
- SQL
- Microsoft Fabric
- Power BI
Architecture
- SourceERP tables: documents, master data, and salesSAP HANA
- ExtractionSQL queries with explicit columns and date filtersFabric Pipelines
- StagingRaw data per load, append-onlyLakehouse
- WarehouseFacts, dimensions, and materialized tablesFabric Warehouse
- ConsumptionSemantic model and reportsPower BI
Modeling decisions
- Keep staging apart from the Warehouse: raw loads do not mix with business logic.
- Materialize consumption tables so heavy joins are not recomputed on every report query.
- Define the grain of each fact table before building measures in Power BI.
- Select explicit columns instead of SELECT * to reduce reads and transfer.
Load strategy and incrementality
- Classify tables by the freshness each one needs before changing its load strategy.
- Replace daily full loads with incremental extraction using a watermark on creation and change dates.
- Load the delta into staging (append) and run the MERGE as a separate step, over a small volume.
- Keep a periodic full reload to reconcile changes that do not update header dates.
Technical problems and solutions
- Problem
- A daily full load of a large document partner table took too long for an analytics layer that needs refreshing during the day.
- Solution
- Incremental extraction joined to the document header and filtered by creation or change date, with explicit columns and append-only staging.
Diagnosis and approach documented
- Problem
- An UPSERT over millions of rows is expensive even when few of them change.
- Solution
- Compute the delta first and MERGE only that set, optimizing the target Delta table by its business keys.
Approach documented
- Problem
- An incremental load based on header dates can miss changes that do not touch those dates.
- Solution
- A periodic full reconciliation alongside the daily incremental load.
Risk identified and mitigation defined
Code sample
-- 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);Case limits
- Table and column names are anonymized.
- No volumes or business data are published; the only timing shown is the report refresh improvement.
- The diagram summarizes the architecture; it does not show every object in the model.