Adatrögzítés és pillanatképek módosítása

Az adatmérnököknek gyakran kell adatokat replikálniuk az Azure Databricks előtti forrásokból, például relációs adatbázisokból (Oracle, Postgres, SQL Server), az Azure Databricksbe elemzési, jelentéskészítési és gépi tanulási célokra. Az operatív rendszerek változásakor az elemzési tábláknak szinkronizálva kell lenniük ezekkel a változásokkal.

Egyes csapatoknak tükrözniük kell a jelentéskészítéshez és elemzéshez használt operatív adatbázisok aktuális állapotát. Másoknak meg kell őrizni a változások teljes előzményeit az auditálás, a szabályozási követelmények vagy az ügyfélelemzés szempontjából.

A Változásadat-rögzítés (CDC) az adatbázist módosítások készleteként kezeli, nem pedig teljes statikus adatbázisként. Az alábbi diagram azt mutatja be, hogy amikor egy alkalmazotti adatokat tartalmazó forrástábla egyik sora frissül, egy új sorkészletet hoz létre egy CDC-hírcsatornában, amely csak a módosításokat tartalmazza. A CDC-hírcsatorna minden sora általában további metaadatokat tartalmaz, beleértve a műveletet, például UPDATE egy oszlopot, amely a CDC-hírcsatorna egyes sorainak determinisztikus sorrendbe rendeléséhez használható, hogy kezelni tudja a rendelésen kívüli frissítéseket. Az alábbi diagramon lévő sequenceNum oszlop meghatározza a CDC-hírcsatorna sorsorrendjét.

Az adatrögzítés áttekintésének módosítása.

A CDC lehetővé teszi az adatok módosításainak megtekintését az egyszerűbb tranzakciókhoz az adatbázis alsóbb rétegbeli rendszerbeli frissítésekor. Ez lehetővé teszi az adatbázis előzményeinek megtekintését is, ha ez követelmény.

A kihívást az jelenti, hogy a forrásrendszerek különböző formátumban szolgáltatnak adatokat. Egyes módosítások (beszúrások, frissítések, törlések) rögzítésére szolgáló változáscsatornákat bocsátanak ki. Mások csak a teljes táblázat időszakos pillanatképeit adják meg. Az alsóbb rétegbeli táblák pontos és naprakész állapotban tartásához minden formátumhoz különböző feldolgozási módszerek szükségesek.

A csapatok korábban egyéni MERGE INTO logikára támaszkodtak a módosítások alkalmazásához, akár változáscsatornákból, akár pillanatképek összehasonlításával. Ez a megközelítés összetett és hibákra hajlamos, staging táblákat, ablakfüggvényeket és szekvenálási feltételezéseket igényel, amelyeket nehéz megérteni és karbantartani, ahogy a folyamatok fejlődnek.

A CDC előnyei

Az adatrögzítés módosítása számos előnnyel jár a számítási feladatokban.

  • A változásadatok általában kisebbek, mint a teljes adathalmaz, és az alsóbb rétegbeli lekérdezések feldolgozhatják a módosításokat az adatok növekményes frissítéseként.
  • A módosítási adatok tárolhatók úgy, hogy lehetővé teszik a rekordok adott időpontban történő rekonstruálását, így teljes körű előzményt biztosíthat a naplózáshoz, az időponthoz kötött jelentéskészítéshez vagy a trendelemzéshez.
  • Az adatok módosítása lehetővé teszi, hogy a helyettes kulcsok idővel stabilak maradnak.

A módosítások alkalmazása: Aktuális állapot vagy a módosítások teljes előzményei

A lassan változó dimenziók (SCD) határozzák meg a felsőbb rétegbeli módosítások alkalmazását és modellezését, miután az elemzési táblákba kerülnek. A szervezetek az adatigények alapján különböző megközelítéseket használhatnak. Az 1. SCD-típus lehetővé teszi, hogy csak az adathalmaz aktuális állapotát mentse. A 2. SCD-típus menti az adathalmaz módosításainak teljes előzményeit. Ez a szakasz részletesebben ismerteti ezeket.

