次の方法で共有


ほぼリアルタイムの Lakehouse データ処理に Azure Synapse Analytics を使用する

Azure AI Search
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs
Azure Synapse Analytics

データ ドリブン企業では、バックエンドと分析のシステムを顧客向けアプリケーションとほぼリアルタイムで同期させておく必要があります。 トランザクション、更新、および変更の影響は、エンドツーエンドのプロセス、関連アプリケーション、およびオンライン トランザクション処理 (OLTP) システムを通じて正確に反映されている必要があります。 OLTP アプリケーションの変更が、データを使用するダウンストリーム システムに反映されるまでの許容可能な待機時間は、わずか数分になる場合があります。

この記事では、レイクハウス データを同期させておくために、ほぼリアルタイムのデータ処理を行うエンド ツー エンドのソリューションについて説明します。このソリューションでは、データの処理と分析に Azure Event Hubs、Azure Synapse Analytics、および Azure Data Lake Storage を使用します。

Microsoft Fabric を使用して同様のアーキテクチャを実装できます。Microsoft Fabric は、データ インジェスト、変換、ストレージ、および分析のためのサービスとしての統合ソフトウェア (SaaS) プラットフォームを提供します。 この場合、Fabric はアーキテクチャの Azure Synapse Analytics コンポーネントを置き換え、リアルタイムのデータ処理と分析のための統合された機能を提供します。 詳細については、「 ファブリック Real-Time インテリジェンス」を参照してください。

Apache® および Apache Spark は、米国およびその他の国の Apache Software Foundation の登録商標または商標です。 これらのマークを使用することが、Apache Software Foundation による保証を意味するものではありません。

アーキテクチャ

エンドツーエンドのデータ処理ソリューションのデータフローを示す図。

この図は、モバイル アプリや顧客向けのアプリケーションなどのストリーミング データ ソースが OLTP データベースを介して、イベントを抽出して送信する Debezium コネクタに流れる方法を示しています。 これらのコネクタは Event Hubs に送られます。 Event Hubs からは、構造化ストリーム処理用の Azure Synapse Analytics Spark プールに直接、または生データ ストレージのランディング ゾーンとして Data Lake Storage に直接、2 方向のデータ フローが行われます。 パートナー データセットやファイル転送プロトコル (FTP) などのバッチ データ ソースも、Data Lake Storage 経由で Azure Synapse Analytics パイプラインに接続します。 Data Lake Storage は、処理のために Azure Synapse Analytics パイプラインにデータを渡します。 検証済みのデータ ゾーンから、処理されたデータは Azure Synapse Analytics Spark プールに、専用 SQL プール、Azure Cosmos DB、または Azure AI Search に読み込まれます。 専用 SQL プールは Power BI に接続して、ダッシュボードとレポートを作成します。 Azure Cosmos DB と AI Search は、ダウンストリームで使用するために API に接続します。 検証されたデータは、モデルのトレーニングとデプロイのために Data Lake Storage から Azure Machine Learning に、または分析のために顧客に渡される Azure Synapse Analytics サーバーレス SQL プールにも流れます。

このアーキテクチャの Visio ファイル をダウンロードします。

