DataOps pro moderní datový sklad

Azure Data Factory

Azure Databricks

Azure DevOps

Azure Key Vault

Azure Synapse Analytics

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í.

Architecture

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

Načte soubor Visio této architektury.

Tok dat

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

Následující tok dat odpovídá předchozímu diagramu:

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

2. Existuje úloha kopírování v datové továrně, která přenáší data do přistávacího schématu.

3. V dalším kroku Azure Databricks data vyčistí a standardizuje. Bere surová data a připravuje je pro použití datovými vědci.

4. Pokud ověření odhalí jakákoli chybná data, převedou se do schématu Neplatné.

   Important

   Lidé se ptali, proč se data neověřují, než jsou uložená v 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 vytvoříte chybu, můžete chybu opravit a znovu spustit pipeline. Pokud jste před jeho přidáním do Data Lake Storage odstranili chybná data, jsou poškozená data k ničemu, protože potrubí nelze znovu spustit.

5. Existuje druhý Azure Databricks transformační krok, který převede data do formátu, který můžete uložit v datovém skladu.

6. Nakonec zpracovatelský řetězec zajišťuje data dvěma různými způsoby:

   1. Databricks zpřístupňuje data datovému vědci, aby mohl trénovat modely.

   2. PolyBase přesouvá data z datového jezera do Azure Synapse Analytics a Power BI k nim přistupuje a prezentuje je firemním uživatelům.

Components

• Azure Data Factory je cloudová služba pro integraci dat, která umožňuje přesun a orchestraci dat. Ve této architektuře zahájí pipeline zkopírováním dat z rozhraní API webové služby Contoso pro parkování do vstupní zóny datového jezera.

• Azure Data Lake Storage Gen2 je škálovatelné a zabezpečené datové jezero založené na Azure Blob Storage, které podporuje vrstvené úložiště a znovu přehrátelné kanály. V této architektuře slouží jako centrální úložiště pro nezpracovaná i zpracovávaná data napříč cílovými, poškozenými a ověřenými datovými zónami.

• Azure Databricks je analytická platforma založená na Apache Sparku určená pro velké objemy dat a strojové učení. V této architektuře provádí dva kritické kroky transformace. Nejprve vyčistí a standardizuje nezpracovaná data při filtrování poškozených záznamů na samostatné schéma. Pak převede ověřená data do formátu vhodného pro úložiště datového skladu a zpřístupňuje zpracovávaná data datovým vědcům pro trénování modelu.

• Azure Key Vault je zabezpečená cloudová služba pro správu tajných kódů, klíčů a certifikátů. V této architektuře ukládá citlivá nastavení konfigurace a přihlašovací údaje používané v celém kanálu a poskytuje centralizovanou a zabezpečenou správu konfigurace.

• Azure Synapse Analytics je integrovaná analytická služba, která kombinuje možnosti velkých objemů dat a datových skladů. V této architektuře slouží jako datový sklad, který přijímá transformovaná data z Data Lake Storage prostřednictvím PolyBase za účelem dotazování a vytváření sestav.

• Power BI je nástroj pro obchodní analýzy, který poskytuje interaktivní vizualizace a řídicí panely. V této architektuře se připojuje k Azure Synapse Analytics prezentovat přehledy dat o využití parkování pro plánovače měst pro informované rozhodování.

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í

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 o 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ů.

Considerations

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

Důležité informace v této části shrnují klíčové poznatky a osvědčené postupy, které toto řešení demonstruje:

• Používejte vrstvení dat v datovém jezeře. Uchovat neupravená zdrojová data ve vstupní zóně, směrovat záznamy, které neprojdou validací, do zóny chybných dat a transformovat validovaná data do formátu připraveného pro datový sklad. Zachování zdrojových dat vám umožní znovu je zpracovat bez návratu do zdrojového systému. Obdobný lakehouse vzor s vrstvami bronz, stříbro a zlato viz medailonová architektura.

• Zajistěte, aby vaše datové pipeline byly znovu spustitelné a idempotentní. Navrhněte kroky transformace tak, aby jejich opakování přes stejný vstup vedlo ke stejnému výsledku. Opětovné přehrání kanálu umožňuje opravit chybu v logice transformace a znovu zpracovat historická data místo toho, abyste je zahodili.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace naleznete v dokumentu Kontrolní seznam návrhu zabezpečení.

