Н
Size: a a a
2020 August 25
ИК
Зубы не бесконечные, аф безопаснее👍
PA
На R есть библиотека которая работает с Yandex
AT
Зубы не бесконечные, аф безопаснее👍
аирфлоу больше на мозг влияет, а не на зубы ))
С
Al T
аирфлоу больше на мозг влияет, а не на зубы ))
Я
Привет, а подскажите,пожалуйста, можно ли сделать так,чтобы таск перезапускался n раз при одной ошибке и ,например, фейлил весь Даг при другой?
С
Ярослав
Привет, а подскажите,пожалуйста, можно ли сделать так,чтобы таск перезапускался n раз при одной ошибке и ,например, фейлил весь Даг при другой?
Retries поставить принудительный
И навестить в питоне эксепшены на ошибки, фейлить можно через AirflowException
+принудительно поставить triggerrule alldone
И навестить в питоне эксепшены на ошибки, фейлить можно через AirflowException
+принудительно поставить triggerrule alldone
С
Либо по хардкору через sys.exit
С
SG
Сюткин
Либо по хардкору через sys.exit
Топовый вариант, +
SG
И назвать ошибку SuperCriticalSystemError
AK
привет всем!а в чем поинт externalsensor если можно просто сделать upstream с о второй таской проставив trigger rule==all_success ?
С
привет всем!а в чем поинт externalsensor если можно просто сделать upstream с о второй таской проставив trigger rule==all_success ?
Внешний сенсор обычно смотрит на другой процесс который не обязательно должен быть завязан с вашим
Например 1 даг грузит 30 таблиц каждую неделю
2 даг раз в месяц собирает витрину на основе одной из таблиц и сенсор нужен чтобы убедиться в том что в 1 даге таблица успешно выгрузилась
Например 1 даг грузит 30 таблиц каждую неделю
2 даг раз в месяц собирает витрину на основе одной из таблиц и сенсор нужен чтобы убедиться в том что в 1 даге таблица успешно выгрузилась
マサ
Подскажите, если у кого-то был опыт с pyspark в airflow.
Запускаем внутри python operator pyspark-джобы на спарк-кластере под мезосом, иногда бывает ситуация что коннект к зукиперу теряется или еще какая-нибудь турбулентность случается. В этом случае джобы просто виснут, не завершаясь (то есть на кластере уже джоба упала, а воркер инфы об этом не получает и просто висит в незавершенном состоянии).
Ожидаемое поведение — если на кластере джоба не завершилась за ожидаемое время по любым причинам, таска в эйрфлоу должна нормально падать
Мы пробовали сделать execution_timeout (не сработало) и перегрузить on_kill оператора стопом спарк-сессии (тоже не помогло). Какие есть варианты?
Запускаем внутри python operator pyspark-джобы на спарк-кластере под мезосом, иногда бывает ситуация что коннект к зукиперу теряется или еще какая-нибудь турбулентность случается. В этом случае джобы просто виснут, не завершаясь (то есть на кластере уже джоба упала, а воркер инфы об этом не получает и просто висит в незавершенном состоянии).
Ожидаемое поведение — если на кластере джоба не завершилась за ожидаемое время по любым причинам, таска в эйрфлоу должна нормально падать
Мы пробовали сделать execution_timeout (не сработало) и перегрузить on_kill оператора стопом спарк-сессии (тоже не помогло). Какие есть варианты?
E
Подскажите, если у кого-то был опыт с pyspark в airflow.
Запускаем внутри python operator pyspark-джобы на спарк-кластере под мезосом, иногда бывает ситуация что коннект к зукиперу теряется или еще какая-нибудь турбулентность случается. В этом случае джобы просто виснут, не завершаясь (то есть на кластере уже джоба упала, а воркер инфы об этом не получает и просто висит в незавершенном состоянии).
Ожидаемое поведение — если на кластере джоба не завершилась за ожидаемое время по любым причинам, таска в эйрфлоу должна нормально падать
Мы пробовали сделать execution_timeout (не сработало) и перегрузить on_kill оператора стопом спарк-сессии (тоже не помогло). Какие есть варианты?
Запускаем внутри python operator pyspark-джобы на спарк-кластере под мезосом, иногда бывает ситуация что коннект к зукиперу теряется или еще какая-нибудь турбулентность случается. В этом случае джобы просто виснут, не завершаясь (то есть на кластере уже джоба упала, а воркер инфы об этом не получает и просто висит в незавершенном состоянии).
Ожидаемое поведение — если на кластере джоба не завершилась за ожидаемое время по любым причинам, таска в эйрфлоу должна нормально падать
Мы пробовали сделать execution_timeout (не сработало) и перегрузить on_kill оператора стопом спарк-сессии (тоже не помогло). Какие есть варианты?
в on_kill делаю yarn application -kill "app_id" (сохраняю его при запуске)
для мезоса должно быть что-то похожее
для мезоса должно быть что-то похожее
2020 August 26