Dataflow Gen2 benchmarkok: mit jelentenek valójában a Fabric számládon

Egy tömeges adatmásolási feladat, amely Dataflow Gen1-en 1 óra 42 percig futott, Gen2-n 7 perc 43 másodperc alatt végzett. Egy ELT-minta 2 óra 42 percről valamivel hat perc alá csökkent. Ezek a Microsoft saját számai egy benchmark-posztból, amelyet a Build 2026-os bejelentésekkel együtt publikáltak, és a fő állítás nagyságrendi javulás teljesítményben és költségben egyaránt. Az állítás teljesítményre vonatkozó felét könnyű leolvasni egy grafikonról. A költségre vonatkozó fele viszont alaposabb figyelmet érdemel, mert 2025 ősze óta a kettő úgy kapcsolódik össze, ahogy korábban nem.

A négy forgatókönyv egymás mellett

A Microsoft négy tipikus munkaterhelést mért össze, mindegyiknél más-más Gen2-képességet bekapcsolva, a futásidőt a Dataflow Gen1-hez hasonlítva:

Ha elosztjuk az időket, nagyjából 13-szoros, 1,6-szeres, 21-szeres és 28-szoros gyorsulás jön ki. Az eloszlás az igazán érdekes. A három látványos szorzó olyan forgatókönyvekből származik, ahol a nyereség architekturális: másolásra optimalizált betöltési backend, párhuzamos kiértékelés a fájlpartíciók fölött, vagy az adat egyszeri materializálása ahelyett, hogy minden downstream lekérdezés újraolvasná a forrást. Az az egy forgatókönyv, ahol a motornak ténylegesen át kell rágnia magát a nem foldolható transzformációs logikán, körülbelül egyharmaddal javul. Ez is valódi nyereség, a poszt a Modern Query Evaluation Service-nek tulajdonítja, amely kifejezetten a soronkénti műveleteket célozza, de megmutatja, hol van a plafon: ha egy dataflow a sűrű, soronkénti M-logika miatt lassú, érezhetően gyorsabb futásra számíts, ne hússzoros gyorsulásra.

Két fenntartás. Ezek gyártói benchmarkok, és a poszt futásidőket közöl, de sem adatmennyiségeket, sem az egyes futások CU-fogyasztását nem. A szorzókat kezeld iránymutatásként, amíg a saját workloadodon nem reprodukáltál valami hasonlót.

Miért jelent a gyorsabb futás mostantól kevesebb pénzt is

A Dataflow történetének nagy részében a sebesség és a költség két külön beszélgetés volt: a gyorsabb frissítésre kellemesebb volt várni, a számla pedig az volt, ami. A benchmark-poszt explicit módon összeköti a kettőt. A Microsoft 2025 szeptemberében, a FabCon Europe-on kiadott Dataflow Gen2 árazási javításai óta ugyanazok a nyereségek, amelyek a frissítési időt csökkentik, a workload CU-fogyasztását is csökkentik. Ha ugyanaz a transzformáció gyorsabban fut le Gen2 (CI/CD)-n, az a Gen1-hez képest kevesebbe is kerül, nem csak kevesebb várakozást jelent.

Megosztott Fabric-kapacitáson a hatás összeadódik. A hosszan futó dataflow-frissítések ugyanazokat a kapacitásegységeket foglalják, amelyekből a riportok, a notebookok és minden más workload is merít, és a gyakorlatban ritkán egyetlen drága job miatt lépnek a csapatok nagyobb F-SKU-ra; a hónapzárás körüli háttérfrissítések feltorlódása miatt szoktak, pontosan akkor, amikor a pénzügynek a riportoláshoz kellene a kapacitás. Ha egy két és fél órás ELT-ablak hat percre zsugorodik, az nemcsak a költségsoron látszik, hanem a hónap legszorosabb napjaiban szabadít fel kapacitást.

Négy kar, nem egy gyorsabb motor

A Gen2 szerkezeti újdonsága, hogy a teljesítmény már nem egyetlen gyorsabb motorból jön. A poszt ezt ki is mondja, és fokozatos megközelítést javasol ahelyett, hogy mindent egyszerre kapcsolnánk be:

• Először az alapértelmezések. A meglévő Power Query-logika átemelése Gen2 (CI/CD)-be alapbeállításokkal a legtöbb esetben már önmagában érdemi javulást hoz, nagyrészt a modern M-kiértékelő motornak köszönhetően.
• Modern Evaluator, ha maga a transzformációs munka a szűk keresztmetszet: nem vagy csak részben foldolható lekérdezések, soronkénti műveletek. Új Gen2 (CI/CD) elemekben alapból be van kapcsolva, és vissza lehet váltani a standard motorra, ha egy adott lekérdezés vagy connector gondot okoz.
• Fast Copy, ha a betöltési áteresztőképesség a korlát. Közvetlenül Lakehouse-célra tölt, és akkor működik a legjobban, ha a betöltés közbeni formálás könnyű marad (oszlopkiválasztás, átnevezés, típusváltás); a nehezebb transzformációk helye egy következő, a staged adatra hivatkozó lekérdezés.
• Partitioned compute (előzetes verzióban, Gen2 CI/CD-vel), ha a forrás particionálható, jellemzően sok fájl a Combine Files funkcióval egyesítve. A partíciókulcs-oszlopnak a lekérdezésben kell maradnia, hogy a motor párhuzamosítani tudjon.
• Staging, ha a betöltés és a transzformáció egyetlen lekérdezésen belül kezd versengeni: materializálj egyszer, hivatkozz rá downstream, és több kimenet épülhet ugyanarra az alapra.

