• Fabric Dataflows Gen2
  • adatátalakítás
  • önkiszolgáló ETL
  • Microsoft Fabric

A Rejtett Igazság az Excel Jelentések Generálásáról, Amit Minden Adatelemzőnek Tudnia Kell

A Fabric Dataflows Gen2 már formázott Excel-munkafüzetet ír (címsor, táblázat, diagram) egyenesen a lakehouse-ba. Mit jelent ez a havi zárásra?

6 perces olvasás

Tartalom6 szakasz
  1. Az Excel marad a kézbesítési formátum, akár tetszik, akár nem
  2. Hogyan működik az Excel-célhely
  3. Hogyan nézne ki ugyanez egy havi zárásnál
  4. Az AI-összefoglaló külön figyelmet érdemel
  5. Dataflows Gen2 vagy paginated report?
  6. Hol érdemes kezdeni

A Fabcon egyik gyakorlati szempontból leghasznosabb bejelentése nem került a főcímek közé: a Fabric Dataflows Gen2 mostantól Excel-fájlt is tud írni kimeneti célhelyként, méghozzá annyi kontrollal az elrendezés felett, hogy az eredmény egyszerű, formázott jelentés lehet, nem csupán nyers adatdump. A funkció egy, a Dataflows Gen2 újdonságait összefoglaló blogposzt közepén bújt meg, valószínűleg ezért kerülte el a legtöbbek figyelmét. Aki Fabricen futtat pénzügyi riportingot, annak ez megér tíz percet.

Az Excel marad a kézbesítési formátum, akár tetszik, akár nem

Az önkiszolgáló BI-programok hajlamosak a dashboardot tekinteni végállomásnak. A pénzügyes valóság mást mond: a havi zárási csomagot munkafüzetben jegyzetelik, az auditor olyan exportot kér, amit maga szűrhet, az egyeztetések során kibukó eltéréseket soronként, táblában dolgozzák fel, és mindig akad egy vezető, aki fájlt szeretne, nem linket. A „megkapnám Excelben?” kérés jellemzően túlél minden dashboard-kezdeményezést, ami elvileg kiváltotta volna. Amikor a Morgan Stanley-nél 50+ felhasználós, globális költségdashboardot építettem, a Power BI réteg tette a dolgát, de a körülötte lévő folyamat továbbra is havi 600+, PDF-ben és Excelben érkező számlát dolgozott fel; az Excel nem tűnt el sehová.

A bejelentés egy tágabb irányt is jelez, amit az eredeti írás külön kiemel: a Dataflows Gen2 már nem pusztán adatbetöltő eszköz, hanem teljes értékű önkiszolgáló ETL. Sokféle forrás, középen Power Query-transzformáció, célhelyek pedig a Fabricen belül és kívül egyaránt, beleértve a CSV-fájlokat, a Snowflake-et és immár az Excelt.

Hogyan működik az Excel-célhely

A mechanika kellemesen földhözragadt. A lekérdezéseket a megszokott módon építjük fel, majd a végére kerül egy záró lekérdezés, ami a dokumentáció által navigációs táblának nevezett szerkezetet adja vissza: soronként egy-egy munkafüzet-elemet. Minden sor megadja a cél-munkalapot, az elem nevét, a típusát (cellatartomány, formázott Excel-táblázat vagy diagram), egy tulajdonság-rekordot (kezdőcella, táblázatstílus és hasonlók), valamint magát az odakerülő adatot. Ezután a lekérdezés célhelyét új Excel-fájlra állítjuk egy lakehouse Files területén, és az advanced formátumopciót választjuk, így a Fabric a navigációs táblát használja a munkafüzet tervrajzaként. Frissítés, letöltés, kész. A célhely dokumentációja szokatlanul alapos.

A funkciót bemutató példa egy cellatartományba címsort tett, alá rövid, AI által generált összefoglalót, az alá formázott értékesítési táblázatot, végül a táblázathoz kötött oszlopdiagramot: apróság, de felismerhetően jelentés, nem adatdump.

Hogyan nézne ki ugyanez egy havi zárásnál

Pénzügyes nyelvre fordítva: képzeljünk el egy kontrollert, aki minden zárás után pillanatképet szeretne a terv-tény eltérésekről a lakehouse-ba írva, hogy aztán a zárási dokumentációhoz csatolhassa. A dokumentált formátumból átdolgozva és általánosítva (illusztráció, nem éles kód) a kimeneti lekérdezés valahogy így festene:

