web-dev-qa-db-ja.com

エアフロー外部センサーが突っついたときに動かなくなる

別のダグの完了後に1つのダグを開始したい。 1つの解決策は、外部センサー機能を使用することです。以下に私の解決策を示します。私が遭遇する問題は、依存するダグが突っついていることです。これをチェックしました answer そして両方のダグが同じスケジュールで実行されることを確認しました。私の簡略化されたコードは次のとおりです。感謝。リーダーダグ：

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime, timedelta


default_args = {
   'owner': 'airflow',
   'depends_on_past': False,
   'start_date': datetime(2015, 6, 1),
   'retries': 1,
   'retry_delay': timedelta(minutes=5),



 }

 schedule = '* * * * *'

 dag = DAG('leader_dag', default_args=default_args,catchup=False, 
 schedule_interval=schedule)

t1 = BashOperator(
   task_id='print_date',
   bash_command='date',
   dag=dag)

依存するdag：

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime, timedelta
from airflow.operators.sensors import ExternalTaskSensor


default_args = {
    'owner': 'airflow',
    'depends_on_past': False,
    'start_date': datetime(2018, 10, 8),
    'retries': 1,
    'retry_delay': timedelta(minutes=5),


}
schedule='* * * * *'
dag = DAG('dependent_dag', default_args=default_args, catchup=False, 
schedule_interval=schedule)

 wait_for_task = ExternalTaskSensor(task_id = 'wait_for_task', 
 external_dag_id = 'leader_dag', external_task_id='t1', dag=dag)

 t1 = BashOperator(
     task_id='print_date',
     bash_command='date',
      dag=dag)

 t1.set_upstream(wait_for_task)

leader_dagのログ： enter image description here

依存するdagのログ：

enter image description here

airflowairflow-scheduler
8
sia

まず、task_idのleader_dagの名前はprint_dateですが、dependent_dagのタスクwait_for_taskを待機しているタスクleader_dagを使用してt1を設定します。 t1という名前のタスクはありません。 pyファイルで割り当てたものは関係ありません。また、Airflowデータベースで使用されたり、センサーによって横方向に使用されたりすることもありません。タスク名print_dateを待機している必要があります。

次に、ログは、dependent_dagが何を待っているかを示すleader_dagの実行で整列しません。

最後に、Airflowを使用して1分ごとにタスクをスケジュールすることはお勧めできません。確かに、2つの依存タスクが一緒になっているわけではありません。 Sparkのような別のシステムでストリーミングジョブを作成するか、このために独自のCeleryまたはDask環境をローリングすることを検討してください。

また、leader_dagの末尾にExternalTaskSensorを追加してdependent_dagをトリガーし、schedule_intervalをTriggerDagRunOperatorに設定してスケジュールを削除することで、Noneを回避することもできます。

私があなたのログに見るのは、2018-10-13T19：08：11のリーダーのログです。これはせいぜいexecution_date2018-10-13 19:07:00のdagrunになります。これは、19：07から始まる分の期間がスケジュール可能な最も早い19:08に終了するためです。そして、スケジューリングと実行の間に約11秒の遅延が見られますこの場合。ただし、Airflowではスケジュールに数分の遅れが生じる可能性があります。

また、19：14：04から19:14:34まで実行され、対応する19：13：00dagrunの完了を探しているdependent_dagからのログも表示されます。スケジューラーが19:14:34までにleader_dagの19：13：00dagrunを開始するのに十分なラグフリーであるという兆候はありません。 5分ほど突っついているのを見せたらもっと納得できたでしょう。もちろん、それは決して意味をなさないleader_dag.t1です。これは、表示されているタスクに名前を付けたものではないためです。

そのため、Airflowにはスケジューリングの遅延があります。システムに1000のダグが数個ある場合は、1分より長くなる可能性があります。そのため、catchup=Falseを使用すると、次々と実行されますIE 19 ：08、19：09、および19:10の後に19:16のように1分（または6）をスキップするいくつかの実行が発生する可能性があり、遅延はダグごとに少しランダムであるため、整列されない可能性があります待機する正しいタスクIDがある場合でも、センサーが待機している状態で実行されます。

 wait_for_task = ExternalTaskSensor(
     task_id='wait_for_task', 
     external_dag_id='leader_dag',
-    external_task_id='t1',
+    external_task_id='print_date',
     dag=dag)
6
dlamblin

ExternalTaskSensorを使用している間は、両方のDAGに同じ開始日を指定する必要があります。それがユースケースで機能しない場合は、ExternalTaskSensorでexecution_deltaまたはexecution_date_fnを使用する必要があります。

1
hbk