Změna zachytávání a snímků dat

Datoví inženýři často potřebují replikovat data z nadřazených zdrojů Azure Databricks, jako jsou relační databáze (Oracle, Postgres, SQL Server), do Azure Databricks pro analýzy, vytváření sestav a strojové učení. Při změně operačních systémů musí analytické tabulky zůstat synchronizované s těmito změnami.

Některé týmy potřebují odrážet aktuální stav provozních databází pro sestavování a analýzu. Ostatní potřebují zachovat úplnou historii změn pro auditovatelnost, zákonné požadavky nebo analýzy zákazníků.

Zachytávání dat změn (CDC) považuje databázi za sadu změn, nikoli jako úplnou statickou databázi. Následující diagram ukazuje, že když se aktualizuje řádek ve zdrojové tabulce obsahující data zaměstnanců, vygeneruje novou sadu řádků v informačním kanálu CDC, který obsahuje pouze změny. Každý řádek informačního kanálu CDC obvykle obsahuje další metadata, včetně operace, jako je UPDATE a sloupec, který lze použít k deterministickému seřazení jednotlivých řádků v informačním kanálu CDC, abyste mohli zpracovávat aktualizace mimo pořadí. Například sequenceNum sloupec v následujícím diagramu určuje pořadí řádků v informačním kanálu CDC:

Přehled zachytávání změn dat

CDC umožňuje pouze zobrazit změny dat pro jednodušší transakce při aktualizaci databáze v podřízeného systému. Pokud je to požadavek, můžete také zobrazit historii databáze.

Problémem je, že zdrojové systémy poskytují data v různých formátech. Některé generují kanály změn, které zaznamenávají jednotlivé změny (vložení, aktualizace, odstranění). Ostatní poskytují pouze pravidelné snímky celé tabulky. Každý formát vyžaduje různé přístupy ke zpracování, aby podřízené tabulky byly přesné a aktuální.

Historicky týmy spoléhaly na vlastní logiku MERGE INTO pro aplikaci těchto změn, ať už z kanálů změn, nebo porovnáváním snímků. Tento přístup je složitý a náchylný k chybám, což vyžaduje pracovní tabulky, funkce oken a předpoklady pro sekvencování, které se obtížně zdůvodní a udržují při vývoji kanálů.

Výhody CDC

Zachytávání dat změn přináší několik výhod vašich úloh.

  • Data změn jsou obvykle menší než úplná datová sada a změny je možné zpracovat podřízenými dotazy jako přírůstkové aktualizace dat.
  • Data změn se dají ukládat způsobem, který vám umožní rekonstruovat záznamy v určitém okamžiku, abyste měli úplnou historii pro auditování, generování sestav k určitému bodu v čase nebo analýzu trendu.
  • Data změn umožňují stabilní náhradní klíče v průběhu času.

Jak se změny použijí: Aktuální stav nebo úplná historie změn

Pomalu se měnící dimenze (SCD) definují způsob použití a modelování nadřazených změn po jejich přechodu do analytických tabulek. Organizace můžou na základě potřeb svých dat používat různé přístupy. ScD Type 1 umožňuje uložit pouze aktuální stav datové sady. ScD Type 2 ukládá úplnou historii změn datové sady. Tato část je podrobněji popisuje.

SCD – typ 1: Pouze aktuální stav

ScD Type 1 přepíše stará data novými daty vždy, když dojde ke změnám a zachová jenom nejnovější verzi každého záznamu. Historie se nezachová.

Typ SCD 1 použijte, když:

  • Potřebujete jenom aktuální stav dat.
  • Chcete, aby se podřízená materializovaná zobrazení přírůstkově aktualizovala, a ne zcela znovu zkompilovat.
  • Pro spojení potřebujete stabilní náhradní klíče.

V SCD1 je k dispozici pouze nejnovější verze dat. Jedná se o jednoduchý přístup, který si můžete představit jako ukládání pouze konečné tabulky. Pokud se záznam změní z Owner na Manager,, pouze Manager zůstane v tabulce.

Přehled zachytávání dat změn typu SCD typu 1

SCD – typ 2: Historické sledování

