Řešení potíží s výkonem v Azure Databricks

Tento článek popisuje, jak používat řídicí panely pro monitorování k nalezení problémových míst výkonu v úlohách Sparku na Azure Databricks.

Azure Databricks je analytická služba založená na Apache Spark, která usnadňuje rychlé vývoj a nasazování analýz velkých objemů dat. Monitorování a řešení potíží s výkonem je důležité při provozu produkčních Azure Databricks úloh. Chcete-li zjistit běžné problémy s výkonem, je vhodné použít vizualizace monitorování na základě dat telemetrie.

Požadavky

Postup nastavení řídicích panelů Grafana, které jsou uvedené v tomto článku:

• Nakonfigurujte svůj cluster datacihlů pro posílání telemetrie do Log Analyticsho pracovního prostoru pomocí knihovny monitorování Azure Databricks. podrobnosti najdete v souboru readme GitHub.

• Nasaďte Grafana na virtuálním počítači. Podívejte se na téma Použití řídicích panelů k vizualizaci Azure Databricks metriky.

Nasazený řídicí panel Grafana zahrnuje sadu vizualizací časových řad. Každý graf je vykreslení časových řad metriky související s Apache Spark úlohou, fázemi úlohy a úkoly, které tvoří jednotlivé fáze.

Přehled výkonu Azure Databricks

Azure Databricks je založen na Apache Spark, distribuovaném výpočetním systému pro obecné účely. Kód aplikace, který se označuje jako úloha, se spouští v clusteru Apache Spark, který je koordinovaný správcem clusteru. Obecně se jedná o jednotku výpočtu nejvyšší úrovně. Úloha představuje úplnou operaci, kterou provede aplikace Spark. Typická operace zahrnuje čtení dat ze zdroje, použití transformace dat a zápis výsledků do úložiště nebo jiného cíle.

Úlohy jsou rozdělené do fází. Úloha projde fázemi postupně, což znamená, že pozdější fáze musí počkat na dokončení předchozích fází. Fáze obsahují skupiny identických úloh , které je možné provádět paralelně na několika uzlech clusteru Spark. Úlohy jsou nejpodrobnější jednotkou spuštění prováděné na podmnožině dat.

V dalších částech jsou popsány některé vizualizace řídicích panelů, které jsou užitečné při řešení potíží s výkonem.

Latence úloh a fází

Latence úlohy je doba trvání spuštění úlohy od okamžiku, kdy se spustí, až do dokončení. Zobrazuje se jako percentily provedení úlohy na cluster a ID aplikace, aby bylo možné vizualizaci mimo provoz. Následující graf znázorňuje historii úloh, u kterých se dosáhlo 90 percentilu 50 sekund, i když byl 50. percentil konzistentně zhruba 10 sekund.

Prozkoumejte provádění úloh pomocí clusteru a aplikace a vyhledá špičky v latenci. Jakmile budou zjištěny clustery a aplikace s vysokou latencí, přejděte k vyšetření latence fáze.

Latence fáze je také zobrazena jako percentily, aby bylo možné vizualizaci mimo jiné. Latence fáze je rozdělená podle názvu clusteru, aplikace a fáze. Identifikujte špičky v latenci úloh v grafu, abyste zjistili, které úlohy se dokončí zpět na dokončení fáze.

V grafu propustnosti clusteru se zobrazuje počet dokončených úloh, fází a úloh za minutu. To vám pomůže pochopit úlohy z pohledu relativního počtu fází a úloh na úlohu. Tady vidíte, že počet úloh za minutu je v rozsahu od 2 do 6, zatímco počet fází je zhruba 12 – 24 za minutu.

Součet latence provádění úlohy

Tato vizualizace znázorňuje součet latence spuštění úlohy na hostitele běžícího v clusteru. Pomocí tohoto grafu můžete detekovat úlohy, které se zpomalují kvůli zpomalení hostitele v clusteru, nebo nejenom přidělení úloh na vykonavatele. V následujícím grafu mají většina hostitelů součet přibližně 30 sekund. Dva z těchto hostitelů ale mají součty najetí myší okolo 10 minut. Hostitelé běží pomalu nebo je počet úloh na vykonavatele nepřiřazený.

Počet úkolů na prováděcí modul ukazuje, že dva prováděcí moduly mají neúměrný počet úkolů, což způsobuje kritické místo.

Metrika úloh na fázi

Vizualizace metriky úloh poskytuje rozdělení nákladů na provádění úkolů. Můžete ji použít k zobrazení relativního času stráveného na úkolech, jako je například serializace a deserializace. Tato data mohou zobrazovat možnosti optimalizace — například pomocí proměnných všesměrového vysílání , aby se předešlo doručení dat. Metrika úlohy také zobrazuje velikost náhodné velikosti dat pro úlohu a dobu náhodného čtení a zápisu. Pokud jsou tyto hodnoty vysoké, znamená to, že v síti probíhá Přesun velkého množství dat.

Další metrikou úlohy je zpoždění plánovače, které měří dobu potřebnou k naplánování úlohy. V ideálním případě by tato hodnota měla být v porovnání s výpočetním časem vykonavatele nízká, což je čas strávený skutečně vykonání úlohy.

