Tanulságok a Power BI-ban végzett harmadik féltől származó integrációs kezdeményezésekből

Vegyünk egy százalékos metrikát (egy margint, egy allokációs rátát, egy év/év varianciát), amelyet egy külső metrics store-ban definiáltak, és próbáljuk meg betölteni egy Import módú Power BI modellbe. A sorszintű értékek rendben lesznek. A részösszegek viszont nem, mert egy hányadost az alapadatok aggregálása után kell kiszámolni, előre kiszámolt értékekből pedig nem lehet helyes összesítést visszaszámolni. Nagyrészt ez az egy technikai tény magyarázza az álláspontot, amelyet a Microsoft most nyíltan kimondott: a Power BI front-endje nem fog rendesen együttműködni külső szemantikus modellekkel, és nincs is terv arra, hogy ez változzon.

Az állítás Chris Webbtől, a Microsoft Fabric CAT csapatának tagjától származik, aki azt írja, hogy a Power BI csapat az elmúlt évben az összes jelentős külső szemantikusmodell-gyártóval egyeztetett az integrációról, és hogy az akadályok tisztán technikaiak, nem versenystratégiai döntések. Akár szó szerint elhisszük ezt a keretezést, akár nem, a technikai részletek jelentik az igazi értéket: a poszt gyakorlatilag katalógusa a kipróbált integrációs megközelítéseknek és annak, hogy melyik miért bukott el. Aki pénzügyes csapatban végigült már egy „definiáld egyszer a metrikáidat, használd mindenhol” típusú pitchet, annak érdemes ezeket a hibamódokat még aláírás előtt megértenie.

Három integrációs út, és mi tört el

A Power BI megoldások túlnyomó többsége Import módú szemantikus modellre épül. Az adat bemásolódik a modellbe, amely a táblák közötti kapcsolatokat, a DAX-ban írt measure-öket és az oszlopok láthatósági szabályait is tartalmazza; a riportok aztán DAX-ban kérdezik le a modellt. Egy külső szemantikus modellnek valahol ebbe az architektúrába kell beilleszkednie, és a poszt szerint a gyártók három helyen próbálkoztak.

Úgy tenni, mintha Analysis Services lenne. A Power BI riportok az XMLA protokollon keresztül csatlakoznak a szemantikus modellekhez; így érik el a régebbi Azure Analysis Services és SQL Server Analysis Services modelleket is. Néhány gyártó implementálta az XMLA-támogatást, és azt mondta az ügyfeleinek, hogy a SQL Server Analysis Services connectorral csatlakozzanak. Webb verdiktje: egy pontig működik, de ezzel a connectorral olyasmihez csatlakozni, ami nem Analysis Services, nem támogatott és nem teljesen megbízható.

A metrics store kimenetének importálása. Ez a nyitó példa. Ha a Power BI már kiszámolt metrikákat importál (százalékos részesedéseket, time intelligence számításokat), nem tudja őket helyesen aggregálni, mert a legtöbb metrikát az alapadatok aggregálása után kell kiszámolni.

DirectQuery a metrics store felett. DirectQuery módban a Power BI modell nem tárol adatot, hanem igény szerint SQL lekérdezéseket generál. Ezt egy külső szemantikus modellre ültetni azt jelenti, hogy az egyik szemantikus modell a másik tetején ül, amit Webb architekturálisan értelmetlennek nevez, és a tünetek őt igazolják. A Power BI csillagsémát feltételez, és olyan SQL-t generál, amely dimenziótáblákat kapcsol ténytáblákhoz; nem minden külső modell támogat még ennyit sem. A Power BI azt is feltételezi, hogy a metrikák nála számolódnak, ami egyes gyártókat olyan workaroundokba kergetett, mint hogy az SQL SUM() függvény valójában ne szummázzon. A következmény: sosem lehetsz biztos abban, hogy egy külső modellben definiált metrika helyes részösszegeket és végösszegeket ad. A DirectQuery ráadásul általában lassabb és kevésbé költséghatékony, mint az Import vagy a Direct Lake mód. A poszt megjegyzi, hogy ez nem Power BI-sajátosság: egyetlen szemantikus modell sem működne jól úgy, hogy egy másik szemantikus modell a forrása.

(A Direct Lake, a harmadik tárolási mód, csak OneLake-ben tárolt vagy shortcuttal elérhető adattal működik, így itt nem játszik.)

Miért pont a pénzügynek fáj az aggregálási probléma

