Vzory a metriky pozorovatelnosti pro ladění výkonu

Toto řešení ukazuje vzory a metriky pozorovatelnosti pro zlepšení výkonu zpracování systému pro velké objemy dat, který používá Azure Databricks.

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Řešení zahrnuje následující kroky:

1. Server odešle velký soubor GZIP seskupený zákazníkem do složky Source ve službě Azure Data Lake Storage (ADLS).

2. ADLS pak odešle úspěšně extrahovaný soubor zákazníka do služby Azure Event Grid, který změní data souboru zákazníka na několik zpráv.

3. Azure Event Grid odesílá zprávy do služby Azure Queue Storage, která je ukládá do fronty.

4. Azure Queue Storage odešle frontu do platformy analýzy dat Azure Databricks ke zpracování.

5. Azure Databricks rozbalí a zpracuje data fronty do zpracovaného souboru, který odesílá zpět do ADLS:

   1. Pokud je zpracovaný soubor platný, přejde do cílové složky.

   2. V opačném případě soubor přejde do stromu chybná složka. Na začátku soubor přejde do podsložky Opakovat a ADLS se pokusí znovu zpracovat soubor zákazníka (krok 2). Pokud pár pokusů o opakování stále vede k vrácení zpracovaných souborů, které nejsou platné, přejde zpracovaný soubor do podsložky Selhání .

6. Vzhledem k tomu, že Azure Databricks rozbalí a zpracuje data v předchozím kroku, odesílá také protokoly aplikací a metriky do služby Azure Monitor pro úložiště.

7. Pracovní prostor Azure Log Analytics používá dotazy Kusto na protokoly aplikací a metriky ze služby Azure Monitor pro řešení potíží a hloubkovou diagnostiku.

Komponenty

• Azure Data Lake Storage je sada funkcí vyhrazených pro analýzy velkých objemů dat.
• Azure Event Grid umožňuje vývojářům snadno vytvářet aplikace s architekturami založenými na událostech.
• Azure Queue Storage je služba pro ukládání velkého počtu zpráv. Umožňuje přístup ke zprávům odkudkoli na světě prostřednictvím ověřených volání pomocí protokolu HTTP nebo HTTPS. Fronty můžete použít k vytvoření backlogu práce pro asynchronní zpracování.
• Azure Databricks je platforma pro analýzu dat optimalizovaná pro cloudovou platformu Azure. Jedním ze dvou prostředí, která Azure Databricks nabízí pro vývoj aplikací náročných na data, je pracovní prostor Azure Databricks, jednotný analytický modul založený na Apache Sparku pro zpracování velkých objemů dat.
• Azure Monitor shromažďuje a analyzuje telemetrii aplikací, jako jsou metriky výkonu a protokoly aktivit.
• Azure Log Analytics je nástroj, který slouží k úpravě a spouštění dotazů na protokoly s daty.

Podrobnosti scénáře

Vývojový tým může pomocí vzorů pozorovatelnosti a metrik najít kritické body a zlepšit výkon systému pro velké objemy dat. Váš tým musí provádět zátěžové testování vysokoobsahového datového proudu metrik v aplikaci ve velkém měřítku.

Tento scénář nabízí pokyny pro ladění výkonu. Vzhledem k tomu, že tento scénář představuje výzvu k výkonu protokolování pro jednotlivé zákazníky, používá Azure Databricks, která může tyto položky robustně monitorovat:

• Vlastní metriky aplikací
• Streamování událostí dotazů
• Zprávy protokolu aplikace

Azure Databricks může tato data monitorování odesílat do různých služeb protokolování, jako je Azure Log Analytics.

Tento scénář popisuje příjem velké sady dat seskupených zákazníkem a uložených v archivním souboru GZIP. Podrobné protokoly nejsou z Azure Databricks dostupné mimo uživatelské rozhraní Apache Sparku™ v reálném čase, takže váš tým potřebuje způsob, jak uložit všechna data pro každého zákazníka a pak provést srovnávací testy a porovnat. U velkého datového scénáře je důležité najít optimální velikost fondu exekutorů a virtuálního počítače pro nejrychlejší dobu zpracování. U tohoto obchodního scénáře se celková aplikace spoléhá na rychlost příjmu dat a dotazování požadavků, aby propustnost systému neočekávaně nezpůsobí snížení objemu práce. Scénář musí zaručit, že systém splňuje smlouvy o úrovni služeb (SLA), které jsou vytvořeny s vašimi zákazníky.

Potenciální případy použití

Mezi scénáře, které můžou těžit z tohoto řešení, patří:

