社内のバッチ処理やETL（データを抽出・変換・格納する一連の処理）を組み替える際、ワークフローオーケストレーター（複数のジョブの実行順序・依存関係・再実行を管理する基盤）の選定で悩む担当者は少なくありません。
候補は主にDatabricks Workflows、Apache Airflow、Dagsterの3つです。どれも「妥当なデフォルト」と言える成熟度に達していますが、最適化している方向がまったく違います。選定を誤っても初日には何も壊れません。問題は1年半ほど経ってから、運用チームがスケジューラの保守に追われるか、開発チームが基盤の制約と戦い続けるかという形で表面化します。
本記事では、業務システムの保守運用という観点から、3つの選択肢をどう見極めるかを整理します。
どんな場面で判断が必要になるか
典型的なのは、既存のバッチ処理群をモダナイズするタイミングです。
cronで動かしていたジョブが増えすぎて依存関係が把握できない、失敗時の通知が属人化している、といった状態から脱却したい場面が代表例です。
もう一つは、Databricksを分析基盤として導入済みの企業が、ETL全体の指揮系統をどこに置くか決める場面です。既存のAirflow環境を残すか、Databricks Workflowsに寄せるか、という選択が発生します。
さらに、複数のSaaS API・オンプレミスのデータベース・メッセージキューをまたぐ複雑なパイプラインを、データ品質の検証込みで構築し直したい場面でもこの判断が必要になります。
判断軸1: 接続先システムの多様性
最初に確認すべきは、パイプラインが何種類のシステムに触るかです。
Databricks Workflowsは、ジョブ・クラスタ・Unity Catalog（Databricksのデータガバナンス機能）の権限管理が同じ制御プレーン上にあります。そのため、別建てのスケジューラや二重の認証情報管理が不要になります。
ただしこれは裏を返せば、Databricks以外のシステムとの連携が弱いという意味でもあります。Salesforceのエクスポート待ちや内部APIの呼び出し、Databricks SQL以外の倉庫に対するdbt実行を組み込みたい場合、Webhookや外部スクリプトで無理やり繋ぐ形になり、ツールの流儀に逆らうことになります。
一方でAirflowは、最大級のオペレーターエコシステム（各種システムへの接続部品群）を持ち、10年間の本番運用で鍛えられています。倉庫が2つ、SaaS APIが3つ、オンプレのデータベース、メッセージキュー、そこにDatabricksも混ざるといった構成なら、Airflow相当の広いカバレッジを持つツールはほぼ必須です。異種システムをまたいで指揮する前提で設計されている点が、他の2つと決定的に違います。
判断軸2: 運用負荷を誰がどれだけ引き受けられるか
Airflowの広さには対価があります。自前でホストする場合、スケジューラ・メタデータDB・Webサーバー・ワーカーの4種類のコンポーネントを運用し続ける必要があります。
DAG（タスクの依存関係を表す有向非巡回グラフ）の数が増えるとパース性能が落ちる問題や、タスク分離の甘さといった細かい課題も自分たちで抱えることになります。
AWSのMWAA、Astronomer、GoogleのCloud Composerといったマネージドサービスを使えばインフラの負担は減りますが、コストは発生しますし、DAGのデプロイや依存関係のバージョン管理は結局自分たちの仕事として残ります。
Databricks Workflowsは、この運用負荷のカテゴリをまるごと削減できる点が強みです。すでにDatabricksを分析基盤の中心に据えているなら、別のスケジューラを維持する理由は薄くなります。
判断軸3: データ品質への信頼をどう担保するか
Airflowの実行モデルはタスク中心です。タスクが実行されたことは分かっても、そのタスクがどんなデータを生成したか、そのデータが新鮮か妥当か、他のDAGが書き込む対象と同じアセットかは分かりません。
この弱点を補うため、多くのチームはdbtを重ねたり、アセットチェックの規約を独自に追加したりして対処しています。Airflow 3ではタスク分離の改善やアセット認識の一部組み込みが進みましたが、運用モデルの本質は「自分で動かすか、動かす人にお金を払うか」のままです。
Dagsterはここで異なる前提から出発しています。タスクをオーケストレーションするのではなく、パイプラインが生成するデータアセットとその依存関係を宣言する「ソフトウェア定義アセット」という考え方です。スケジューラは、そのアセットグラフからDAGを自動的に組み立てます。
この設計により、単一のアセットだけをマテリアライズ（実際に計算・保存)して、入力をモックしてローカルで検証する、といった開発体験が大きく改善します。パイプライン全体を立ち上げずに1つのアセットだけテストできる点は、Airflowでは得にくい利点です。データリネージ（データの来歴・加工過程の追跡)も、後付けの仕組みではなく定義の副産物として自然に得られます。Airflowで「DAGは通ったのに中身がゴミデータだった」という経験があるチームにとって、Dagsterの型付きI/Oとアセットチェックの仕組みは信頼性の面で明確な進歩です。
代わりに支払う対価はエコシステムの小ささです。Airflowほど多くの外部システム向けオペレーターが揃っているわけではなく、社内の接続先が多岐にわたる場合は自作の統合コードが増える可能性があります。
3つの選択肢の比較
| 観点 | Databricks Workflows | Airflow | Dagster |
|---|---|---|---|
| 運用負荷 | 低い(単一制御プレーン) | 高い(自前運用は4コンポーネント) | 中程度 |
| 外部システム連携 | 弱い(Databricks中心) | 強い(最大級のエコシステム) | 中程度(拡大中) |
| データ品質・リネージ | タスク単位で弱い | 後付けの補強が必要 | 設計段階で組み込み済み |
| 採用のしやすさ | Databricks前提 | 実績豊富・人材確保しやすい | 比較的新しく人材は限定的 |
ケース別の推奨
分析基盤がDatabricksで完結している(取り込み・変換・機械学習・提供まで)なら、Databricks Workflowsを選ぶのが妥当です。別のスケジューラを並行運用するコストを避けられます。
接続先が10前後のシステムにまたがり、SaaS API・オンプレDB・メッセージキューが混在するなら、Airflowか同等の広さを持つツールがほぼ必須です。
データの信頼性が繰り返し問題になっていて、DAGは成功するのに出力データが壊れているという経験があるなら、Dagsterのアセットベースの設計を検討する価値があります。ローカルでの単体検証のしやすさも、テスト文化を整えたいチームには大きな利点です。
あえて見送るべき条件
Databricksを部分的にしか使っておらず、他の倉庫やSaaSとの連携が主戦場になっているなら、Databricks Workflowsは避けたほうが安全です。無理に寄せると外部連携のたびにWebhookの応急処置が積み上がります。
すでに広範なオペレーターエコシステムに依存した大規模なAirflow環境が稼働していて、移行の投資対効果が見えない場合、Dagsterへの全面移行は見送る判断も妥当です。エコシステムの狭さが移行後にボトルネックになる可能性があります。
逆に、接続先がほぼ単一システムに閉じているのにAirflowを選ぶのは、必要以上の運用負荷を背負うことになります。習慣で選んでいないか、一度立ち止まって確認する価値があります。
まとめ
選定の出発点は、接続先システムの多様性・運用負荷を負える体制・データ品質への要求水準の3つです。
Databricks中心ならWorkflows、異種システムをまたぐならAirflow、データ資産としての信頼性とテストのしやすさを重視するならDagster、という整理がまず出発点になります。
実際に判断する際は、現行のパイプラインが触っているシステムの数を棚卸しし、運用チームの人員でAirflowの4コンポーネントを維持できるか確認し、DAGの成功と実データの妥当性がどれだけ乖離しているかを洗い出すところから始めてみてください。