Osvědčené postupy pro spolehlivost

Tento článek popisuje osvědčené postupy pro spolehlivost uspořádané podle principů architektury uvedených v následujících částech.

1. Návrh s ohledem na selhání

Použití datového formátu, který podporuje transakce ACID

Transakce ACID jsou důležitou funkcí pro zachování integrity a konzistence dat. Volba datového formátu, který podporuje transakce ACID, pomáhá vytvářet kanály, které jsou jednodušší a spolehlivější.

Delta Lake je opensourcová architektura úložiště, která poskytuje transakce ACID a také vynucování schématu, škálovatelné zpracování metadat a sjednocené zpracování streamovaných a dávkových dat. Delta Lake je plně kompatibilní s rozhraními Apache Spark API a je navržená pro úzkou integraci se strukturovaným streamováním, takže můžete snadno použít jednu kopii dat pro dávkové i streamovací operace a poskytovat přírůstkové zpracování ve velkém měřítku.

Použití odolného distribuovaného datového modulu pro všechny úlohy

Apache Spark, jako výpočetní modul Azure Databricks Lakehouse, je založený na odolném distribuovaném zpracování dat. Pokud interní úloha Sparku nevrátí výsledek podle očekávání, Apache Spark automaticky přeplánuje chybějící úlohy a pokračuje v provádění celé úlohy. To je užitečné pro selhání, které nesouvisí s kódem, jako je krátký problém se sítí nebo odvolaný Spot VM. Při práci s rozhraním SQL API a rozhraním Spark DataFrame API je tato odolnost integrovaná do jádra.

V Databricks Lakehouse Photon, nativní vektorizovaný modul zcela napsaný v jazyce C++, je vysoce výkonný výpočetní modul kompatibilní s rozhraními Apache Spark API.

Automatická záchrana neplatných nebo nekonformních dat

Neplatná nebo nekonformní data můžou způsobit chybové ukončení úloh, které spoléhají na vytvořený formát dat. Pro zvýšení end-to-end odolnosti celého procesu se doporučuje vyfiltrovat neplatná a nekonformní data při jejich zpracování. Podpora zachráněných dat zajišťuje, že během načítání nebo ETL nikdy neztratíte ani nezmeškáte data. Sloupec zachráněných dat obsahuje všechna data, která nebyla analyzována, a to buď proto, že v daném schématu chyběla, protože došlo k neshodě typů, nebo protože tělo sloupce v záznamu nebo souboru nebylo v tomto schématu shodné.

• Auto Loader Databricks:Auto Loader je ideální nástroj pro streamované zpracování souborů. Podporuje obnovená data pro JSON a CSV. Například pro JSON obsahuje sloupec s obnovenými daty veškerá data, která nebyla analyzována, pravděpodobně proto, že v daném schématu chyběla, došlo k nesouladu typu nebo nesouhlasil formát písmen ve sloupci. Sloupec zachráněných dat je součástí schématu vráceného Auto Loaderem jako _rescued_data standardně při odvození schématu.
• DLT: Další možností vytváření pracovních postupů pro odolnost je použití DLT s omezeními kvality. Podívejte se na Spravujte kvalitu dat podle očekávání datového toku. DlT ve výchozím nastavení podporuje tři režimy: uchovávání, odstraňování a selhání u neplatných záznamů. Chcete-li umístit do karantény identifikované neplatné záznamy, mohou být pravidla očekávání definována určitým způsobem, aby byly neplatné záznamy uloženy ("v karanténě") v jiné tabulce. Viz Neplatné záznamy v karanténě.

Konfigurace úloh pro automatické opakování a ukončení

Distribuované systémy jsou komplexní a selhání v jednom bodě se potenciálně může kaskádovitě přenést na celý systém.

• Úlohy Azure Databricks podporují zásady opakování pro úlohy, které určují, kdy a kolikrát se neúspěšná spuštění opakují. Viz Nastavení zásad opakování.
• Pro úkol můžete nakonfigurovat volitelné prahové hodnoty doby trvání, včetně očekávané doby dokončení úkolu a maximální doby dokončení úkolu.
• DLT také automatizuje zotavení po selhání pomocí eskalace opakování pro vyrovnávání rychlosti a spolehlivosti. Viz režimy vývoje a produkce.

Na druhou stranu, zaseknutý úkol může zabránit dokončení celé úlohy, což vede k vysokým nákladům. Úlohy Databricks podporují konfiguraci časového limitu pro ukončení úloh, které zabírají déle, než se čekalo.

Použití škálovatelného a produkčního modelu obsluhující infrastrukturu

Pro šaržové a streamové odvozování použijte úlohy Azure Databricks a MLflow k nasazení modelů jako UDFs Apache Spark, aby bylo možné využít plánování úloh, opakování, automatické škálování a další možnosti. Viz Nasazení modelů pro dávkové odvozování a predikce.

Obsluha modelů poskytuje škálovatelnou a produkční infrastrukturu pro obsluhu modelu v reálném čase. Zpracovává modely strojového učení pomocí MLflow a zveřejňuje je jako koncové body rozhraní REST API. Tato funkce využívá bezserverové výpočetní prostředky, což znamená, že koncové body a přidružené výpočetní prostředky se spravují a spouští v cloudovém účtu Azure Databricks.

