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 ACID transakcí a také zabezpečení pravidel schema, škálovatelné zpracování metadat a sjednocuje streamové a dávkové zpracování 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. Zachráněná data column obsahují všechna data, která nebyla analyzována, buď proto, že chyběla v daném schema, kvůli neshodě typů, nebo protože tělo column v záznamu nebo souboru se neshodovalo s tím v schema.
-
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 záchranná data column obsahují všechna data, která nebyla analyzována, pravděpodobně proto, že v daném schemachyběla, protože došlo k neshodě typu nebo kvůli neshodě velikostí column. Zachráněná data column jsou součástí schema, které Auto Loader vrací jako
_rescued_data
ve výchozím nastavení, když se odvozuje schema. - Delta Live Tables: Další možností vytváření pracovních postupů pro odolnost je použití Delta Live Tables s omezeními kvality. Viz Správa kvality dat pomocí delta live Tables. Produkt Delta Live Tables ve výchozím nastavení podporuje tři režimy: zachování, vyřazení a selhání u neplatných záznamů. Chcete-li umístit do karantény identifikované neplatné záznamy, lze pravidla očekávání definovat určitým způsobem, aby byly neplatné záznamy uloženy ("v karanténě") v jiné table. Podívejte se na neplatná data o 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í. Podívejte se na Set a zásady 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.
Použijte spravované služby where, je to možné.
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ý pohled 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 views). 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 stanou mimo sync, má významný negativní dopad na integritu a kvalitu dat, což vyvolává otázky, jako je například "Která datová set je hlavní?" nebo "Jsou data set aktuální?
Aktivně spravovat schémata
Nekontrolovatelné schema změny 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í schema:
- Delta Lake podporuje ověřování schema a vynucení schema automatickým zpracováním variant schema, aby se zabránilo vkládání chybných záznamů během příjmu dat. Viz Schema vynucení.
-
automatického zavaděče zjistí přidání nových columns při zpracování dat. Ve výchozím nastavení přidání nového column způsobí, že se datové proudy zastaví pomocí
UnknownFieldException
. Auto Loader podporuje několik režimů pro vývoj schema.
Použití omezení a očekávání dat
Delta tables podporují standardní klauzule správy SQL constraint, které zajišťují automatickou kontrolu kvality a integrity dat přidaných do table. Když dojde k porušení constraint, Delta Lake vyvolá chybu InvariantViolationException
, která signalizují, že se nová data nedají přidat. Viz Omezení v Azure Databricks.
Pro další vylepšení tohoto zpracování Delta Live Tables podporuje očekávání: Ta definují omezení kvality dat u obsahu dat set. 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 SQL constraint. Viz Správa kvality dat pomocí delta live Tables.
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. Proto zprovoznění řešení ML vyžaduje sloučení dat z předpovědí, monitorování a funkcí tables 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 použít automatické škálování a jak get největší výhodu.
Pro úlohy streamování doporučuje Databricks používat delta live Tables 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 ten neúspěšný dotaz u where 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 set 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 – Set monitorování, upozorňování a protokolování.