DataOps pro moderní datový sklad

Tento článek popisuje, jak by toto řešení mohla využít fiktivní kancelář pro plánování města. Řešení poskytuje ucelený datový kanál, který se řídí vzorem architektury MDW spolu s odpovídajícími procesy DevOps a DataOps, k vyhodnocení využití parkování a provádění informovanějších obchodních rozhodnutí.

Architektura

Následující diagram znázorňuje celkovou architekturu řešení.

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

Tok dat

Azure Data Factory orchestruje a Azure Data Lake Storage Gen2 ukládá data:

1. Rozhraní API webové služby Contoso pro parkování je k dispozici k přenosu dat z parkovacích míst.

2. Existuje úloha kopírování datové továrny, která přenáší data do cílového schématu.

3. V dalším kroku Azure Databricks data vyčistí a standardizuje data. Vezme nezpracovaná data a podmínky, aby je mohli používat datoví vědci.

4. Pokud ověření odhalí všechna chybná data, zobrazí se do schématu Poškozený.

   Důležité

   Lidé se ptali, proč se data neověřují, než jsou uložená ve službě Data Lake Storage. Důvodem je, že ověření může způsobit chybu, která by datovou sadu mohla poškodit. Pokud v tomto kroku představíte chybu, můžete chybu opravit a znovu přehrát kanál. Pokud jste před jejich přidáním do Data Lake Storage vypsali chybná data, jsou poškozená data nepoužitá, protože kanál nejde přehrát znovu.

5. Existuje druhý krok transformace Azure Databricks, který převede data do formátu, který můžete uložit do datového skladu.

6. Nakonec kanál obsluhuje data dvěma různými způsoby:

   1. Databricks zpřístupňuje datům datovému vědci, aby mohli trénovat modely.

   2. PolyBase přesune data z datového jezera do Azure Synapse Analytics a Power BI k datům přistupuje a prezentuje je firemnímu uživateli.

Komponenty

Řešení používá tyto komponenty:

• Azure Data Factory (ADF)

• Azure Databricks

• Azure Data Lake Storage (ADLS) Gen2

• Azure Synapse Analytics

• Azure Key Vault

• Azure DevOps

• Power BI

Podrobnosti scénáře

Moderní datový sklad (MDW) umožňuje snadno spojit všechna data v libovolném měřítku. Nezáleží na tom, jestli jsou strukturovaná, nestrukturovaná nebo částečně strukturovaná data. Přehled o MDW můžete získat prostřednictvím analytických řídicích panelů, provozních sestav nebo pokročilých analýz pro všechny uživatele.

Nastavení prostředí MDW pro vývojová i produkční prostředí (prod) je složité. Automatizace procesu je klíčem. Pomáhá zvýšit produktivitu a současně minimalizovat riziko chyb.

Tento článek popisuje, jak by toto řešení mohla využít fiktivní kancelář pro plánování města. Řešení poskytuje ucelený datový kanál, který se řídí vzorem architektury MDW spolu s odpovídajícími procesy DevOps a DataOps, k vyhodnocení využití parkování a provádění informovanějších obchodních rozhodnutí.

Požadavky na řešení

• Schopnost shromažďovat data z různých zdrojů nebo systémů

• Infrastruktura jako kód: automatizovaně nasaďte nová vývojová a přípravná prostředí (stg).

• Automatické nasazení změn aplikací v různých prostředích:

  • Implementujte kanály kontinuální integrace a průběžného doručování (CI/CD).

  • Pro ruční schvalování použijte brány nasazení.

• Kanál jako kód: Ujistěte se, že definice kanálů CI/CD jsou ve správě zdrojového kódu.

• Proveďte integrační testy změn pomocí ukázkové datové sady.

• Spouštět kanály podle plánu

• Podpora budoucího agilního vývoje, včetně přidání úloh datových věd.

• Podpora zabezpečení na úrovni řádků i na úrovni objektů:

  • Funkce zabezpečení je k dispozici ve službě SQL Database.

  • Najdete ho také v Azure Synapse Analytics, Azure Analysis Services a Power BI.

• Podpora 10 souběžných uživatelů řídicího panelu a 20 souběžných uživatelů napájení

• Datový kanál by měl provádět ověření dat a vyfiltrovat poškozené záznamy do zadaného úložiště.

• Podpora monitorování

• Centralizovaná konfigurace v zabezpečeném úložišti, jako je Azure Key Vault.

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

Tento článek popisuje scénář použití fiktivního města Contoso. V příběhu společnost Contoso vlastní a spravuje parkovací senzory pro město. Vlastní také rozhraní API, která se připojují k senzorům a získávají z nich data. Potřebují platformu, která bude shromažďovat data z mnoha různých zdrojů. Data se pak musí ověřit, vyčistit a transformovat na známé schéma. Plánovači měst společnosti Contoso pak můžou zkoumat a vyhodnocovat data sestav při používání parkování pomocí nástrojů pro vizualizaci dat, jako je Power BI, a určit, jestli potřebují více parkovacích nebo souvisejících zdrojů.

Důležité informace

Následující seznam shrnuje klíčové poznatky a osvědčené postupy, které toto řešení demonstruje:

• Použijte vrstvení dat ve službě Data Lake.

• V rané fázi kanálu ověřte data.

• Přehrání datových kanálů a idempotentní

• Ujistěte se, že je kód transformace dat testovatelný.

• Máte kanál CI/CD.

• Zabezpečená a centralizovaná konfigurace

• Monitorování infrastruktury, kanálů a dat

Nasazení tohoto scénáře

