airflow - Apache Airflow - ワークフローをプログラムで作成、スケジュール、監視するためのプラットフォーム

(Apache Airflow - A platform to programmatically author, schedule, and monitor workflows)

Created at: 2015-04-14 02:04:58
Language: Python
License: Apache-2.0

アパッチエアフロー

PyPI バージョン GitHub ビルド カバレッジ ステータス ライセンス PyPI - Python バージョン Docker プル ドッカースターズ PyPI-ダウンロード アーティファクトハブ コードスタイル:黒 フォローする スラック ステータス

Apache Airflow (または単に Airflow) は、ワークフローをプログラムで作成、スケジュール、および監視するためのプラットフォームです。

ワークフローをコードとして定義すると、ワークフローの保守、バージョン管理、テスト、およびコラボレーションが容易になります。

Airflow を使用して、ワークフローをタスクの有向非巡回グラフ (DAG) として作成します。Airflow スケジューラは、指定された依存関係に従いながら、ワーカーの配列でタスクを実行します。豊富なコマンド ライン ユーティリティにより、DAG で複雑な手術を簡単に実行できます。豊富なユーザー インターフェイスにより、実稼働環境で実行されているパイプラインを簡単に視覚化し、進行状況を監視し、必要に応じて問題をトラブルシューティングできます。

目次

プロジェクトの焦点

Airflow は、ほとんどが静的でゆっくりと変化するワークフローで最適に機能します。DAG 構造が実行ごとに類似している場合、作業単位と継続性が明確になります。他の同様のプロジェクトには、ルイージウージーアズカバンなどがあります。

エアフローはデータの処理に一般的に使用されますが、タスクは理想的には冪等であるべきであり (つまり、タスクの結果は同じであり、宛先システムで重複データを作成しない)、大量のデータを渡すべきではないという意見があります。あるタスクから次のタスクへ (ただし、タスクは Airflow のXcom 機能を使用してメタデータを渡すことができます)。大量のデータ集約型タスクのベスト プラクティスは、そのタイプの作業に特化した外部サービスに委任することです。

Airflow はストリーミング ソリューションではありませんが、リアルタイム データを処理するためによく使用され、ストリームからデータをバッチで取得します。

原則

  • Dynamic : Airflow パイプラインはコード (Python) として構成され、動的なパイプラインの生成を可能にします。これにより、パイプラインを動的にインスタンス化するコードを記述できます。
  • 拡張可能: 独自のオペレーター、エグゼキューターを簡単に定義し、ライブラリーを拡張して、環境に適した抽象化のレベルに適合させます。
  • エレガント: エアフロー パイプラインは無駄がなく明示的です。スクリプトのパラメータ化は、強力なJinjaテンプレート エンジンを使用して Airflow のコアに組み込まれています。
  • スケーラブル: Airflow はモジュラー アーキテクチャを備えており、メッセージ キューを使用して任意の数のワーカーを調整します。

要件

Apache Airflow は以下でテストされています。

メインバージョン (開発) 安定版 (2.3.4)
パイソン 3.7、3.8、3.9、3.10 3.7、3.8、3.9、3.10
プラットホーム AMD64/ARM64(*) AMD64/ARM64(*)
Kubernetes 1.21、1.22、1.23、1.24、1.25 1.20、1.21、1.22、1.23、1.24
PostgreSQL 10、11、12、13、14 10、11、12、13、14
MySQL 5.7、8 5.7、8
SQLite 3.15.0+ 3.15.0+
MSSQL 2017年(※)、2019年(※) 2017年(※)、2019年(※)

*実験的

注: MySQL 5.x バージョンでは、複数のスケジューラを実行できないか、実行に制限があります。スケジューラのドキュメントを参照してください。MariaDB はテストされておらず、推奨されていません。

: SQLite は Airflow テストで使用されます。本番環境では使用しないでください。ローカルでの開発には、最新の安定したバージョンの SQLite を使用することをお勧めします。

