Apache Airflowに関する6つの不都合な真実（およびその対処法）

複雑な取り込みプロセスを扱うデータ・チームは、Apache Airflowを特に気に入っています。

Pythonでワークフローを定義できます。そのシステムには幅広い拡張性があり、健全なプラグインの 幅を提供します。ユーザーの86％が満足し、他のワークフロー・エンジンよりも継続して使用する予定であると回答しています。同じ数の回答者がその製品を推奨すると回答しています。

しかし、すべてのソフトウェア、特にオープンソースの種類のソフトウェアと同様、Airflowも、補う必要のある多数のギャップや欠点に悩まされています。これは、まだ慣れていない開発者にとっては、開始が遅く、進むのが困難であることを意味します。この記事では、これらの問題と、考えられるいくつかの回避策について説明します。

Airflowはブラインダーを備えた労働者です。データに問題が発生した場合に軌道修正することは何もせず、パイプラインのみに行います。ほぼすべてのユーザーが、あるバージョンの Airflow でジョブが完了したと告げられ、その後データをチェックしただけで、列が欠落していてすべてが間違っている、またはデータが実際にシステムを通過していないことがわかった経験があります。

これは特に、データの組織が成熟し、データ非巡回グラフィック（DAG）が10個から数千個に増えたときにはなおさら当てはまります。このような状況では、外部データソースやAPIからデータを取り込むためにDAGを使用している可能性が高く、Airflowでのデータ品質管理がさらに難しくなっています。ソース・データセットを「クリーンアップ」したり、ガバナンスポリシーをそこで実装したりすることはできません。

各実行を手動でチェックするための Slack アラートを作成することもできますが、Airflow をデータ・エンジニアリング組織の便利な要素として組み込み、 SLA を満たすためには、品質チェックを自動化したくなるものです。そのためには、ジョブが実行されたかどうかだけでなく、正しく実行されたかどうかも可視化する必要がありますまた、正しく実行されなかった場合には、その理由とエラーの発生場所の可視化も。それがなければ、同じことが繰り返される「グラウンドホッグ・デー」を体験することになります。

これは単純な課題ではありません。率直に言えば、IBM Databandが設立された理由はそこにあります。DatadogやNew Relicのようなほとんどの製品オブザーバビリティ・ツールは、パイプラインを分析するように構築されておらず、問題の発生場所を特定したり、共起問題をグループ化して根本原因を示したり、修正プログラムを提案したりすることができません。

しかし、Airflowコミュニティー内でも、オブザーバビリティーの必要性はまだ完全には理解されていません。現在、データ品質測定を実施したと答えた回答者はわずか32％ですが、この調査の作成者が質問しているという事実は改善の兆しでもあります。2019年と2020年の調査では、この質問をしていませんでした。

Airflow でデータ品質を監視するにはどうすればよいでしょうか?実際、Airflowはその半分まで達成してくれます。保守担当者が指摘するように、「ワークフローがコードとして定義されると、保守性、バージョン管理性、テスト性、共同作業性が向上します。」

Airflowは、コードの正式な表現を提供します。あなたが必要とするのは、データ・パイプラインを監視するために特別に構築されたオブザーバビリティー・ツールです。製品を監視するために構築されたものは中間的な対策ですが、すでにそれらのライセンスを持っているため、通常は観察可能性プロセスの一部となります。

エンジニアリング組織が完全な観察可能性、つまり成熟した状態に至るまでには、通過するいくつかの段階があることがわかりす。

• 事前アウェアネス： データ品質を監視していない（Airflowコミュニティーの68％）。
• ダクトテープと梱包用ワイヤー:理想的ではないかもしれませんが、製品観察ツールを借りて機能させます。
• 目的のあるソリューション: Databandなどのフルパイプライン・オブザーバビリティー・ツールを採用することで、アラートの自動化、根本原因の特定、問題の迅速な修正が可能になります。予想されるデータ・パラメーターに基づいて機械学習を設定し、Airflow Schedulerで欠落しているデータやスキーマの変更を示すSlackアラートを取得し、問題の系譜を遡り、履歴データを使用してバックテストを行います。

Airflowの学習には時間の投資が必要です。多くの記事やStack Overflowのスレッドでは、「なぜ自分がスケジュールに入れた作業が始まらなかったのか？」といった基本的な疑問で行き詰まってしまう開発者たちの苦労が記録されています。（一般的な回答：Airflow Schedulerは、スケジュールされた期間の最初ではなく、終わりにスケジュールを開始します。詳しくは後で説明します。）

さらに、Airflowを使いこなすには、Celery Executorのほか、RabbitMQまたはRedisのいずれかを学ぶ必要があり、これを回避する方法はありません。

この摩擦は十分で、CMSソフトウェア会社のBluecoreのような一部の組織は、実質的に自分たち独自のAirflowインターフェースをコーディングする方が簡単だと判断しました。そうすることで、雇ったり割り当てたりした新しい開発者はそれぞれ、新しいオペレーターをすべて学ぶ必要はなく、代わりにすでに慣れ親しんだKubernetesに頼ることができます。