A pénzügyi metrikák aránytalanul nagy hányada nem additív. Margin-százalékok, allokációs ráták, terv-tény eltérési hányadosok, bármi, amiben time intelligence van: ezek csak arra a szeletre értelmezve jelentenek valamit, amelyet a felhasználó éppen néz.

Amikor a Morgan Stanley-nél a tevékenységalapú költségallokációt építettem (egy Power BI + DAX megoldást, amely a settlement költségeket trading aktivitás alapján osztotta szét költséghelyekre, régiókon és üzletágakon átívelően), gyakorlatilag minden szám, amely számított, lekérdezéskor kiértékelt ráta volt. Egy költséghely allokációs részesedése egy üzletágon belül nem összege, nem átlaga és nem is bármilyen egyszerű rollupja az alatta lévő részesedéseknek. Ha ezeket a rátákat tárolt sorokként materializáljuk, minden management riport minden részösszege csendben romlik el, ami lényegesen rosszabb, mint ha hangosan romlana.

Ezért nem tooling-ízlés kérdése, hogy hol élnek a metrikadefiníciók. Ezen múlik, hogy a végösszegeknek hinni lehet-e.

A támogatott út

Egy integrációs út Webb áldását is bírja: a külső szemantikus modellben definiált számítások szinkronizálása egy Power BI szemantikus modellbe, DAX-ban újraírva. Ez lehetséges és támogatott, partnerek (például a Tabular Editor csapata) már el is indultak ezen az úton, és a Microsoft az utóbbi időben sokat fektetett abba, hogy a szemantikus modellek programozott módosítása minél egyszerűbb legyen. A folytatás nehezen vitatható: a DAX jobban illik metrikadefinícióra, mint az SQL, lesznek metrikák, amelyek csak DAX-ban definiálhatók, és ha a metrikakatalógus egy részének úgyis a Power BI modellben kell élnie, a definíciók két rendszer közötti szétosztása önként vállalt komplexitás.

A fogyasztói oldal is nyitottabb, mint amit a „zárt kert” keretezés sugall. A poszt szerint a Power BI szemantikus modellek használhatók Excelből és Fabric paginated reportokból, Tableau-ból és más nem-Microsoft front-endekből, Fabricen belül SQL-ben lekérdezhetők, a Semantic Link libraryvel pedig Pandas DataFrame-be is kihúzhatók.

A lehetőségek egymás mellett

Szervezeti tanulság a záró bekezdésben

Webb záró diagnózisa az a rész, amelyet egy CFO elé tennék. Szerinte azok a szervezetek, amelyek már kiterjedten használnak Power BI-t, nagyrészt azért fontolgatnak külső szemantikus modellt, mert data engineering vagy adatbázis hátterű emberek (gyakran nem maguk a Power BI felhasználók) pusztán vizualizációs eszköznek látják a Power BI-t, és nem tudják, hogy a piac legérettebb, legszélesebb körben használt szemantikus modellje van benne, self-service és enterprise BI-ra egyaránt tervezve. A nagyságrend, amelyet idéz: havonta 35 millió felhasználó néz Power BI riportokat, és közben 20 millió szemantikus modellt kérdeznek le.

Ez egybevág azzal, amit a gyakorlatban látok. A Syngentánál a szemantikus modelleket governance alá vont, CI/CD-vel deployolt assetként kezelem egy Fabric lakehouse-on, row-level securityvel és adatminőségi standardokkal, mint bármely más éles rendszert. Ha egy csapat így dolgozik, a munkamegosztás magától beáll: az adat-előkészítés a lakehouse- és warehouse-rétegek dolga (ezen a szinten a Microsoft szorosan együttműködik a Databricksszel, a Snowflake-kel és a dbt-vel, ahogy a poszt is megjegyzi), az üzleti jelentéstartalom pedig a szemantikus modellé. A külső metrics store vonzereje jellemzően azoknál a csapatoknál jelentkezik, ahol a szemantikus modell még nem kapta meg ezt a mérnöki rangot.

Hol olvasd el az eredetit

A teljes írás, a Power BI and support for third-party semantic models, szokatlanul egyenes beszéd ahhoz képest, hogy a Microsofton belülről született; Webb 28 éve dolgozik Microsoft BI eszközökkel, és minden érve mögé odateszi az architekturális hátteret. Ha a felhasználóid a Power BI-on keresztül fogyasztják az adatot, a konklúziója egyben gyakorlati iránymutatás bármely pénzügyi BI környezetre: a metrikadefiníciók és az üzleti logika helye a Power BI szemantikus modell, nem egy külső metrics store, és az elmúlt év integrációs kísérletei erre a bizonyítékok.