Power Query M
let
    // Soronként egy munkafüzet-elem
    workbook = #table(
        type table [
            Sheet = nullable text,
            Name = nullable text,
            PartType = nullable text,
            Properties = nullable record,
            Data = any
        ],
        {
            // Jelentés-fejléc fix cellába írva
            {"Zaras", "Fejlec", "Range",
                [StartCell = "B1", SkipHeader = true], ReportHeader},
            // Terv-tény eltérés költséghelyenként, formázott Excel-táblázatként
            {"Zaras", "VarianciaTabla", "Table",
                [StartCell = "B4", TableStyle = "TableStyleMedium2"],
                CostCentreVariance},
            // A fenti táblázathoz a nevén keresztül kötött diagram
            {"Zaras", "VarianciaDiagram", "Chart",
                [ChartType = "Column",
                 ChartTitle = "Eltérés a tervtől költséghelyenként",
                 DataSeries = [AxisColumns = {"CostCentre"},
                               ValueColumns = {"Variance"}]],
                #table({}, {}) meta [Name = "VarianciaTabla"]}
        }
    )
in
    workbook

A diagram sora az igazán figyelemre méltó részlet: saját adatot nem hordoz. Metaadaton keresztül a névvel hivatkozott táblázatra mutat, így a kész munkafüzetben a diagram abból a táblázatból dolgozik, amelyet a Fabric ír ki.

Az AI-összefoglaló külön figyelmet érdemel

Az eredeti példában szerepel egy lekérdezés, ami az adatot a FabricAI.Prompt M-függvénynek adja át, rövid szöveges összefoglalót kér, és az eredményt külön tartományként teszi a munkafüzetbe. Demónak ügyes. Pénzügyi dokumentumban viszont érdemes megállni egy pillanatra: a zárási csomag eltérés-kommentárja olyan állítás, amit valaki aláír, és egy LLM által írt bekezdés egy egyébként determinisztikus fájlban két különböző bizonyossági szintet kever össze. A Morgan Stanley-nél részt vettem egy cégszintű, pénzügyi dokumentumokon dolgozó RAG-rendszer tervezésében és tesztelésében, szóval nem a nyelvi modellek ellen érvelek; az a szerep viszont, amit kiérdemeltek, az emberi ellenőrzés mellett dolgozó asszisztensé, nem pedig a felügyelet nélküli szerzőé, aki a csapat nevében ír. A vázlat-összefoglalót nyugodtan generáltassuk, de menjen át emberen, mielőtt a munkafüzet a zárás hivatalos dokumentációjába kerül.

Dataflows Gen2 vagy paginated report?

Az írás maga is felteszi a kérdést, és őszintén „nem biztos”-sal válaszol, főleg most, hogy a Power Query a paginated reportokban is elérhető. Az értékelés röviden:

SzempontDataflows Gen2 Excel-célhelyPaginated report Excelként renderelve
ElkészítésNémileg kód-intenzív MNehezebb megépíteni (RDL), bár AI-jal generálható
Kontroll az Excel-kimenet felettTartományok, táblázatok, diagramok a navigációs táblával; nem teljes formátum-kontrollNehezebb befolyásolni, hogyan néz ki a renderelt fájl
Sima adatdumpMostantól valószínűleg a jobb opcióAz írás szerint nem ez az első választás
Egyszerű formázott jelentésMűködőképesMég mindig előnyben lehet
CU-költség és generálási időA forrás nyitva hagyja; mérni kellA forrás nyitva hagyja; mérni kell

Két tényezőt az írás kifejezetten eldöntetlenül hagy: a kapacitás- (CU-) költséget és azt, hogy a két megközelítésnek mennyi időbe telik legenerálnia egy fájlt. Mindkettő mérhető a saját tenantban, és egy havonta visszatérő zárási fájlnál mindkettő többet nyom a latban, mint a fejlesztői kényelem. A szabványosítás előtt érdemes lefuttatni az összehasonlítást.

Hol érdemes kezdeni

Ha a csapat ma kézzel exportál egy visszatérő munkafüzetet (egyeztetési kivonatot, vagy havi pillanatképet egy olyan vezetőnek, aki sosem fog dashboardot nyitni), az a jelölt. Építsük újra dataflow-ként Excel-célhellyel, és írjuk a lakehouse Files területére, hogy a fájl governance alá tartozó tárolóban éljen, frissítési előzményekkel, ne postafiókokban. Két fenntartás átöröklődik az írásból: a fájl formázása felett nincs teljes kontroll, és a megközelítés kód-intenzív, bár a szerző szerint AI-segítséggel kevesen fognak kézzel navigációs táblát írni.

A teljes, kidolgozott példa (az AI-generálta összefoglalóval és a diagram-definícióval együtt) Chris Webb Generating Excel reports with Fabric Dataflows Gen2 bejegyzésében található, a célhely dokumentációja pedig ennél is mélyebbre megy.

A címben ígért rejtett igazság kifejezetten prózai: a Fabcon egyik leghasznosabb Fabric-bejelentése egy olyan funkció, ami Excel-fájlokat ír.