クラウド データ ウェアハウスとデータ レイクは、データを強化し、情報を一元化し、強力な分析を可能にします。 しかし、データの真の価値は、分析情報を実際の意思決定とカスタマー エクスペリエンスに変えることです。 この目標を達成するには、クリーンで信頼性の高いデータをウェアハウス/データ レイクから運用システムに移動する必要があります。 逆 ETL は、Azure Databricks や Microsoft Fabric の Delta Lake などのデータ ウェアハウス レイヤーから運用システムにデータを移動します。 この移行手順により、ダウンストリーム アプリは最新のエンリッチされたデータを使用して、リアルタイムの運用分析を行うことができます。 逆 ETL は、分析と運用のギャップを埋めることでデータ資産の可能性を最大限に引き出し、より良い意思決定を可能にする上で重要な役割を果たします。
Azure Cosmos DB for NoSQL は、超低待機時間、グローバル分散、および NoSQL のスケーラビリティを実現するように設計されているため、リアルタイム アプリケーションに最適です。 リバース ETL を使用すると、差分エンリッチされたデータを Azure Cosmos DB に同期し、リアルタイムの運用分析を可能にすることができます。 このパターンを使用して、製品カタログ、パーソナライズされた顧客情報、価格の更新、在庫データ、機能の推奨事項などのデータをプッシュできます。 このデータを運用データ ストアにプッシュして、ダウンストリーム アプリがデータドリブンの意思決定を即座に行えるようにすることができます。
ソリューション アーキテクチャ
逆 ETL を実装するための合理化されたアーキテクチャは、Apache Spark と Azure Databricks で構成されています。 このアーキテクチャでは、差分テーブルなどのソースからクレンジングおよびエンリッチされたデータを抽出し、Azure Cosmos DB for NoSQL の運用ストアにデータを書き戻します。
この図には、次のコンポーネントが含まれています。
次のようなデータ を含むデータ ソース。製品データ、CRM データ、注文情報、広告情報。
元のデータ ソースからデータ ウェアハウスまたはデータ レイクにデータを移動し、Azure Databricks や Microsoft Fabric などのソリューションを使用してデータを格納および強化する ETL ワークフロー。
Apache Spark テーブルと Delta テーブルを使用してエンリッチされたデータを運用データ ストアに移行するための ETL ワークフローの反転
Azure Cosmos DB for NoSQL などのデータ ストアを操作して、エンリッチされたデータをリアルタイム アプリケーションで使用します。
逆 ETL プロセスでは、次のようなシナリオが可能になります。
Real-Time の決定: アプリは、アナリストや SQL に依存することなく、最新のデータにアクセスできます。
データのアクティブ化: 分析情報は、ダッシュボードだけでなく、必要な場所にプッシュされます。
統一された真理の源: Delta Lake は正規レイヤーとして機能し、システム間の一貫性を確保します。
データ取り込みステージ
機能ストア、レコメンデーション エンジン、不正検出、リアルタイム製品カタログなどのシナリオでは、データ フローを 2 つの段階に分ける必要があります。 これらのステージでは、Delta Lake から Azure Cosmos DB for NoSQL への逆 ETL パイプラインがあることを前提としています。
この図のステージは次で構成されています。
初期読み込み: 初期読み込みは、差分テーブルから Azure Cosmos DB for NoSQL にすべての履歴データを取り込むための 1 回限りのバッチ プロセス ステップです。 運用データ ストアに完全な履歴データがあることを確認することで、逆 ETL パイプラインの基盤を設定します。 この負荷は、データの増分同期を開始する前の基本的な手順です。
変更データ キャプチャ (CDC) 同期: この手順では、Delta Tables から Azure Cosmos DB for NoSQL への変更を増分かつ継続的に同期します。 差分テーブルの変更は、差分変更データ フィード (CDF) を有効にした後でキャプチャできます。 バッチ ベースまたはストリーミング ベースの変更データ キャプチャ (CDC) 同期を実装できます。
Azure Cosmos DB for NoSQL への CDC 同期には、次の 2 つのオプションがあります。
バッチ CDC 同期: このオプションはスケジュール (毎日または時間単位など) で実行され、最後のバージョンまたはタイムスタンプ以降にキャプチャされた変更に基づいて、データの増分スナップショットを読み込みます。
ヒント
差分テーブルから Azure Cosmos DB for NoSQL に大量の増分ボリュームが読み込まれるときにデータの不整合を回避するために、新しい Azure Cosmos DB スナップショットに切り替えます。 たとえば、新しいコンテナーに書き込む場合やバージョン フラグを使用する場合は、新しいデータが完全に読み込まれたら、新しいスクリーンショットへのポインターを反転します。
ストリーム CDC 同期: このオプションは、ほぼリアルタイムで増分変更を継続的に同期し、ターゲット システムを最小限のラグで最新の状態に保ちます。 このオプションでは、Apache Spark 構造化ストリーミングを使用して、変更を継続的にキャプチャおよび書き込みます。 デルタ テーブルは、
readChangeData = trueを使用したストリーミング ソースとして機能し、Azure Cosmos DB for NoSQL コネクタはストリーミング シンクとして機能します。ヒント
チェックポイントの場所を指定して、進行状況が追跡され、重複する書き込みが回避されるようにします。
ベスト プラクティス
Azure Cosmos DB for NoSQL コネクタで Apache Spark バッチ ジョブを使用して、最初の読み込み手順を実行します。
初期負荷が割り当てられたスループットに対して大量の RU/秒を消費することが予想される場合は、標準のプロビジョニング済みスループットに切り替えてインジェスト スループットを最適化します。 具体的には、最初の読み込みプロセスのほとんどの期間、1 秒あたりの最大要求ユニット数 (RU/秒) が一貫して使用される場合は、標準のプロビジョニングスループットを使用します。 このシナリオでは、最初の読み込み手順に自動スケーリング スループットを使用しないでください。
ヒント
正規化された RU 消費量メトリックが一貫して 100%である場合、メトリックは初期負荷が最大自動スケール要求ユニット (RU) を一貫して消費することを示します。 このしきい値は、このシナリオがワークロードに適用され、標準のプロビジョニング済みスループットを使用する必要があることを明確に示します。
並列処理を最大化する有効なパーティション キーを選択します。 詳細については、 パーティション分割とパーティション キーに関する推奨事項を参照してください。
大規模なデータ インジェストのために、すべてのパーティションのパーティションの合計数と合計 RU/秒を計画します。 詳細とガイダンスについては、 パーティション分割とスループットに関する推奨事項を参照してください。
Apache Spark スループット制御を使用して、ジョブの要求ユニット (RU) の消費量を制限します。 スループット制御は、ターゲット操作コンテナーのオーバーロードを防ぐのに役立ちます。
Azure Cosmos DB for NoSQL for CDC 同期では、自動スケールが使用量に基づいて RU/秒を動的にスケールアップまたはスケールダウンするため、可能な場合は自動スケール スループットを使用します。 自動スケーリングによるスループットは、スケジュールされた CDC 同期ジョブなどの定期的かつ変動が激しいワークロードに最適です。 詳細については、 スループットに関する推奨事項を参照してください。
データ初回読み込み手順のインジェスト時間を見積もります。 詳細とサンプルについては、 スループットの見積もりを参照してください。