Apache Airflow Tutorials
hirataku322/airflow
ローカル環境構築
- pipとpip3の混同に気をつける
- 本当はDocker使って立てたい
- ドキュメントにはなかったがpipでvirtualenvをinstallしろと怒られた
- 時間をくった。ログを読んでいれば直ぐに解決できた
OperatorのインスタンスがTask
from airflow.operators.bash import BashOperator
t1 = BashOperator(
task_id="print_date",
bash_command="date",
)
dag.pyから外部ファイルを参照できる。
dag/
からの相対パスで指定する。
template_searchpath
で相対パスの起点を設定できる
dag (directed acyclic graph):有向非巡回グラフ
dag.pyはDAGの構成ファイルに過ぎない。
実際のデータ処理はネットワーク上の複数のノードで実行される。
It’s a DAG definition file
One thing to wrap your head around (it may not be very intuitive for everyone at first) is that this Airflow Python script is really just a configuration file specifying the DAG’s structure as code. The actual tasks defined here will run in a different context from the context of this script. Different tasks run on different workers at different points in time, which means that this script cannot be used to cross communicate between tasks. Note that for this purpose we have a more advanced feature called XComs.
People sometimes think of the DAG definition file as a place where they can do some actual data processing - that is not the case at all! The script’s purpose is to define a DAG object. It needs to evaluate quickly (seconds, not minutes) since the scheduler will execute it periodically to reflect the changes if any.
1.0系ではタスク間の依存関係や、複数のノード間での受け渡しを記述する必要があった。2.0系から@dag, @taskなどのデコレータが導入され、これらを意識する必要がなくなった。
「Using the TaskFlow API with complex/conflicting Python dependencies」以降は一旦飛ばす。
依存関係が複雑な環境で動かす場合、もしくは、1.0系と2.0系のコードを共存させる場合は見たほうが良い。
Building a Running Pipeline — Airflow Documentation
Dockerで動かしたPostgresに、ネット上のcsvをDBに入れて、Transformする処理を書いた。
こんなに簡単に書けるものなのかと少し感動した。
Object Storage — Airflow Documentation
さっと流し見。必要になったらもう一度読めば良い。
Tutorial完了
忘れないうちに手を動かしてなにか作る