⚙️ Добавить логику повторных попыток retry в оркестрацию расчетов DAG

Для того, чтобы бороться с повторяющимися случайными ошибками.

В моем случае это проблемы с сетью (сетевым подключением). В рамках расчетов я делаю обращение из Clickhouse во внешнюю СУБД и порой во время чтения данных подключение прерывается:

05:08:57    :HTTPDriver for https://***:8443 returned response code 500)
05:08:57     Poco::Exception. Code: 1000, e.code() = 2013, mysqlxx::ConnectionLost: Lost connection to MySQL server during query (***:3306) (version 23.3.17.13 (official build))

* Можно тонко конфигурировать настройки, но не всегда это возможно на стороне СУБД-источника данных

В итоге расчет всех витрин прерывается в случайном месте, и в результате имеем в отчетности либо отстающие, либо несогласованные данные.

🔹 Как можно предусмотреть возможность повторных попыток?

— Реализовать собственноручно в коде исполнения (Exception handling, Retries, etc.)
— Настроить встроенные механизмы (Airflow task retries)
— Использовать специальные обертки (Github Actions)

В моем случае использую Github Actions как оркестратор запусков dbt

Step, который прежде выполнял единственную команду dbt build, теперь выглядит так:

  - uses: Wandalen/wretry.action@master
    with:
      command: dbt build
      attempt_limit: 3
      attempt_delay: 2000

В Github Actions я бы рекомендовал использовать retry action. Есть ряд альтернатив, но, например с Retry Step у меня возникли проблемы и я отказался от его использования.

#orchestration #dbt #github_actions

🌐 @data_apps | Навигация по каналу