• Monitorování stavu systému.
• Údržba výkonu
• Monitorování každodenního využití systému
• Sledování trendů, které by mohly způsobit budoucí problémy, pokud není oblékaná.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Při zvažování této architektury mějte na paměti tyto body:

• Azure Databricks může automaticky přidělit výpočetní prostředky potřebné pro velkou úlohu, což zabraňuje problémům, které zavádějí jiná řešení. Například u automatického škálování optimalizovaného pro Databricks v Apache Sparku může nadměrné zřizování způsobit neoptimální využití prostředků. Nebo možná neznáte počet exekutorů požadovaných pro úlohu.

• Zpráva fronty ve službě Azure Queue Storage může mít velikost až 64 kB. Fronta může obsahovat miliony zpráv fronty až do celkového limitu kapacity účtu úložiště.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

K odhadu nákladů na implementaci tohoto řešení použijte cenovou kalkulačku Azure.

Nasazení tohoto scénáře

Pokud chcete získat všechny protokoly a informace o procesu, nastavte Azure Log Analytics a knihovnu monitorování Azure Databricks. Knihovna monitorování streamuje události na úrovni Apache Sparku a metriky strukturovaného streamování Sparku z vašich úloh do služby Azure Monitor. U těchto událostí a metrik nemusíte provádět žádné změny kódu aplikace.

Postup nastavení ladění výkonu pro systém pro velké objemy dat je následující:

1. Na webu Azure Portal vytvořte pracovní prostor Azure Databricks. Zkopírujte a uložte ID předplatného Azure (GUID), název skupiny prostředků, název pracovního prostoru Databricks a adresu URL portálu pracovního prostoru pro pozdější použití.

2. Ve webovém prohlížeči přejděte na adresu URL pracovního prostoru Databricks a vygenerujte osobní přístupový token Databricks. Zkopírujte a uložte řetězec tokenu, který se zobrazí (který začíná dapi šestnáctkovou hodnotou 32 znaků) pro pozdější použití.

3. Naklonujte úložiště GitHubu pro monitorování mspnp/spark do místního počítače. Toto úložiště má zdrojový kód pro následující komponenty:

   • Šablona Azure Resource Manageru (ARM) pro vytvoření pracovního prostoru Azure Log Analytics, který také nainstaluje předem připravené dotazy pro shromažďování metrik Sparku
   • Knihovny monitorování Azure Databricks
   • Ukázková aplikace pro odesílání metrik aplikací a protokolů aplikací z Azure Databricks do služby Azure Monitor

4. Pomocí příkazu Azure CLI pro nasazení šablony ARM vytvořte pracovní prostor Azure Log Analytics s předem připravenými dotazy na metriky Sparku. Ve výstupu příkazu zkopírujte a uložte vygenerovaný název nového pracovního prostoru služby Log Analytics (ve formátu spark-monitoring-randomized-string><).

5. Na webu Azure Portal zkopírujte a uložte ID a klíč pracovního prostoru služby Log Analytics pro pozdější použití.

6. Nainstalujte Community Edition IntelliJ IDEA, integrované vývojové prostředí (IDE), které má integrovanou podporu sady Java Development Kit (JDK) a Apache Mavenu. Přidejte modul plug-in Scala.

7. Pomocí IntelliJ IDEA sestavte knihovny monitorování Azure Databricks. Pokud chcete provést skutečný krok sestavení, vyberte Zobrazit>nástroj Windows>Maven, aby se zobrazilo okno nástrojů Maven a pak vyberte Spustit balíček Maven Goal>mvn.

8. Pomocí instalačního nástroje balíčku Pythonu nainstalujte rozhraní příkazového řádku Azure Databricks a nastavte ověřování pomocí osobního přístupového tokenu Databricks, který jste si zkopírovali dříve.

9. Nakonfigurujte pracovní prostor Azure Databricks tak, že upravíte inicializační skript Databricks pomocí hodnot Databricks a Log Analytics, které jste zkopírovali dříve, a pak pomocí rozhraní příkazového řádku Azure Databricks zkopírujte inicializační skript a knihovny monitorování Azure Databricks do pracovního prostoru Databricks.

10. Na portálu pracovního prostoru Databricks vytvořte a nakonfigurujte cluster Azure Databricks.

11. V IntelliJ IDEA sestavte ukázkovou aplikaci pomocí Mavenu. Pak na portálu pracovního prostoru Databricks spusťte ukázkovou aplikaci, která vygeneruje ukázkové protokoly a metriky pro Azure Monitor.

