5 tanulság a Microsoft Fabric konfigurálható adatmegőrzéséről

Eddig minden Fabric Warehouse pontosan 30 napnyi adattörténetet őrzött. Ugyanannyit kapott a sprintenként újrahúzott dev sandbox, a szabályozott riportingot kiszolgáló warehouse és a havi zárást tápláló éles környezet is, módosítási lehetőség nélkül. A Microsoft most ezt az ablakot konfigurálhatóvá tette, egyelőre preview-ban: a megőrzés warehouse-onként 1 és 120 nap között állítható, egyetlen T-SQL paranccsal, újraindítás és support ticket nélkül.

Papíron ez egy apró platformbeállítás. A gyakorlatban viszont ez a szám szabja meg, mit tud érted tenni a platform egy hiba után: az időutazó lekérdezések, a point-in-time klónok, a restore pointok és a warehouse snapshotok mind ezen az ablakon belül működnek. Öt szempont, amit érdemes végiggondolni, mielőtt hozzányúlsz.

Honnan van egyáltalán ez a történet

A Fabric Warehouse a Deltára épül, a Delta pedig soha nem írja felül a múltat. Az insertek, update-ek és delete-ek új Parquet-fájlokat fűznek az adathoz, és minden tranzakció commitként kerül be a Delta tranzakciós logba. Ez az állandó verziótörténet hajtja az időutazó lekérdezéseket, a point-in-time klónokat, a restore pointokat és a warehouse snapshotokat, anélkül hogy bármit duplikálna a tárhelyen. A restore pointok például nyolcóránként automatikusan létrejönnek, és számuk a beállított megőrzési időszakkal arányosan nő.

A retention-beállítás csak azt dönti el, milyen messzire ér vissza ez az emlékezet, és minden további ebből következik.

1. A retention helyreállítási kontroll, nem tárhely-beállítás

A bejelentés egy ismerős forgatókönyvvel indít: egy pipeline a hétvégén elromlik, csendben rossz adatot ír, a dashboardok pedig teljes magabiztossággal renderelnek tovább, amíg valakinek fel nem tűnik. Az időutazással ez többé nem forrásból-újratöltős tűzoltás, hanem egy lekérdezés a warehouse csütörtöki állapota ellen.

Ez pedig azt jelenti, hogy a retention-szám ugyanazt a bánásmódot érdemli, mint bármely más kontrollparaméter egy pénzügyi környezetben. Aki dolgozott már egyeztetési eltérés kivizsgálásán, tudja, hogy az első kérdés mindig az: hogyan nézett ki az adat aznap, amikor eltört. Napi 500 ezernél több settlement ügynöki és CSD-számlákkal szembeni egyeztetésére építettem kontrollokat, és ott is minden vizsgálat ezzel a kérdéssel indult; az határozza meg az egész munka menetét, hogy milyen gyorsan lehet rá válaszolni. A Microsoft saját ajánlása is ebbe az irányba mutat: ha release-ciklusban szállítasz transzformációkat, igazítsd a megőrzést a deployment-ablakhoz, hogy egy rossz pénteki release után pont akkora visszagörgetési mozgástered legyen, amekkora kell.

2. A csökkentés egyirányú utca

A megőrzési időszak csökkentése véglegesen törli az új ablakon kívül eső történetet. A Fabric menedzselt garbage collectora takarítja el, és ha utána visszaemeled a beállítást, semmi nem jön vissza: az új történet onnantól kezd gyűlni.

Ennek az aszimmetriának kell vezérelnie a change-folyamatot. Mivel a beállítás egyetlen T-SQL utasítás, bárki, akinek van hozzá joga, másodpercek alatt zsugoríthat egy 120 napos audit trailt egyetlen napra, és ezt semmilyen utólagos bánat nem hozza helyre. A Syngenta Fabric-környezetén végzett data governance munkámban a visszatérő kérdés ritkán az, hogy mi legyen egy beállítás értéke; sokkal inkább az, hogy ki változtathatja meg, és marad-e nyoma. A retention csökkentését ezért úgy kezeld, mint egy destruktív sémamigrációt, review-val és jóváhagyással előtte.