SCD Type 2 udržuje úplný historický záznam tím, že vytváří více verzí dat v průběhu času, z nichž každá obsahuje časové razítko a metadata. Sloupce __START_AT a __END_AT definují dobu platnosti pro každou verzi záznamu. Aktivní záznamy mají __END_AT = NULL. Stav datové sady můžete zobrazit v libovolném okamžiku.

Typ SCD 2 použijte, když:

  • Auditovatelnost nebo zákonné požadavky vyžadují historické sledování.
  • Analýza zákazníků vyžaduje pochopení toho, jak se entity v průběhu času vyvíjely.
  • Obchodní logika vyžaduje generování sestav v daném okamžiku.
  • Potřebujete analyzovat trendy nebo porovnávat historické stavy.

Zpracování typu SCD 2 udržuje historický záznam o změnách dat. Pokud má například záznam aktuálně nastavené Managerpole role , můžete také vidět, že role byla dříve nastavena na Owner. Na následujícím obrázku je přesně to, co se stalo se záznamem pro Chris. Aktuální záznam můžete zjistit, protože pole null má hodnotu end_at.

Přehled zachytávání změn v datech SCD typ 2

Co je informační kanál CDC?

Change Data Capture (CDC) je model integrace dat, který zachycuje změny provedené v datech ve zdrojovém systému: vkládání, aktualizace a odstraňování. Místo zpracování celých datových sad generuje CDC kanály obsahující pouze upravené záznamy.

Pokud máte například tabulku zaměstnanců v Oracle s 50 řádky a změní se pracovní pozice jednoho zaměstnance, informační kanál CDC obsahuje jeden UPDATE záznam pro daného zaměstnance. Díky tomu může Azure Databricks zpracovávat pouze změněné záznamy, a ne číst celou zdrojovou tabulku při každém spuštění.

Každý záznam CDC ze zdrojové databáze zahrnuje:

  • Typ operace (INSERT, UPDATE, DELETE)
  • Hodnoty dat pro záznam
  • Pořadové číslo nebo časové razítko pro deterministické řazení

Pořadové číslo zajišťuje správné použití pozdních nebo zastaralých doručení. Transakční databáze, jako jsou SQL Server, MySQL a Oracle, generují nativně informační kanály CDC. Tabulky Delta také generují vlastní kanál CDC označovaný jako kanál CDF (Change Data Feed), což usnadňuje zpracování změn ze zdrojů Delta.

Co je snímek?

Snímek představuje úplný stav tabulky v určitém bodu v čase. Na rozdíl od informačních kanálů CDC, které zachycují pouze změny, obsahují snímky každý řádek ve zdrojové tabulce.

Týmy nepovolují informační kanály CDC v provozních databázích z různých důvodů:

  • Náklady (CDC může zvýšit zatížení produkčních databází)
  • Problémy s výkonem zdrojové databáze
  • Starší verze systémů, které nepodporují CDC
  • Organizační omezení (týmy spravující příjem dat nevlastní nadřazené databáze)

Pokud je kanál změn nedostupný, je jediným parametrem příjem dat založený na snímku. Snímky můžou pocházet z:

  • Pravidelné exporty z relačních databází (Oracle, Postgres, SQL Server)
  • Výpisy souborů z cloudového úložiště z vstupních systémů
  • Tabulky Delta (každá verze tabulky je efektivně snímek)
  • OpenSharing od nadřazených klientů

Vzhledem k tomu, že snímky nezachytávají změny na úrovni záznamu, identifikace změn vyžaduje porovnání záznamů mezi snímky, aby bylo možné odvodit vložení, aktualizace a odstranění.

Automatické zpracování zdrojů CDC

Azure Databricks zjednodušuje zpracování CDC prostřednictvím rozhraní AUTO CDC API v kanálech Lakeflow. Toto rozhraní API je navržené tak, aby zpracovával změny z informačních kanálů CDC ve zdrojových databázích nebo tabulkách Delta s povoleným datovým kanálem změn.

Ukázky kódu v jazycích SQL a Python najdete v příkladech AUTO CDC.

