Azure でのクラウド規模の分析を使用した取り込みプロセス
Azure には、ネイティブおよびサードパーティーのプラットフォームにデータを取り込み、リリースするためのいくつかのサービスが用意されています。 ボリューム、ベロシティ、多様性、方向などに応じて、さまざまなサービスを使用できます。 次のようなサービスがあります。
- Azure Data Factory は、あらゆるデータ アプリケーション (ソースアライン済み) のニーズとスキル レベルに合わせて構築されたサービスです。 直感的なビジュアル環境内で、独自のコードを書くことや、コードを書かずにプロセスの構築、抽出、読み込み、変換を行うことができます。 90 を超えるネイティブに構築されたメンテナンス フリーのコネクタが用意されているので、追加コストなしでデータ ソースを視覚的に統合することができます。 エンジニアは、プライベート エンドポイントとリンク サービスを使用して、Azure サービスとしてのプラットフォーム (PaaS) リソースのパブリック エンドポイントを使用せずに PaaS リソースに安全に接続できます。 エンジニアは、統合ランタイムを使用して、パイプラインをオンプレミスのデータ ソースや他のクラウドなどのサードパーティー環境に拡張することができます。
こうしたコネクタの中には、ソース (読み込み) またはシンク (書き込み) としての使用をサポートするものがあります。 Azure ネイティブ サービス、Oracle、SAP などは、ソースまたはシンクとして使用できますが、すべてのコネクタがサポートしているわけではありません。 このような場合は、Open Database Connectivity (ODBC)、ファイル システム、SSH File Transfer Protocol (SFTP) コネクタなどの汎用コネクタを使用できます。
Azure Databricks は、高速で使いやすい、コラボレーション対応の Apache Spark ベースの分析サービスです。 ビッグ データ パイプラインの場合、データ ファクトリを介して Azure にデータ (未加工または構造化) をバッチで取り込むか、Apache Kafka、Azure Event Hubs、IoT Hub を使用して準リアルタイムでストリーム配信することができます。 このデータは、Azure Data Lake Storage の長期永続保管を目的としたデータ レイクに到達します。 Azure Databricks により、ワークフローの一部として複数のデータ ソースからデータを読み込むことができます。
Microsoft Power Platform には、イベント、スケジュール、またはプッシュによって起動できる何百ものサービスへのコネクタが用意されています。 Microsoft Power Automate を使用すると、イベントに応じて実行し、1 つレコードや少量のデータに最適化されたワークフローをトリガーすることができます。
専用のネイティブ ツールとサードパーティー製ツールには、特殊なシステムとの統合や、準リアルタイムのレプリケーションなどのニッチな機能があります。
- Azure Data Share は、組織が複数の外部の顧客やパートナーとデータを簡単かつ安全に共有することをサポートします。 データ共有アカウントを作成してデータ製品を追加すると、顧客とパートナーをデータ共有に招待することができます。 データ プロバイダーは、共有するデータを常に制御しています。 Azure Data Share を使用すると、どのデータが共有されているか、いつ共有されたか、誰が共有したかを簡単に管理および監視することができます。
重要
すべてのデータ ランディング ゾーンにメタデータ インジェスト リソース グループがあります。これはデータに依存しないインジェスト エンジンを使用する企業用に存在します。 このフレームワーク エンジンがない場合、推奨される唯一のリソースは、Azure Databricks の分析ワークスペースをデプロイすることです。これは複雑なインジェストを実行するデータ統合に使用されます。 潜在的な自動化パターンについては、「データに依存しないインジェスト エンジン」を参照してください。
Azure Data Factory のインジェストに関する考慮事項
データに依存しないインジェスト エンジンがある場合、インジェストおよび処理リソース グループの各データ ランディング ゾーンに対して、1 つのデータ ファクトリをデプロイする必要があります。 ユーザーに対して Data Factory ワークスペースをロックする必要があり、マネージド ID とサービス プリンシパルにのみ、デプロイするアクセス権を付与します。 データ ランディング ゾーンの運用には、パイプラインのデバッグを可能にする読み取りアクセス権が必要です。
データ アプリケーションは、データ移動用の独自の Data Factory を持つことができます。 各データ アプリケーション リソース グループにデータ ファクトリを持つことで、Azure DevOps または GitHub からのみパイプラインをデプロイできるようになり、完全な継続的インテグレーション (CI) および継続的デプロイ (CD) をサポートします。
すべての Data Factory ワークスペースのデータ管理ランディング ゾーン内のデータ ランディング ゾーンには、主に Data Factory のマネージド仮想ネットワーク (VNet) 機能またはセルフホステッド統合ランタイムが使用されます。 エンジニアは、マネージド VNet 機能を使用して Azure PaaS リソースに安全に接続することが推奨されます。
ただし、オンプレミス、サードパーティー クラウド、サードパーティーのサービスとしてのソフトウェア (SaaS) データ ソースから取り込むために、さらに統合ランタイムを作成することができます。
Azure Databricks のインジェストに関する考慮事項
このガイダンスでは、次の情報について詳述します。
Azure Databricks から Azure Data Lake Storage Gen2 へのアクセスをセキュリティで保護する
開発の場合、統合運用では、テストおよび運用時に 1 つの Azure Databricks ワークスペースにデプロイするコードをチェックインする前に、独自の Azure Databricks 環境を用意する必要があります。
データ アプリケーション (ソースアライン済み) リソース グループの Data Factory には、Azure Databricks ジョブを呼び出すためのフレームワークを用意する必要があります。
サービス プリンシパルは、データ レイクをこのワークスペースにマウントするのに役立ちます。 詳細については、パターン 1 - サービス プリンシパルによるアクセスに関するページを参照してください。
データ アプリケーション チームは、短い自動化されたジョブを Azure Databricks 上にデプロイすると、クラスターが迅速に開始され、ジョブが実行され、終了することを期待できます。 クラスターのジョブの開始にかかる時間を短縮するために、Azure Databricks プールを設定することをお勧めします。
組織は Azure DevOps を使用して、新しいパイプラインのデプロイ フレームワークを実装することをお勧めします。 このフレームワークは、Databricks テーブルのアクセス制御を実施するかどうかにかかわらず、データセット フォルダーの作成、アクセス制御リストの割り当て、テーブルの作成に使用されます。
ストリームのインジェスト
場合によっては、組織は発行元によって高速のイベント ストリームが生成されるシナリオをサポートする必要があります。 このパターンの場合、こうしたストリームを取り込むために、Event Hubs や IoT Hub などのメッセージ キューを使用することをお勧めします。
Event Hubs と IoT Hub はスケーラブルなイベント処理サービスであり、大量のイベントとデータを低待機時間かつ高い信頼性で取り込み、処理することができます。 Event Hubs は、ビッグ データのストリーミングおよびイベント インジェスト サービスとして設計されています。 IoT Hub は、IoT アプリケーションとそれが管理するデバイスの間の双方向通信に対する中央メッセージ ハブとして機能する管理サービスです。 そこから、データを一定の間隔でデータ レイクにエクスポートすること (バッチ) や、Azure Databricks を使用して Apache Spark Streaming、Azure Data Explorer、Stream Analytics、Time Series Insights を介して準リアルタイムで処理することができます。
ユース ケースの特定のランディング ゾーン内の最後の Event Hubs または Apache Kafka ランディング ゾーンから、その集計されたデータを、データ ランディング ゾーンのいずれかのデータ レイクの未加工層と、データ ランディング ゾーンのデータ アプリケーション (ソースアライン済み) リソース グループに関連する Event Hubs に送信する必要があります。
インジェストを監視する
すぐに使用できる Azure Data Factory パイプライン監視を使用して、Data Factory パイプラインからの例外を監視し、トラブルシューティングすることができます。 これにより、カスタムの監視およびレポート ソリューションを開発する労力が軽減されます。
組み込みの監視は、Azure Data Factory をメインのオーケストレーション ツールとして使用する主な理由の 1 つです。また、Azure Policy はこの設定を自動化するのに役立ちます。
データ ソースをサービスにマップする
このセクションのガイダンスでは、インジェスト サービスと処理サービスを、通常は Azure から取り込むかリリースする必要があるソースにマップします。
インジェスト サービス:
| id | メカニズム | 注意 |
|---|---|---|
| A | Data Factory | 組み込みおよび汎用 (ODBC、SFTP、REST) コネクタ |
| B | Azure Databricks | カスタム コード (JDBC、JAR など) |
| C | サードパーティ | WANdisco、Qlik、および Oracle GoldenGate |
| D | その他 | たとえば、ネイティブ機能 |
| E | Microsoft Power Platform と Azure Logic Apps | Microsoft Power Automate コネクタ |
データ ソースのサービスへマッピング:
| プロバイダー | Type | ホストされている | カテゴリ | メモ | 完全読み込みの取り込み | 段階的読み込みの取り込み | リアルタイムの取り込み | 完全読み込みのエグレス | 段階的読み込みのエグレス | リアルタイムのエグレス |
|---|---|---|---|---|---|---|---|---|---|---|
| Oracle | 表形式 | IaaS | データベース | GoldenGate から Azure Data Lake Storage へ | A、B | A、B | C | A、B | A、B | C |
| Microsoft SQL Server | 表形式 | IaaS | データベース | SAP Landscape Transformation と Qlik | A、B | A、B | C、D2 | A、B | A、B | C、D2 |
| MySQL | 表形式 | IaaS | データベース | SAP Landscape Transformation と Qlik | A、B | A、B | C、D2 | A、B | A、B | C、D2 |
| SAP BW/4HANA | 表形式 | IaaS | データベース | SAP Landscape Transformation と Qlik | A、B、C、D | A、B、C、D | C | - | - | - |
| SAP HANA | 表形式 | IaaS | データベース | SAP Landscape Transformation と Qlik | A、B、C、D | A、B、C、D | C | A、B | A、B | - |
| Apache Impala | 表形式 | IaaS | データベース | - | A、B | A、B | - | B | B | - |
| Microsoft SharePoint | List | SaaS | Record Store | - | A、E | A、E | E | A、E | A、E | E |
| REST | REST | 各種 | REST | XML、JSON、CSV | A、B、E | A、B、E | A、B、E | A、B、E | A、B、E | A、B、E |
| Microsoft Outlook | 電子メール | SaaS | REST | XML、JSON、CSV | E | E | E | E | E | E |
対象によっては、Azure Database Migration Service により、オンプレミスおよびサードパーティーのデータベース (Microsoft SQL Server、PostgreSQL、MySQL、Oracle など) から Azure ベースのデータ ストアにレプリケートすることができます。