気流

airflowはタスクスケジューリングコンポーネントであり、主にDAG（有向非循環グラフ）に基づいてワークフロー全体を定義します。彼は主に、タスク依存、Webサービス、タスクの中断、およびcrontabスケジューリングでは完了できないその他の機能を解決します。また、気流はpython、spark、hive、k8sなどをサポートできます。

エアフローアーキテクチャ

エアフローには次のコンポーネントが含まれています。

メタデータベース（ストレージDAG）

アクチュエーターワーカー（タスクの実行を担当）

スケジューラーシェデュラー（タスクのトリガーを担当）

webServer（ウェブサービス）

気流タスクスケジューリングの原則

エアフローマルチプロセススケジューリングの原理は次のとおりです。

最初に、airflowはDagFileProcessorプロセスプールを作成して、dagフォルダー内のすべてのdagファイルをトラバースします。各プロセスはdagファイルを処理します。その結果、DAGRUNS（グラフの状態）とtaskInstance（タスクインスタンス）がデータベースに入れられます。この時点でtaskInstanceキューに追加済みとしてマークされています。

同時に、sedulerjobクラスオブジェクトは定期的にデータベースをチェックし、キューに登録済みとしてマークされたtaskInstanceをエグゼキューターキューに入れ、データベース内のタスクステータスをスケジュール済みとしてマークします

使用可能な各エグゼキューターは、エグゼキューターキューから実行するTaskInstanceを取得し、データベースのタスクステータスを実行中としてマークします

taskInstanceが実行されると、executorはデータベース内のタスクのステータスを（完了、失敗、スキップなど）としてマークし、グラフのタスク依存関係に従って各タスクを順番に処理します

プロセスがDAGの処理を完了すると、次のDAGに対して上記のプロセスを繰り返します。

すべてのDAGファイルが処理されると、エアフローは次のサイクルに入ります。DAGの処理時間が長すぎる場合、プロセスプールは次のサイクルでこのDAGを無視して、ブロックを回避します。

Airflowのセロリメカニズム：

CeleryExecutorは主に労働者の規模を拡大するために使用されます。この機能を使用するには、関連アクセサリ（RabbitMQ、REDISなど）を構成し、CeleryExecutorへのエアフローの関連構成を変更する必要があります。

1.ウェブサーバーがワーカーからタスク実行ログを取得します

2. WebサーバーはDagファイルからDag構造を取得します

3. WebサーバーはDBからタスクのステータスを取得します

4.ワーカーはDAG構造を取得し、DAGFilesからタスクを実行します

5.ワーカーは、DBから接続構成、変数、XCOM情報を取得して保存します

6.ワーカーがセロリ結果バックエンドにタスクのステータスを保存します

7.ワーカーは実行されたコマンドをセロリのキューブローカーに保存します

8.スケジューラはグラフの状態と関連タスクをDBに保存します

9.スケジューラはDAG構造を取得し、DAGFilesからタスクを実行します

10.スケジューラは、Celery Resultバックエンドから完了したタスクのステータス情報を取得します

11.スケジューラは、実行するコマンドをCeleryブローカーに配置します。

Airflow Dagの作成

AirflowのDAGは、タスク間の依存関係を定義するPythonスクリプトを介して作成されます。以下に作成したDAGを例にとります

最初に、エアフローパッケージにDAGとBashOperatorを導入する必要があります

次に、パラメーター辞書セットを作成します

args = { 
    'owner'： ' 
    Airflow '、'start_date'：airflow.utils.dates.days_ago（2）、
}

指定されていない場合、 'owner'はデフォルトで 'airflow'になります。

次にDAGオブジェクトを作成します

日= DAY（
    dag_id = 'example_bash_operator'、
    default_args = args、
    schedule_interval = '0 0 * * *'、
    dagrun_timeout =時間デルタ（分= 60）、
）

dag_idはdagを識別する唯一の属性です。default_argsはdagのデフォルトパラメータを設定します。'schedule_interval 'はdagの実行間隔を示します。dagrun_timeoutはdagのタイムアウト設定を示します。この時間後にdagが完了しない場合、dagで実行されていないタスクが示されます。失敗しました。

タスクを作成する

run_this_last = DummyOperator（
    task_id = 'run_this_last'、
    dag = dag、
）

タスクは、さまざまな操作に応じてDummyOperator（）、PythonOperator（）、BashOperator（）などに分割され、ユーザーはoperator（）もカスタマイズできます。task_idやdagなどのパラメーターでインスタンス化します。いくつかのタスクを次々に定義します

