Přechod na Microsoft Fabric: jak jsme postavili centralizovaný datový sklad pro celý reporting firmy
Když jsme v DataBrothers začali intenzivněji rozvíjet interní reporting, postupně se začal objevovat problém typický pro mnoho rychle rostoucích firem. Data existovala na více místech, reporty vznikaly nezávisle na sobě a transformační logika byla rozprostřená mezi Power BI reporty, SharePointy a Dataflows Gen1.
Řešení sice dlouhou dobu fungovalo, ale s rostoucím počtem datových zdrojů a business požadavků začalo být stále složitější na správu. Přidání nového reportu často znamenalo duplikaci logiky, debugging refreshů byl časově náročný a některé metriky začaly mít v různých reportech odlišné definice.
Ve stejné době přicházel Microsoft Fabric jako nová datová platforma, která slibovala sjednocení datového inženýrství, analytiky a reportingu do jednoho prostředí. Rozhodli jsme se proto projít stejnou transformační cestou, kterou dnes řeší řada našich klientů – navrhnout a postavit vlastní produkční datový sklad přímo na Microsoft Fabric.
Tento článek popisuje, proč jsme se do toho pustili, jakou cestou jsme šli, co nás překvapilo a kde jsme udělali chyby, které jsme museli napravit.
Výchozí stav: reporty napojené přímo na zdroje
Jako konzultační firma pracujeme s daty napříč celou firmou – finance, sales, marketing, delivery, HR. Jenže do určité doby neexistoval žádný centralizovaný základ. Power BI reporty byly napojeny přímo na zdrojové systémy: SharePoint listy, účetní systém Pohoda, Dataverse a další.
Takový přístup měl několik praktických dopadů:
- stejná business logika vznikala na více místech,
- reporty používaly rozdílné definice metrik,
- refresh dat byl obtížně debugovatelný,
- onboarding nových datových zdrojů byl pomalý,
- a správa prostředí byla stále složitější.
Tento stav je dobře známý každému, kdo BI řešení buduje déle než pár let. Je to přirozený výsledek organického růstu – každý report vznikal s dobrým záměrem, ale bez centrálního architektonického základu.
Spouštěč: Microsoft Fabric jako příležitost i závazek
Impulsem ke změně byl příchod Microsoft Fabric. Chtěli jsme platformu důkladně poznat na vlastním produkčním use case – nejen v rámci testovacího prostředí, ale opravdu na datech, která jsou pro fungování firmy zásadní. Teprve pak ji lze zodpovědně doporučovat a implementovat u klientů.
- standardizaci datových transformací,
- zjednodušení správy,
- lepší troubleshooting,
- škálovatelnost řešení,
- a možnost postupného rozvoje bez zásadních redesignů
Z pohledu businessu bylo důležité i to, aby migrace proběhla bez dopadu na dostupnost existujících Power BI reportů.
Architektura: dvě iterace, jedna lekce
Projekt začal poměrně ambiciózní architekturou. V PoC fázi jsme zvolili distribuovaný model – workspaces rozdělené podle domén a vrstev, několik Lakehouses a transformační logiku postavenou na PySpark noteboocích.
Tento přístup odpovídal tehdejším doporučením pro enterprise datové platformy. Postupem času se ale ukázalo, že pro náš objem dat a způsob práce přináší zbytečně vysokou komplexitu.
Správa více pracovních prostorů komplikovala debugging i deployment. PySpark přidával režii, která nedávala vzhledem k workloadu dostatečný smysl. A protože se Fabric v průběhu projektu velmi rychle vyvíjel, část původních architektonických rozhodnutí přestala být optimální.
Výsledkem byla druhá architektonická iterace.
Přešli jsme na konsolidovaný model s jedním centrálním workspacem, jedním hlavním Lakehousem a transformační logikou postavenou na Python noteboocích s knihovnou Polars.
Tato změna výrazně zjednodušila provoz i další rozvoj platformy.
Medallion architektura jako základ stability
Celé řešení bylo postavené na medallion architektuře:
- Bronze vrstva uchovává surová data ze zdrojových systémů,
- Silver vrstva zajišťuje standardizaci a čištění,
- Gold vrstva obsahuje business objekty a datové modely připravené pro reporting.
Tento přístup umožnil oddělit ingest dat od business logiky a zároveň vytvořit jednotné místo pro definice metrik a KPI.
Jedním z nejsložitějších témat projektu bylo právě rozhodování, které transformace ještě patří do silver vrstvy a které už mají být součástí business logiky v gold vrstvě. Tato rozhodnutí mají zásadní dopad na dlouhodobou udržitelnost analytiky a možnost dalšího rozšiřování řešení.
Rozsah a napojené zdroje
Výsledné řešení pokrývá 7 business domén – finance, sales, marketing, HR, delivery a další — s celkem 80 tabulkami a views. Napojeny jsou zdroje Dataverse, SharePoint, Pohoda, Clockify, LinkedIn, Google Analytics, Ecomail a bankovní účty. Desítky Dataflows Gen1 z různých workspaců nahradil jediný, verzovaný kód v přehledném workspace.
Projekt probíhal iterativně v několika navazujících fázích. Nejprve proběhl průzkum možností Microsoft Fabric a návrh počáteční architektury. Následovala PoC implementace, architektonické vyhodnocení a následný redesign finálního řešení.
Velkou část práce tvořilo sjednocování historicky vzniklých datových struktur, naming conventions a rozdílných datových typů mezi jednotlivými doménami.
V průběhu projektu se postupně onboardovaly další business oblasti a nové datové zdroje. Díky centralizované architektuře a standardizovanému frameworku už ale onboarding nových dat nepředstavoval samostatný mini-projekt jako dříve.
Výsledky: co se ve firmě skutečně změnilo
Po dokončení migrace přešly všechny Power BI reporty na centralizovanou datovou vrstvu. Každá business metrika má jediný zdroj pravdy v datovém skladu — rozcházející se výpočty napříč reporty zmizely.
Doba ladění chyb v datových tocích se zkrátila o 70 % díky plnému logování na úrovni pipeline kroků. Čas potřebný na přidání nových datových zdrojů nebo domén klesl o polovinu díky standardizovanému frameworku a metadatovému přístupu k pipeline konfiguraci. Správa se zjednodušila z desítek workspaců s Dataflows Gen1 na jeden přehledný workspace s verzovaným kódem.
“Prvotní architektonická analýza je u datového skladu naprosto klíčová. Rozhodnutí o vrstvách, technologiích a konvencích, která uděláte na začátku, budete nést po celou dobu životnosti řešení. My jsme to prošli dvakrát — a ta druhá verze stojí za to.” — Adam Poslední, Senior Consultant, DataBrothers
Co bylo nejtěžší
Zpětně je nejobtížnější část projektu stanovení cílové architektury v době, kdy se platforma teprve formuje a best practices se rychle mění. Fabric byl při startu projektu relativně nová platforma – rozhodnutí, která v jednom čtvrtletí vypadají správně, mohou být v dalším překonána novými možnostmi nebo doporučeními Microsoftu.
“Největší lekce? Architekturu nelze přeskočit. My jsme ji dělali dvakrát – a až ta druhá verze opravdu funguje tak, jak má. Dnes máme všechna firemní data na jednom místě, víme odkud pochází a můžeme jim věřit. A práce s nimi je konečně radost, ne detektivka.” – Adam Poslední, Senior Consultant, DataBrothers
Dalším skutečným problémem bylo správně rozhodnout, co patří do silver a co do gold vrstvy. Jde o otázku, která nemá jednoznačnou odpověď a kde se liší každé prostředí. Nakonec zásadní bylo i sjednocení dat z původních dataflows, která vznikala v různých obdobích s odlišnými konvencemi pojmenování sloupců a datovými typy.
Co bude dál?
DWH je živý projekt – architektura je hotová, ale požadavky na nové datové zdroje a výpočty jsou kontinuální. Do budoucna plánujeme rozvoj interního frameworku s pokročilejším logováním, monitoringem zdraví pipeline a governance nad datovými objekty.
Interní implementace Fabricu se pro nás zároveň stala velmi důležitou referenční zkušeností pro další klientské projekty. Řadu architektonických rozhodnutí, která jsme si ověřili na vlastním prostředí, dnes využíváme i při návrhu enterprise datových platforem u zákazníků.