恥ずかしながら最近になって知ったワークフローエンジン Apache Airflow。日本語の紹介記事もちらほら出てきていますが、公式ドキュメントをちょっとずつ抄訳しながら読んでいこうと思います。
今回はまずはじめに（Home / Apache Airflow Documentation）。
バージョン2.3.3時点のものです。
はじめに
Airflowはプログラムによりワークフローを設計し、スケジュールし、監視するためのプラットフォームです。
複数タスクからなる有向非巡回グラフ（DAG）としてワークフローを作成することができます。
一連のワーカー上でタスクを実行します。
リッチなコマンドラインユーティリティによりDAGに対する複雑なオペをいともたやすく実現できます。
リッチなUIのおかげで本番環境で実行されているパイプラインの可視化、進捗の監視、そして必要なら問題発生時のトラブルシューティングも容易です。
コードにより定義されたワークフローは、メンテナンス性に優れ、バージョン管理が容易く、協力しやすいものとなります。
基本原則
- 動的：ワークフローはPythonコードにより構成されます。動的なワークフローの生成が可能です。
- 拡張性：あなた自身でオペレーターやエグゼキューターを定義し、あなたの置かれた状況に則した抽象レベルでライブラリを拡張することができます。
- 洗練：ワークフローには余分なものがなくすっきりしています。スクリプトのパラメータ化はJinjaテンプレート・エンジンを用いてAirflowのコアに組み込まれています。
- スケーラビリティ：モジュラー・アーキテクチャを持ち、多数のワーカーを協調させるためにメッセージキューを使用します。無限のスケーラビリティを実現します。
地平線の向こう側へ
Airflowはデータ・ストリーミング・ソリューションではありません。タスクはデータをある場所から別のある場所へと移動させるものではありません。AirflowはSpark StreamingやStormではなく、OozieやAzkabanと比較すべきものです。
ワークフローはほとんど不変であるか、ゆっくりと変化していくものであるべきです。データベースの構造よりは若干動的というくらいに考えましょう。ワークフローの見た目が実行の都度大きく変わるようなことのないようにすべきです。そうすることで個々の処理とその流れが明快な状態を保つことができます。
基本原則に示された、コードによるワークフロー（workflow as code）、拡張性、スケーラビリティ、WebUIはいずれも魅力的です。
「地平線～」の後段はワークフロー設計のベストプラクティスにかかわるものかと思いますが、いまいち言わんとしていることが不明確であるように感じます。