Az ehhez szükséges készség egy BI-csapatnál ennek megfelelően tolódik el. Kevesebb idő megy az egyes lekérdezések finomhangolására, több arra, hogy felismerjük, a négy forgatókönyv közül melyikben vagyunk, és azt az egy kart húzzuk meg.

Hová esik ebben egy tipikus pénzügyi pipeline

Ha a forgatókönyveket egy közepes méretű pénzügyi csapat stackjére vetítjük, a megfeleltetés elég tiszta. A hónapzárási mappa, benne entitásonkénti főkönyvi kivonatokkal vagy bankfájlokkal, Combine Files-minta, vagyis partitioned compute-terület, amint a funkció kikerül az előzetesből. Egy teljes tranzakciótörténet vagy vendor master Lakehouse-ba landolása formálás előtt: Fast Copy plusz staging. A számlafeldolgozás pedig, a maga soronkénti értelmezésével és mezőszármaztatásával, pontosan az a transzformáció-nehéz, nem foldolható profil, amelyet a Modern Evaluator céloz, és pontosan az, ahol a benchmark a legkisebb szorzót mutatja.

Ennél az utolsó kategóriánál érdemes reálisra kalibrálni az elvárásokat. A Morgan Stanley-nél építettem egy globális költségdashboardot, amely 600+ havi, PDF-ben és Excelben érkező számla feldolgozását automatizálta, és az ilyen flow-k szinte teljes egészében soronkénti munkából állnak; semmi nem foldolódik, és kevés dolog párhuzamosítható szépen. Erre a problématípusra a benchmark nagyjából harmadával rövidebb futásidőt sugall. Ez is megéri, de egy egész éjjel futó jobból ettől még nem lesz kávészünet.

Governance szempontból még egy részlet számít: a fő funkciók a Dataflow Gen2 CI/CD-változatában érkeznek. Történetesen ez az a változat, amelyen egy pénzügyi adatplatformnak amúgy is lennie kellene; a saját lakehouse-munkám a Syngentánál pontosan azért futtat minden BI-assetet CI/CD-n keresztül, mert a riporting-infrastruktúrába történő deploy ugyanazt a fegyelmet igényli, mint bármi másba.

Mielőtt bármit migrálnál a Gen1-ről

A poszt ajánlása egyértelmű: a Dataflow Gen2 (CI/CD) Lakehouse-célra írva, rajta Power BI Direct Lake-kel a legjobb felállás, a Gen1 és a csak szemantikus modellre épülő architektúra pedig az, ahonnan érdemes továbblépni. Az évek alatt felhalmozott több tucat Gen1-dataflow-val dolgozó csapatoknak néhány gyakorlati megjegyzés árnyalja a képet. A partitioned compute még előzetes verzióban van. A Modern Evaluator alapból be van kapcsolva, de dokumentált visszaváltási lehetőséggel, ami arra utal, hogy bizonyos lekérdezéseknél és connectoroknál előfordulhatnak kompatibilitási problémák. A Fast Copy pedig könnyű, betöltés közbeni transzformációkat vár, így azokat a dataflow-kat, amelyek nehéz formálást kevernek a betöltési lépésbe, land-then-transform mintára kell átstrukturálni, hogy a teljes hasznot hozzák.

A teljes forgatókönyv-leírások és az árazási rész a Fabric Updates Blogon olvashatók: Benchmarking Dataflow Gen2: Faster data transformation at lower cost, a Gen2 árazási dokumentációjának linkjeivel együtt.

Mit kezdjünk ezzel a gyakorlatban

Állj ellen a tömeges migrációnak. Válassz egy-egy reprezentatív dataflow-t minden ténylegesen futtatott kategóriából: egy nagy másolást, egy formálás-nehéz flow-t, egy többfájlos egyesítést. Építsd újra őket Gen2 (CI/CD)-ben változatlan Power Query-logikával, és két dolgot hasonlíts a Gen1-es alapvonalhoz: a falióra szerinti frissítési időt és a frissítésenkénti CU-fogyasztást a kapacitásmetrikákból. Ha a számaid egybevágnak a Microsoftéival, a migráció melletti érvelés szinte összeáll magától, és lesz hozzá saját benchmarkod is. Ha nem, három dataflow-n derült ki, nem ötvenen.