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 pro 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í mimo kód, jako je krátký problém se sítí nebo odvolaný spotový virtuální počítač. Práce s rozhraním SQL API i rozhraním API sparkového datového rámce je tato odolnost integrovaná do modulu.

V Databricks Lakehouse , Photon, nativní vektorizovaný modul zcela napsaný v jazyce C++, je vysoce výkonný výpočetní výkon 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. Pokud chcete zvýšit celkovou odolnost celého procesu, doporučuje se vyfiltrovat neplatná a nekonformní data při ingestování. Podpora zachráněných dat zajišťuje, že během ingestování nebo ETL nikdy neztratíte nebo 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:Automatický zavaděč je ideální nástroj pro streamování příjmu souborů. Podporuje záchranná 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.
• Delta Live Tables: Další možností vytváření pracovních postupů pro odolnost je použití Delta Live Tables s omezeními kvality. Podívejte se na Spravujte kvalitu dat podle očekávání datového toku. Delta Live Tables podporuje ve výchozím nastavení 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.
• Delta Live Tables také automatizuje zotavení po selhání pomocí eskalace opakovaných pokusů za účelem vyvážení rychlosti a spolehlivosti. Viz režimy vývoje a produkce.

Na druhou stranu předsazení úkolu 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 odvozování dávek a streamování použijte úlohy Azure Databricks a MLflow k nasazení modelů jako UDF Apache Sparku k využití plánování úloh, opakování, automatického škálování atd. 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žití spravovaných služeb (bezserverových výpočetních prostředků) z platformy Data Intelligence Platform, například:

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

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ě

Kurátorovat data vytvořením vrstvené architektury a zajištěním zvýšení kvality dat při procházení mezi 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 vytváření sestav napříč všemi rolemi a funkcemi.
• 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 pravdivou pro firmu.

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 obchodním rozhodnutím, stanou se datovými silami. Když se tato datová sila přestanou synchronizovat, má 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. Podívejte se na 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í datových proudů s UnknownFieldException. Auto Loader podporuje několik režimů pro vývoj schématu .

Použití 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í podporují Delta Live Tables očekávání: Očekávání definují standardy kvality dat u obsahu datové sady. Očekávání se skládá z popisu, invariantu a akce, která se má provést, pokud záznam porušuje invariantní. 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. Zobrazení MLOps zaměřeného na data 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 tabulky Delta Live 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á clustery do skladu a odebírá je, najdete v tématu Určení velikosti, škálování a řazení do fronty 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 možností cestování v čase dat

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 by se měla vrátit zpět. Pomocí rozdílového časového limitu můžou uživatelé snadno vrátit změny do starší verze nebo časového razítka, opravit kanál a restartovat pevný kanál.

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žené 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í, ušetří čas a peníze, viz Řešení potíží a selhání úloh opravy.

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ě. Oblast je například skupina budov připojených k různým zdrojům napájení, aby se zajistilo, že jeden výpadek napájení nepřinese oblast. 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í.