• Zabezpečená a centralizovaná konfigurace Ukládat připojovací řetězce, klíče a další tajné kódy v Key Vault místo v poznámkových blocích, definicích kanálů nebo správě zdrojového kódu. Odkazujte na ně z propojených služeb Data Factory a z oblastí tajných kódů Azure Databricks tak, aby si každé prostředí určilo své vlastní hodnoty.

Efektivita provozu

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.

• Ověřujte data co nejdříve ve své pipeline. Použijte kontroly schématu a kvality v prvním kroku transformace a směrujte záznamy, které selžou do poškozeného schématu. Předčasné ověření uchovává vadné záznamy mimo podřízené úrovně a poskytuje vám záznam o tom, co bylo odmítnuto a proč.

• Ujistěte se, že je kód transformace dat testovatelný. Rozdělte logiku transformace do funkcí a modulů, které běží mimo notebook, abyste je mohli pokrýt jednotkovými testy v kanálu pro ověřování pull requestů.

• Mějte CI/CD pipeline. Sestavte a uvolněte každé prostředí ze správy zdrojového kódu, a ne ručně. Informace o mechanismu specifickém pro technologie najdete v tématu CI/CD v Azure Data Factory a CI/CD na Azure Databricks.

• Monitorování infrastruktury, kanálů a dat Shromažďujte metriky a logy z každé vrstvy, aby se selhání projevilo jako výstraha, a ne jako neaktuální report. Další informace najdete v tématu Monitorování služby Data Factory.

Nasazení tohoto scénáře

Následující seznam obsahuje základní kroky potřebné k nastavení tohoto řešení s odpovídajícími kanály buildu a verze.

Nastavení a nasazení

1. Počáteční nastavení: Nainstalujte všechny požadavky, vytvořte úložiště Git, které obsahuje infrastrukturu, poznámkový blok a kód kanálu, a nastavte požadované proměnné prostředí.

2. Nasazení Azure prostředků: K nasazení prostředků Azure a instančních objektů služby Microsoft Entra pro jednotlivá prostředí použijte nasazení infrastruktury jako kódu, například pomocí Bicep nebo Terraform. Samostatně nakonfigurujte definice Azure Pipelines, skupiny proměnných a připojení ke službám, které spouštějí nasazení infrastruktury.

3. Nastavení integrace Gitu ve službě Dev Data Factory: Nakonfigurujte integraci Gitu tak, aby se vývojová datová továrna zapíše do vašeho úložiště.

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.

Kontinuální integrace a kontinuální doručování (CI/CD)

Následující diagram znázorňuje proces CI/CD a posloupnost kanálů sestavení a verzí.

Načte soubor Visio této architektury.

1. Vývojáři pracují ve svých vlastních sandboxových prostředích v rámci skupiny zdrojů pro vývoj a commitují změny do svých vlastních krátkodobých větví Git. Například: <developer_name>/<branch_name>.

2. Po dokončení změn vývojáři vytvoří pull request (PR) do hlavní větve ke kontrole. Tím se automaticky spustí kanál validace PR, který provádí jednotkové testy, lintování a sestavení balíčku aplikace datové vrstvy (DACPAC).

3. Po dokončení ověření pull requestu způsobí commit do hlavní větve spuštění sestavovacího kanálu, který publikuje všechny potřebné artefakty sestavení.

4. Dokončení úspěšného sestavovacího kanálu spustí první etapu kanálu nasazení. Tím nasadíte publikované artefakty sestavení do vývojového prostředí, s výjimkou služby Data Factory.

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

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

   Po schválení nasazovací kanál pokračuje ve druhé fázi a nasazuje změny do stagovacího prostředí.

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í.

   Po schválení vydávací kanál pokračuje ve třetí fázi a nasazuje změny do produkčního prostředí.

Další informace o implementaci těchto fází najdete v tématu CI/CD v Azure Data Factory.

Testing

Řešení zahrnuje podporu testování jednotek i integračního testování. Jednotkové testy pokrývají transformační moduly v Pythonu a integrační testy spouštějí pipeline ve službě Data Factory a ověřují její výstup jako součást nasazení do stagingového prostředí. Další informace najdete v tématu Testování jednotek pro poznámkové bloky.

