Graph in Fabric: amikor a kapcsolatok legyőzik a csillagsémát

Vegyünk egy konkrét kérdést a settlement-műveletek világából: beérkezik egy agent banki számla egy gyanús díjsorral, és valakinek vissza kell vezetnie a klíringláncon át azokig a trade-ekig, amelyek a költséget generálták. Trade-ből settlement-instrukció, abból agent, agentből CSD, CSD-ből számlasor. Dimenzionális modellben minden egyes ugrás egy join, jellemzően bridge táblán keresztül, és a lekérdezés, amely végigjárja őket, lassan fut és még lassabban debugolható. Az ilyen kérdés nem aggregációs, hanem útvonal-probléma, és a csillagsémát soha nem erre találták ki.

A Microsoftnak mostantól van rá first-party válasza: a Graph in Fabric ebben a hónapban, a Build 2026-os bejelentéshullám részeként vált általánosan elérhetővé, és natív gráfmotort tesz abba a platformba, ahol egyre több pénzügyi adat amúgy is él.

Mi jelent meg pontosan

A Graph in Fabric egy gráfmotor, amely közvetlenül a OneLake-ben tárolt adatokon dolgozik: nem kell külön gráfadatbázist üzemeltetni, és nincs plusz adatmozgatás, amit szinkronban kellene tartani. Az architektúra elosztott és shardolt, több milliárd kapcsolatot tartalmazó gráfokra méretezve. A lekérdezések nyelve a GQL, a gráflekérdezések ISO/IEC 39075-ös szabványa, mintaillesztéssel, útvonal-bejárással és aggregációkkal, a Microsoft pedig külön kiemeli a hordozhatóságot a GQL-kompatibilis rendszerek között. Az NL2GQL réteg természetes nyelven is enged kérdezni, a motor pedig örökli a Fabric meglévő OneLake-governance-ét: ugyanaz az RBAC, lineage-követés és compliance vonatkozik rá, mint az adatvagyon többi részére.

A release egyben a Fabric IQ végrehajtó rétege is. A nyers gráf fölött ül az Ontology, ahol közös üzleti szókincset (entitásokat, szabályokat, megkötéseket) lehet definiálni, így az AI-ügynökök egy explicit módon modellezett üzleti képet kérdeznek le, nem táblanevekből találgatják a struktúrát.

Hol fogy el a csillagséma

A dimenzionális modellezés kiérdemelte a helyét, és ezen ez a release sem változtat. Költségek szeletelésére cost centerenként, budget-variancia számítására vagy egy szervezeti hierarchián való felgörgetésre továbbra is a csillagséma plusz DAX a jó eszköz. Egy aktivitásalapú költségallokációs modellnek, amely a settlement-költségeket trading-aktivitás szerint osztja szét cost centerekre, semmire nincs szüksége abból, amit egy gráfmotor kínál.

A gond ott kezdődik, amikor a kérdés nem az összegzésről szól, hanem arról, hogy mi mivel függ össze. A rekonsziliáció ezt látványosan megmutatja: a platform, amelyen a Morgan Stanley-nél dolgoztam, napi 500K+ settlementet egyeztetett agent- és CSD-számlákkal, és bár maga az egyeztetés táblás műfaj, egy break kivizsgálása sosem az. Az ember egy gyanús számlasorból indul, és visszafelé halad: melyik díjtétel, melyik agent könyvelte, melyik settlementhez, melyik trade-hez, milyen díjkonstrukció alatt. Minden ugrás egy self-join vagy egy bridge tábla, a mélység esetről esetre változik, az SQL pedig előre megköveteli, hogy rögzítsük az ugrások számát, mielőtt egyáltalán feltehetnénk a kérdést. Ugyanilyen alakú az intercompany-folyamatok feltérképezése, a duplikált szállítói hálózatok keresése az accounts payable-ben vagy egy lakehouse függőségi kérdései. Az adat a szó hétköznapi értelmében kapcsolati, csak a tárolási modell nem hajlandó ezt elismerni.

A gráfadatbázisok évek óta kezelik ezt a problémaosztályt. Az újdonság az, hogy most a platformon belül van egy, ugyanazon governance alatt, közvetlenül az adat mellett.

Mikor melyik modell nyer

A korrekt keret nem a gráf kontra csillagséma, hanem a gráf a csillagséma mellett. Egy hozzávetőleges döntési táblázat:

A bejelentés saját döntési forgatókönyvei ugyanebbe az irányba mutatnak: ellátási láncok, fraud-nyomozás, customer intelligence, valamint ontológiák mint az AI-ügynökök kapcsolati gerince.

Hogy néz ki egy útvonal-lekérdezés

A bejelentés fraud-példája ültethető át legjobban pénzügyes terepre: a nyomozó egy megjelölt számlából indul, és azt követi, hogyan mozog a pénz közvetítő számlákon át további intézményekig, így olyan mule-hálózatokat talál meg, amelyek tranzakciónként nézve láthatatlanok maradnának. Cseréljük ki a főneveket, és megkapjuk a settlement-költségek visszakövethetőségét. Egy ilyen lekérdezés váza GQL-ben (ismerős terep annak, aki írt már Cyphert):

// Illusztratív vázlat: a címkék és property-k a saját modelltől függenek
MATCH (line:InvoiceLine {invoice: 'AGT-2026-0412', row: 7})
      <-[:BILLED_AS]-(c:Charge)
      <-[:GENERATED*1..4]-(t:Trade)   // változó mélység: 1-4 ugrás
RETURN t.trade_id, t.cost_center, c.amount

A szintaxisnál fontosabb maga a primitív: a változó mélységű bejárás beépített képesség, nem rekurzív CTE-vel összerakott trükk, amelynél abban reménykedünk, hogy az optimalizáló együttműködik. Az NL2GQL egy szinttel feljebb céloz, de a messzebbre mutató részlet az, ahogyan a Microsoft az ügynök-hozzáférést keretezi: az ügynökök determinisztikus lekérdezéseket futtatnak explicit módon modellezett kapcsolatokon, nem valószínűségi alapon következtetik ki a struktúrát. Annak, akinek egy számot audit előtt kell megvédenie, egy visszanézhető útvonalú lekérdezés lényegesen jobb alap, mint egy hasonlósági pontszám.

A governance a csendes főhír

Egy külön gráfadatbázis felállításának szabályozott környezetben mindig volt rejtett ára: második biztonsági modell, második access-review ciklus, és lyuk a lineage-történetben. A Graph in Fabric ehelyett a OneLake governance-ét örökli, egyetlen biztonsági modellel az összes adat felett. A Syngentánál végzett Fabric-munkámban a mérnöki órák aránytalanul nagy része pont erre a rétegre megy el (row-level security, adatminőségi standardok, CI/CD a BI-eszközökre), úgyhogy egy motor, amely eleve ezen a perimeteren belül érkezik, okafogyottá teszi azt az ellenérvet, amely a gráfról szóló beszélgetéseket általában már az első héten lezárja.

A méretekre házon belülről érkezik a bizonyíték: a Sentinel a gráfmotorral modellezi a biztonsági függőségeket, több százmillió összekapcsolt entitáson következtet, és több ugráson át követi a blast radiust. Az identitás–tenant–policy lánc szerkezetileg nincs messze a trade–settlement–számla lánctól.

Mivel kezdenék

Értelmes pilotnak egy nyomozás-jellegű probléma való, nem egy riporting-újraépítés. Jelöltek a pénzügyi back office-ból: rekonsziliációs breakek visszakövetése a settlement-láncon, intercompany-folyamatok feltérképezése, szállítói hálózatok duplikátum-ellenőrzése az accounts payable-ben, vagy függőségelemzés egy lakehouse-ban refaktor előtt. A vezetői riporting maradjon a szemantikus modellen, ahová való, az NL2GQL korai kimenetét pedig úgy kezeljük, mint egy új elemző első lekérdezéseit: hasznos, de ellenőrizzük.

A teljes bejelentés, a Graph in Fabric (Generally Available), tutorialokat, dokumentációt, learning pathet és egy friss webinárt is linkel, ha valaki a gyakorlatban akarja kiértékelni.

Az általános elérhetőség itt leginkább engedély arra, hogy a témát komolyan vegyük. Sok pénzügyi csapat nézte meg a gráfképességeket previewban, és jutott arra a teljesen észszerű következtetésre, hogy a havi zárás infrastruktúrája nem fut preview-funkciókon. Ez a kifogás mostantól nem él; azt viszont, hogy a saját működésükben elég fájdalmasak-e az útvonal-jellegű kérdések egy pilothoz, csak ők tudják megítélni.