airflow
Apache Airflow 2.10.3
Apache Airflow (または単に Airflow) は、ワークフローをプログラムで作成、スケジュール、監視するためのプラットフォームです。
ワークフローがコードとして定義されると、ワークフローの保守性、バージョン管理性、テスト性、および共同作業性が向上します。
Airflow を使用して、タスクの有向非巡回グラフ (DAG) としてワークフローを作成します。 Airflow スケジューラは、指定された依存関係に従いながら、ワーカーの配列でタスクを実行します。豊富なコマンド ライン ユーティリティにより、DAG での複雑な手術を簡単に実行できます。豊富なユーザー インターフェイスにより、実稼働環境で実行されているパイプラインを簡単に視覚化し、進行状況を監視し、必要に応じて問題のトラブルシューティングを行うことができます。
目次
Airflow は、ほとんどが静的でゆっくりと変化するワークフローで最も効果的に機能します。 DAG 構造が実行ごとに類似している場合、作業単位と連続性が明確になります。他の同様のプロジェクトには、ルイージ、オージー、アズカバンなどがあります。
Airflow は一般にデータの処理に使用されますが、タスクは理想的に冪等であるべき (つまり、タスクの結果は同じであり、宛先システムに重複データが作成されない) ため、大量のデータを渡すべきではないという意見があります。あるタスクから次のタスクへ (ただし、タスクは Airflow の XCom 機能を使用してメタデータを渡すことができます)。大量のデータ集約型タスクの場合、ベスト プラクティスは、その種類の作業に特化した外部サービスに委任することです。
Airflow はストリーミング ソリューションではありませんが、ストリームからデータをバッチで取得して、リアルタイム データを処理するためによく使用されます。
Apache Airflow は以下を使用してテストされます。
| メインバージョン (開発) | 安定版（2.10.3） | |
|---|---|---|
| パイソン | 3.9、3.10、3.11、3.12 | 3.8、3.9、3.10、3.11、3.12 |
| プラットフォーム | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Kubernetes | 1.28、1.29、1.30、1.31 | 1.27、1.28、1.29、1.30 |
| PostgreSQL | 13、14、15、16、17 | 12、13、14、15、16 |
| MySQL | 8.0、8.4、イノベーション | 8.0、8.4、イノベーション |
| SQLite | 3.15.0以降 | 3.15.0以降 |
* 実験的
注: MariaDB はテストされておらず、推奨されていません。
注: SQLite は Airflow テストで使用されます。運用環境では使用しないでください。ローカル開発には SQLite の最新の安定バージョンを使用することをお勧めします。
注: Airflow は現在、POSIX 準拠のオペレーティング システムで実行できます。開発のために、かなり最新の Linux ディストリビューションと macOS の最新バージョンで定期的にテストされています。 Windows では、WSL2 (Windows Subsystem for Linux 2) または Linux コンテナー経由で実行できます。 Windows サポートを追加する作業は #10388 で追跡されていますが、優先度は高くありません。 Linux ベースのディストリビューションはサポートされている唯一の環境であるため、「実稼働」実行環境としてのみ使用する必要があります。 CI テストで使用され、コミュニティ管理の DockerHub イメージで使用される唯一のディストリビューションはDebian Bookwormです。
Airflow のインストール、開始方法、またはより完全なチュートリアルの手順については、Airflow の公式 Web サイトのドキュメント (最新の安定リリース) にアクセスしてください。
注: メイン ブランチ (最新の開発ブランチ) のドキュメントをお探しの場合は、s.apache.org/airflow-docs で見つけることができます。
Airflow Improvement Proposals (AIP) の詳細については、Airflow Wiki を参照してください。
プロバイダー パッケージ、Docker イメージ、Helm チャートなどの依存プロジェクトのドキュメントは、ドキュメント インデックスにあります。
Apache Airflow を PyPI のapache-airflowパッケージとして公開します。ただし、Airflow はライブラリとアプリケーションの両方の役割を果たしているため、インストールが難しい場合があります。通常、ライブラリはその依存関係をオープンなままにし、アプリケーションは通常それらを固定しますが、どちらも同時に行うべきではなく、両方を同時に行うべきではありません。ユーザーが必要に応じてさまざまなバージョンのライブラリをインストールできるように、依存関係を可能な限りオープンな状態 ( pyproject.toml内) に保つことにしました。これは、 pip install apache-airflow時々機能しなくなるか、使用できない Airflow インストールが生成されることを意味します。
ただし、繰り返しインストールできるようにするために、一連の「動作することがわかっている」制約ファイルを孤立constraints-mainおよびconstraints-2-0ブランチに保持します。これらの「動作することがわかっている」制約ファイルは、Python のメジャー/マイナー バージョンごとに個別に保存されます。これらは、PyPI から Airflow をインストールするときに制約ファイルとして使用できます。 URL には正しい Airflow タグ/バージョン/ブランチと Python バージョンを指定する必要があることに注意してください。
注: 現在、正式にサポートされているのは
pipインストールのみです。
Poetry や pip-tools などのツールを使用して Airflow をインストールすることは可能ですが、特に制約と要件の管理に関しては、 pipと同じワークフローを共有しません。 Poetryまたはpip-tools介したインストールは現在サポートされていません。
bazel使用して Airflow をインストールすると、循環依存関係が発生する可能性がある既知の問題があります。このような問題が発生した場合は、 pipに切り替えてください。 Bazelコミュニティはthis PR <https://github.com/bazelbuild/rules_python/pull/1166>での問題の修正に取り組んでいます。そのため、 bazelの新しいバージョンで対処できる可能性があります。
これらのツールを使用して Airflow をインストールする場合は、制約ファイルを使用し、ツールが必要とする適切な形式とワークフローに変換する必要があります。
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "プロバイダー パッケージのインストールについては、プロバイダーを確認してください。
Apache Airflow は Apache Software Foundation (ASF) プロジェクトであり、公式ソース コードがリリースされています。
ASF ルールに従って、リリースされるソース パッケージは、適切なプラットフォームとツールにアクセスできるユーザーがリリースをビルドしてテストするのに十分なものでなければなりません。
Airflow をインストールして使用する他の方法もあります。これらは「便利な」方法であり、 ASF Release Policyで規定されている「公式リリース」ではありませんが、ソフトウェアを自分で構築したくないユーザーも使用できます。
これらは、Airflow をインストールする最も一般的な方法の順序です。
pipツールを使用して Airflow をインストールするための PyPI リリースdockerツール経由で airflow をインストールし、Kubernetes、Helm Charts、 docker-compose 、 docker swarmなどで使用します。イメージの使用、カスタマイズ、拡張について詳しくは、最新のドキュメントを参照し、内部の詳細を学ぶことができます。画像ドキュメント内。これらのアーティファクトはすべて公式リリースではありませんが、公式にリリースされたソースを使用して作成されています。これらのアーティファクトの一部は「開発」または「プレリリース」のものであり、ASF ポリシーに従ってそのように明確にマークされています。
DAG : 環境内のすべての DAG の概要。
Grid : 時間にわたる DAG のグリッド表現。
グラフ: DAG の依存関係と特定の実行の現在のステータスを視覚化します。
タスク期間: さまざまなタスクに費やされた合計時間の経過。
ガント: DAG の期間と重複。
コード: DAG のソース コードを簡単に表示する方法。
Airflow 2.0.0 では、リリースされたすべてのパッケージに対して厳密な SemVer アプローチがサポートされています。
さまざまなパッケージのバージョン管理の詳細を定義する、私たちが同意した特定のルールがいくつかあります。
google 4.1.0およびamazon 3.0.3プロバイダーは、 Airflow 2.1.2とともに問題なくインストールできます。プロバイダーと Airflow パッケージの間に相互依存関係の制限がある場合、それらはinstall_requires制限としてプロバイダーに存在します。私たちは、以前にリリースされたすべての Airflow 2 バージョンとプロバイダーの下位互換性を維持することを目指していますが、一部またはすべてのプロバイダーに最小 Airflow バージョンが指定される可能性がある重大な変更が行われる場合があります。Apache Airflow バージョンのライフサイクル:
| バージョン | 現在のパッチ/マイナー | 州 | 最初のリリース | 限定的なサポート | EOL/終了 |
|---|---|---|---|---|---|
| 2 | 2.10.3 | サポートされています | 2020年12月17日 | 未定 | 未定 |
| 1.10 | 1.10.15 | EOL | 2018年8月27日 | 2020年12月17日 | 2021年6月17日 |
| 1.9 | 1.9.0 | EOL | 2018年1月3日 | 2018年8月27日 | 2018年8月27日 |
| 1.8 | 1.8.2 | EOL | 2017 年 3 月 19 日 | 2018年1月3日 | 2018年1月3日 |
| 1.7 | 1.7.1.2 | EOL | 2016 年 3 月 28 日 | 2017 年 3 月 19 日 | 2017 年 3 月 19 日 |
限定サポート バージョンは、セキュリティと重大なバグ修正のみをサポートします。 EOL バージョンには修正もサポートも提供されません。使用中のメジャー バージョンに関係なく、すべてのユーザーが利用可能な最新のマイナー リリースを実行することを常にお勧めします。 EOL 日より前の都合の良い時期に、最新の Airflow メジャー リリースにアップグレードすることを強くお勧めします。
Airflow 2.0 の時点で、Python と Kubernetes のサポートに関して従う特定のルールに同意しました。これらは、Python と Kubernetes の公式リリース スケジュールに基づいており、Python 開発者ガイドと Kubernetes バージョン スキュー ポリシーにわかりやすくまとめられています。
Python および Kubernetes バージョンは EOL に達するとサポートを終了します。 Kubernetes を除き、2 つの主要なクラウド プロバイダーがそのバージョンのサポートを提供している場合、そのバージョンは引き続き Airflow によってサポートされます。これらの EOL バージョンのサポートは、EOL 日の直後にメインで削除され、Airflow の最初の新しいマイナー (新しいマイナー バージョンがない場合はメジャー) をリリースすると、事実上削除されます。たとえば、Python 3.9 の場合、2023 年 6 月 27 日の直後にメインでのサポートが終了し、その後リリースされる Airflow の最初のメジャー バージョンまたはマイナー バージョンにはサポートが含まれないことを意味します。
新しいバージョンの Python/Kubernetes は、正式にリリースされた後、メインでサポートされます。CI パイプラインで動作するようになるとすぐに (依存関係が Python の新しいバージョンに追いつくため、すぐには機能しない可能性があります)、新しいイメージをリリースします。動作中の CI セットアップに基づいて Airflow でサポートされます。
このポリシーはベストエフォート型であり、状況により必要に応じてサポートを早期に終了する場合があることを意味します。
Airflow コミュニティは、Apache Airflow リリースが公開されるたびに公開される、便利なパッケージ化されたコンテナ イメージを提供します。これらの画像には次のものが含まれています。
基本 OS イメージのバージョンは、Debian の安定バージョンです。 Airflow は、現在アクティブなすべての安定バージョンの使用をサポートします。すべての Airflow 依存関係がビルドをサポートし次第、OS バージョンをビルドおよびテストするための CI パイプラインをセットアップします。以前の安定バージョンの OS の定期サポートが終了する約 6 か月前に、Airflow はサポートされている最新バージョンの OS を使用するようにリリースされたイメージを切り替えます。
たとえば、 Debian BullseyeからDebian Bookwormへの切り替えは、2023 年 10 月の 2.8.0 リリースより前に実装されており、Airflow 2.10.0 の時点でサポートされる唯一のオプションはDebian Bookwormになります。
ユーザーは、定期サポートが終了するまで引き続き安定した Debian リリースを使用してイメージをビルドでき、イメージのビルドと検証は CI で行われますが、 mainブランチでこのイメージを使用して単体テストは実行されませんでした。
Airflow には多くの依存関係 (直接的および推移的) があり、Airflow はライブラリとアプリケーションの両方でもあるため、依存関係に対するポリシーには、アプリケーションのインストールの安定性だけでなく、開発を行うユーザー向けに新しいバージョンの依存関係をインストールする機能の両方を含める必要があります。 DAG。私たちは、 constraints使用してエアフローを反復可能な方法でインストールできるようにするアプローチを開発しましたが、依存関係のほとんどをアップグレードすることをユーザーに制限しませんでした。その結果、依存関係の重要性と、特定の依存関係のアップグレードに伴うリスクを考慮して、上限を設ける必要があると考える十分な理由がない限り、デフォルトでは Airflow 依存関係のバージョンの上限を設定しないことにしました。また、問題の原因となることがわかっている依存関係の上限も設けました。
私たちの制約メカニズムは、上限以外のすべての依存関係を自動的に見つけてアップグレードします (すべてのテストが合格した場合)。 mainビルドの失敗は、テストを壊す依存関係のバージョンがある場合にそれを示します。これは、それらの依存関係からの上流の変更を考慮してそれらを上位バインドするか、コード/テストを修正する必要があることを示します。
このような依存関係に上限を設定する場合は、常にその理由をコメントする必要があります。つまり、依存関係が上限である十分な理由が必要です。また、バインディングを解除するための条件についても言及する必要があります。
これらの依存関係はpyproject.tomlで維持されます。
依存関係は予測可能なバージョン管理スキームに従っていることが知られており、それらの新しいバージョンが重大な変更をもたらす可能性が非常に高いことがわかっているため、デフォルトで上限を設定するほど重要であると判断した依存関係はほとんどありません。私たちは定期的に依存関係を確認し、リリースされる依存関係の新しいバージョンへのアップグレードを試みることを約束しますが、これは手動のプロセスです。
重要な依存関係は次のとおりです。
SQLAlchemy : 特定の MINOR バージョンに上限があります (SQLAlchemy は非推奨を削除し、特に異なるデータベースのサポートが異なり、さまざまな速度で変更される破壊的変更を導入することが知られています)Alembic : 予測可能かつパフォーマンスの高い方法で移行を処理することが重要です。 SQLAlchemy と共同で開発されました。私たちの Alembic の経験では、MINOR バージョンでは非常に安定しています。Flask : Web UI と API のバックボーンとして Flask を使用しています。 Flask のメジャー バージョンでは重大な変更が導入される可能性が非常に高いため、メジャー バージョンに限定するのは理にかなっています。werkzeug : このライブラリは、新しいバージョンで問題を引き起こすことが知られています。 Flask ライブラリと密接に結合されているため、一緒に更新する必要がありますcelery : Celery は、CeleryExecutor (および同様のもの) に使用されているように、Airflow の重要なコンポーネントです。 Celery は SemVer に従っているため、次のメジャー バージョンに上限を設定する必要があります。また、ライブラリの上位バージョンをアップグレードするときは、Celery Provider の最小 Airflow バージョンが更新されていることを確認する必要があります。kubernetes : Kubernetes は、KubernetesExecutor (および同様のもの) に使用されるため、Airflow の重要なコンポーネントです。 Kubernetes Python ライブラリは SemVer に従っているため、次のメジャー バージョンに上限を設定する必要があります。また、ライブラリの上位バージョンをアップグレードするときは、Kubernetes プロバイダーの最小 Airflow バージョンが更新されていることを確認する必要があります。Airflow の主要な部分は Airflow Core ですが、Airflow のパワーは、コア機能を拡張し、個別にリリースされている多数のプロバイダーからもたらされています。たとえ便宜上 (今のところ) 同じモノリポジトリ内に置いているとしてもです。プロバイダーの詳細については、プロバイダーのドキュメントを参照してください。また、プロバイダーのドキュメントには、コミュニティ管理のプロバイダーの維持とリリース、およびコミュニティとサードパーティのプロバイダーのアプローチに関する一連のポリシーも実装されています。
これらのextrasとproviders依存関係は、各プロバイダーのprovider.yamlで維持されます。
デフォルトでは、プロバイダーの依存関係の上限を設定すべきではありませんが、各プロバイダーの管理者が追加の制限を追加することを決定する可能性があります (コメントで制限を正当化する)。
Apache Airflow の構築を支援したいですか?セットアップ手順、コーディング標準、プル リクエストのガイドラインなど、貢献方法の包括的な概要については、貢献者ガイドをご覧ください。
貢献するのが待ちきれず、すぐにでも始めたい場合は、ここで貢献クイックスタートをチェックしてください。
Apache Airflow の公式 Docker (コンテナ) イメージを画像で説明します。
+1s拘束力のある投票とみなされます。 私たちは、Apache Airflow を実際に使用している組織を約 500 社知っています (ただし、さらに多くの組織があると思われます)。
Airflow を使用している場合は、お気軽に PR を作成して、あなたの組織をリストに追加してください。
Airflow はコミュニティの仕事ですが、コアのコミッタ/メンテナは、PR のレビューとマージ、および新機能リクエストに関する会話の舵取りを担当します。メンテナーになりたい場合は、Apache Airflow コミッターの要件を確認してください。
多くの場合、Airflow バージョンの特定のマイルストーンに割り当てられている問題や、メイン ブランチにマージされた PR が表示されますが、マージされた PR がどのリリースでリリースされるのか、または修正された問題がどのリリースになるのか疑問に思うかもしれません。これに対する答えはいつものように、さまざまなシナリオによって異なります。 PR と問題では答えが異なります。
コンテキストを少し追加すると、Airflow リリース プロセスで説明されているように、Semver バージョン管理スキームに従っています。詳細については、この README のセマンティック バージョニングの章で詳しく説明されていますが、要するに、Airflow にはMAJOR.MINOR.PATCHバージョンがあります。
MAJORバージョンがインクリメントされますMINORバージョンが増加しますPATCHバージョンが増加します通常、Airflow のMINORバージョンは、マイナー バージョンにちなんで名付けられたブランチからリリースされます。たとえば、 2.7.*リリースはv2-7-stableブランチからリリースされ、 2.8.*リリースはv2-8-stableブランチからリリースされます。
リリース サイクルのほとんどの場合、次のMINORブランチのブランチがまだ作成されていないときは、 mainにマージされたすべての PR (元に戻されない限り) が次のMINORリリースへの道を見つけます。たとえば、最後のリリースが2.7.3で、 v2-8-stableブランチがまだ作成されていない場合、次のMINORリリースは2.8.0となり、main にマージされたすべての PR は2.8.0でリリースされます。ただし、一部の PR (バグ修正およびドキュメントのみの変更) は、マージされると、現在のMINORブランチに選択して次のPATCHLEVELリリースでリリースできます。たとえば、 2.8.1がすでにリリースされており、現在2.9.0devに取り組んでいる場合、PR に2.8.2マイルストーンをマークすると、PR がv2-8-testブランチに厳選され、 2.8.2rc1でリリースされることを意味します。そして最終的には2.8.2になります。
次のMINORリリースの準備をするとき、新しいv2-*-testおよびv2-*-stableブランチを切り取り、次のMINORバージョン用のalphaリリースとbetaリリースを準備します。メインにマージされた PR は引き続き次のMINORリリースでリリースされます。 rc版がカットされるまで。これは、次のbetaおよびrcリリースが準備されるときに、 v2-*-testおよびv2-*-stableブランチが main の上にリベースされるために発生します。たとえば、 2.10.0beta1バージョンをカットすると、 2.10.0rc1がリリースされる前に main にマージされたものはすべて 2.10.0rc1 に移動します。
次に、MINOR リリースの最初の RC 候補を準備したら、 v2-*-testおよびv2-*-stableブランチの移動を停止し、main にマージされた PR は次のMINORリリースでリリースされます。ただし、一部の PR (バグ修正およびドキュメントのみの変更) は、マージされると、現在のMINORブランチに選択して次のPATCHLEVELリリースでリリースできます。たとえば、 v2-10-stableブランチからの最後にリリースされたバージョンが2.10.0rc1場合です。 2.10.0rc1 、メインからの PR の一部はコミッターによって2.10.0マイルストーンとしてマークされる可能性があり、リリース マネージャーはそれらをリリース ブランチに厳選しようとします。成功すると、 2.10.0rc2でリリースされ、その後2.10.0でリリースされます。これは、後続のPATCHLEVELバージョンにも適用されます。たとえば、 2.10.1がすでにリリースされている場合、PR に2.10.2マイルストーンをマークすると、それがv2-10-stableブランチに厳選され、 2.10.2rc1でリリースされ、最終的に2.10.2でリリースされることを意味します。
チェリーピッキングに関する最終決定は、リリース マネージャーによって行われます。
マイルストーンで問題をマークするのは少し異なります。メンテナは通常、問題をマイルストーンでマークしません。通常、問題は PR でのみマークされます。問題にリンクされた PR (および「修正」) が上記のプロセスに従ってマージされ、特定のバージョンでリリースされた場合、問題は自動的にクローズされ、問題にマイルストーンは設定されません。そのため、PR を確認する必要があります。どのバージョンでリリースされたかを確認できるように問題を修正しました。
ただし、メンテナが特定のマイルストーンで問題をマークする場合があります。これは、その問題が、リリースの準備中に検討する候補となるために重要であることを意味します。これはオープンソース プロジェクトであり、基本的にすべての貢献者がボランティアで時間を費やしているため、特定の問題が特定のバージョンで修正されるという保証はありません。一部の問題が修正されていないためにリリースを保留することは望ましくありません。その場合、リリース マネージャーは、現在のリリースまでに修正が間に合わない場合に備えて、そのような未修正の問題を次のマイルストーンに再割り当てします。したがって、問題のマイルストーンは、バージョンで修正されることを約束するものではなく、検討する必要があるという意図に近いものです。
パッチレベル リリースに関する詳細なコンテキストとFAQ は、リポジトリのdevフォルダにある「次のリリースに含まれる内容」ドキュメントで参照できます。
はい！ Apache Foundation の商標ポリシーと Apache Airflow ブランドブックを必ず遵守してください。最新のロゴは、このリポジトリと Apache Software Foundation の Web サイトにあります。
Apache Airflow の CI インフラストラクチャは、以下によって後援されています。
