この記事では、架空の都市計画室でこのソリューションをどのように使用できるかについて説明します。 このソリューションでは、MDW アーキテクチャ パターンに従うエンドツーエンドのデータ パイプラインを、対応する DevOps および DataOps プロセスと共に提供し、駐車の使用を評価して、より多くの情報に基づくビジネス上の意思決定を行います。
アーキテクチャ
次の図は、ソリューションの全体的なアーキテクチャを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
データは、Azure Data Factory (ADF) によって調整され、Azure Data Lake Storage (ADLS) Gen2 によって格納されます。
Contoso の都市駐車 Web サービス API は、駐車場からデータを転送するために利用できます。
データをランディング スキーマに転送する ADF コピー ジョブがあります。
次に、Azure Databricks によってデータがクレンジングされ、標準化されます。 データ サイエンティストが使用できるように、生データと条件が取得されます。
検証で無効なデータがあることがわかった場合は、無効な形式スキーマにダンプされます。
重要
データが ADLS に格納される前に検証されないのはなぜでしょうか。 理由は、データセットが破損する可能性のあるバグが検証時に発生する場合があるためです。 この手順でバグが発生した場合は、そのバグを修正してパイプラインを再生できます。 無効なデータを ADLS に追加する前にダンプした場合、パイプラインを再生できないため、破損したデータは役に立ちません。
データ ウェアハウスに格納できる形式にデータを変換する、2 番目の Azure Databricks 変換手順があります。
最後に、パイプラインによって、次の 2 つの異なる方法でデータが提供されます。
Databricks を利用すると、データ サイエンティストはデータを使用できるようになり、モデルをトレーニングすることができます。
Polybase ではデータ レイクから Azure Synapse Analytics にデータを移動し、Power BI ではデータにアクセスしてビジネス ユーザーに提示します。
コンポーネント
このソリューションではこれらのコンポーネントを使用します。
シナリオの詳細
最新のデータ ウェアハウス (MDW) を使用すると、すべてのデータをあらゆる規模で簡単にまとめることができます。 データが構造化、非構造化、あるいは半構造化であるかどうかは関係ありません。 すべてのユーザーの分析ダッシュボード、操作レポート、または高度な分析を通じて、MDW に関する分析情報を得ることができます。
開発と運用の両方の環境に対する MDW 環境の設定は複雑です。 プロセスの自動化が鍵となります。 これは、エラーのリスクを最小限に抑えながら、生産性を向上させるのに役立ちます。
この記事では、架空の都市計画室でこのソリューションをどのように使用できるかについて説明します。 このソリューションでは、MDW アーキテクチャ パターンに従うエンドツーエンドのデータ パイプラインを、対応する DevOps および DataOps プロセスと共に提供し、駐車の使用を評価して、より多くの情報に基づくビジネス上の意思決定を行います。
ソリューションの要件
さまざまなソースまたはシステムからデータを収集する機能。
コードとしてのインフラストラクチャ: 自動化された方法で新しい開発およびステージング環境をデプロイします。
自動化された方法でさまざまな環境間にアプリケーションの変更をデプロイする:
継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインを実装します。
手動による承認でデプロイ ゲートを使用します。
コードとしてのパイプライン: CI/CD パイプラインの定義が確実にソース管理に含まれるようにします。
サンプル データ セットを使用して、変更に対する統合テストを実行します。
スケジュールに従ってパイプラインを実行します。
データ サイエンス ワークロードの追加など、将来のアジャイル開発をサポートします。
行レベルとオブジェクト レベルの両方のセキュリティのサポート:
セキュリティ機能は SQL Database で利用できます。
また、Azure Synapse Analytics、Azure Analysis Services (AAS)、Power BI で見つけることもできます。
10 人のダッシュボードの同時ユーザーと 20 人の同時パワー ユーザーのサポート。
データ パイプラインでは、データ検証を実行し、指定されたストアに対する無効な形式のレコードを除外する必要があります。
監視をサポートします。
Azure Key Vault のようなセキュリティで保護されたストレージで構成を一元化します。
考えられるユース ケース
この記事では、Contoso という架空の都市を使用してユース ケース シナリオについて説明します。 この物語では、Contoso によって都市の駐車センサーが所有され、管理されています。 また、センサーに接続してデータを取得する API も所有しています。 多くの異なるソースからデータを収集するプラットフォームが必要です。 その後、データを検証し、クレンジングして、既知のスキーマに変換する必要があります。 Contoso の都市プランナーは、その後、Power BI などのデータ視覚化ツールで駐車の使用に関するレポート データを探索して評価し、より多くの駐車または関連リソースが必要かどうかを判断できます。
考慮事項
次の一覧は、このソリューションで示されている主な学習内容とベスト プラクティスをまとめたものです。
注意
以下の一覧の各項目は、GitHub の駐車センサー ソリューション例に関するドキュメントの、関連する「主な学習内容」セクションにリンクされています。
このシナリオのデプロイ
次の一覧には、対応するビルドとリリースのパイプラインを使用して、駐車センサー ソリューションを設定するために必要な手順の概要が含まれています。 詳細な設定手順と必須コンポーネントについては、こちらの Azure サンプル リポジトリを参照してください。
設定とデプロイ
初期設定: 必須コンポーネントをすべてインストールし、Azure サンプル GitHub リポジトリを独自のリポジトリにインポートして、必要な環境変数を設定します。
Azure リソースをデプロイする: このソリューションには、自動化されたデプロイ スクリプトが付属しています。 環境ごとに必要なすべての Azure リソースと Microsoft Entra サービス プリンシパルがデプロイされます。 また、このスクリプトでは、Azure パイプライン、変数グループ、サービス接続もデプロイされます。
開発 Data Factory で Git 統合を設定する: インポートされた GitHub リポジトリと連動するように Git 統合を構成します。
初期ビルドおよびリリースを実行する: スケジュール トリガーの有効化など、Data Factory でサンプルを変更し、環境間で自動的にデプロイされる変更を監視します。
デプロイされるリソース
デプロイに成功した場合は、3 つの環境 (開発、ステージング、および運用) を表す 3 つのリソース グループが Azure にあるはずです。また、Azure DevOps には、これら 3 つの環境間で変更を自動的にデプロイできる、エンドツーエンドのビルドとリリースのパイプラインがあるはずです。
すべてのリソースの詳細な一覧については、「DataOps - 駐車センサーのデモ」 README の「デプロイされたリソース」セクションを参照してください。
継続的インテグレーションと継続的デリバリー
以下の図は、ビルドおよびリリース パイプラインの CI/CD プロセスとシーケンスを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
開発者は開発リソース グループ内の独自のサンドボックス環境で開発を行い、有効期間が短い Git ブランチに変更をコミットします。 たとえば、「
<developer_name>/<branch_name>」のように入力します。変更が完了すると、開発者はレビューのためにメイン ブランチに対して pull request (PR) を行います。 これにより、PR 検証パイプラインが自動的に開始され、単体テスト、リンティング、およびデータ層アプリケーション パッケージ (DACPAC) ビルドが実行されます。
PR 検証の完了時に、メインにコミットすると、必要なすべてのビルド成果物を公開するビルド パイプラインがトリガーされます。
正常なビルド パイプラインが完了すると、リリース パイプラインの最初のステージがトリガーされます。 これにより、ADF を除き、開発環境に公開ビルド成果物がデプロイされます。
開発者は、コラボレーション ブランチ (メイン) から開発 ADF に手動で公開します。 手動による公開では、
adf_publishブランチ内の Azure Resource Manager (ARM) テンプレートが更新されます。最初のステージが正常に完了すると、手動承認ゲートがトリガーされます。
承認されると、リリース パイプラインは 2 番目のステージに進み、変更をステージング環境にデプロイします。
統合テストを実行し、ステージング環境で変更をテストします。
2 番目のステージが正常に完了すると、パイプラインによって 2 番目の手動承認ゲートがトリガーされます。
承認されると、リリース パイプラインは 3 番目のステージに進み、運用環境に変更をデプロイします。
詳細については、README の「ビルドおよびリリース パイプライン」セクションを参照してください。
テスト
このソリューションには、単体テストと統合テストの両方のサポートが含まれています。 pytest-adf と Nutter テスト フレームワークが使用されます。 詳細については、README の「テスト」セクションを参照してください。
可観測性と監視
このソリューションでは、Databricks および Data Factory の可観測性と監視がサポートされます。 詳細については、README の「可観測性と監視」セクションを参照してください。
次のステップ
ソリューションをデプロイする場合は、「DataOps - 駐車センサーのデモ」 README の「サンプルの使用方法」セクションの手順に従います。
GitHub のソリューション コード サンプル
可観測性と監視
Azure Databricks
Data Factory
Synapse Analytics
- Azure Synapse Analytics でのリソース使用状況とクエリ アクティビティの監視
- DMV を使用して Azure Synapse Analytics SQL プールのワークロードを監視する
Azure Storage
回復性とディザスター リカバリー
Azure Databricks
Data Factory
Synapse Analytics
Azure Storage
- ディザスター リカバリーとストレージ アカウントのフェールオーバー
- Azure Data Lake Storage Gen2 の使用に関するベスト プラクティス - 高可用性とディザスター リカバリー
- Azure Storage の冗長性
詳細なチュートリアル
ソリューションと主要概念の詳細なチュートリアルについては、次のビデオ録画をご覧ください。Microsoft Azure の最新のデータ ウェアハウスの DataDevOps