Použijte AUTO CDC , pokud je některá z těchto možností pravdivá:

  • Váš zdrojový systém vygeneruje datový kanál změn (CDF)
  • Čtete z tabulky Delta s povolenou funkcí Change Data Feed.
  • Máte informační kanál CDC z relační databáze (prostřednictvím nástrojů, jako je Debezium nebo Oracle GoldenGate).

AUTO CDC automaticky zpracovává záznamy mimo posloupnosti zpracováním událostí v pořadí definovaném sloupcem sekvencování. Sloupec sekvencování musí být monotonicky rostoucí reprezentací správného pořadí událostí, s jednou jedinečnou aktualizací pro klíč při každé hodnotě sekvencování. NULL Hodnoty sekvencování nejsou podporovány. Pro SCD Type 2 kanál šíří hodnoty sekvencování do __START_AT a __END_AT sloupců cílové tabulky.

Počáteční načítání: Při replikaci existující tabulky provozní databáze do Azure Databricks musíte nejprve načíst všechna historická data, než začnete zpracovávat probíhající změny. AUTO CDC podporuje prostřednictvím jednorázových toků, režim, který zpracovává všechna dostupná data jednou a poté se zastaví. Po dokončení počátečního načtení použijte spouštěný nebo kontinuální tok pro průběžné zpracování CDC. Tím je zajištěna konzistentní logika pro hromadné i přírůstkové načítání.

Automatické zpracování snímků

Pokud nejsou dostupné informační kanály CDC, Azure Databricks poskytuje rozhraní API AUTO CDC FROM SNAPSHOT. Toto rozhraní API je navržené pro příjem dat na základě snímků; porovná po sobě jdoucí snímky, vygeneruje syntetický kanál změn a použije logiku SCD Type 1 nebo Type 2 do cílové tabulky. Cílová tabulka může poskytovat informační kanál CDC (označovaný jako change data feed (CDF) v tabulkách Delta) buď SCD Typ 1 nebo Typ 2 pro podřízené dotazy.

Příklady kódu Python najdete v příkladech funkce AUTO CDC FROM SNAPSHOT.

AUTO CDC FROM SNAPSHOT se podporuje pouze v rozhraní Python pipeline. Snímky musí být zpracovány ve vzestupném pořadí podle verze; Pokud se zjistí snímek mimo pořadí, bude ignorován. Podřízené zpracování, jako je materializované zobrazení dotazující se na výstup AUTO CDC FROM SNAPSHOT datové sady, získává výhody CDC, jako je schopnost inkrementace a stabilní zástupné klíče.

Note

AUTO CDC FROM SNAPSHOT není určen pouze pro prvotní načítání. Je navržená pro průběžné zpracování, pokud jsou snímky jediným dostupným formátem. Pokaždé, když dorazí nový snímek, rozhraní API ho porovná s předchozím snímkem a vyvodí změny a datový tok změn.

Použít AUTO CDC FROM SNAPSHOT když:

  • CdC není ve zdrojové databázi povolená
  • Máte přístup jenom k pravidelným snímkům (úplné výpisy tabulky).
  • Chcete mít výhody CDC pro přírůstkové zpracování nebo mít úplnou historii změn.

AUTO CDC FROM SNAPSHOT zpracovává následující automaticky:

  1. Porovná po sobě jdoucí snímky a identifikuje vložené, aktualizované a odstraněné záznamy.
  2. Generuje syntetický kanál změn na základě rozdílů mezi snímky.
  3. Použije stejnou logiku SCD jako AUTO CDC pro výpočet typu SCD typu 1 nebo typu 2.

Note

AUTO CDC FROM SNAPSHOT ví pouze o změnách mezi jedním snímkem a dalším a nezískává průběžné změny. Pokud například získáte denní snímky a uživatel změní svou adresu dvakrát za jeden den (nejdříve z A na B a potom z B na C), váš kanál změn může přejít přímo z A do C, protože jste obdrželi snímky pouze pro tyto časy.

Vzory zpracování snímků

AUTO CDC FROM SNAPSHOT podporuje dva vzory pro určení verzí snímků.

Zpracování snímků s využitím času příjmu dat kanálu