SCD 1. típus: Csak aktuális állapot

Az 1. típusú SCD felülírja a régi adatokat új adatokkal, amikor változások történnek, és csak az egyes rekordok legújabb verzióját őrzi meg. Az előzmények nem maradnak meg.

Az SCD 1. típusának használata a következő esetekben:

  • Csak az adatok aktuális állapotára van szüksége.
  • Azt szeretné, hogy az alsóbb rétegbeli materializált nézetek növekményesen frissüljenek a teljes újrafordítás helyett.
  • Stabil helyettesítő kulcsokra van szüksége az illesztésekhez.

Az SCD1-ben csak az adatok legújabb verziója érhető el. Ez egy egyszerű megközelítés, amellyel úgy gondolhatja, hogy csak a végső táblázatot tárolja. Ha egy rekord a Owner-ról Manager,-re változik, csak Manager marad a táblában:

Változáskövetés SCD 1. típus áttekintés.

SCD 2. típus: Előzménykövetés

A 2. típusú SCD teljes előzményrekordot tart fenn azáltal, hogy több adatverziót hoz létre az idő függvényében, minden alkalommal metaadatokkal. Az __START_AT és __END_AT az oszlopok határozzák meg a rekord egyes verzióira vonatkozó érvényességi időtartamot. Az aktív rekordok rendelkeznek __END_AT = NULL. Az adathalmaz állapotát bármikor megtekintheti.

Az SCD 2. típusának használata a következő esetekben:

  • Az auditálási vagy szabályozási követelmények előzménykövetést igényelnek.
  • Az ügyfélelemzéshez ismerni kell az entitások időbeli alakulását.
  • Az üzleti logikához időponthoz kötött jelentéskészítés szükséges.
  • Elemeznie kell a trendeket, vagy össze kell hasonlítania a korábbi állapotokat.

A 2. típusú SCD-feldolgozás megőrzi az adatváltozások előzményeit. Ha például egy rekordban jelenleg a szerepkör mező van beállítva Manager, azt is láthatja, hogy a szerepkör korábban Owner értékre volt beállítva. Az alábbi képen pontosan ez történt a rekorddal Chris. Meghatározhatja az aktuális rekordot, mert a mező null értéke end_at.

Változáskövetés SCD Type 2 áttekintése.

Mi az a CDC-hírcsatorna?

A Change Data Capture (CDC) egy adatintegrációs minta, amely rögzíti a forrásrendszer adatainak módosításait: beszúrásokat, frissítéseket és törléseket. A CDC a teljes adathalmazok feldolgozása helyett csak a módosított rekordokat tartalmazó hírcsatornákat hoz létre.

Ha például egy 50 sorból álló alkalmazotti táblával rendelkezik az Oracle-ben, és egy alkalmazott beosztása megváltozik, a CDC-hírcsatorna egyetlen UPDATE rekordot tartalmaz az adott alkalmazotthoz. Ez lehetővé teszi, hogy az Azure Databricks csak a módosított rekordokat dolgozza fel ahelyett, hogy minden futtatáskor beolvassa a teljes forrástáblát.

A forrásadatbázis minden CDC-rekordja a következőket tartalmazza:

  • A művelet típusa (INSERT, UPDATE, DELETE)
  • A rekord adatértékei
  • Sorszám vagy időbélyeg a determinisztikus rendezéshez

A sorszám biztosítja, hogy a késedelmes vagy a rendelésen kívüli érkezések megfelelően legyenek alkalmazva. A tranzakciós adatbázisok, például az SQL Server, a MySQL és az Oracle natív módon hoznak létre CDC-hírcsatornákat. A Delta-táblák saját CDC-hírcsatornát is létrehoznak, más néven változásadatcsatornát (CDF), így a Delta-források módosításainak feldolgozása is egyszerű.

Mi az a pillanatkép?

A pillanatképek egy tábla teljes állapotát jelölik egy adott időpontban. A csak módosításokat rögzítő CDC-hírcsatornákkal ellentétben a pillanatképek a forrástábla minden sorát tartalmazzák.