Pozorovatelnost a monitorování

Řešení podporuje pozorovatelnost a monitorování pro Databricks a Data Factory. V Databricks používejte integrované protokolování auditů platformy (tabulku system.access.audit) a monitorování spuštění úloh namísto toho, abyste ve výchozím nastavení exportovali veškerou diagnostiku. Pokud potřebujete doručovat diagnostické protokoly Databricks do pracovního prostoru Log Analytics pro centralizované výstrahy, tato funkce vyžaduje plán Premium, platí pro protokoly místo metrik a vyžaduje pečlivé řízení přístupu, protože protokoly auditu můžou obsahovat citlivé podrobnosti o vašem nasazení. Pro službu Data Factory směrujte diagnostické protokoly a metriky do pracovního prostoru Log Analytics a nastavte upozornění na selhání pipeline a prodlevu úlohy. Další informace najdete v tématu Monitorování služby Data Factory.

Další kroky

Následující zdroje informací vám pomůžou implementovat postupy DataOps, které tento článek popisuje.

Průběžná integrace a doručování

• CI/CD v Azure Data Factory
• CI/CD na Azure Databricks

Observability/monitoring

Azure Databricks

• Sledování úloh Azure Databricks pomocí Application Insights

Data Factory

• Monitorování služby Azure Data Factory
• Vytvořte upozornění pro proaktivní monitorování procesů v datové továrně

Azure Synapse Analytics

• Monitoring využití prostředků a aktivity dotazů v Azure Synapse Analytics
• Monitorujte pracovní zátěž fondu Azure Synapse Analytics SQL pomocí zobrazení dynamické správy

Azure Storage

• Monitorování služby Azure Storage

Odolnost a zotavení po havárii

Azure Databricks

• Zotavení po havárii pro 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á obnova pro SQL Pool

Azure Storage

• Zotavení po havárii a převzetí služeb účtu úložiště po selhání
• Návrh Azure úložiště pro zajištění vysoké dostupnosti
• Azure Storage redundance

Podrobný přehled

Podrobný přehled řešení a klíčových konceptů najdete v následujícím záznamu videa: DataDevOps pro moderní Data Warehouse na Microsoft Azure

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í.

Architecture

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

Načte soubor Visio této architektury.

Tok dat

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

Následující tok dat odpovídá předchozímu diagramu:

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

2. Existuje úloha kopírování v datové továrně, která přenáší data do přistávacího schématu.

3. V dalším kroku Azure Databricks data vyčistí a standardizuje. Bere surová data a připravuje je pro použití datovými vědci.

4. Pokud ověření odhalí jakákoli chybná data, převedou se do schématu Neplatné.

   Important

   Lidé se ptali, proč se data neověřují, než jsou uložená v 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 vytvoříte chybu, můžete chybu opravit a znovu spustit pipeline. Pokud jste před jeho přidáním do Data Lake Storage odstranili chybná data, jsou poškozená data k ničemu, protože potrubí nelze znovu spustit.

5. Existuje druhý Azure Databricks transformační krok, který převede data do formátu, který můžete uložit v datovém skladu.

6. Nakonec zpracovatelský řetězec zajišťuje data dvěma různými způsoby:

   1. Databricks zpřístupňuje data datovému vědci, aby mohl trénovat modely.

   2. PolyBase přesouvá data z datového jezera do Azure Synapse Analytics a Power BI k nim přistupuje a prezentuje je firemním uživatelům.

Components

• Azure Data Factory je cloudová služba pro integraci dat, která umožňuje přesun a orchestraci dat. Ve této architektuře zahájí pipeline zkopírováním dat z rozhraní API webové služby Contoso pro parkování do vstupní zóny datového jezera.

• Azure Data Lake Storage Gen2 je škálovatelné a zabezpečené datové jezero založené na Azure Blob Storage, které podporuje vrstvené úložiště a znovu přehrátelné kanály. V této architektuře slouží jako centrální úložiště pro nezpracovaná i zpracovávaná data napříč cílovými, poškozenými a ověřenými datovými zónami.