＃[START howto_operator_bash] 
run_this = BashOperator（
    task_id = 'run_after_loop'、
    bash_command = 'echo 1'、
    dag = dag、
）
＃[END howto_operator_bash]

run_this >> run_this_last

for i in range（3）：
    task = BashOperator（
        task_id = 'runme_' + str（i）、
        bash_command = 'echo "{{task_instance_key_str}}" && sleep 1'、
        dag = dag、
    ）
    task >> run_this 

＃[ START howto_operator_bash_template]

also_run_this = BashOperator（
    task_id = 'also_run_this'、
    bash_command = 'echo "run_id = {{run_id}} | dag_run = {{dag_run}}"'、
    dag = dag、
）
＃[END howto_operator_bash_template]

also_run_this >> run_this_last

タスク間の依存関係は、各タスク間の<<、>>によって定義されます。たとえば、also_run_this >> run_this_lastは、as_run_thisが実行された後にrun_this_lastを実行することを意味します。これは、run_this_last << also_run_thisと同等です。

同時に、set_upstreamおよびset_downstreamを介して依存関係を設定することもできます。たとえば、also_run_this.set_downstream（run_this_last）も、run_this_last.set_upstream（also_run_this）と同等です。

上記で作成したスクリプトをairflowのデフォルトのdagsフォルダーに配置すると、airflowがdagをスキャンして自動的に実行します。または、コマンドラインインターフェース（cli）またはwebUIを使用して手動でdagの実行をトリガーできます。

エアフローのwebUI

Airflowには、DAGグラフの表示、ツリーグラフの表示、ログの表示、ソースコードの表示、実行ステータスの表示、タスクの一時停止、その他の操作などのタスクをサポートする強力なWebページがあります。詳細を以下に示します。

K8S

K8sは、ポッドをスケジュールすることによりタスクの実行を最適化する、コンテナースケジューリング用のマイクロサービスアーキテクチャです。その配布アーキテクチャは、クラスター制御ポイントと複数の動作ノードであり、主にポッドとノード間のリソースマッチングの問題を解決します。その中で、マスターノードはクラスター全体の管理を担当し、クラスターの管理インターフェイスを提供します。

そして、クラスター内の各作業ノードを監視して配置します。各ワーカーノードはポッドの形式でコンテナーを実行し、コンテナーが依存するすべてのサービスとリソースを実行するには、各ノードに構成番号が必要です。

k8sスケジューリング

アフィニティ/反アフィニティの原則

頻繁な相互作用や共通リソースを必要とする一部のサービスでは、一部のポッドを同じノードまたは同じドメインにデプロイする必要がありますが、その他のサービスは、セキュリティと災害耐性のために異なるポイントまたはリージョンにデプロイする必要があります。上記のビジネス上の考慮事項は、affinityおよびanti_affinityのデプロイメントルールにつながります。

node_affinityは、ポッドを生成するときに、特定のラベルを持つノードにデプロイする必要があるポッドを示すことができます。たとえば、一部のポッドは、高速IO操作を必要とし、ssdのハードディスクにデプロイする必要があります。ノードラベルにdisk_type：ssd、その後、ポッドをノードにデプロイできます。それ以外の場合は、正常にデプロイできません。その後、改良バージョンでは、ハード要件とソフト要件の概念が導入されました。ハード要件は上記と同じです。ソフト要件は、条件が最適であれば、条件が満たされない場合に正常に作成できることを示します。

ポッドの親和性/ anti_affinityは、デプロイ前にノードまたはドメインに特定のラベルが付いたポッドがあるかどうかを確認することを意味します。ここでのスコープは、ポッドの定義されたトポロジドメインによって決定されます。

汚れと耐性

一部のノードにはテイントが定義されており、そのようなタグが付いたポッドのみをデプロイできることを示しています。それ以外の場合はデプロイできません

ポッドはノードに一致する許容値を定義できます。

wangyhwyh753

42件の元の記事を公開・賞賛4 ・ 10,000以上のビュー

プライベートの手紙の懸念

エアフロースケジューリングの原則とk8sスケジューリングの原則

気流

エアフローアーキテクチャ

気流タスクスケジューリングの原則

Airflowのセロリメカニズム：

Airflow Dagの作成

エアフローのwebUI

K8S

おすすめ