データフロー

  1. 変更データ キャプチャ (CDC) は、ソース システムが変更をリッスンするための前提条件です。 Debezium コネクタは、 異なるソース システムに接続し、発生した変更を活用できます。 このコネクタは、変更をキャプチャし、さまざまなリレーショナル データベース管理システム (RDBMS) からイベントを生成できます。 Debezium コネクタをインストールするには、Kafka 接続システムが必要です。

  2. コネクタは変更データを抽出し、キャプチャされたイベントを Event Hubs に送信します。 Event Hubs は、複数のソースから大量のデータを受信できます。

  3. Event Hubs は、データを Azure Synapse Analytics Spark プールに直接ストリーミングするか、未加工の形式で Data Lake Storage ランディング ゾーンにデータを送信します。

  4. 他のバッチ データ ソースでは、Azure Synapse Analytics パイプラインを使用して Data Lake Storage にデータをコピーし、処理できるようにします。 エンド ツー エンドの抽出、変換、読み込み (ETL) ワークフローでは、異なるステップをチェーンしたり、ステップ間の依存関係を追加したりする必要がある場合があります。 Azure Synapse Analytics パイプラインでは、全体的な処理フレームワーク内でワークフローの依存関係を調整できます。

  5. Azure Synapse Analytics Spark プールでは、完全にサポートされている Apache Spark 構造化ストリーミング API を使用して、Spark ストリーミング フレームワーク内のデータを処理します。 データ処理ステップには、データ品質チェックと高度なビジネス ルール検証が組み込まれています。

  6. Data Lake Storage は、検証済みのデータを開いている Delta Lake 形式で格納します。 Delta Lake は、既存のデータ レイクに対して、アトミック性、一貫性、分離性、持続性 (ACID) のセマンティクスとトランザクション、スケーラブルなメタデータ処理、および統合ストリーミングとバッチ データ処理を提供します。

    クエリ アクセラレーションにインデックスを使用すると、Delta Lake のパフォーマンスが向上します。 また、Data Lake Storage 検証済みゾーンからのデータは、高度な分析と機械学習のソースにもなることができます。

  7. Data Lake Storage の検証済みゾーンからのデータは、より多くのルールで変換され、最終的な処理済み状態にエンリッチされ、大規模な分析クエリを実行するための専用 SQL プールに読み込まれます。

  8. Power BI では、専用 SQL プールを介して公開されるデータを使用して、エンタープライズ レベルのダッシュボードとレポートを作成します。

  9. 次のタスクでは、Data Lake Store でキャプチャされた生データと差分形式の検証済みデータを使用することもできます。

    • Azure Synapse Analytics サーバーレス SQL プールを使用した計画外および探索的分析

    • Azure Machine Learning を使用した機械学習モデルのトレーニングとデプロイ

  10. 一部の低遅延インターフェイスでは、1 桁のサーバー待機時間のためにデータを非正規化する必要があります。 このユース ケースは、主に API 応答用です。 このシナリオでは、Azure Cosmos DB などの NoSQL データストア内のドキュメントに 1 桁のミリ秒の応答を照会します。

  11. Azure Cosmos DB のパーティション分割戦略では、すべてのクエリ パターンが効率的にサポートされない場合があります。 その場合は、API が Azure AI Search でアクセスするために必要なデータのインデックスを作成することで、ソリューションを拡張できます。 Azure Cosmos DB と AI Search は、待機時間の短いクエリ応答を必要とするほとんどのシナリオを満たすことができます。 たとえば、小売アプリケーションは Azure Cosmos DB に製品カタログ データを格納しますが、フルテキスト検索機能と柔軟なインデックス作成が必要です。 AI Search では、データのインデックスを作成し、オートコンプリート、シノニム、セマンティック ランク付けなどの高度な検索機能を提供できます。 これらの機能は、Azure Cosmos DB のインデックス作成の制限によって複雑な検索シナリオが制限される場合に便利です。

コンポーネント