• Azure Databricks je analytická platforma založená na Apache Sparku určená pro velké objemy dat a strojové učení. V této architektuře provádí dva kritické kroky transformace. Nejprve vyčistí a standardizuje nezpracovaná data při filtrování poškozených záznamů na samostatné schéma. Pak převede ověřená data do formátu vhodného pro úložiště datového skladu a zpřístupňuje zpracovávaná data datovým vědcům pro trénování modelu.

• Azure Key Vault je zabezpečená cloudová služba pro správu tajných kódů, klíčů a certifikátů. V této architektuře ukládá citlivá nastavení konfigurace a přihlašovací údaje používané v celém kanálu a poskytuje centralizovanou a zabezpečenou správu konfigurace.

• Azure Synapse Analytics je integrovaná analytická služba, která kombinuje možnosti velkých objemů dat a datových skladů. V této architektuře slouží jako datový sklad, který přijímá transformovaná data z Data Lake Storage prostřednictvím PolyBase za účelem dotazování a vytváření sestav.

• Power BI je nástroj pro obchodní analýzy, který poskytuje interaktivní vizualizace a řídicí panely. V této architektuře se připojuje k Azure Synapse Analytics prezentovat přehledy dat o využití parkování pro plánovače měst pro informované rozhodování.

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í

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 o 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ů.

Considerations

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

Důležité informace v této části shrnují klíčové poznatky a osvědčené postupy, které toto řešení demonstruje:

• Používejte vrstvení dat v datovém jezeře. Uchovat neupravená zdrojová data ve vstupní zóně, směrovat záznamy, které neprojdou validací, do zóny chybných dat a transformovat validovaná data do formátu připraveného pro datový sklad. Zachování zdrojových dat vám umožní znovu je zpracovat bez návratu do zdrojového systému. Obdobný lakehouse vzor s vrstvami bronz, stříbro a zlato viz medailonová architektura.

• Zajistěte, aby vaše datové pipeline byly znovu spustitelné a idempotentní. Navrhněte kroky transformace tak, aby jejich opakování přes stejný vstup vedlo ke stejnému výsledku. Opětovné přehrání kanálu umožňuje opravit chybu v logice transformace a znovu zpracovat historická data místo toho, abyste je zahodili.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace naleznete v dokumentu Kontrolní seznam návrhu zabezpečení.

• Zabezpečená a centralizovaná konfigurace Ukládat připojovací řetězce, klíče a další tajné kódy v Key Vault místo v poznámkových blocích, definicích kanálů nebo správě zdrojového kódu. Odkazujte na ně z propojených služeb Data Factory a z oblastí tajných kódů Azure Databricks tak, aby si každé prostředí určilo své vlastní hodnoty.

Efektivita provozu

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.

• Ověřujte data co nejdříve ve své pipeline. Použijte kontroly schématu a kvality v prvním kroku transformace a směrujte záznamy, které selžou do poškozeného schématu. Předčasné ověření uchovává vadné záznamy mimo podřízené úrovně a poskytuje vám záznam o tom, co bylo odmítnuto a proč.

• Ujistěte se, že je kód transformace dat testovatelný. Rozdělte logiku transformace do funkcí a modulů, které běží mimo notebook, abyste je mohli pokrýt jednotkovými testy v kanálu pro ověřování pull requestů.

• Mějte CI/CD pipeline. Sestavte a uvolněte každé prostředí ze správy zdrojového kódu, a ne ručně. Informace o mechanismu specifickém pro technologie najdete v tématu CI/CD v Azure Data Factory a CI/CD na Azure Databricks.

• Monitorování infrastruktury, kanálů a dat Shromažďujte metriky a logy z každé vrstvy, aby se selhání projevilo jako výstraha, a ne jako neaktuální report. Další informace najdete v tématu Monitorování služby Data Factory.

Nasazení tohoto scénáře

Následující seznam obsahuje základní kroky potřebné k nastavení tohoto řešení s odpovídajícími kanály buildu a verze.

Nastavení a nasazení

1. Počáteční nastavení: Nainstalujte všechny požadavky, vytvořte úložiště Git, které obsahuje infrastrukturu, poznámkový blok a kód kanálu, a nastavte požadované proměnné prostředí.

2. Nasazení Azure prostředků: K nasazení prostředků Azure a instančních objektů služby Microsoft Entra pro jednotlivá prostředí použijte nasazení infrastruktury jako kódu, například pomocí Bicep nebo Terraform. Samostatně nakonfigurujte definice Azure Pipelines, skupiny proměnných a připojení ke službám, které spouštějí nasazení infrastruktury.