Pokud je to možné, používejte spravované služby.

Využijte spravované služby (bezserverové výpočty) z platformy Databricks Data Intelligence, jako například:

• bezserverové sklady SQL
• obsluha modelu
• úlohy bez serveru
• výpočetní prostředí bez serveru pro poznámkové bloky
• DLT

Tyto služby provozuje Databricks spolehlivým a škálovatelným způsobem bez dalších nákladů, takže úlohy budou spolehlivější.

2. Správa kvality dat

Použití vrstvené architektury úložiště

Zpracovávat data vytvořením vrstvené architektury a zajištěním zvýšení kvality dat, jak data procházejí vrstvami. Běžným přístupem k vrstvení je:

• Nezpracovaná vrstva (bronzová): Zdrojová data se ingestují do jezera do první vrstvy a měly by se tam zachovat. Když se všechna podřízená data vytvoří z nezpracované vrstvy, je možné podle potřeby z této vrstvy znovu sestavit další vrstvy.
• Kurátorovaná vrstva (silver): Účelem druhé vrstvy je uchovávat vyčištěná, zpřesněná, filtrovaná a agregovaná data. Cílem této vrstvy je poskytnout solidní a spolehlivý základ pro analýzu a sestavování zpráv ve všech rolích a funkcích.
• Konečná vrstva (gold): Třetí vrstva je postavená na obchodních nebo projektových potřebách. Poskytuje jiné zobrazení jako datové produkty pro jiné obchodní jednotky nebo projekty, přípravu dat v oblasti potřeb zabezpečení (například anonymizovaných dat) nebo optimalizaci výkonu (například s předem agregovanými zobrazeními). Datové produkty v této vrstvě jsou považovány za pravdu pro podnikání.

Konečná vrstva by měla obsahovat pouze vysoce kvalitní data a být plně důvěryhodná z obchodní perspektivy.

Zlepšení integrity dat snížením redundance dat

Kopírování nebo duplikování dat vytváří redundanci dat a vede ke ztrátě integrity, ztrátě rodokmenu dat a často různým přístupovým oprávněním. To snižuje kvalitu dat v jezeře.

Dočasná nebo jednorázová kopie dat není sama o sobě škodlivá – někdy je nutné zvýšit flexibilitu, experimentování a inovace. Pokud se však tyto kopie stanou funkčními a pravidelně se používají k podnikatelským rozhodnutím, změní se na datové silosy. Když se tyto oddělené datové systémy dostanou mimo synchronizaci, má to významný negativní dopad na integritu a kvalitu dat, což vyvolává otázky, jako je například "Která datová sada je hlavní?" nebo "Je datová sada aktuální?

Aktivně spravovat schémata

Nepředvídatelné změny schématu můžou vést k neplatným datům a neúspěšným úlohám, které tyto datové sady používají. Azure Databricks má několik metod pro ověření a vynucování schématu:

• Delta Lake podporuje ověřování schématu a vynucení schématu tím, že automaticky zpracovává varianty schématu, aby se zabránilo vkládání chybných záznamů během příjmu dat. Viz vynucení schématu.
• Auto Loader zjistí přidání nových sloupců při zpracování vašich dat. Ve výchozím nastavení přidání nového sloupce způsobí zastavení vašich streamů s UnknownFieldException. Auto Loader podporuje několik režimů pro vývoj schématu .

Používejte omezení a očekávání dat

Tabulky Delta podporují standardní klauzule správy omezení SQL, které zajišťují automatickou kontrolu kvality a integrity dat přidaných do tabulky. Když dojde k porušení omezení, Delta Lake vyvolá chybu InvariantViolationException, která signalizují, že nová data není možné přidat. Viz Omezení v Azure Databricks.

Pro další zlepšení tohoto zpracování podporuje DLT očekávání: Očekávání definují omezení kvality dat pro obsah datové sady. Očekávání se skládá z popisu, invariantu a akce, kterou je třeba provést, pokud záznam porušuje invariant. Očekávání týkající se dotazů používají dekorátory Pythonu nebo klauzule omezení SQL. Podívejte se na Spravujte kvalitu dat podle očekávání datového toku.

Přístup založený na datech ke strojovému učení

Hlavní princip, který zůstává jádrem vize umělé inteligence pro platformu Databricks Data Intelligence, je přístup orientovaný na data k strojovému učení. S tím, jak se generující AI stává více, zůstává tato perspektiva stejně důležitá.

Základní komponenty libovolného projektu ML lze jednoduše považovat za datové kanály: příprava funkcí, trénování, nasazení modelu, odvozování a monitorování kanálů jsou všechny datové kanály. Zprovoznění řešení ML proto vyžaduje sloučení dat z předpovědí, monitorování a tabulek funkcí s dalšími relevantními daty. Nejjednodušší způsob, jak toho dosáhnout, je vyvinout řešení založená na umělé inteligenci na stejné platformě, která se používá ke správě produkčních dat. Podívejte se na Data-centric MLOps a LLMOps