: 現在、Airflow は POSIX 準拠のオペレーティング システムで実行できます。開発のために、かなり最新の Linux ディストリビューションと最近のバージョンの MacOS で定期的にテストされています。Windows では、WSL2 (Windows Subsystem for Linux 2) または Linux コンテナー経由で実行できます。Windows サポートを追加する作業は#10388で追跡されていますが、優先度は高くありません。Linux ベースのディストリビューションは、サポートされている唯一の環境であるため、「運用」実行環境としてのみ使用する必要があります。CI テストで使用され、コミュニティ管理の DockerHub イメージで使用される唯一のディストリビューションは

Debian Bullseye
.

入門

Airflow のインストール開始方法、またはより完全なチュートリアルの説明については、公式の Airflow Web サイト ドキュメント (最新の安定版リリース) に アクセスしてください。

注: メイン ブランチ (最新の開発ブランチ) のドキュメントをお探しの場合: s.apache.org/airflow-docsで見つけることができます。

Airflow Improvement Proposals (AIP) の詳細については、Airflow Wikiを参照してください。

プロバイダー パッケージ、Docker イメージ、Helm チャートなどの依存プロジェクトのドキュメントは、ドキュメント インデックスにあります。

PyPI からのインストール

PyPI でApache Airflow を

apache-airflow
パッケージとして公開しています。ただし、Airflow はライブラリとアプリケーションの両方を兼ねているため、インストールが難しい場合があります。通常、ライブラリはその依存関係を開いたままにし、アプリケーションは通常それらを固定しますが、どちらも同時に行うべきではありません。
setup.py
ユーザーが必要に応じて異なるバージョンのライブラリをインストールできるように、依存関係を可能な限りオープンにしておくことにしました ( )。これは、
pip install apache-airflow
時々機能しないか、使用できない Airflow インストールが生成されることを意味します。

constraints-main
ただし、繰り返しインストールできるようにするために、孤立したブランチとブランチに一連の「動作することがわかっている」制約ファイルを保持しています
constraints-2-0
。これらの「動作することがわかっている」制約ファイルは、Python のメジャー/マイナー バージョンごとに個別に保持されます。PyPI から Airflow をインストールするときに、これらを制約ファイルとして使用できます。URL で正しい Airflow タグ/バージョン/ブランチと Python バージョンを指定する必要があることに注意してください。

  1. Airflow のみのインストール:

注:

pip
現在、インストールのみが正式にサポートされています。

Poetrypip-toolsなどのツールを使用して Airflow をインストールすることは可能ですが、

pip
特に制約と要件の管理に関しては、同じワークフローを共有しません 。
Poetry
またはを介し​​たインストール
pip-tools
は現在サポートされていません。

これらのツールを使用して Airflow をインストールする場合は、制約ファイルを使用して、ツールに必要な適切な形式とワークフローに変換する必要があります。

pip install 'apache-airflow==2.3.4' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.3.4/constraints-3.7.txt"
  1. エクストラを使用したインストール (つまり、postgres、google)
pip install 'apache-airflow[postgres,google]==2.3.4' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.3.4/constraints-3.7.txt"

プロバイダー パッケージのインストールについては、 providers を確認して ください

公式ソースコード

Apache Airflow はApache Software Foundation (ASF) プロジェクトであり、公式のソースコード リリースは次のとおりです。

ASF の規則に従って、リリースされたソース パッケージは、ユーザーが適切なプラットフォームとツールにアクセスできれば、リリースをビルドしてテストするのに十分なものでなければなりません。

コンビニエンスパッケージ

Airflow をインストールして使用する方法は他にもあります。これらは「便利な」方法です。 が述べているように「公式リリース」

ASF Release Policy
ではありませんが、ソフトウェアを自分でビルドしたくないユーザーが使用できます。

