Azure Data Factory の課題：UI パイプラインと Spark 変換の隠れたコスト

Azure Data Factory は、あらゆる Azure 環境においてデフォルトの統合ツールとして選ばれており、データ転送層としてはその地位を確立しています。Copy アクティビティ、トリガー、サービス間のファイル移動などはまさに得意分野です。しかし、ADF にモデリングやデータ変換の責務まで負わせようとした瞬間から運用の摩擦が生じ始めます。その摩擦は、本シリーズの個別記事で詳しく解説している 3 つの場所に顕著に現れます。

3 つの壁、1 つの原因

• キャンバスの限界： ソースごとに行儀よくコピーされた何百もの手作業のアクティビティは、配線した本人しか解読できなくなります。詳しくは大規模なビジュアルパイプラインに関する記事をご覧ください。
• リリースの破綻： ARM テンプレート、環境ごとのパラメータファイル、そしてわずか 1 箇所のデータ型の不一致で失敗するデプロイ作業に悩まされます。詳しくは JSON デプロイに関する記事をご覧ください。
• 膨れ上がる Spark 費用： ウェアハウス内の 1 行の SQL 文で瞬時に済むデータロードに対して、実行ごとにマネージド Spark クラスターが起動し高額な課金が発生します。詳しくは Mapping Data Flow のコストに関する記事をご覧ください。

これら 3 つの問題はすべて同一の根本原因から生じています。それは、「データウェアハウスの設計構造を、パイプラインを自動生成するモデルとしてではなく、クラウドサービス上のパイプライン設定として直接書き込んでしまっている」という点です。

4 つ目の壁：クラウドを乗り換えられない

ADF のパイプラインは Azure のリソースそのものです。AWS や Google Cloud 上でそのまま動作するバージョンは存在せず、マイクロソフトの後継サービスである Fabric Data Factory も同様に Azure 固有の環境に依存します。システム環境が永続的に Azure だけで完結している限りは問題ありません。しかし、企業の統廃合、調達方針の変更、マルチクラウド戦略の策定などによって別のプラットフォームが選ばれた瞬間、すべてのパイプラインが全面的な書き直し（リビルド）を迫られます。なぜなら、データ変換ロジックがデータウェアハウスではなく特定のクラウド基盤に固く結びついているからです。

一方で、モデルによって管理されるデータウェアハウスにはそのような縛りはありません。生成されるネイティブ SQL は、データウェアハウスが稼働する任意の場所でそのまま実行できます。

Datavault Builder による変革

Datavault Builder は、データウェアハウスをビジュアルなモデルとして一元管理し、ステージング、Vault、ビジネス層への配信ロードに加えて、デプロイ、ロールバック、ドキュメント、データリネージをモデルから完全自動生成します。生成されたコードは、Fabric、Synapse、Azure SQL、SQL Server 上でネイティブに稼働します。

• ビジネスをモデル化すれば、残りは自動構築： エンティティ、キー、リレーションシップを 1 度定義すれば、テーブル構造とすべてのロード処理が自動生成されます。新しいデータソースの追加は単なるマッピング作業であり、アクティビティを複製する作業ではありません。キャンバスは身軽なファイル移動とトリガーだけに縮小されます。
• ロールバックを含むリリーススクリプトの自動生成： モデルの差分からターゲット環境ごとのデプロイスクリプトが生成され、実行前に事前検証されます。手作業で整合性を保つべき ARM テンプレートは不要です。
• データベースエンジン内でのネイティブ実行： ターゲットプラットフォームに最適化されたセットベースの差分 SQL を実行します。一般的なウェアハウス処理にクラスターは不要です。
• ポータブルなデータモデル： 今日は Fabric、将来もし別のプラットフォームに移行することになっても、同じモデルをそのまま再利用できます。クラウドの変更はターゲット設定の変更に過ぎず、コードの書き直しは発生しません。
• ADF はシンプルな役割に限定： ファイル移動やイベント連携は引き続き Data Factory で担い、Datavault Builder のジョブをトリガーします。複雑なロードオーケストレーションはプラットフォーム内部で堅牢に実行されます。

何から始めるべきか

まずは 2 つのリストを作成することから始めてください。1 つ目は、最大規模のパイプラインの中で、ソースごとのコピー、参照、プロシージャ呼び出しのためだけに存在しているアクティビティのリストです。2 つ目は、Azure の請求書に記載された Mapping Data Flow の明細を実行あたりの処理行数で並び替えたリストです。前者は「モデルによって自動生成すべきキャンバスの領域」であり、後者は「外部クラスターではなくウェアハウス内で直接処理すべきワークロード」です。多くの場合、これら 2 つが Data Factory 全体の大部分を占めています。