3. Nastavení integrace Gitu ve službě Dev Data Factory: Nakonfigurujte integraci Gitu tak, aby se vývojová datová továrna zapíše do vašeho úložiště.

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.

Kontinuální integrace a kontinuální doručování (CI/CD)

Následující diagram znázorňuje proces CI/CD a posloupnost kanálů sestavení a verzí.

Načte soubor Visio této architektury.

1. Vývojáři pracují ve svých vlastních sandboxových prostředích v rámci skupiny zdrojů pro vývoj a commitují změny do svých vlastních krátkodobých větví Git. Například: <developer_name>/<branch_name>.

2. Po dokončení změn vývojáři vytvoří pull request (PR) do hlavní větve ke kontrole. Tím se automaticky spustí kanál validace PR, který provádí jednotkové testy, lintování a sestavení balíčku aplikace datové vrstvy (DACPAC).

3. Po dokončení ověření pull requestu způsobí commit do hlavní větve spuštění sestavovacího kanálu, který publikuje všechny potřebné artefakty sestavení.

4. Dokončení úspěšného sestavovacího kanálu spustí první etapu kanálu nasazení. Tím nasadíte publikované artefakty sestavení do vývojového prostředí, s výjimkou služby Data Factory.

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

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

   Po schválení nasazovací kanál pokračuje ve druhé fázi a nasazuje změny do stagovacího prostředí.

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í.

   Po schválení vydávací kanál pokračuje ve třetí fázi a nasazuje změny do produkčního prostředí.

Další informace o implementaci těchto fází najdete v tématu CI/CD v Azure Data Factory.

Testing

Řešení zahrnuje podporu testování jednotek i integračního testování. Jednotkové testy pokrývají transformační moduly v Pythonu a integrační testy spouštějí pipeline ve službě Data Factory a ověřují její výstup jako součást nasazení do stagingového prostředí. Další informace najdete v tématu Testování jednotek pro poznámkové bloky.

Pozorovatelnost a monitorování

Řešení podporuje pozorovatelnost a monitorování pro Databricks a Data Factory. V Databricks používejte integrované protokolování auditů platformy (tabulku system.access.audit) a monitorování spuštění úloh namísto toho, abyste ve výchozím nastavení exportovali veškerou diagnostiku. Pokud potřebujete doručovat diagnostické protokoly Databricks do pracovního prostoru Log Analytics pro centralizované výstrahy, tato funkce vyžaduje plán Premium, platí pro protokoly místo metrik a vyžaduje pečlivé řízení přístupu, protože protokoly auditu můžou obsahovat citlivé podrobnosti o vašem nasazení. Pro službu Data Factory směrujte diagnostické protokoly a metriky do pracovního prostoru Log Analytics a nastavte upozornění na selhání pipeline a prodlevu úlohy. Další informace najdete v tématu Monitorování služby Data Factory.

Další kroky

Následující zdroje informací vám pomůžou implementovat postupy DataOps, které tento článek popisuje.

Průběžná integrace a doručování

• CI/CD v Azure Data Factory
• CI/CD na Azure Databricks

Observability/monitoring

Azure Databricks

• Sledování úloh Azure Databricks pomocí Application Insights

Data Factory

• Monitorování služby Azure Data Factory
• Vytvořte upozornění pro proaktivní monitorování procesů v datové továrně

Azure Synapse Analytics

• Monitoring využití prostředků a aktivity dotazů v Azure Synapse Analytics
• Monitorujte pracovní zátěž fondu Azure Synapse Analytics SQL pomocí zobrazení dynamické správy

Azure Storage

• Monitorování služby Azure Storage

Odolnost a zotavení po havárii

Azure Databricks

• Zotavení po havárii pro 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á obnova pro SQL Pool

Azure Storage

• Zotavení po havárii a převzetí služeb účtu úložiště po selhání
• Návrh Azure úložiště pro zajištění vysoké dostupnosti
• Azure Storage redundance

Podrobný přehled

Podrobný přehled řešení a klíčových konceptů najdete v následujícím záznamu videa: DataDevOps pro moderní Data Warehouse na Microsoft Azure