12. Zatímco ukázková úloha běží v Azure Databricks, přejděte na Azure Portal a zobrazte a dotazujte se na typy událostí (protokoly aplikací a metriky) v rozhraní Log Analytics:

    1. Výběrem možnosti Tabulky>vlastní protokoly zobrazíte schéma tabulky pro události naslouchacího procesu Sparku (SparkListenerEvent_CL), události protokolování Sparku (SparkLoggingEvent_CL) a metriky Sparku (SparkMetric_CL).
    2. Vyberte Průzkumník>dotazů uložené metriky> Sparku pro zobrazení a spuštění dotazů, které byly přidány při vytváření pracovního prostoru služby Log Analytics.

    Další informace o prohlížení a spouštění předem připravených a vlastních dotazů najdete v další části.

Dotazování protokolů a metrik v Azure Log Analytics

Předem připravené dotazy accessu

Předem připravené názvy dotazů pro načítání metrik Sparku jsou uvedené níže.

Psaní vlastních dotazů

Do dotazovací jazyk Kusto (KQL) můžete také napsat vlastní dotazy. Stačí vybrat horní prostřední podokno, které se dá upravit, a přizpůsobit dotaz tak, aby vyhovoval vašim potřebám.

Následující dva dotazy načítá data z událostí protokolování Sparku:

SparkLoggingEvent_CL | where logger_name_s contains "com.microsoft.pnp"

SparkLoggingEvent_CL
| where TimeGenerated > ago(7d)
| project TimeGenerated, clusterName_s, logger_name_s
| summarize Count=count() by clusterName_s, logger_name_s, bin(TimeGenerated, 1h)

A tyto dva příklady jsou dotazy na protokol metrik Sparku:

SparkMetric_CL
| where name_s contains "executor.cpuTime"
| extend sname = split(name_s, ".")
| extend executor=strcat(sname[0], ".", sname[1])
| project TimeGenerated, cpuTime=count_d / 100000

SparkMetric_CL
| where name_s contains "driver.jvm.total."
| where executorId_s == "driver"
| extend memUsed_GB = value_d / 1000000000
| project TimeGenerated, name_s, memUsed_GB
| summarize max(memUsed_GB) by tostring(name_s), bin(TimeGenerated, 1m)

Terminologie dotazů

Následující tabulka vysvětluje některé termíny, které se používají při vytváření dotazu na protokoly aplikací a metriky.

Následující části obsahují typické metriky používané v tomto scénáři pro monitorování propustnosti systému, stavu spuštění úlohy Sparku a využití systémových prostředků.

Propustnost systému

Stav spuštěné úlohy Sparku

Využití systémových prostředků

Rozhodněte se, jak propojit vstup zákazníka, který se zkombinoval do archivní souboru GZIP, s konkrétním výstupním souborem Azure Databricks, protože Azure Databricks zpracovává celou dávkovou operaci jako jednotku. Tady použijete členitost trasování. Pomocí vlastních metrik můžete také trasovat jeden výstupní soubor do původního vstupního souboru.

Podrobnější definice jednotlivých metrik najdete v tématu Vizualizace na řídicích panelech na tomto webu nebo v části Metriky v dokumentaci k Apache Sparku.

Posouzení možností ladění výkonu

Definice směrného plánu

Vy a váš vývojový tým byste měli vytvořit směrný plán, abyste mohli porovnat budoucí stavy aplikace.

Změřte výkon vaší aplikace kvantitativním způsobem. V tomto scénáři je klíčovou metrikou latence úlohy, která je typická pro většinu předzpracování a příjmu dat. Pokuste se zrychlit dobu zpracování dat a zaměřit se na měření latence, jak je znázorněno v následujícím grafu:

Změřte latenci provádění úlohy: hrubý přehled o celkovém výkonu úlohy a dobu provádění úlohy od začátku do dokončení (mikrobatchová doba). Ve výše uvedeném grafu na značce 19:30 trvá zpracování úlohy přibližně 40 sekund.

Pokud se podrobněji podíváte na tyto 40 sekundy, zobrazí se následující data pro fáze:

Na značce 19:30 jsou dvě fáze: oranžová fáze 10 sekund a zelená fáze v 30 sekundách. Sledujte, jestli fáze špičky, protože špička indikuje zpoždění ve fázi.

Prozkoumejte, kdy určitá fáze běží pomalu. Ve scénáři dělení existují obvykle alespoň dvě fáze: jedna fáze čtení souboru a druhá fáze pro náhodné prohazování, dělení a zápis souboru. Pokud máte vysokou latenci fáze většinou ve fázi zápisu, může při dělení dojít k problému s kritickým bodem.

