Azure Data Factory の Mapping Data Flow のコストがデータ価値を上回っていませんか？

Mapping Data Flow は、Azure Data Factory でノーコードのデータ変換を実現する中核機能であり、キャンバスの裏側ではマネージド Spark クラスターが稼働しています。クラスターが起動し、フローが実行され、クラスターが停止するまでの間、vCore 時間単位で課金が発生します。テラバイト級の大規模なデータ変換であれば、このコストは十分に正当化されます。しかし、一般的なデータウェアハウスのロード処理の大半において、それは 1 行の SQL 文で瞬時に終わる処理のために、わざわざ専用の巨大な分散クラスターを立ち上げているようなものです。

コストが膨張する理由

• 実行するたびにクラスター起動費用が発生する： クラスターの立ち上げには数分かかり、処理対象が 1,000 万行であってもわずか 1 万行であっても、その起動時間分の料金が確実に請求されます。
• ウォームスタンバイはコストの性質を変えるだけで削減にはならない： Integration Runtime に TTL（Time to Live）を設定してクラスターを維持すれば待ち時間はなくなりますが、今度はアイドル中のクラスター費用を支払い続けることになります。
• 小規模なロード処理が大半を占めている： データウェアハウスのロード処理の多くは、小規模かつ高頻度です。これはクラスターごとの時間課金モデルにとって、最もコストパフォーマンスが悪化するパターンです。
• データはすでにデータベース内に存在している： ウェアハウス内のリレーショナルデータを一度外部の Spark に読み込み、変換処理を行った上で、再びウェアハウスに書き戻しています。ウェアハウスのエンジン自体がその場で直接処理できるにもかかわらず、無駄なデータ転送とコンピュートを発生させています。

これらは Data Flow 自体の欠点ではありません。Spark は高負荷なビッグデータ変換のために設計されており、通常のデータウェアハウスの標準的なロード処理にはオーバースペックなのです。

データ変換が本来行われるべき場所

• データを保持しているデータベースエンジン内部： Fabric、Synapse、Azure SQL、SQL Server は、いずれも強力なセットベースのデータベースエンジンです。差分ロードは、これらのエンジンが最も得意とする処理です。
• 全件再処理ではなく差分（デルタ）処理： 自動生成された Vault ロードは、すでに履歴保持されているデータと照合し、変更があったレコードのみを最小限の処理で反映します。
• プラットフォームごとに一度だけ自動生成： 個々の開発者がフローごとに手探りでチューニングするのではなく、ターゲットエンジンに合わせて極限まで最適化されたセットベースの SQL が一貫して自動生成されます。

Datavault Builder による変革

Datavault Builder は、Hub、Link、Satellite のためのセットベースの差分ロードを自動生成し、Fabric、Synapse、Azure SQL、SQL Server 向けに最適化してコンパイルします。これにより、途中に外部クラスターを介在させることなく、ウェアハウス内部で直接標準的なデータ変換を実行します。

• 標準ロードにクラスターは一切不要： ロード処理は、すでにデータを保持しているエンジン内の SQL 文として直接実行されます。クラスターの起動待ちも、無駄なアイドル費用も発生しません。
• すべてのロード処理が差分処理： 新規および変更された行のみが移動・処理されるため、データ全体の総量ではなく、ソースの変更量に応じた最小限のコンピュートコストしかかかりません。
• 履歴管理はサテライトに記録、再計算は不要： 過去時点の問い合わせ（as-was）には、記録済みの変更差分から直接回答できるため、毎晩過去データ全体を再集計する必要はありません。
• Spark は真に必要なワークロードだけに限定： 極めて巨大なデータセットや非構造化データの処理にのみクラスターを残します。それらは例外的な処理となり、ウェアハウス全体のベースコストを押し上げる要因ではなくなります。
• コンピュートコストの予測が容易： ウェアハウスのキャパシティは事前に計画・予約できる安定したリソースです。実行ごとの予測不能なクラスター稼働時間とは異なります。

今すぐ判断すべきこと

Azure の請求書から Mapping Data Flow の項目を取り出し、1 回の実行あたりの処理行数で各フローを並び替えてみてください。クラスターの起動コストが実際の処理価値を上回っているすべてのフローは、クラスターではなくネイティブ SQL として自動生成すべき対象です。