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:

Note

Jednotlivé aspekty v této části odkazuje na související oddíl Klíčové učení v dokumentaci k příkladu řešení senzoru parkování na GitHub.

• Používejte vrstvení dat ve svém datovém jezeře

• Učiňte své datové kanály opakovatelnými a idempotentními.

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čte a centralizujte konfiguraci.

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.

• Validujte data v rané fázi pipeline.

• Zajistěte, aby byl kód transformace dat testovatelný.

• Mějte CI/CD pipeline.

• Monitor 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ích senzorů s odpovídajícími kanály sestavení a vydání. Podrobný postup nastavení a požadavky najdete v tomto úložišti ukázek Azure.

Nastavení a nasazení

1. Inicializace nastavení: Nainstalujte všechny předpoklady, importujte úložiště GitHub s ukázkami Azure do vlastního úložiště a nastavte požadované proměnné prostředí.

2. Nasadit Azure prostředky: Řešení obsahuje automatizovaný skript nasazení. Nasadí všechny potřebné prostředky Azure a služební principály Microsoft Entra pro každé prostředí. Skript také nasadí Azure Pipelines, variabilní skupiny a služební připojení.

3. Nastavte integraci 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 ve 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 sestavení 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 části DataOps - Parking Sensor Demo README.

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 najdete v oddílu Build and Release Pipeline souboru README.

Testing

Ř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 Testing souboru README.

Pozorovatelnost a monitorování

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

Další kroky

Pokud chcete řešení nasadit, postupujte podle kroků v Použít ukázku části DataOps – Ukázka parkovacího senzoru README.

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

• Visit stránku projektu na GitHub

Observability/monitoring

Azure Databricks

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

Data Factory

• Sledujte Azure Data Factory pomocí Azure Monitor
• 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

• Monitor 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á obnova pro SQL Pool

Azure Storage

• Zotavení po havárii a převzetí služeb účtu úložiště po selhání
• Best postupy pro používání Azure Data Lake Storage Gen2 – vysoká dostupnost a zotavení po havárii
• 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:

Note

Jednotlivé aspekty v této části odkazuje na související oddíl Klíčové učení v dokumentaci k příkladu řešení senzoru parkování na GitHub.

• Používejte vrstvení dat ve svém datovém jezeře

• Učiňte své datové kanály opakovatelnými a idempotentními.

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čte a centralizujte konfiguraci.

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.

• Validujte data v rané fázi pipeline.

• Zajistěte, aby byl kód transformace dat testovatelný.

• Mějte CI/CD pipeline.

• Monitor 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ích senzorů s odpovídajícími kanály sestavení a vydání. Podrobný postup nastavení a požadavky najdete v tomto úložišti ukázek Azure.

Nastavení a nasazení

1. Inicializace nastavení: Nainstalujte všechny předpoklady, importujte úložiště GitHub s ukázkami Azure do vlastního úložiště a nastavte požadované proměnné prostředí.

2. Nasadit Azure prostředky: Řešení obsahuje automatizovaný skript nasazení. Nasadí všechny potřebné prostředky Azure a služební principály Microsoft Entra pro každé prostředí. Skript také nasadí Azure Pipelines, variabilní skupiny a služební připojení.

3. Nastavte integraci 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 ve 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 sestavení 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 části DataOps - Parking Sensor Demo README.

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 najdete v oddílu Build and Release Pipeline souboru README.

Testing

Ř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 Testing souboru README.

Pozorovatelnost a monitorování

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

Další kroky

Pokud chcete řešení nasadit, postupujte podle kroků v Použít ukázku části DataOps – Ukázka parkovacího senzoru README.

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

• Visit stránku projektu na GitHub

Observability/monitoring

Azure Databricks

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

Data Factory

• Sledujte Azure Data Factory pomocí Azure Monitor
• 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

• Monitor 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á obnova pro SQL Pool

Azure Storage

• Zotavení po havárii a převzetí služeb účtu úložiště po selhání
• Best postupy pro používání Azure Data Lake Storage Gen2 – vysoká dostupnost a zotavení po havárii
• 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