Následující seznam obsahuje základní kroky potřebné k nastavení řešení Parkovací senzory s odpovídajícími kanály buildu a verze. Podrobný postup nastavení a požadavky najdete v tomto úložišti ukázek Azure.

Nastavení a nasazení

1. Počáteční nastavení: Nainstalujte všechny požadavky, naimportujte úložiště GitHubu ukázek Azure do vlastního úložiště a nastavte požadované proměnné prostředí.

2. Nasazení prostředků Azure: Řešení se dodává se skriptem automatizovaného nasazení. Nasadí všechny potřebné prostředky Azure a instanční objekty Microsoft Entra pro každé prostředí. Skript také nasadí Azure Pipelines, skupiny proměnných a připojení služeb.

3. Nastavení integrace Gitu ve službě Dev Data Factory: Nakonfigurujte integraci Gitu tak, aby fungovala s importovaným úložištěm GitHub.

4. Proveďte počáteční sestavení a vydání: Vytvořte ukázkovou změnu ve službě Data Factory, jako je povolení aktivační události plánu, a pak sledujte, jak se tato změna automaticky nasazuje napříč prostředími.

Nasazené prostředky

Pokud je nasazení úspěšné, měli byste mít v Azure tři skupiny prostředků, které představují tři prostředí: vývoj, stg a prod. V Azure DevOps by také měly existovat kompletní kanály buildu a verze, které můžou automaticky nasazovat změny napříč těmito třemi prostředími.

Podrobný seznam všech prostředků najdete v části Nasazené prostředky v souboru README DataOps – Parking Sensor Demo .

Průběžná integrace a průběžné nasazování (CI/CD)

Následující diagram znázorňuje proces a posloupnost CI/CD pro kanály buildu a verze.

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

1. Vývojáři se vyvíjejí ve svých vlastních prostředích sandboxu v rámci vývojové skupiny prostředků a zavádějí změny do vlastních krátkodobých větví Gitu. Například <developer_name>/<branch_name>.

2. Po dokončení změn vývojáři vytvoří žádost o přijetí změn do hlavní větve ke kontrole. Tím se automaticky spustí kanál ověření žádosti o přijetí změn, který spouští sestavení testů jednotek, lintování a balíčku aplikace datové vrstvy (DACPAC).

3. Po dokončení ověření žádosti o přijetí změn aktivuje potvrzení do hlavního kanálu sestavení kanál sestavení, který publikuje všechny nezbytné artefakty sestavení.

4. Dokončení úspěšného kanálu buildu aktivuje první fázi kanálu verze. Tím nasadíte artefakty sestavení publikování do vývojového prostředí s výjimkou služby Data Factory.

   Vývojáři ručně publikují do vývojové služby Data Factory z větve pro spolupráci (hlavní). Ruční publikování aktualizuje šablony Azure Resource Manageru adf_publish ve větvi.

5. Úspěšné dokončení první fáze aktivuje bránu ručního schválení.

   Při schválení kanál verze pokračuje ve druhé fázi a nasazuje změny do prostředí stg.

6. Spuštěním integračních testů otestujte změny v prostředí stg.

7. Po úspěšném dokončení druhé fáze kanál aktivuje druhou bránu ručního schválení.

   Při schválení kanál verze pokračuje ve třetí fázi a nasazuje změny do prod prostředí.

Další informace najdete v části Kanál sestavení a verze souboru README.

Testování

Řešení zahrnuje podporu testování jednotek i integračního testování. Používá architekturu pytest-Data Factory a Nutter Testing Framework. Další informace najdete v části Testování souboru README.

Pozorovatelnost a monitorování

Řešení podporuje pozorovatelnost a monitorování pro Databricks a Data Factory. Další informace naleznete v části Pozorovatelnost/Monitorování souboru README.

Další kroky

Pokud chcete řešení nasadit, postupujte podle kroků v části Použití ukázkového souboru README DataOps – Parking Sensor Demo .

Ukázky kódu řešení na GitHubu

• Navštivte stránku projektu na GitHubu.

Pozorovatelnost/monitorování

Azure Databricks

• Monitorování Azure Databricks pomocí Služby Azure Monitor
• Monitorování úloh Azure Databricks pomocí Application Insights

Data Factory

• Monitorování služby Azure Data Factory pomocí služby Azure Monitor
• Vytváření upozornění pro proaktivní monitorování kanálů datové továrny

Azure Synapse Analytics

• Monitorování využití prostředků a aktivity dotazů ve službě Azure Synapse Analytics
• Monitorování úloh fondu SQL služby Azure Synapse Analytics pomocí zobrazení dynamické správy

Azure Storage

• Monitorování služby Azure Storage

Odolnost a zotavení po havárii

Azure Databricks

• Regionální zotavení po havárii pro clustery Azure Databricks

Data Factory

• Vytvoření a konfigurace místního prostředí Integration Runtime – Vysoká dostupnost a škálovatelnost

Azure Synapse Analytics

• Geografické zálohy a zotavení po havárii
• Geografické obnovení pro fond SQL

Azure Storage

• Zotavení po havárii a převzetí služeb při selhání účtu úložiště
• Osvědčené postupy pro používání Azure Data Lake Storage Gen2 – vysoká dostupnost a zotavení po havárii
• Redundance služby Azure Storage

Podrobný postup

Podrobný návod k řešení a klíčovým konceptům najdete v následujícím záznamu videa: DataDevOps pro moderní datový sklad v Microsoft Azure.

Související prostředky

• Monitorování Azure Databricks pomocí Služby Azure Monitor