これらの学習のハードルはコミュニティーにとって繰り返し発生する問題であるため、Airflowの2021年コミュニティー調査（以下の写真）では、「オンボーディングの問題」について独自の質問が投げかけられました。

ユーザーの最大の不満の中に、「DAG の開発に関するベスト・プラクティスの欠如」と「簡単に立ち上げられるオプションがない」というものがありました。この後者の問題は、Airflowバージョン2.0（調査済み後にリリースされた）で部分的に対処されていますが、このバージョンは並列化が不可能なSQLiteデータベース上で実行され、すべてが順番に行われます。
Airflowのクイックスタートガイドが指摘するように、「これは非常に制限的」であり、「すぐに成長して卒業できるはず」なのです。

Airflowの主なユースケースは、頻繁な実行ではなく、定期的なバッチのスケジュール設定です。このことは、その独自のドキュメンテーションでも、「ワークフローはほとんど静的であるか、またはゆっくりと変化することが予想される」と証明されています。これは、アドホックかつ継続的にデータをサンプリングしたりプッシュしたりする必要があるユーザー向けの機能がほとんどないことを意味し、一部のETLやデータサイエンスのユースケースには理想的ではありません。

それだけではありませんこれについては前に触れましたが、Airflow Schedulerは、Airflow Schedulerの開始間隔の始めではなく終わりに schedule_interval ジョブを実行します。つまり、予想以上にポケット数学の計算を行うことになり、ときには驚かされることになります。

そして、これらのスケジュールされたジョブを適切に実行するには、オペレーターとタスクの間の Airflow 固有のニュアンス、DAG の動作、デフォルト引数、Airflow メタデータ・データベース、DAG をデプロイするためのホーム・ディレクターなどを学ぶ必要があります。

修正は？独自のグラフィカル・ユーザー・インターフェイスを開発し、自分たちにとってより意味のある用語にオペレーターの名前を変更するAirflowユーザーの6％に加わることを検討してみてください。

Airflow には従来のソフトウェア開発や DevOps のプラクティスの多くが欠けていますが、その大きなものの 1 つがパイプラインのバージョンを維持できる能力です。構築したすべてを文書化し、必要に応じて以前のバージョンに戻す簡単な方法はありません。たとえば、DAGからタスクを削除して再デプロイすると、タスク・インスタンス上の関連するメタデータが失われます。

これにより、Airflowはやや脆弱になり、これを自分でキャプチャするスクリプトを作成していない限り、問題のデバッグがはるかに困難になります。過去のデータに対して修正プログラムをバックテストして検証することはできません。

繰り返しになりますが、Airflowは正式なコード表現を提供します。課題は、欠けている機能を埋めるために他のソフトウェア開発と DevOps ツールを適用することです。

他に言うことはあまりありません。メイン・リポジトリに含まれていない特定のDocker composeファイルを使用しない限り、それは不可能です。

Airflowスケジューラーが機能しない？コーヒーを補充したほうがいいでしょう。これから、時間のかかるデバッグ作業が待っているかもしれません。

これは、私たちの意見では、Airflowはオーケストレーションを行うオペレーターと実行するオペレーターを十分に区別していないからです。多くのオペレーターは両方を行っています。それはプラットフォームの最初のコーディングには役に立ったかもしれませんが、デバッグを非常に困難にする致命的な組み込みとなります。何か問題が発生した場合、開発者はまずDataFlowのパラメーターを、次にオペレーター自身を毎回調べる必要があります。

そのため、Databandのようなツールが大いに役立ちます。Databandは、グローバルなAirflow、DAG、タスク、ユーザー対応など、あらゆるレベルでインフラストラクチャーのヘルスを把握するための支援に優れています。Databandは、データエンジニアリングの時間を非常に特殊な機能の学習に費やす代わりに、データエンジニアがビジネスの問題解決に真に集中できるようにします。

時間をかけて新しい変更を提案するオープンソースの貢献者なら誰でもそうであるように、この記事が愛のメモとして解釈されることを願っています。私たちDatabandは、Airflowコミュニティーに積極的に貢献しており、既存の制限を超えて成長し、より多くのETLとデータサイエンスのユースケースに優れたサービスを提供することを強く望んでいます。

前述したように、ユーザーの86％は他の運用エンジンよりもこのモデルを使い続ける予定です。86％が「強く推奨したい」と回答しました。私たちは両方のグループに属していることを嬉しく思います。これは素晴らしいツールです。Airflowに精通したばかりの方は、前述の問題を念頭に置いて取り組むのであれば、Airflow Schedulerは努力するだけの価値があることを知っておいてください。DatabandがすべてのAirflowの可観測性アクティビティーを統合し、Apache Airflowの可観測性を簡素化し、一元化する方法をご覧ください。さらなる詳細については、今すぐデモを予約してください。