最新のデータ ウェアハウス向けのDataOps

この記事では、架空の都市計画室でこのソリューションをどのように使用できるかについて説明します。 このソリューションでは、MDW アーキテクチャ パターンに従うエンドツーエンドのデータ パイプラインを、対応する DevOps および DataOps プロセスと共に提供し、駐車の使用を評価して、より多くの情報に基づくビジネス上の意思決定を行います。

Architecture

次の図は、ソリューションの全体的なアーキテクチャを示しています。

このアーキテクチャのVisio ファイルをダウンロードしてください。

データ フロー

Azure Data Factoryがデータをオーケストレーションし、Azure Data Lake Storage Gen2がデータを格納します。

次のデータ フローは、前の図に対応しています。

1. Contoso の都市駐車 Web サービス API は、駐車場からデータを転送するために利用できます。

2. データをランディング スキーマに転送するデータ ファクトリ コピー ジョブがあります。

3. 次に、Azure Databricksはデータをクリーンアップして標準化します。 生のデータを整備して、データサイエンティストが使用できるようにします。

4. 検証によって不正データがあることが判明した場合、それは不正スキーマにダンプされます。

   Important

   データがData Lake Storageに格納される前にデータが検証されない理由を尋ねられた。 理由は、データセットが破損する可能性のあるバグが検証時に発生する場合があるためです。 この手順でバグが発生した場合は、そのバグを修正してパイプラインを再生できます。 不適切なデータをData Lake Storageに追加する前にダンプした場合、パイプラインを再生できないため、破損したデータは役に立ちません。

5. データウェアハウスに格納できる形式にデータを変換する 2 つ目のAzure Databricks変換手順があります。

6. 最後に、パイプラインによって、次の 2 つの異なる方法でデータが提供されます。

   1. Databricks を利用すると、データ サイエンティストはデータを使用できるようになり、モデルをトレーニングすることができます。

   2. Polybase はデータ レイクからデータを Azure Synapse Analytics に移動し、Power BI がそのデータにアクセスしてビジネスユーザーに提示します。

Components

• Azure Data Factory は、データの移動とオーケストレーションを可能にするクラウドベースのデータ統合サービスです。 このアーキテクチャでは、Contoso 市の駐車 Web サービス API からデータ レイクのランディング ゾーンにデータをコピーして、パイプラインを開始します。

• Azure Data Lake Storage Gen2 は、階層化されたストレージと再生可能なパイプラインをサポートするAzure Blob Storage上に構築された、スケーラブルで安全なデータ レイクです。 このアーキテクチャでは、着地ゾーン、不正な形式ゾーン、検証済みゾーンにわたる生データと処理済みデータの両方の中央リポジトリとして機能します。

• Azure Databricks は、ビッグ データと機械学習用に設計された Apache Spark ベースの分析プラットフォームです。 このアーキテクチャでは、2 つの重要な変換手順を実行します。 まず、形式が正しくないレコードを別のスキーマにフィルター処理しながら、生データをクリーンアップして標準化します。 次に、検証済みのデータをデータ ウェアハウスストレージに適した形式に変換し、処理されたデータをモデルトレーニングのためにデータ サイエンティストが使用できるようにします。

• Azure Key Vault は、シークレット、キー、証明書を管理するためのセキュリティで保護されたクラウド サービスです。 このアーキテクチャでは、パイプライン全体で使用される機密性の高い構成設定と資格情報を格納し、一元的で安全な構成管理を提供します。

• Azure Synapse Analytics は、ビッグ データとデータ ウェアハウス機能を組み合わせた統合分析サービスです。 このアーキテクチャでは、クエリとレポートのために PolyBase を介してData Lake Storageから変換されたデータを取り込むデータ ウェアハウスとして機能します。

• Power BI は、対話型の視覚化とダッシュボードを提供するビジネス分析ツールです。 このアーキテクチャでは、Azure Synapse Analyticsに接続して、情報に基づいた意思決定を行うために、駐車使用状況データの分析情報を都市プランナーに提示します。

シナリオの詳細

最新のデータ ウェアハウス (MDW) を使用すると、すべてのデータをあらゆる規模で簡単にまとめることができます。 データが構造化、非構造化、あるいは半構造化であるかどうかは関係ありません。 すべてのユーザーの分析ダッシュボード、操作レポート、または高度な分析を通じて、MDW に関する分析情報を得ることができます。

開発と運用の両方の環境に対する MDW 環境の設定は複雑です。 プロセスの自動化が鍵となります。 これは、エラーのリスクを最小限に抑えながら、生産性を向上させるのに役立ちます。

この記事では、架空の都市計画室でこのソリューションをどのように使用できるかについて説明します。 このソリューションでは、MDW アーキテクチャ パターンに従うエンドツーエンドのデータ パイプラインを、対応する DevOps および DataOps プロセスと共に提供し、駐車の使用を評価して、より多くの情報に基づくビジネス上の意思決定を行います。

ソリューションの要件

• さまざまなソースまたはシステムからデータを収集する機能。

• コードとしてのインフラストラクチャ: 自動化された方法で新しい開発およびステージング環境をデプロイします。

• 自動化された方法でさまざまな環境間にアプリケーションの変更をデプロイする:

  • 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを実装します。

  • デプロイメント ゲートを手動承認に使用します。

• コードとしてのパイプライン: CI/CD パイプラインの定義が確実にソース管理に含まれるようにします。

• サンプル データ セットを使用して、変更に対する統合テストを実行します。

• スケジュールに従ってパイプラインを実行します。

• データ サイエンス ワークロードの追加など、将来のアジャイル開発をサポートします。

• 行レベルとオブジェクト レベルの両方のセキュリティのサポート:

  • セキュリティ機能は SQL Database で利用できます。

  • Azure Synapse Analytics、Azure Analysis Services、Power BIで見つけることもできます。

• 10人のダッシュボード同時ユーザーと20人の同時パワーユーザーをサポート。

• データ パイプラインは、データ検証を実行し、形式が不正なレコードを指定されたストアへ除外する必要があります。

• 監視をサポートします。

考えられるユース ケース

この記事では、Contoso という架空の都市を使用してユース ケース シナリオについて説明します。 この物語では、Contoso によって都市の駐車センサーが所有され、管理されています。 また、センサーに接続してデータを取得する API も所有しています。 多くの異なるソースからデータを収集するプラットフォームが必要です。 その後、データを検証し、クレンジングして、既知のスキーマに変換する必要があります。 Contoso の都市プランナーは、Power BIなどのデータ視覚化ツールを使用して、駐車場の使用に関するレポート データを調査して評価し、駐車場や関連リソースが必要かどうかを判断できます。

Considerations

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

このセクションの考慮事項は、このソリューションによって示される主な学習とベスト プラクティスをまとめたものです。

• データレイクでデータの階層化を利用します。 変更されていないソース データをランディング ゾーンに保持し、検証に失敗したレコードを正しくないゾーンにルーティングし、検証されたデータをウェアハウス対応の形式に変換します。 ソース データを保持すると、ソース システムに戻らずに再処理できます。 対応するブロンズ、シルバー、ゴールドのレイクハウス パターンについては、メダリオン アーキテクチャを参照してください。

• データパイプラインを再実行可能かつ冪等にしましょう。 同じ入力に対して再実行すると同じ結果が生成されるように、変換手順を設計します。 パイプラインを再生すると、変換ロジックの欠陥を修正し、履歴データを破棄するのではなく再処理することができます。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、セキュリティ設計レビューのチェックリストを参照してください。

• セキュリティで保護された一元化された構成。 ノートブック、パイプライン定義、またはソース管理ではなく、接続文字列、キー、その他のシークレットをKey Vaultに格納します。 各環境が独自の値を解決できるように、Data Factory のリンクされたサービスとAzure Databricksシークレット スコープからそれらを参照します。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「 オペレーショナル エクセレンスの設計レビュー チェックリスト」を参照してください。

• パイプラインの早い段階でデータを検証します。 最初の変換手順でスキーマと品質チェックを適用し、正しくないスキーマに失敗したレコードをルーティングします。 早期検証により、不良レコードがダウンストリーム層に流入するのを防ぎ、何がなぜ拒否されたかの記録を残すことができます。

• データ変換コードがテスト可能であることを確認します。 ノートブックの外部で実行される関数とモジュールへの要素変換ロジックを使用して、プル要求検証パイプラインの 単体テスト でカバーできるようにします。

• CI/CD パイプラインを導入する。 手動ではなく、ソース管理からすべての環境をビルドして解放します。 テクノロジ固有のメカニズムについては、Azure Data Factoryの CI/CD と Azure Databricksの CI/CD を参照してください。

• インフラストラクチャ、パイプライン、データを監視します。 各レイヤーからメトリックとログを収集して、古いレポートではなくアラートとして障害が発生するようにします。 詳細については、「Data Factory の監視」を参照してください。

このシナリオを展開します

次の一覧には、対応するビルドおよびリリース パイプラインを使用してこのソリューションを設定するために必要な大まかな手順が含まれています。

設定とデプロイ

1. 初期セットアップ: 前提条件をインストールし、インフラストラクチャ、ノートブック、パイプライン コードを保持する Git リポジトリを作成し、必要な環境変数を設定します。

2. Azure リソースのデプロイ: Bicepや Terraform などのコードデプロイとしてインフラストラクチャを使用して、環境ごとにAzure リソースとMicrosoft Entraサービス プリンシパルをデプロイします。 インフラストラクチャのデプロイを呼び出すAzure Pipelines定義、変数グループ、およびサービス接続を個別に構成します。

3. Dev Data Factory で Git 統合を設定する: 開発データ ファクトリがリポジトリにコミットされるように Git 統合を構成 します。

4. 初期ビルドおよびリリースを実行する: スケジュール トリガーの有効化など、Data Factory でサンプルを変更し、環境間で自動的にデプロイされる変更を監視します。

継続的インテグレーションと継続的デリバリー (CI/CD)

次の図は、ビルド パイプラインとリリース パイプラインの CI/CD プロセスとシーケンスを示しています。

このアーキテクチャのVisio ファイルをダウンロードしてください。

1. 開発者は開発リソース グループ内の独自のサンドボックス環境で開発を行い、有効期間が短い Git ブランチに変更をコミットします。 たとえば、「 <developer_name>/<branch_name> 」のように入力します。

2. 変更が完了すると、開発者はレビューのためにメイン ブランチに対して pull request (PR) を行います。 これにより、単体テスト、linting、およびデータ層アプリケーション パッケージ (DACPAC) ビルドを実行する PR 検証パイプラインが自動的に開始されます。

3. PR 検証の完了時に、メインにコミットすると、必要なすべてのビルド成果物を公開するビルド パイプラインがトリガーされます。

4. 正常なビルド パイプラインが完了すると、リリース パイプラインの最初のステージがトリガーされます。 これにより、Data Factory を除き、開発環境に公開ビルド成果物がデプロイされます。

   開発者は、コラボレーション ブランチ (メイン) から開発 Data Factory に手動で公開します。 手動発行では、adf_publish ブランチのAzure Resource Manager テンプレートが更新されます。

5. 最初のステージが正常に完了すると、手動承認ゲートがトリガーされます。

   承認されると、リリース パイプラインは 2 番目のステージに進み、変更をステージング環境にデプロイします。

6. 統合テストを実行し、ステージング環境で変更をテストします。

7. 2 番目のステージが正常に完了すると、パイプラインによって 2 番目の手動承認ゲートがトリガーされます。

   承認されると、リリース パイプラインは 3 番目のステージに進み、運用環境に変更をデプロイします。

これらのステージの実装の詳細については、Azure Data Factoryの CI/CD を参照してください。

Testing

このソリューションには、単体テストと統合テストの両方のサポートが含まれています。 単体テストでは、Python変換モジュールが対象となり、統合テストによって Data Factory パイプラインがトリガーされ、ステージング環境へのリリースの一部としてその出力が検証されます。 詳細については、「 ノートブックの単体テスト」を参照してください。

可観測性と監視

このソリューションでは、Databricks および Data Factory の可観測性と監視がサポートされます。 Databricks の場合は、既定ですべての診断をエクスポートするのではなく、プラットフォームの組み込みの監査ログ ( system.access.audit テーブル) とジョブ実行監視を使用します。 Databricks 診断ログをLog Analytics ワークスペースに配信して一元的なアラートを生成する必要がある場合、その機能には Premium プランが必要であり、メトリックではなくログに適用され、監査ログにはデプロイに関する機密情報が含まれる可能性があるため、慎重なアクセス制御が必要です。 Data Factory の場合、診断ログとメトリックを Log Analytics ワークスペースにルーティングし、パイプラインの障害とジョブの待機時間に関するアラートを設定します。 詳細については、「Data Factory を監視する」を参照してください。

次のステップ

次のリソースは、この記事で説明する DataOps プラクティスの実装に役立ちます。

継続的インテグレーションと配信

• Azure Data Factoryの CI/CD
• Azure Databricks での CI/CD

Observability/monitoring

Azure Databricks

• Application Insights を使用して行う Azure Databricks ジョブの監視

Data Factory

• Azure Data Factory を Azure Monitor で監視する
• データ ファクトリ パイプラインを事前に監視するためのアラートを作成する

Azure Synapse Analytics

• Azure Synapse Analytics
• Azure Synapse Analytics SQL プールワークロードを DMVs を使用して監視します

Azure Storage

• Azure Storage を監視する

回復性とディザスター リカバリー

Azure Databricks

• Azure Databricks クラスターのリージョナル ディザスター リカバリー

Data Factory

• セルフホステッド統合ランタイムを作成して構成する - 高可用性とスケーラビリティ

Azure Synapse Analytics

• ジオバックアップと災害復旧
• SQL プールのジオリストア

Azure Storage

• 災害復旧とストレージアカウントのフェールオーバー
• Azure Data Lake Storage Gen2の使用に関するベスト プラクティス - 高可用性とディザスター リカバリー
• Azure Storage冗長性

詳細な概要

ソリューションと主要な概念の詳細な概要については、DataDevOps for the Modern Data Warehouse on Microsoft Azure