Csapatok különböző okokból nem mindig engedélyezik a CDC-hírcsatornákat az operatív adatbázisokon.

  • Költség (A CDC rendszer növelheti az éles adatbázisok terhelését)
  • A forrásadatbázis teljesítményproblémái
  • Örökölt rendszerek, amelyek nem támogatják a CDC-t
  • Szervezeti korlátozások (a betöltést kezelő csapatok nem birtokolják a felsőbb rétegbeli adatbázisokat)

Ha egy változáscsatorna nem érhető el, a pillanatkép-alapú betöltés az egyetlen lehetőség. A pillanatképek az alábbiakból származhatnak:

  • Időszakos exportálás relációs adatbázisokból (Oracle, Postgres, SQL Server)
  • Felhőalapú állománytárolási kiszűrések a feljebb lévő rendszerekből
  • Delta-táblák (az egyes táblaverziók gyakorlatilag pillanatképek)
  • OpenSharing felsőbb szintű bérlőktől

Mivel a pillanatképek nem rögzítik a rekordszintű változásokat, a módosítások azonosításához össze kell hasonlítani a rekordokat a pillanatképek között a beszúrások, frissítések és törlések következtetéséhez.

CDC-hírcsatornák automatikus feldolgozása

Az Azure Databricks leegyszerűsíti a CDC-feldolgozást a AUTO CDC API-n keresztül a Lakeflow-folyamatokon belül. Ez az API úgy lett kialakítva, hogy feldolgozhassa a CDC-hírcsatornák által közvetített módosításokat forrásadatbázisokon vagy Delta-táblákon, ahol engedélyezve van a Változásadatcsatorna.

Sql- és Python-példakódokért tekintse meg az AUTO CDC-példákat.

Akkor használja AUTO CDC , ha ezek közül bármelyik igaz:

  • A forrásrendszer létrehoz egy változásadatcsatornát (CDF)
  • Delta-táblából olvas, amelyen engedélyezve van az adatcsatorna módosítása
  • CDC-adatforrással rendelkezik egy relációs adatbázisból (például Debezium vagy Oracle GoldenGate)

AUTO CDC automatikusan kezeli a sorrenden kívüli rekordokat úgy, hogy az eseményeket a szekvenálási oszlop által meghatározott sorrendben dolgozza fel. A szekvenálási oszlopnak monoton módon növekvőnek kell lennie a megfelelő eseménysorrendnek, és minden egyes szekvenálási értéknél kulcsonként egy külön frissítésnek kell lennie. NULL a szekvenálási értékek nem támogatottak. Az SCD 2-es típus esetén a folyamat továbbítja a sorszámozási értékeket a céltábla __START_AT és __END_AT oszlopaiba.

Kezdeti hidratálás: Ha egy meglévő operatív adatbázistáblát replikál az Azure Databricksbe, először be kell töltenie az összes előzményadatot a folyamatban lévő módosítások feldolgozása előtt. AUTO CDC ezt az egyszeri folyamatokkal támogatja, amely egy olyan mód, amely az összes rendelkezésre álló adatot egyszer dolgozza fel, majd leáll. A kezdeti terhelés befejeződése után aktivált vagy folyamatos módú folyamatot használjon a folyamatos CDC-feldolgozáshoz. Ez egységes logikát biztosít a tömeges és növekményes terhelésekhez is.

Pillanatképek automatikus feldolgozása