このソリューションでは、次の Azure コンポーネントを使用します。

  • Event Hubs は、大量のデータを取り込むためのスケーリングが可能な、管理された分散インジェスト サービスです。 Event Hubs パブリッシャーサブスクライバー メカニズムを使用すると、さまざまなアプリケーションが Event Hubs トピックにメッセージを送信でき、ダウンストリーム コンシューマーはそれらのメッセージに接続して処理できます。 Event Hubs キャプチャ機能は、受信時に Avro 形式で Data Lake Storage にメッセージを書き込むことができます。 この機能により、マイクロバッチ処理と長期保有シナリオが容易になります。 Event Hubs では、Kafka と互換性のある API も提供され、スキーマ レジストリがサポートされます。 このアーキテクチャでは、Event Hubs は複数のソースから CDC イベントを受信し、ダウンストリーム コンシューマーに配布します。

  • Data Lake Storage は、スケーラブルで安全な Data Lake ソリューションです。 これは、生および検証済みの形式ですべてのデータを格納するストレージ サブシステムを形成します。 このアーキテクチャでは、Data Lake Storage は大規模なトランザクションを処理し、さまざまなファイル形式とサイズをサポートします。 階層型名前空間は、データを使い慣れたフォルダー構造に整理し、Unix (POSIX) のポータブル オペレーティング システム インターフェイスのアクセス許可をサポートするのに役立ちます。 Azure Blob Filesystem (ABFS) ドライバーは、Hadoop と互換性のある API を提供します。

  • Azure Synapse Analytics は、データ統合、エンタープライズ データ ウェアハウス、ビッグ データ分析を組み合わせた無制限の分析サービスです。 このソリューションでは、Azure Synapse Analytics エコシステムの次の機能を使用します。

    • Azure Synapse Analytics Spark プール は、オープンソースの Spark に組み込みのパフォーマンス強化を追加するオンデマンド Spark ランタイムを提供するクラスターです。 このアーキテクチャでは、柔軟な自動スケール設定を構成し、Apache Livy エンドポイントを介してリモートでジョブを送信し、対話型エクスペリエンスに Synapse Studio ノートブック インターフェイスを使用できます。

    • Azure Synapse Analytics サーバーレス SQL プール は、使い慣れた T-SQL 構文を使用して Lakehouse データにクエリを実行するためのインターフェイスを提供するクエリ オンデマンド機能です。 設定するインフラストラクチャはなく、Azure Synapse Analytics ワークスペースのデプロイによってエンドポイントが自動的に作成されます。 このアーキテクチャでは、Azure Synapse Analytics サーバーレス SQL プールを使用すると、計画外のクエリ分析のためにデータの基本的な検出と探索を行うことができます。

    • Azure Synapse Analytics 専用 SQL プール は、プロビジョニングされたデータ ウェアハウス リソースです。 列形式ストレージを使用してリレーショナル テーブルにデータを格納します。 このアーキテクチャでは、専用 SQL プールはスケールアウト アーキテクチャを使用して、複数のノードにデータ処理を分散します。 PolyBase クエリにより、データは SQL プール テーブルに持ち込まれます。 このテーブルは、分析とレポートのために Power BI に接続できます。

  • Power BI は、レポートとダッシュボードを作成してアクセスするためのビジュアル インターフェイスを提供するビジネス分析サービスです。 Power BI Desktop は、さまざまなデータ ソースに接続し、ソースを結合して 1 つのデータ モデルにし、レポートまたはダッシュボードを構築できます。 このアーキテクチャでは、Power BI を使用してビジネス要件に基づいてデータを変換し、ビジュアルやレポートを顧客と共有できます。

  • Azure Cosmos DB は、グローバルに分散された NoSQL データベース サービスです。 このソリューションでは、1 桁のミリ秒の応答時間と高可用性を必要とするアプリケーションに Azure Cosmos DB を使用します。 Azure Cosmos DB では、すべての Azure リージョンで複数リージョンの書き込みが提供されます。

  • AI Search は、AI を利用したサービスとしてのプラットフォーム (PaaS) であり、開発者はアプリケーションや Web サイトの豊富な検索エクスペリエンスを構築できます。 高度な検索シナリオで Azure Cosmos DB インデックス作成モデルが厳密すぎる場合は、このソリューションで AI Search を使用します。 AI Search を使用すると、入力ミスの許容度、オートコンプリート、セマンティック ランク付け、シノニム マッチングなどの機能を使用して柔軟なクエリを実行できます。 インデックス付きデータに対してクエリを実行するには、REST API または .NET SDK を使用します。 複数のインデックスからデータを取得する必要がある場合は、それらを 1 つのインデックスに統合するか、 複雑なデータ型 を使用して入れ子になった構造をモデル化できます。

シナリオの詳細

ほぼリアルタイムで変更を処理するエンドツーエンドのワークフローには、次のものが必要です。

  • CDC テクノロジ。 OLTP アプリケーションでは、SQL Server、MySQL、Oracle など、バックエンド データ ストアが異なる場合があります。 最初の手順では、発生した変更をリッスンし、前方に伝達します。

  • 変更イベントを大規模に公開するためのインジェスト バッファー。 このサービスには、メッセージの着信時に大量のデータを処理する機能が必要です。 個々のサブスクライバーは、このシステムに接続してデータを処理できます。

  • 生の形式でそのままのデータ用のスケーラブルな分散ストレージ。

  • ユーザーが再起動して状態を管理できるようにする、効率的な分散ストリーム処理システム。

  • ビジネス上の意思決定を強化するために大規模に実行される分析システム。

  • セルフサービス分析インターフェイス。

  • 待機時間の短い API 応答の場合、データの非正規化表現を格納する NoSQL データベース。

  • 場合によっては、データのインデックスを作成し、一定の間隔でインデックスを更新し、最新のデータをダウンストリームで使用できるようにするシステム。