Sledujte úkoly, jak se fáze v úloze spouštějí postupně, přičemž dřívější fáze blokují pozdější fáze. Pokud jedna úloha ve fázi spustí oddíl s náhodném prohazování pomaleji než jiné úlohy, musí všechny úlohy v clusteru čekat na dokončení pomalejší úlohy, než se fáze dokončí. Úkoly pak představují způsob, jak monitorovat nerovnoměrnou distribuci dat a možné kritické body. V grafu výše vidíte, že všechny úkoly jsou rovnoměrně distribuované.

Teď monitorujte dobu zpracování. Vzhledem k tomu, že máte scénář streamování, podívejte se na propustnost streamování.

V grafu propustnosti streamování nebo dávkové latence výše představuje oranžová čára vstupní rychlost (vstupní řádky za sekundu). Modrá čára představuje rychlost zpracování (zpracovávané řádky za sekundu). V některých bodech rychlost zpracování nezachytí vstupní rychlost. Potenciálním problémem je, že vstupní soubory se hromadí ve frontě.

Vzhledem k tomu, že rychlost zpracování neodpovídá vstupní frekvenci v grafu, podívejte se, jak zlepšit rychlost zpracování, aby se vstupní rychlost plně pokrývala. Jedním z možných důvodů může být nerovnováha zákaznických dat v každém klíči oddílu, který vede k kritickým bodům. V případě dalšího kroku a potenciálního řešení využijte škálovatelnost Azure Databricks.

Zkoumání dělení

Nejprve určete správný počet exekutorů škálování, které potřebujete s Azure Databricks. Použijte pravidlo přiřazení jednotlivých oddílů vyhrazeným procesorem při spouštění exekutorů. Pokud máte například 200 klíčů oddílu, počet procesorů vynásobený počtem exekutorů by měl být 200. (Například osm procesorů v kombinaci s 25 exekutory by se dobře shodovalo.) S 200 klíči oddílu může každý exekutor pracovat pouze na jednom úkolu, což snižuje riziko kritického bodu.

Vzhledem k tomu, že v tomto scénáři jsou některé pomalé oddíly, prozkoumejte vysokou odchylku doby trvání úkolů. Zkontrolujte případné špičky v době trvání úkolu. Jeden úkol zpracovává jeden oddíl. Pokud úkol vyžaduje více času, může být oddíl příliš velký a způsobit kritický bod.

Trasování chyb

Přidejte řídicí panel pro trasování chyb, abyste mohli zjistit selhání dat specifická pro zákazníky. Při předběžném zpracování dat existují časy, kdy jsou soubory poškozené a záznamy v souboru neodpovídají schématu dat. Následující řídicí panel zachytává mnoho chybných souborů a špatných záznamů.

Tento řídicí panel zobrazí počet chyb, chybovou zprávu a ID úlohy pro ladění. Ve zprávě můžete chybu snadno vysledovat zpět do souboru chyby. Při čtení došlo k chybě několika souborů. Zkontrolujete horní časovou osu a prozkoumáte konkrétní body v našem grafu (16:20 a 16:40).

Další kritické body

Další příklady a pokyny najdete v tématu Řešení potíží s kritickými body výkonu v Azure Databricks.

Souhrn posouzení ladění výkonu

V tomto scénáři tyto metriky identifikovaly následující pozorování:

• V grafu latence fáze trvá většina fází zpracování.
• V grafu latence úlohy je latence úlohy stabilní.
• V grafu propustnosti streamování je výstupní rychlost v některých bodech nižší než vstupní rychlost.
• V tabulce doby trvání úkolu je rozdíl mezi úkoly z důvodu nevyváženosti zákaznických dat.
• Pokud chcete dosáhnout optimalizovaného výkonu ve fázi dělení, měl by počet exekutorů škálování odpovídat počtu oddílů.
• Existují chyby trasování, jako jsou chybné soubory a chybné záznamy.

K diagnostice těchto problémů jste použili následující metriky:

• Latence úlohy
• Latence fáze
• Latence úlohy
• Propustnost streamování
• Doba trvání úkolu (max, průměr, minimum) ve fázi
• Trasování chyb (počet, zpráva, ID úkolu)

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• David McGhee | Hlavní programový manažer

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Přečtěte si kurz služby Log Analytics.
• Monitorování Azure Databricks v pracovním prostoru Služby Azure Log Analytics
• Nasazení Služby Azure Log Analytics s využitím metrik Sparku
• Vzory pozorovatelnosti

Související prostředky

• Odesílání protokolů aplikací Azure Databricks do Azure Monitoru
• Použití řídicích panelů k vizualizaci metrik Azure Databricks
• Osvědčené postupy pro monitorování cloudových aplikací
• Model Opakování