3. Warehouse-onként egy szám: a környezetek végre szétválhatnak

A régi, egységes 30 nap három különböző problémát gyömöszölt egyetlen beállításba: a fejlesztői csapatok olyan történetért fizettek, amit sosem használtak, a compliance nem kapta meg a szabályozók által elvárt hosszabb audit trailt, a mérnökök pedig nem tudták a release-ciklusukhoz igazítani az ablakot. A warehouse-onkénti konfiguráció ezt feloldja.

Egy mellékhatást érdemes tudni: mivel a restore pointok száma a megőrzéssel arányos, a hosszabb ablak több rendszer által létrehozott visszaállítási pontot is jelent, és a warehouse snapshotoknak is több történet áll rendelkezésére.

4. Mit old meg auditnál a 120 napos ablak, és mit nem

A pénzügyi bizonylatmegőrzést években mérik. A 120 napos időutazási ablak nem az a hely, ahol az aláírt beszámolók élnek, és hiba lenne irattárként prezentálni az auditornak.

Amit viszont megold, az az alatta lévő operatív réteg. Az időutazás stabil riportingot ad egy rögzített időbélyeg ellen, miközben a háttérben még futnak az ETL-pipeline-ok; pontosan az a hó végi zárási helyzet, amikor délelőtt menet közben mozdulnak el a számok a riport alatt. Az ablakot túlélni hivatott állapotokra pedig a bejelentés a point-in-time klónokat ajánlja: egy tábla adott pillanat szerinti klónozása könnyűsúlyú metaadat-művelet, gyakorlatilag tárhelyköltség nélkül, és a Microsoft kifejezetten historikus pillanatképek hosszabb távú megőrzésére is pozicionálja. Képzelj el egy kontrollert, aki minden hónap utolsó napján leklónozza a zárás mögötti néhány kulcstáblát. A „riportolt” állapot azután is lekérdezhető marad, hogy a retention-ablak rég túlgördült rajta, és ehhez senkinek nem kell egyetlen CSV-t sem exportálnia.

5. A data retention és a dropped retention két külön gomb

Könnyű összemosni őket, pedig szándékosan különálló képességek. A data retention azt szabályozza, meddig őrződnek az élő adat historikus verziói; a dropped retention pedig a türelmi idő arra az esetre, ha valaki magát a warehouse-t törli. Egy törölt warehouse alapból hét naptári napig marad meg, és ez 7 és 90 nap között állítható.

A bevezetési tanulság: mindkettőt tudatosan állítsd be. Egy 120 napos történet kevés vigasz, ha maga a warehouse egy véletlen törlés után egy héttel végleg eltűnhet; fordítva pedig a 90 napos dropped-ablak sem segít visszagörgetni egy rossz transzformációt egy élő, egészséges warehouse-ban. A teljes bejelentés, a Configurable Data Retention in Microsoft Fabric Warehouse (Preview) mindkét képességet végigveszi a Microsoft forgatókönyvenkénti ajánlásaival együtt, és érdemes elolvasni, mielőtt bármit szkriptelnél.

Hol érdemes kezdeni

Leltárral kezdj, ne szkripttel. Írd össze a warehouse-okat, sorold be őket (dev, teszt, éles, szabályozott), és osztályonként dönts az ablakról azokkal együtt, akik a helyreállítási és audit-követelményekért felelnek, ne csak a mérnökökkel. Rögzítsd, ki módosíthatja a beállítást, és hogyan naplózódik a változás. Ha pedig bizonytalan vagy, először a hosszabb irányba tévedj: a megőrzés kiterjesztése mindig biztonságos, a rövidítés az az irány, amit nem lehet visszacsinálni.

A funkció preview-ban van, és a bejelentés szerint ügyfél-visszajelzések nyomán készült. Ezúttal ez látszik is rajta: valódi korlátot old fel mindenkinél, aki vegyesen futtat dev- és szabályozott workloadokat Fabricon.