それらは - 人々が Airflow をインストールする最も一般的な方法の順序で:

  • 標準
    pip
    ツールを使用して Airflow をインストールするための PyPI リリース
  • ツールを介してエアフローをインストール し、Kubernetes
    docker
    、Helm チャートなどで使用するため
    docker-compose
    Dockerイメージ.
    docker swarm
  • git 経由で公式ソース パッケージを生成するために使用された git プロジェクト ソースを取得するためのGitHub のタグ

これらの成果物はすべて公式リリースではありませんが、公式にリリースされたソースを使用して作成されています。これらのアーティファクトの一部は「開発」または「プレリリース」のものであり、ASF ポリシーに従って明確にマークされています。

ユーザーインターフェース

  • DAG : 環境内のすべての DAG の概要。

    DAG

  • Grid : 時間をまたがる DAG のグリッド表現。

    グリッド

  • グラフ: DAG の依存関係と特定の実行の現在の状態の視覚化。

    グラフ

  • タスクの所要時間: さまざまなタスクに費やされた時間の合計。

    タスク期間

  • ガント: DAG の期間とオーバーラップ。

    ガント

  • Code : DAG のソース コードを表示する簡単な方法。

    コード

セマンティック バージョニング

Airflow 2.0.0 以降、リリースされたすべてのパッケージに対して厳密なSemVerアプローチをサポートしています。

さまざまなパッケージのバージョン管理の詳細を定義することに同意したいくつかの特定の規則があります。

  • Airflow : SemVer ルールはコア Airflow のみに適用されます (プロバイダーへの変更は除外されます)。Airflow 依存関係のバージョンの制限を変更すること自体は、互換性を破る変更ではありません。
  • Airflowプロバイダー: SemVer ルールは、特定のプロバイダーのコードの変更にのみ適用されます。パッケージの SemVer MAJOR および MINOR バージョンは、Airflow バージョンとは無関係です。たとえば、
    google 4.1.0
    プロバイダ
    amazon 3.0.3
    は で問題なくインストールできます
    Airflow 2.1.2
    。プロバイダーと Airflow パッケージ間の相互依存関係に制限がある場合、それらはプロバイダーに次のように存在します。
    install_requires
    制限。以前にリリースされたすべての Airflow 2 バージョンとのプロバイダーの下位互換性を維持することを目指していますが、一部またはすべてのプロバイダーに最小の Airflow バージョンが指定される可能性のある重大な変更が行われることがあります。新しいプロバイダーをインストールすると Airflow が自動的にアップグレードされる可能性があるため、サポートされている Airflow の最小バージョンの変更は、プロバイダーにとって重大な変更です (これは、プロバイダーのアップグレードの望ましくない副作用である可能性があります)。
  • Airflow Helm チャート: SemVer ルールは、チャートの変更にのみ適用されます。チャートの SemVer MAJOR および MINOR バージョンは、Airflow バージョンから独立しています。リリースされたすべての Airflow 2 バージョンとの Helm Chart の下位互換性を維持することを目指していますが、一部の新機能は特定の Airflow リリース以降でのみ機能する可能性があります。ただし、最小限の Airflow バージョンに依存するように Helm チャートを制限する場合があります。
  • Airflow API クライアント: SemVer MAJOR および MINOR バージョンは、Airflow の MAJOR および MINOR バージョンに従います。Airflow の最初のメジャーまたはマイナー XY0 リリースの後には、常にすべてのクライアントの XY0 リリースが続く必要があります。その後、クライアントは、Airflow PATCH リリースとは別に、バグ修正を含む独自の PATCH リリースをリリースできます。

バージョンのライフ サイクル

Apache Airflow バージョンのライフ サイクル:

バージョン 現在のパッチ/マイナー 最初のリリース 限定サポート EOL/終了
2 2.3.4 対応 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年01月03日 2018年8月27日 2018年8月27日
1.8 1.8.2 EOL 2017年3月19日 2018年01月03日 2018年01月03日
1.7 1.7.1.2 EOL 2016 年 3 月 28 日 2017年3月19日 2017年3月19日