Snímek se načte v době spuštění kanálu a čas příjmu dat se použije jako verze snímku. Při každé aktualizaci potrubí se ingestuje nový snímek. Při spuštění kanálu v průběžném režimu je zpracováváno více snímků na základě nastavení časového intervalu spuštění toku.

Tento vzor použijte, když snímky dorazí pravidelně a v pořadí a při správě verzí můžete spoléhat na časové razítko spuštění kanálu.

Zpracování snímků pomocí funkcí verzí

Zadáte funkci, která při spuštění kanálu určuje verzi snímku k zpracování. Funkce vrátí n-tici: (DataFrame, version_number). Rozhraní API zpracovává snímky v pořadí definovaném čísly verzí. Pokud se zjistí snímek mimo pořadí, snímek se ignoruje.

Tento model použijte v těchto případech:

  • Více snímků může dorazit najednou a vyžadovat sekvenční zpracování.
  • Snímky můžou přijít mimo pořadí.
  • Potřebujete explicitní kontrolu nad řazením snímků.

Další možnosti CDC

Operace změn v cílech AUTOMATICKÉho CDC

Na rozdíl od standardních streamovaných tabulek tabulky katalogu Unity, které jsou AUTO CDC cíli, podporují INSERT, UPDATE, DELETE, a MERGE příkazy i když je kanál spuštěn. Podrobnosti a omezení najdete v tématu Přidání, změna nebo odstranění dat v cílové streamovací tabulce.

Čtení datových kanálů změn z cílů AUTO CDC

AUTO CDC Cílové streamovací tabulky můžou generovat vlastní datový kanál změn (CDF), což umožňuje podřízeným kanálům využívat změny z výstupu AUTO CDC . Podrobnosti najdete v tématu Čtení datového kanálu změn z cílové tabulky AUTO CDC.

Metriky a monitorování

AUTO CDCměří a zaznamenává metriky num_upserted_rows automaticky při každém spuštění kanálu num_deleted_rows. Podrobnosti najdete v tématech Advanced AUTO CDC.

Sledování podmnožin sloupců pro Typ 2 SCD

Ve výchozím nastavení vytvoří SCD Type 2 novou verzi pokaždé, když se změní jakákoli hodnota sloupce. AUTO CDC umožňuje určit, které sloupce se mají sledovat pro historii, aby změny nesledovaných sloupců aktualizovaly aktuální verzi místo vytváření nového historického záznamu. To snižuje náklady na úložiště a složitost dotazů při zachování historie kritických atributů. Příklad najdete v tématu Sledovat podmnožinu sloupců pomocí SCD Type 2.

Recommendations

Zachytávání dat změn (CDC) použijte, pokud chcete pracovat jenom se změnami dat, například pokud chcete umožnit přírůstkovou aktualizaci podřízených materializovaných zobrazení. CdC použijte také v případě, že chcete zachovat historii změn dat, například zjistit, kdo měl v určitém časovém okamžiku jakou roli.

Pokud potřebujete replikovat nadřazená data do Azure Databricks a synchronizovat je se zdrojovými změnami, použijte rozhraní API automatického CDC. Správné rozhraní API závisí na tom, jak váš zdrojový systém zveřejňuje změny:

  • Použijte AUTO CDC, když váš zdroj generuje proud změn, například relační databáze s povoleným CDC (prostřednictvím nástrojů, jako jsou Debezium nebo Oracle GoldenGate), tabulka Delta s povolenou funkcí Change Data Feed nebo jakýkoli zdroj, který produkuje proud vložení, aktualizací a odstranění se sekvenčním sloupcem.
  • Použijte AUTO CDC FROM SNAPSHOT, pokud váš zdroj nepodporuje CDC a poskytuje pouze pravidelné úplné výpisy tabulek. Toto rozhraní API odvodí změny porovnáním po sobě jdoucích snímků a vygenerováním syntetického kanálu změn, takže získáte stejné výhody zpracování SCD i bez nativního kanálu CDC.

V obou případech zvolte typ SCD 1, pokud potřebujete jenom aktuální stav každého záznamu, nebo typ SCD 2, pokud potřebujete zachovat úplnou historii změn pro auditování, generování sestav k určitému bodu v čase nebo analýzu trendu.

Dodatečné zdroje

  • Last updated on