上記のすべてのテクノロジでは、境界セキュリティ、認証、承認、およびデータ暗号化に関連するセキュリティコンストラクトを使用する必要があります。

考えられるユース ケース

このソリューションは、次のユース ケースに適しています。

  • OLTP からオンライン分析処理 (OLAP) に変更を伝達する必要がある業界。

  • データ変換またはエンリッチメントを必要とするアプリケーション。

リアルタイム データ処理シナリオは、金融サービス業界に特に重要です。 たとえば、保険、クレジット カード、銀行の顧客が支払いを行ってから、すぐにカスタマー サービスに連絡する場合、カスタマー サポート エージェントには最新の情報が必要です。

同様のシナリオは、小売、商取引、医療のセクターに適用されます。 これらのシナリオを有効にすると、運用が合理化され、組織の生産性が向上し、顧客満足度が向上します。

考慮事項

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

[信頼性]

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の 設計レビュー チェックリスト」を参照してください。

  • Event Hubs では、Premium レベルと専用レベルで 90 日間のデータリテンション期間が提供されます。 フェールオーバー シナリオでは、ペアのリージョンにセカンダリ名前空間を設定し、フェールオーバー時にアクティブ化できます。 ゾーンの冗長性を有効にして、データセンターの障害に対する回復性を確保します。 Event Hubs キャプチャ機能を使用すると、再生と復旧のシナリオでデータを Data Lake Storage に保持できます。

  • メンテナンスのためにノードが停止されると、Azure Synapse Analytics Spark プール ジョブは 7 日ごとにリサイクルされます。 システムに関連付けられているサービス レベル アグリーメント (SLA) を処理するときは、このアクティビティを検討してください。 この制限は、目標復旧時間 (RTO) が約 15 分である多くのシナリオでは問題になりません。 負荷の急増とノードの障害を処理するように自動スケールが構成されていることを確認します。

  • geo バックアップとゾーン冗長ストレージ (ZRS) を備えた専用 SQL プールを使用して、リージョンとゾーンの停止から保護します。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「 コストの最適化」のデザイン レビュー チェックリストを参照してください。

  • ワークロードの特性に基づいて、さまざまな Event Hubs レベルの中から選択できます。 Event Hubs では、Data Lake Storage に格納されているデータの量に基づいて、ストレージが個別にキャプチャされます。

  • Data Lake Storage の階層を使用したオブジェクト ライフ サイクル管理を検討します。 データが古くなるにつれて、分析のために最新のデータにアクセスする必要があるホット 層から、コストの低いコールド ストレージ層にデータを移動できます。 コールド ストレージ層は、長期保有のためのコスト効率の高いオプションです。

  • 専用 SQL プールは、開発環境またはテスト環境で使用していないときに一時停止できます。 必要に応じてプールを一時停止するスクリプトをスケジュールすることも、ポータルを使用してプールを手動で一時停止することもできます。

  • Azure Synapse Analytics Spark プールの場合は、自動スケーリングを使用して、ワークロードの需要に基づいてリソースを動的に割り当て、オーバープロビジョニングを回避します。 パフォーマンスニーズを満たす最小のプール サイズを選択し、自動終了設定を使用してアイドル 状態のプールをすぐにシャットダウンします。 シャッフル操作を最小限に抑え、中間結果をキャッシュし、パーティション サイズをチューニングして、実行時とリソースの消費量を減らすことで、Spark ジョブを最適化します。 Azure Synapse Analytics 監視ツールを使用して使用状況を監視し、ジョブのパフォーマンスとコストの傾向に基づいて構成を調整します。

  • Azure Cosmos DB のコスト効率を最適化するには、必要なパスのみを含むようにインデックス作成ポリシーを調整します。これにより、ストレージと要求ユニット (RU) の使用量が削減されます。 オーバープロビジョニングを行わずに、ワークロードのニーズに合わせて適切な API と整合性レベルを選択します。 自動スケーリングスループットを使用して、需要に基づいて RU を動的に調整し、可能な場合はワークロードをより少ないコンテナーに統合してオーバーヘッドを最小限に抑えます。 Microsoft Cost Management を使用して使用状況を定期的に監視し、予期しない料金が発生しないようにアラートを設定します。

  • Azure 料金計算ツールを使用して価格を見積もります。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、 パフォーマンス効率のデザイン レビュー チェックリストを参照してください。

  • パーティション分割を使用して Event Hubs をスケーリングできます。これにより、イベントが複数の並列ログ (パーティション) に分散され、スループットが向上します。 同じ顧客やデバイスからのイベントなど、関連するイベントの順序を保持するには、イベントを発行するときに一貫性のある パーティション キー を使用します。 この方法により、関連するすべてのイベントが同じパーティションにルーティングされ、Event Hubs によって順序が維持されます。 予想されるイベント ボリュームに基づいてスループット ユニット (TU) を調整します。 キャプチャ機能を使用して、Avro または Parquet 形式で Data Lake Storage に直接書き込み、ダウンストリーム処理を効率的に行います。

  • ワークロードに基づいて、小規模、中規模、または大規模の仮想マシン (VM) SKU を使用して Azure Synapse Analytics Spark プールを設定できます。 ワークロードのアクティビティの急増を考慮して、Azure Synapse Analytics Spark プールで自動スケーリングを構成することもできます。 より多くのコンピューティング リソースが必要な場合は、需要に合わせてクラスターが自動的にスケールアップされ、処理が完了した後にスケールダウンされます。

  • Delta Lake は、このアーキテクチャで高パフォーマンス、信頼性、およびスケーラブルなデータ処理を確保する上で中心的な役割を果たします。

    • Delta Lake の自動最適化機能と自動圧縮機能を有効にして、書き込み操作中に小さなファイルを自動的に管理し、データ レイアウトを最適化します。 これらの機能は、手動による介入の必要性を減らすので、ストリーミングや頻繁なマイクロバッチ インジェストシナリオに最適です。

    • OPTIMIZEを使用して、小さなファイルを大きなファイルに手動で圧縮します。 この方法は、ストリーミング インジェストによって多数の小さなファイルが作成された後に、読み取り効率を向上させ、メタデータのオーバーヘッドを削減する場合に特に便利です。

    • 関連するデータを併置するには、タイムスタンプや顧客 ID など、頻繁に照会される列にOPTIMIZEを含むZORDER BYを使用します。 このクエリは、読み取り中にスキャンされるデータの量を減らすことで、クエリのパフォーマンスを向上させます。

  • ほぼリアルタイムの分析のために専用 SQL プールのパフォーマンスを最適化するには、次のタスクを実行します。

    • ハッシュ、ラウンド ロビン、レプリケートされたメソッドなどの適切な分散方法を使用します。
    • クエリの排除を向上させるために、時間またはリージョン別に大きなテーブルをパーティション分割します。
    • 頻繁にアクセスされるデータには、具体化されたビューと結果セットのキャッシュを使用します。
    • クエリを効率的に実行するために、up-to-date 統計とインデックスを維持します。
    • リソース クラスを割り当ててメモリとコンカレンシーを管理します。
    • SQL Insights や動的管理ビュー (DMV) などの組み込みツールを使用してパフォーマンスを監視します。

    これらのプラクティスは、大規模な分析ワークロードで低待機時間で高スループットのパフォーマンスを確保するのに役立ちます。

  • リアルタイム分析シナリオでのパフォーマンスのために Azure Cosmos DB を最適化するには、クエリの待機時間とストレージのオーバーヘッドを減らすために適切なインデックス作成ポリシーを構成し、パフォーマンスとデータの精度のバランスを取るための適切な整合性レベルを選択します。 パーティション分割を効果的に使用してワークロードを均等に分散し、ホット パーティションを回避します。 複数リージョンの書き込みを有効にして待機時間の短いグローバル アクセスを実現し、RU を使用してスループットを監視し、必要に応じて動的にスケーリングします。 これらのプラクティスは、インジェストが多く、待機時間が短いワークロードに対して、応答性が高くスケーラブルなパフォーマンスを確保するのに役立ちます。

共同作成者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパル作成者:

その他の共同作成者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