3. Návrh pro automatické škálování

Povolení automatického škálování pro úlohy ETL

Automatické škálování umožňuje clusterům automaticky měnit velikost na základě úloh. Automatické škálování může těžit z mnoha případů použití a scénářů z hlediska nákladů i výkonu. Dokumentace obsahuje důležité informace o tom, jestli se má používat automatické škálování a jak získat největší výhodu.

Pro úlohy streamování doporučuje Databricks používat DLT s automatickým škálováním. Vylepšené automatické škálování Databricks optimalizuje využití clusteru automatickým přidělováním prostředků clusteru na základě svazku úloh s minimálním dopadem na latenci zpracování dat vašich kanálů.

Povolení automatického škálování pro SQL Warehouse

Parametr škálování služby SQL Warehouse nastaví minimální a maximální počet clusterů, ve kterých se distribuují dotazy odeslané do skladu. Výchozí hodnota je jeden cluster bez automatického škálování.

Pokud chcete zpracovat více souběžných uživatelů pro daný sklad, zvyšte počet clusterů. Informace o tom, jak Azure Databricks přidává a odebírá clustery ve skladech, najdete v tématu Velikost, škálování a fronta ve službě SQL Warehouse.

4. Testovací postupy obnovení

Zotavení po selhání dotazů strukturovaného streamování

Strukturované streamování poskytuje odolnost proti chybám a konzistenci dat pro dotazy streamování. Pomocí úloh Databricks můžete snadno nakonfigurovat dotazy strukturovaného streamování tak, aby se automaticky restartoval při selhání. Povolením kontrolních bodů pro streamovací dotaz můžete po selhání dotaz restartovat. Restartovaný dotaz bude pokračovat tam, kde neúspěšný dotaz skončil. Viz kontrolní body strukturovaného streamování a aspekty produkce pro strukturované streamování.

Obnovení úloh ETL s využitím schopností návratu k historickým datům

I přes důkladné testování může úloha selhat v produkčním prostředí nebo způsobit neočekávaná a dokonce neplatná data. Někdy to může být opraveno pomocí další úlohy po pochopení zdroje problému a vyřešení kanálu, který problém způsobil na prvním místě. Často to ale není jednoduché a úloha v daném případě by měla být vrácena zpět. Pomocí Delta Time cestování mohou uživatelé snadno vrátit změny ke starší verzi nebo časovému razítku, opravit datový tok a restartovat opravený datový tok.

Pohodlný způsob, jak to udělat, je RESTORE příkaz.

Využití architektury automatizace úloh s integrovaným obnovením

Úlohy Databricks jsou navrženy pro obnovení. Pokud úkol v úloze s více úlohami selže (a tím i všechny závislé úkoly), prostředí Azure Databricks Jobs poskytuje maticové zobrazení spuštění, které vám umožní prozkoumat problém, který způsobil selhání, viz Zobrazení spuštění pro jednu úlohu. Ať už se jedná o krátký problém se sítí nebo skutečný problém s daty, můžete je opravit a spustit spuštění opravy v úlohách Azure Databricks. Spustí pouze neúspěšné a závislé úlohy a zachová úspěšné výsledky z dřívějšího spuštění, a tím ušetří čas a peníze, viz Řešení potíží a oprav selhání úloh

Konfigurace vzoru zotavení po havárii

Pro platformu pro analýzu dat nativní pro cloud, jako je Azure Databricks, je zásadní jasný model zotavení po havárii. Je důležité, aby vaše datové týmy mohly využívat platformu Azure Databricks i ve výjimečných událostech výpadku poskytovatele cloudových služeb v celé oblasti, ať už příčinou regionální katastrofy, jako je hurikán, zemětřesení nebo nějaký jiný zdroj.

Azure Databricks je často klíčovou součástí celkového ekosystému dat, který zahrnuje mnoho služeb, včetně upstreamových služeb pro příjem dat (batch/streaming), nativního cloudového úložiště, jako je Azure Data Lake Storage Gen2, podřízené nástroje a služby, jako jsou aplikace business intelligence a nástroje pro orchestraci. Některé z vašich případů použití můžou být obzvláště citlivé na výpadek na úrovni regionální služby.

zotavení po havárii zahrnuje sadu zásad, nástrojů a postupů, které umožňují zotavení nebo pokračování klíčové technologické infrastruktury a systémů po přírodní nebo lidské havárii. Velká cloudová služba, jako je Azure, obsluhuje mnoho zákazníků a má integrovanou ochranu proti jediné chybě. Například oblast je skupina budov připojených k různým zdrojům napájení, aby se zajistilo, že jeden výpadek napájení nevyřadí oblast z provozu. K selháním oblasti cloudu ale může dojít a závažnost selhání a její dopad na vaši firmu se může lišit.

5. Automatizace nasazení a úloh

Viz Efektivita provozu – Automatizace nasazení a úloh.

6. Monitorování systémů a úloh

Viz Efektivita provozu – nastavení monitorování, upozorňování a protokolování.