Ha a CDC-hírcsatornák nem érhetők el, az Azure Databricks biztosítja az API-t AUTO CDC FROM SNAPSHOT . Ezt az API-t pillanatképalapú betöltéshez tervezték; összehasonlítja az egymást követő pillanatképeket, szintetikus változáscsatornát hoz létre, és SCD 1. vagy 2. típusú logikát alkalmaz a céltáblára. A céltábla képes CDC-hírcsatornát (más néven változásadatcsatornát (CDF) biztosítani a Delta-táblákban az 1-es vagy 2-es típusú SCD számára a további lekérdezésekhez.

A Python példakódokért tekintse meg az AUTO CDC FROM SNAPSHOT példákat.

AUTO CDC FROM SNAPSHOT csak a Python csővezeték-felületén támogatott. A pillanatképeket verzió szerint növekvő sorrendben kell feldolgozni; ha a rendszer elavult pillanatképet észlel, a rendszer figyelmen kívül hagyja. Az utófeldolgozás, mint például az adathalmaz kimenetét AUTO CDC FROM SNAPSHOT lekérdező materializált nézet, élvezi a CDC előnyeit, mint az inkrementálás képessége és a stabil helyettesítő kulcsok.

Note

AUTO CDC FROM SNAPSHOT nem csak a kezdeti betöltésekhez. Folyamatos feldolgozásra tervezték, ha a pillanatképek az egyetlen elérhető formátum. Minden alkalommal, amikor új pillanatkép érkezik, az API összehasonlítja azt az előző pillanatképpel, hogy megállapítsa a változásokat és változásadatfolyamot hozzon létre.

Használja a AUTO CDC FROM SNAPSHOT-t, amikor:

  • A CDC nincs engedélyezve a forrásadatbázisban
  • Csak időszakos pillanatképekhez (teljes táblaképekhez) férhet hozzá
  • Szeretné a CDC előnyeit kihasználni a növekményes feldolgozáshoz, vagy a változások teljes történetét rögzíteni.

AUTO CDC FROM SNAPSHOT automatikusan kezeli a következőket:

  1. Összehasonlítja az egymást követő pillanatképeket a beszúrt, frissített és törölt rekordok azonosításához.
  2. Szintetikus változáscsatornát hoz létre a pillanatképek közötti különbségek alapján.
  3. Ugyanazt az SCD-logikát alkalmazza, mint AUTO CDC az 1. vagy 2. típusú számítási SCD-hez.

Note

AUTO CDC FROM SNAPSHOT csak az egyik pillanatképről a másikra történő módosításokról tud, és nem kap köztes módosításokat. Ha például napi pillanatképeket kap, és egy felhasználó egy nap alatt kétszer módosítja a címét (az egyik címről A a másik címre B, majd B újabb címre C), előfordulhat, hogy a változáscsatorna közvetlenül A helyett C módosul, mivel csak az adott időpontokban készült pillanatképeket kapott.

Pillanatkép-feldolgozási minták

AUTO CDC FROM SNAPSHOT két mintát támogat a pillanatkép-verziók meghatározásához.

Pillanatkép-feldolgozás a csővezeték beviteli idejének használatával

A rendszer a pillanatképet a folyamat futtatásakor olvassa be, a betöltési időt pedig pillanatkép-verzióként használja a rendszer. Minden egyes folyamatfrissítés új pillanatképet ad meg. Ha egy folyamat folyamatos módban fut, a rendszer több pillanatképet is betölt a folyamat eseményindító időközi beállítása alapján.

Ezt a mintát akkor használja, amikor a pillanatképek rendszeresen és sorrendben érkeznek, és a folyamat futási időbélyegére támaszkodhat a verziószámozáshoz.

Pillanatkép-feldolgozás verziókhoz kapcsolódó függvényekkel

Megad egy függvényt, amely meghatározza, hogy a folyamat futtatásakor melyik pillanatkép-verziót kell feldolgozni. A függvény egy többértékűt ad vissza: (DataFrame, version_number). Az API a verziószámok által meghatározott sorrendben dolgozza fel a pillanatképeket. Ha a rendszer elavult pillanatképet észlel, a rendszer figyelmen kívül hagyja a pillanatképet.

Használja ezt a mintát a következő esetekben:

  • Egyszerre több pillanatkép is érkezhet, és szekvenciális feldolgozásra van szükség.
  • A pillanatképek nem sorrendben érkezhetnek.
  • Explicit módon szabályoznia kell a pillanatképek sorrendjét.

További CDC-képességek

Az automatikus CDC-célok műveleteinek módosítása

A szabványos streamelési táblákkal ellentétben a célobjektumként megadott Unity Catalog-táblák a folyamat futása közben is támogatják a AUTO CDC, INSERT, UPDATE, DELETE és MERGE utasításokat. Részletekért és korlátozásokért lásd: Adatok hozzáadása, módosítása vagy törlése egy célstreamelési táblában.

Az AUTO CDC célokból származó változási adatok olvasása

AUTO CDC A célstreamelési táblák saját Change Data Feedet (CDF) bocsáthatnak ki, így az alsóbb rétegbeli folyamatok felhasználhatják a AUTO CDC kimenet módosításait. Részletekért lásd: Változásadatcsatorna olvasása AUTO CDC céltáblából.

Változásadatfolyamok olvasása materializált nézetekből

A materializált nézetek saját Change Data Feed (CDF) kibocsátást adhatnak ki, így a lejtebb áramló fogyasztók feldolgozhatják a megjelenített nézetek módosításait, beleértve azokat az Azure Databricks-en kívül is replikálni. Ez a funkció bétaverzióban érhető el. Részletekért lásd: Olvasd a változásadatfolyamot a materializált nézetből.

Metrikák és monitorozás

AUTO CDC automatikusan rögzíti num_upserted_rows és num_deleted_rows metrikákat készít minden egyes folyamatfuttatáson. További részletekért tekintse meg a Speciális AUTOMATIKUS CDC-témaköröket.

2. SCD-típus oszlop-részhalmazainak nyomon követése

Alapértelmezés szerint az SCD 2. típusa új verziót hoz létre, amikor bármilyen oszlopérték megváltozik. AUTO CDC Lehetővé teszi az előzmények nyomon követésére szolgáló oszlopok megadását, hogy a nyomon nem követett oszlopok módosításai új előzményrekord létrehozása helyett az aktuális verziót frissítve frissüljenek. Ez csökkenti a tárolási költségeket és a lekérdezések összetettségét, miközben megőrzi a kritikus attribútumok előzményeit. Példaként lásd a SCD 2. típusú oszloprészhalmaz nyomon követése című dokumentumot.

Recommendations

A változásadat-rögzítést (CDC) akkor használja, ha csak az adatok módosításaival szeretne dolgozni, például az alsóbb rétegbeli materializált nézetek növekményes frissítésének engedélyezéséhez. Akkor is használja a CDC-t, ha meg szeretné őrizni az adatok módosításainak előzményeit, például annak megismeréséhez, hogy ki milyen szerepkörrel rendelkezett egy adott időpontban.

Az AUTO CDC API-kat akkor használja, ha a felsőbb rétegbeli adatokat az Azure Databricksbe kell replikálnia, és szinkronban kell tartania a forrásváltozásokkal. A megfelelő API attól függ, hogy a forrásrendszer hogyan teszi elérhetővé a változásokat:

  • Használja a AUTO CDC elemet, ha a forrás változási feedet bocsát ki, például egy CDC-vel engedélyezett relációs adatbázis (például Debezium vagy Oracle GoldenGate használatával), egy engedélyezett Change Data Feeddel rendelkező Delta-tábla, vagy bármely olyan forrás esetén, amely beszúrásokból, frissítésekből és törlésekből álló adatfolyamot állít elő egy szekvenálási oszloppal.
  • Használja AUTO CDC FROM SNAPSHOT, ha a forrás nem támogatja a CDC-t, és csak rendszeres, teljes táblamentéseket biztosít. Ez az API az egymást követő pillanatképek összehasonlításával és egy szintetikus változáscsatorna generálásával következtet a változásokra, így a natív CDC-hírcsatorna nélkül is ugyanazokat az SCD-feldolgozási előnyöket érheti el.

Mindkét esetben válassza az SCD 1. típusát, ha csak az egyes rekordok aktuális állapotára van szüksége, vagy ha meg kell őriznie a naplózási, időponthoz kötött jelentéskészítési vagy trendelemzési módosítások teljes előzményeit.

További források

  • Last updated on