Для того, чтобы бороться с повторяющимися случайными ошибками.
В моем случае это проблемы с сетью (сетевым подключением). В рамках расчетов я делаю обращение из 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 | Навигация по каналу