私はすでに this と this の質問をSOで見て、それに応じて変更を加えました。しかし、依存するDAGはまだ突っついた状態で立ち往生しています。 。以下は私のマスターDAGです。
from airflow import DAG
from airflow.operators.jdbc_operator import JdbcOperator
from datetime import datetime
from airflow.operators.bash_operator import BashOperator
today = datetime.today()
default_args = {
'depends_on_past': False,
'retries': 0,
'start_date': datetime(today.year, today.month, today.day),
'schedule_interval': '@once'
}
dag = DAG('call-procedure-and-bash', default_args=default_args)
call_procedure = JdbcOperator(
task_id='call_procedure',
jdbc_conn_id='airflow_db2',
sql='CALL AIRFLOW.TEST_INSERT (20)',
dag=dag
)
call_procedure
以下は私の依存DAGです:
from airflow import DAG
from airflow.operators.jdbc_operator import JdbcOperator
from datetime import datetime, timedelta
from airflow.sensors.external_task_sensor import ExternalTaskSensor
today = datetime.today()
default_args = {
'depends_on_past': False,
'retries': 0,
'start_date': datetime(today.year, today.month, today.day),
'schedule_interval': '@once'
}
dag = DAG('external-dag-upstream', default_args=default_args)
task_sensor = ExternalTaskSensor(
task_id='link_upstream',
external_dag_id='call-procedure-and-bash',
external_task_id='call_procedure',
execution_delta=timedelta(minutes=-2),
dag=dag
)
count_rows = JdbcOperator(
task_id='count_rows',
jdbc_conn_id='airflow_db2',
sql='SELECT COUNT(*) FROM AIRFLOW.TEST',
dag=dag
)
count_rows.set_upstream(task_sensor)
以下は、マスターDAGが実行された後の依存DAGのログです。
[2019-01-10 11:43:52,951] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
[2019-01-10 11:44:52,955] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
[2019-01-10 11:45:52,961] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
[2019-01-10 11:46:52,949] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
[2019-01-10 11:47:52,928] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
[2019-01-10 11:48:52,928] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
[2019-01-10 11:49:52,905] {{external_task_sensor.py:91}} INFO - Poking for call-procedure-and-bash.call_procedure on 2019-01-10T11:45:47.893735+00:00 ...
以下は、マスターDAG実行のログです。
[2019-01-10 11:45:20,215] {{jdbc_operator.py:56}} INFO - Executing: CALL AIRFLOW.TEST_INSERT (20)
[2019-01-10 11:45:21,477] {{logging_mixin.py:95}} INFO - [2019-01-10 11:45:21,476] {{dbapi_hook.py:166}} INFO - CALL AIRFLOW.TEST_INSERT (20)
[2019-01-10 11:45:24,139] {{logging_mixin.py:95}} INFO - [2019-01-10 11:45:24,137] {{jobs.py:2627}} INFO - Task exited with return code 0
私の仮定では、マスターが正常に実行された場合、Airflowは依存DAGをトリガーする必要がありますか? execution_delta
で遊んでみましたが、うまくいかないようです。
また、schedule_interval
とstart_date
は両方のDAGで同じであるため、問題が発生することはないと思います。
私は何かが足りませんか?
両方のDAGが同時に開始すること、およびどちらのDAGも手動で開始しないことを確認してください。
正のタイムデルタを使用する必要があるかもしれません: https://airflow.readthedocs.io/en/stable/_modules/airflow/sensors/external_task_sensor.html 実行デルタを差し引くと、それ自体の2分後に実行されたタスクを探すことになります。
ただし、デルタは実際には範囲ではありません。TIは、一致するDag ID、タスクID、成功した結果、および日時のリストに実行日を持っている必要があります。 _execution_delta
_をデルタとして指定すると、現在の実行日を取得してtimedeltaを引いた1つの日時のリストになります。
これはおそらく、2つの実行日が一致するようにタイムデルタを削除し、センサーが他のタスクが成功するまで待機するかのいずれかになります。OR開始日とスケジュール間隔は基本的に今日のように設定されますと_@once
_は、互いに予測可能なロックステップではない実行日を取得しています。たとえば、datetime(2019,1,10)
と_0 1 * * *
_を設定して、両方を毎日午前1時に実行するようにしてください(これも_execution_delta
_)。