AirflowからLakeflowへ？Databricksが示すデータワークフロー近代化の選択肢
データエンジニアリングの世界では、ワークフローのオーケストレーションが常に中心的な課題です。長年にわたり、多くの組織がApache Airflowをその強力なエコシステムと柔軟性のために採用してきました。しかし、プラットフォームが進化するにつれて、運用負荷や近代的なデータスタックとの統合が新たな課題として浮上しています。
本記事では、DatabricksのプロダクトマネージャーであるJames氏とRoland氏によるセッション「From Apache Airflow to Lakeflow Jobs: A Guide for Workflow Modernization」の内容をもとに、既存のAirflow環境をどのように近代化できるか、そしてDatabricks Lakeflowがどのような選択肢を提供するのかを、客観的な視点から深掘りしていきます。Airflowを使い続けている方、あるいは新しいオーケストレーションツールを検討している方にとって、具体的なヒントが見つかるはずです。
Apache Airflowの強みと直面する課題
まず、Apache Airflowがなぜこれほど広く受け入れられているのかを再確認しておきましょう。AirflowはPythonでワークフローをコードとして記述できるオープンソースのプラットフォームです。これにより、データパイプラインをDAG（有向非巡回グラフ）として定義し、複雑な依存関係やスケジューリングを柔軟に管理できます。セルフホスト型であるため、組織の要件に合わせてインフラを自由にカスタマイズしたり、豊富なコミュニティ製オペレーターを活用して様々な外部システムと連携したりできる点が大きな魅力です。
一方で、この自由度の高さは、運用上の課題と表裏一体です。セッションでも指摘されたように、セルフホスト環境の維持にはインフラのプロビジョニング、スケーリング、セキュリティパッチの適用といった継続的な管理コストが発生します。特に組織が拡大し、扱うデータパイプラインが数百、数千に達すると、これらの管理業務はデータチームにとって大きな負担となり得ます。
Databricks Lakeflowの全体像
こうした課題に対する一つの答えとして、Databricksは「Lakeflow」を提唱しています。Lakeflowは、Databricksが推進するData Intelligence Platformの中核をなす機能群であり、単一のオーケストレーションツールというよりは、データワークフロー全体をカバーする統合ソリューションと位置づけられています。
セッションによると、Lakeflowは主に以下の3つのコンポーネントで構成されています。
- Lakeflow Connect: SalesforceやGoogle AnalyticsといったSaaSアプリケーション、PostgreSQLなどのデータベース、あるいはクラウドストレージ上のファイルなど、多様なデータソースからのデータ取り込みを簡素化するコネクタ群です。
- Lakeflow Declarative Pipelines (旧Delta Live Tables): データ変換ロジックを宣言的に記述することで、パイプラインの構築を容易にするフレームワークです。プラットフォーム側で依存関係の解決やインクリメンタルな処理が自動化されます。
- Lakeflow Jobs: Databricksプラットフォーム上でのあらゆる処理（ノートブック、SQLクエリ、dbt Coreプロジェクトなど）をオーケストレーションするためのフルマネージドな機能です。
これらのコンポーネントは、Databricksの統合データガバナンス基盤であるUnity Catalog上に構築されており、データリネージの自動追跡やきめ細かなアクセス制御といった恩恵を標準で受けることができます。
LakeflowとAirflowのアーキテクチャ比較
では、LakeflowとAirflowは具体的に何が違うのでしょうか。セッションではいくつかの重要な比較点が示されました。
- 運用形態: Lakeflow Jobsはフルマネージドかつサーバレスで提供されるため、ユーザーはインフラの管理について一切気にする必要がありません。一方、Airflowはセルフホストが基本であり、インフラ管理の責任はユーザー側にあります。
- 開発体験: Airflowはコードファーストのアプローチを基本とするのに対し、Lakeflowは「Lakeflow Designer」のようなUIベースの開発から、Databricks Asset Bundles（DABs）を用いたコードベースのデプロイまで、幅広いスキルレベルのユーザーに対応しています。
- プラットフォーム統合: Lakeflow JobsではUnity Catalog内のテーブルが更新されたことをトリガーにジョブを自動実行する「テーブルトリガー」がネイティブ機能として提供されています。Airflowで同様のことを実現するには、
Sensorによるポーリングが必要で、リソース消費や遅延のリスクがあります。
AirflowとLakeflowを組み合わせる2つのパターン
セッションで特に強調されていたのは、AirflowとLakeflowは排他的ではなく、「Better Together（共に使うことでより良くなる）」という考え方です。既存のAirflow資産を活かしつつ、Lakeflowの利点を取り入れるためのパターンが2つ紹介されました。
AirflowからLakeflow Jobを呼び出す このパターンでは、データ取り込みから変換、分析までの一連のロジックをLakeflow JobとしてDatabricks内に定義します。Airflowは
DatabricksRunNowOperatorを通じてそのジョブをトリガー役に徹し、パイプラインロジックをDatabricks側に集約できます。なお、Airflowからの接続設定や認証管理は引き続き必要です。AirflowからLakeflowの機能を個別に呼び出す Airflowを全体のオーケストレーターとして維持しつつ、DAG内のタスク単位でDatabricksの機能を利用します。たとえば、あるタスクではDatabricksノートブックを実行し、次のタスクではDatabricks SQLを実行するといった構成です。 動的タスク生成については、Lakeflow Jobsで
for_eachを使う方法が紹介され、Airflowにも動的タスクマッピングなどの機能がある点が示されました。ただし実装の詳細や成熟度には差異がある可能性があります。
実践デモ：AI感情分析パイプラインをAirflowで構築
デモでは、オンライン小売業者が顧客レビューを分析するというシナリオが紹介されました。このワークフローはAirflowのDAGとして定義され、Databricksの各種機能を活用して構築されています。
- ストリーミングデータの取り込み: Databricksの Streaming Tables を作成し、継続的に到着するデータをインクリメンタルに処理するテーブルを定義。
- 集計ビューの高速化: Materialized Views を構築し、クエリ結果を物理的に保持することで、ダッシュボードなどからのアクセス時に高速応答を実現。
- AIによる感情分析:
SQLの AI Functions（例：
ai_query）を使い、レビューのテキストを外部LLMモデルに渡してポジティブ／ネガティブ判定を実行。一行のSQLでAI機能が呼び出せる点が特徴です。
これらのタスクがAirflowのUIから順次トリガーされ、Databricksのクエリ履歴で実行状況をモニタリングできる様子は、両プラットフォームのシームレスな連携を示しています。
高度な機能の比較と検討ポイント
セッションの後半では、より高度なオーケストレーション機能について、Lakeflow JobsとAirflowを比較しながら、選択や併用の検討ポイントが示されました。
- 条件分岐 (If/Else): 上流タスクの結果に基づいて後続処理を分岐させる機能は、両者でサポートされています。
- 動的タスク生成 (Loop): Lakeflow Jobsでは
for_each、Airflowでは動的タスクマッピングといった手法でループ処理が可能です。 - DAG間連携: あるDAGが別のDAGをトリガーする機能も両ツールで提供されています。
- イベントドリブン実行: Lakeflow Jobsはテーブル更新をネイティブにトリガーできる一方、Airflowは
Sensorを使ったポーリングで対応します。
これらを踏まえ、各組織のユースケースや運用体制に応じた検討ポイントを整理します。
AirflowとLakeflowの検討ポイント
- Airflow継続の理由:
多様なオンプレミスやSaaSシステムとの連携で、既存のAirflowエコシステムを活かしたい場合。 - Lakeflow Jobs検討の理由:
Databricks上で完結するデータ処理を中心に据え、インフラ管理やスケーリングをプラットフォームに委ねたい場合。UIベースからコードベースまで幅広い開発体験を必要とするチームにも適しています。 - 統合アプローチ:
Airflowを外部システム連携ハブとして維持しつつ、LakeflowのStreaming TablesやAI Functionsなどをパイプラインの一部として組み込むことで、Databricks固有の機能をシームレスに活用できます。
まとめ：競合ではなく「共存」の時代へ
今回のセッションは、AirflowとLakeflowを単なる競合製品とみなすのではなく、互いの強みを補完し合う「Better Together」というメッセージを示しました。
Airflowのオープンなエコシステムとコミュニティによる拡張性は依然として強力です。一方で、Lakeflow Jobsが提供するフルマネージドな運用体験やUnity Catalogとの深い統合は、データパイプラインの開発と管理を大幅に簡素化します。
データワークフローの近代化とは、単一のツールにすべてを置き換えることではありません。自社のユースケースやチームのスキルセット、ガバナンス要件を踏まえ、最適なツールを賢く組み合わせることが、これからのデータエンジニアリングの鍵となるでしょう。