限定サポート バージョンは、セキュリティと重大なバグ修正のみでサポートされます。EOL バージョンには修正もサポートもありません。すべてのユーザーが、使用中のメジャー バージョンに関係なく、利用可能な最新のマイナー リリースを実行することを常にお勧めします。最新の Airflow メジャー リリースにアップグレードすることを、EOL 日前にできるだけ早い時期に行うことを強くお勧めします。

Python および Kubernetes バージョンのサポート

Airflow 2.0 の時点で、Python と Kubernetes のサポートのために従う特定のルールに同意しました。これらは、Python と Kubernetes の公式リリース スケジュールに基づいており、 Python 開発者ガイドKubernetes バージョン スキュー ポリシーにうまくまとめられています。

  1. We drop support for Python and Kubernetes versions when they reach EOL. Except for Kubernetes, a version stays supported by Airflow if two major cloud providers still provide support for it. We drop support for those EOL versions in main right after EOL date, and it is effectively removed when we release the first new MINOR (Or MAJOR if there is no new MINOR version) of Airflow. For example, for Python 3.7 it means that we will drop support in main right after 27.06.2023, and the first MAJOR or MINOR version of Airflow released after will not have it.

  2. The "oldest" supported version of Python/Kubernetes is the default one until we decide to switch to later version. "Default" is only meaningful in terms of "smoke tests" in CI PRs, which are run using this default version and the default reference image available. Currently

    apache/airflow:latest
    and
    apache/airflow:2.3.4
    images are Python 3.7 images. This means that default reference image will become the default at the time when we start preparing for dropping 3.7 support which is few months before the end of life for Python 3.7.

  3. We support a new version of Python/Kubernetes in main after they are officially released, as soon as we make them work in our CI pipeline (which might not be immediate due to dependencies catching up with new versions of Python mostly) we release new images/support in Airflow based on the working CI setup.

Base OS support for reference Airflow images