Následující graf znázorňuje dobu zpoždění plánovače (3,7 s), která překračuje výpočetní čas prováděcího modulu (1,1 s). To znamená více času stráveného čekáním na to, aby úkoly byly naplánovány, než je skutečná práce.

V tomto případě byl problém způsoben příliš mnoha oddíly, což způsobilo hodně režie. Snížení počtu oddílů, které snížily dobu zpoždění plánovače. Další graf ukazuje, že většina času stráví prováděním úlohy.

Propustnost streamování a latence

Propustnost streamování je přímo v souvislosti se strukturovaným streamování. Propustnost streamování má dvě důležité metriky: vstupní řádky za sekundu a zpracované řádky za sekundu. Pokud vstupní řádky za sekundu přesměrují zpracované řádky za sekundu, znamená to, že se do systému zpracování datového proudu vztahuje. Navíc platí, že pokud vstupní data pocházejí z Event Hubs nebo Kafka, pak vstupní řádky za sekundu by měly udržovat rychlost příjmu dat na front-endu.

Dvě úlohy můžou mít podobnou propustnost clusteru, ale velmi různé metriky streamování. Následující snímek obrazovky ukazuje dvě různé úlohy. Jsou podobné propustnosti clusteru (úlohy, fáze a úlohy za minutu). Ale druhý běh zpracovává 12 000 řádků/s oproti 4 000 řádků/s.

Propustnost streamování je často lepší obchodní metrikou než propustnost clusteru, protože měří počet zpracovávaných záznamů dat.

Spotřeba prostředků na vykonavatele

Tyto metriky pomůžou pochopit práci, kterou každý prováděcí modul provádí.

Procentuální metrika měří, kolik času prováděcího modulu stráví různými akcemi, vyjádřený poměrem času stráveného oproti celkovému výpočetnímu času prováděcího modulu. Jsou to:

• % Doby serializace
• % Doby deserializace
• % Času prováděcího modulu CPU
• % JVM čas

Tyto vizualizace znázorňují, kolik z těchto metrik přispívá k celkovému zpracování prováděcího modulu.

Rozmístění metrik jsou metriky související s pohybem dat v rámci prováděcích modulů.

• Náhodné I/O
• Náhodně vymíchat paměť
• Využití systému souborů
• Využití disku

Běžné kritické body výkonu

Dva běžné potíže s výkonem ve Sparku jsou stragglers úlohy a neoptimální počet oddílů, které jsou náhodně neoptimální.

Stragglers úlohy

Fáze v rámci úlohy jsou spouštěny postupně, přičemž předchozí fáze blokují pozdější fáze. Pokud je jedna úloha náhodně rozmístěný oddíl, než jiné úkoly, musí všechny úlohy v clusteru počkat, než se pomalý úkol zachytí, aby bylo možné ukončit fázi. K tomu může dojít z následujících důvodů:

1. Hostitel nebo skupina hostitelů běží pomalu. Příznaky: vysoká latence úlohy, fáze nebo latence úloh a nízká propustnost clusteru. Součet latencí úkolů na hostitele nebude rovnoměrně distribuován. Spotřeba prostředků se ale rovnoměrně distribuuje mezi prováděcími moduly.

2. Úlohy mají náročnou agregaci ke spuštění (zkosení dat). Příznaky: vysoká latence úlohy, latence při vysoké latenci, vysoká latence úlohy nebo nízká propustnost clusteru, ale součet latencí na hostitele je rovnoměrně distribuován. Spotřeba prostředků bude rovnoměrně rozložena mezi prováděcími moduly.

3. Pokud jsou oddíly nestejné velikosti, větší oddíl může způsobit nevyvážené provádění úloh (převážení oddílů). Příznaky: využití prostředků prováděcího modulu je ve srovnání s jinými prováděcími moduly běžícími v clusteru vysoké. Všechny úlohy spuštěné v tomto prováděcím modulu poběží pomalu a v kanálu budou mít spuštěné fáze. Tyto fáze se označují jako bariéry fází.

Neoptimální náhodný počet oddílů

Během strukturovaného dotazování streamování je přiřazení úlohy do prováděcího modulu operací náročných na prostředky clusteru. Pokud data náhodně nedosahují optimální velikosti, bude doba zpoždění úlohy negativně ovlivňovat propustnost a latenci. Pokud je příliš málo oddílů, jádra v clusteru budou nevyužitá, což může vést k neefektivitě zpracování. Naopak, pokud existuje příliš mnoho oddílů, existuje značná režie správy pro malý počet úkolů.

Metriky spotřeby prostředků použijte k řešení potíží se zkosením oddílů a neúspěšným přidělením prováděcích modulů v clusteru. Pokud je oddíl zkosený, budou se prostředky prováděcího modulu v porovnání s jinými prováděcími moduly, které jsou spuštěny v clusteru, zvýšeny.

Například následující graf ukazuje, že paměť využívaná v prvních dvou prováděcích modulech je 90X větší než ostatní prováděcí moduly: