Azure Data Factory
Azure Databricks
Azure DevOps
Azure Key Vault
Azure Synapse Analytics
この記事では、架空の都市計画室でこのソリューションをどのように使用できるかについて説明します。 このソリューションでは、MDW アーキテクチャ パターンに従うエンドツーエンドのデータ パイプラインを、対応する DevOps および DataOps プロセスと共に提供し、駐車の使用を評価して、より多くの情報に基づくビジネス上の意思決定を行います。
Architecture
次の図は、ソリューションの全体的なアーキテクチャを示しています。
最新のデータ ウェアハウスの DataOps を示すアーキテクチャの図。
Dataflow
Azure Data Factoryは、データを調整してAzure Data Lake Storage Gen2格納します。
Contoso の都市駐車 Web サービス API は、駐車場からデータを転送するために利用できます。
データをランディング スキーマに転送するデータ ファクトリ コピー ジョブがあります。
次に、Azure Databricksはデータをクリーンアップして標準化します。 生のデータを整備して、データサイエンティストが使用できるようにします。
検証によって不正データがあることが判明した場合、それは不正スキーマにダンプされます。
Important
データがData Lake Storageに格納される前にデータが検証されない理由を尋ねられた。 理由は、データセットが破損する可能性のあるバグが検証時に発生する場合があるためです。 この手順でバグが発生した場合は、そのバグを修正してパイプラインを再生できます。 不適切なデータをData Lake Storageに追加する前にダンプした場合、パイプラインを再生できないため、破損したデータは役に立ちません。
データウェアハウスに格納できる形式にデータを変換する 2 つ目のAzure Databricks変換手順があります。
最後に、パイプラインによって、次の 2 つの異なる方法でデータが提供されます。
Databricks を利用すると、データ サイエンティストはデータを使用できるようになり、モデルをトレーニングすることができます。
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」を参照してください。
このセクションの考慮事項は、このソリューションによって示される主な学習とベスト プラクティスをまとめたものです。
Note
このセクションの各考慮事項は、GitHubの駐車センサー ソリューションの例に関するドキュメントの関連する Key Learnings セクションにリンクしています。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
このシナリオを展開します
次の一覧には、対応するビルドとリリースのパイプラインを使用して、駐車センサー ソリューションを設定するために必要な手順の概要が含まれています。 詳細なセットアップ手順と前提条件については、この Azure Samples リポジトリを参照してください。
設定とデプロイ
Initial setup: 前提条件をインストールし、Azure Samples GitHub リポジトリを独自のリポジトリにインポートし、必要な環境変数を設定します。
Azure リソースのデプロイ: ソリューションには自動デプロイ スクリプトが付属しています。 環境ごとに必要なすべてのAzure リソースとMicrosoft Entraサービス プリンシパルがデプロイされます。 スクリプトでは、Azure Pipelines、変数グループ、サービス接続もデプロイされます。
Dev Data Factory での Git 統合の設定: インポートされたGitHub リポジトリと連携するように Git 統合を構成します。
初期ビルドおよびリリースを実行する: スケジュール トリガーの有効化など、Data Factory でサンプルを変更し、環境間で自動的にデプロイされる変更を監視します。
デプロイされたリソース
デプロイが成功した場合、Azureには、開発、stg、prod の 3 つの環境を表す 3 つのリソース グループが存在する必要があります。また、これらの 3 つの環境間で変更を自動的にデプロイできるエンド ツー エンドのビルドパイプラインとリリース パイプラインがAzure DevOpsに存在する必要があります。
すべてのリソースの詳細な一覧については、「
継続的インテグレーションと継続的デリバリー (CI/CD)
次の図は、ビルド パイプラインとリリース パイプラインの CI/CD プロセスとシーケンスを示しています。
ビルドおよびリリースのプロセスとシーケンスを示すダイアグラム。
開発者は開発リソース グループ内の独自のサンドボックス環境で開発を行い、有効期間が短い Git ブランチに変更をコミットします。 たとえば、。
変更が完了すると、開発者はレビューのためにメイン ブランチに対して pull request (PR) を行います。 これにより、単体テスト、linting、およびデータ層アプリケーション パッケージ (DACPAC) ビルドを実行する PR 検証パイプラインが自動的に開始されます。
PR 検証の完了時に、メインにコミットすると、必要なすべてのビルド成果物を公開するビルド パイプラインがトリガーされます。
正常なビルド パイプラインが完了すると、リリース パイプラインの最初のステージがトリガーされます。 これにより、Data Factory を除き、開発環境に公開ビルド成果物がデプロイされます。
開発者は、コラボレーション ブランチ (メイン) から開発 Data Factory に手動で公開します。 手動発行では、
adf_publishブランチのAzure Resource Manager テンプレートが更新されます。最初のステージが正常に完了すると、手動承認ゲートがトリガーされます。
承認されると、リリース パイプラインは 2 番目のステージに進み、変更をステージング環境にデプロイします。
統合テストを実行し、ステージング環境で変更をテストします。
2 番目のステージが正常に完了すると、パイプラインによって 2 番目の手動承認ゲートがトリガーされます。
承認されると、リリース パイプラインは 3 番目のステージに進み、運用環境に変更をデプロイします。
詳細については、README の「Build and Release Pipeline」セクションを参照してください。
Testing
このソリューションには、単体テストと統合テストの両方のサポートが含まれています。 pytest-Data Factory と Nutter Testing Framework を使用します。 詳細については、README の Testing セクションを参照してください。
可観測性と監視
このソリューションでは、Databricks および Data Factory の可観測性と監視がサポートされます。 詳細については、README の「Observability/Monitoring」セクションを参照してください。
次のステップ
ソリューションをデプロイする場合は、「
GitHubのソリューション コード サンプル
GitHub
Observability/monitoring
Azure Databricks
Data Factory
- Azure Data Factory を Azure Monitor で監視する
- データ ファクトリ パイプラインを事前に監視するためのアラートを作成する
Azure Synapse Analytics
Azure Synapse Analytics - Azure Synapse Analytics SQL プールワークロードを DMVs を使用して監視します
Azure Storage
回復性とディザスター リカバリー
Azure Databricks
Data Factory
- セルフホステッド統合ランタイムを作成して構成する - 高可用性とスケーラビリティ
Azure Synapse Analytics
- ジオバックアップとディザスタリカバリー
- SQL プールの地理的リストア
Azure Storage
- ディザスター リカバリーとストレージ アカウントのフェールオーバー
- Azure Data Lake Storage Gen2の使用に関するベスト プラクティス - 高可用性とディザスター リカバリー
- Azure Storage冗長性
詳細な概要
ソリューションと主要な概念の詳細な概要については、