The Airflow Community provides conveniently packaged container images that are published whenever we publish an Apache Airflow release. Those images contain:

  • Base OS with necessary packages to install Airflow (stable Debian OS)
  • Base Python installation in versions supported at the time of release for the MINOR version of Airflow released (so there could be different versions for 2.3 and 2.2 line for example)
  • Libraries required to connect to suppoerted Databases (again the set of databases supported depends on the MINOR version of Airflow.
  • Predefined set of popular providers (for details see the Dockerfile).
  • Possibility of building your own, custom image where the user can choose their own set of providers and libraries (see Building the image)
  • In the future Airflow might also support a "slim" version without providers nor database clients installed

The version of the base OS image is the stable version of Debian. Airflow supports using all currently active stable versions - as soon as all Airflow dependencies support building, and we set up the CI pipeline for building and testing the OS version. Approximately 6 months before the end-of-life of a previous stable version of the OS, Airflow switches the images released to use the latest supported version of the OS. For example since

Debian Buster
end-of-life was August 2022, Airflow switched the images in
main
branch to use
Debian Bullseye
in February/March 2022. The version was used in the next MINOR release after the switch happened. In case of the Bullseye switch - 2.3.0 version used
Debian Bullseye
. The images released in the previous MINOR version continue to use the version that all other releases for the MINOR version used.

Support for

Debian Buster
image was dropped in August 2022 completely and everyone is expected to stop building their images using
Debian Buster
.

Users will continue to be able to build their images using stable Debian releases until the end of life and building and verifying of the images happens in our CI but no unit tests were executed using this image in the

main
branch.

Approach to dependencies of Airflow

Airflow has a lot of dependencies - direct and transitive, also Airflow is both - library and application, therefore our policies to dependencies has to include both - stability of installation of application, but also ability to install newer version of dependencies for those users who develop DAGs. We developed the approach where

constraints
are used to make sure airflow can be installed in a repeatable way, while we do not limit our users to upgrade most of the dependencies. As a result we decided not to upper-bound version of Airflow dependencies by default, unless we have good reasons to believe upper-bounding them is needed because of importance of the dependency as well as risk it involves to upgrade specific dependency. We also upper-bound the dependencies that we know cause problems.

私たちの制約メカニズムは、すべての非上限依存関係を自動的に見つけてアップグレードすることに注意を払います (すべてのテストに合格する場合)。

main
ビルドの失敗は、テストを中断する依存関係のバージョンがある場合に示されます。これは、それらを上位バインドするか、それらの依存関係からの上流の変更を考慮してコード/テストを修正する必要があることを示します。

そのような依存関係を上限に制限するときはいつでも、なぜそれを行うのかについて常にコメントする必要があります。また、バインディングを削除する条件についても言及する必要があります。

Airflow Core の依存関係へのアプローチ

それら

extras
providers
依存関係は で維持され
setup.cfg
ます。

予測可能なバージョン管理スキームに従うことが知られているため、デフォルトで上限を設定するのに十分重要であると判断した依存関係はほとんどありません。また、それらの新しいバージョンが重大な変更をもたらす可能性が非常に高いことがわかっています。依存関係がリリースされたら、定期的に確認し、新しいバージョンへのアップグレードを試みることをお約束しますが、これは手動のプロセスです。

重要な依存関係は次のとおりです。

  • SQLAlchemy
    : 特定の MINOR バージョンへの上限 (SQLAlchemy は非推奨を削除し、破壊的変更を導入することが知られています。特に、さまざまなデータベースのサポートが異なり、さまざまな速度で変更されます (例: SQLAlchemy 1.4 は Airflow の MSSQL 統合を壊しました)。
  • Alembic
    : 予測可能でパフォーマンスの高い方法で移行を処理することが重要です。SQLAlchemy と一緒に開発されています。Alembic での私たちの経験では、マイナー バージョンで非常に安定しています。
  • Flask
    : ウェブ 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 プロバイダーとエクストラの依存関係へのアプローチ

それら

extras
providers
依存関係は で維持され
setup.py
ます。

デフォルトでは、プロバイダーの依存関係の上限を設定するべきではありませんが、各プロバイダーのメンテナーは、追加の制限を追加することを決定する可能性があります (コメントでそれらを正当化します)。

プロバイダーのリリース プロセス

コミュニティによってリリースされたプロバイダー (ほぼ毎月の頻度で) には、サポートされている Airflow の最小バージョンの制限があります。Airflow の最小バージョンは

MINOR
、プロバイダーがこのリリースに登場した機能を使用する可能性があることを示すバージョン (2.2、2.3 など) です。Airflow の最小バージョンのデフォルトのサポート期間 (正当な例外がある場合があります) は、Airflow のマイナー バージョンの最初のリリースから 12 か月が経過したときに、最小 Airflow バージョンを引き上げることです。

たとえば、これはデフォルトで、2022 年 10 月 11 日以降の最初のプロバイダーのリリースで、プロバイダーがサポートする Airflow の最小バージョンを 2.3.0 にアップグレードすることを意味します (2021 年 10 月 11 日は、

PATCHLEVEL
2.2 (2.2.0)の最初のリリース日です)。リリースされました。

多くの場合、プロバイダーは、統合における下位互換性を維持することに非常に関心のある一部の利害関係者 (クラウド プロバイダーや特定のサービス プロバイダーなど) とつながっています。 しかし、誰がリリースし、どのように ASF ソフトウェアをリリースするかを説明するApache Software Foundation のリリース ポリシーにも拘束されます。プロバイダーのガバナンス モデルは、私たちが「混合ガバナンス」と名付けたものです。ここでは、リリース ポリシーに従いますが、チェリー ピックの実行と古いブランチへの PR を行うことを約束する人には、チェリー ピック バージョンの保守とテストの負担がかかります。

「混合ガバナンス」 (オプション、プロバイダーごと) とは、次のことを意味します。

  • Airflow コミュニティとリリース マネージャーは、これらのプロバイダーをいつリリースするかを決定します。これはコミュニティによって完全に管理されており、 Apache Software Foundation のリリース ポリシーに従って、通常のリリース管理プロセスが行われています。
  • コントリビューター (プロバイダーの直接の利害関係者である場合もそうでない場合もある) は、古いバージョンのプロバイダーを厳選してテストするという負担を負います。
  • どのバージョンのプロバイダーがリリースされるかを決定するための「選択」および承認プロセスはありません。それは、チェリーピックされた変更で PR を上げるコントリビューターのアクションによって決定され、メンテナーがそのような PR を承認 (またはしない) し、マージする (またはしない) 通常の PR レビュープロセスに従います。簡単に言えば、古いバージョンのプロバイダーをチェリー ピッキングしてテストするというアクションが完了すると、リリースの資格が得られます。自発的にチェリーピッキングとテストを実行する人がいない限り、プロバイダーは解放されません。
  • 貢献者がチェリー ピッキングの実行をコミットすると、PR を発生させるブランチが作成されます (たとえば、チェリー ピックへの PR のコメントとして)。

Usually, community effort is focused on the most recent version of each provider. The community approach is that we should rather aggressively remove deprecations in "major" versions of the providers - whenever there is an opportunity to increase major version of a provider, we attempt to remove all deprecations. However, sometimes there is a contributor (who might or might not represent stakeholder), willing to make their effort on cherry-picking and testing the non-breaking changes to a selected, previous major branch of the provider. This results in releasing at most two versions of a provider at a time:

  • potentially breaking "latest" major version
  • selected past major version with non-breaking changes applied by the contributor

このような変更のチェリー ピックは、以前のマイナー Airflow バージョンの Airflow パッチレベル リリースをリリースするのと同じプロセスに従います。通常、このようなチェリー ピッキングは、重要なバグ修正があり、最新バージョンにバグ修正とは関係のない重大な変更が含まれている場合に行われます。プロバイダーの最新バージョンでそれらを一緒にリリースすると、効果的に結合されるため、別々にリリースされます。厳選された変更は、コミッターがコミュニティの通常のルールに従ってマージする必要があります。

古いバージョンのプロバイダーを厳選してリリースする義務はありません。コミュニティは、コントリビューターがチェリー ピックを実行し、古いプロバイダー バージョンの実行テストを実行する努力がある限り、そのような古いバージョンのプロバイダーをリリースし続けます。

「サービス指向」のメンテナンスを管理でき、そのような責任に同意する利害関係者が利用できることは、将来の新しいプロバイダーを受け入れてコミュニティ管理になるという私たちの意欲にもつながります。

貢献する

Apache Airflow の構築を手伝いたいですか? 私たちの貢献ドキュメントをチェックしてください。

Apache Airflow の公式 Docker (コンテナ) イメージはIMAGES.rstに記述されています。

Apache Airflow を使用しているのは誰ですか?

400 を超える組織が実際に Apache Airflow を使用 しています。

Apache Airflow を維持しているのは誰ですか?

Airflow はコミュニティの仕事ですが、コア コミッター/メンテナー は、PR のレビューとマージ、および新しい機能のリクエストに関する会話の誘導を担当します。メンテナーになりたい場合は、Apache Airflow コミッターの要件を確認してください。

プレゼンテーションで Apache Airflow のロゴを使用できますか?

はい!Apache Foundation の商標ポリシーと Apache Airflow Brandbookを必ず遵守してください。最新のロゴは、このリポジトリと Apache Software Foundation のWeb サイトにあります。

気流商材

Apache Airflow のステッカーや T シャツなどが欲しい場合は、 Redbubble Shopをチェックしてください。

リンク

スポンサー

Apache Airflow の CI インフラストラクチャは、次のスポンサーによって提供されています。

天文学者.io AWS オープンソース