Видимо, последний вопрос. Можно ли сделать ожидание на некий внешний источник за пределами Airflow? Например, «появились файлы в HDFS» или «внешний API ответил, что он готов». В теории, можно сделать через retry и долго пытаться, пока не получится. Но ещё лучше совсем в очередь задачу не ставить, пока данные не готовы. Можно ли так сделать?
Для таких задач есть отличный набор операторов — sensor-ы. Они как раз про, что бы что-нибудь подождать. Есть и минус, минус в том что сенсоры это такие же задачи airflow, требующие постановки в очередь и свободного слота и воркера. Мы держим сенсоры в отдельном пуле, тем самым контролируем их кол-во и приоритезируем их.
Спасибо за информацию по подходу к организации среды для разработки.
Как дела обстоят с логикой повторных попыток в случае ошибки (retry)?
Кол-во и интервал ритраев можно настроить на уровне дага, можно переопределить на уровне задачек. Есть параметр оповещать на ритрай, есть на финальный феилд. Достаточно просто и удобно.
Как работает перезагрузка блока старых данных? Например, хотим перезагрузить все логи транзакций за 2016 год и всё, что от них зависит за то же самое время. Удобно ли это сделать?
Если даг построен корректно, т.е. с применением макросов airflow и за определенный день (дату) даг работает с определенными данными, то достаточно просто найти в запусках дага требуемый день и с него почистить статусы задачек в этом дне и в последующих днях (делается это легко). Планировщик обработает эти задачки ещё раз. Так же есть процедура backfill (https://airflow.apache.org/cli.html), можно с помощь неё перезапустить определенный период в даге.
Как организован devel environment? Можно ли целиком протестировать ETL на своей ветке, используя sample от production данных и не мешая при этом другим разработчикам?
Эта часть у нас пока плохо организована. Здесь ещё предстоит много работы. Нашему DWH всего год. Куда двигаться в целом понятно: у каждого разраба свои репы, система пул реквестов, скрипт копирования прод таблиц/данных в песочницу для разработчиков (в рамках одного hadoop кластера).
Хороший вопрос. Переходы между задачками, их запуск — это не сильная сторона Airflow. Есть много накладных расходов, таких как постановка задачек в очередь, их приоритезиция при запуске, в случае наличия свободного слота в пуле и свободного воркера сельдерея. Планирощик работает постоянно и постоянно пытается толкать задачи, делает он с настраиваемым интервалом (scheduler_heartbeat_sec). У нас при не загруженном сервере, т.е. при наличие свободных слотов в пуле и свободных воркеров сельдерея последующие задачки запускаются в интервале 5-10 секунд.
Хороший вопрос. Начали в сентябре прошлого года (2016). У нас было пустое хранилище и ноль дагов на среде. Было некое наследие. Наследие мигрировало (с необходимыми переработками) на новую инфраструктуру, это где-то 1/4 текущих процессов, остальное было разработано считай в течение года.
1. Если у тебя информатика и ты плотно на ней сидишь, то не думаю что тебе что-то даст Airflow. Разве что если только поможет открыть глаза на что более светлое ;) Про стоимость конечно глупо говорить. Про скорость разработки и добавления на среду новых процессов, вот про про что нужно говорить. Про кодогенерацию, про сравнительную простоту масштабирования. Про возможность делать кастом операторы стоит говорить.
2. У нас в хранилище для батч уровня да, только Airflow. Есть такая стратегия, сейчас всё хранилище строится на опенсорс.
3. Кейсы ты имеешь ввиду что? Падений? Или требования которые было непонятно как решить на текущей сборке Airflow? Падения были, разрешали сами, + стековерфло, +гитхаб. Требования которае не могли бы решить, тут как мне кажется если задача адекватная, и источник в меру адекватный и алгоритм в меру адекватный, то для airflow проблем не будет, т.к. есть PythonOperator на котором в целом можно решить достаточно заковыристые задачи по получению данных. Ты можешь мне подкинуть задачу, я могу тебе на шагах расписать как это будет реализовано на Airflow.
Как делать масштабирование пока вопрос открытый. Оставлять CeleryExecutor или сделать шаг в сторону MesosExecutor — хз (хотел бы знать) как правильно. С Mesos экспертизы нет, а с Celery и Airflow работает у нас работает, и на Celery ещё пытаемся одну внутреннюю штуку писать. По этому сейчас кажется что несколько сельдереев (worker node) для нас будет оптимальным решением.
Если делать масштабирование Airflow на Mesos, в чем преимущество?
Если я правильно понял из статьи про Huginn, то Huginn это такой self-service mix из ESB+BPM. Airflow это совсем не про это. Вы работали с хранилищами данных? Или наверняка слышали про λ архитектуру? Airflow про ETL/ELT и batch слой вашей λ-ы. Кейс может быть простой: вам нужно собрать по клиенту кучу данных из разных источников и например раз в день (можно чаще) обновлять его собирательный профиль.
Спасибо за вопрос. Я хотел бы подчеркнуть что этот инструмент подходит для команда разных размеров и разных по объему задач. В силу того что он бесплатный, с открытым кодом, гибкий и удобный для быстрого старта вы можете организовать под свои требования свой сервис, будь у вас маленькая компания и вам будет достаточно одного сервера или же airflow подселенного на сервер БД, или будь у вас кластер Airflow для проворачивания тысяч задач и работы с гетерогенным хранилищем и гетерогенными источниками данных.
Трансформации в Oracle GoldenGate или Attunity это скорее возможность, у вас же трансформации — необходимость :) Но в случае NoSql по другому, я думаю, и быть не может.
Можете потом свои наработки продать Informatica, они назовут это модным словом адаптер (PowerExchange for GT.m) :)
«Риалтаймовость» — это круто! Желаю успехов и удачи в новых релизах! :)
ODS на Oracle подразумевает единую БД. Шаг перегрузки данных из, как вы говорите, квази-копии в Oracle тоже надо будет реализовывать. Но сама как идея у вас интересная.
В части триггеров, кажется понял. Т.е. CDI получаете уже тогда когда дельту вычитываете?
И ещё. Не сочтите за придирку. Но, можно ли назвать то, что у вас получилось репликацией? По сути у вас просто получился ETL из NoSQL источника (GT.m) в ODS (Oracle)?
Пара вопросов.
— Не понял про триггеры. Получается что триггеры можно вешать на CDI?
— Иерархические ну или объектные СУБД удобны «отсутствием» схемы данных (ваш пример про 2 и 22 телефона). Как в этом случае формируется структура таблицы на стороне ODS? И поддерживаете или же думаете реализовывать поддержку репликации DDL? А может это вопрос как раз к механизму создания таблиц аудита на стороне Profile.
Вот интересное, для общего понимания, сравнение Airflow, Luigi и Pinball — bytepawn.com/luigi-airflow-pinball.html#luigi-airflow-pinball
Для таких задач есть отличный набор операторов — sensor-ы. Они как раз про, что бы что-нибудь подождать. Есть и минус, минус в том что сенсоры это такие же задачи airflow, требующие постановки в очередь и свободного слота и воркера. Мы держим сенсоры в отдельном пуле, тем самым контролируем их кол-во и приоритезируем их.
Спасибо за информацию по подходу к организации среды для разработки.
Вот вообще сложно поспорить :)
Кол-во и интервал ритраев можно настроить на уровне дага, можно переопределить на уровне задачек. Есть параметр оповещать на ритрай, есть на финальный феилд. Достаточно просто и удобно.
Если даг построен корректно, т.е. с применением макросов airflow и за определенный день (дату) даг работает с определенными данными, то достаточно просто найти в запусках дага требуемый день и с него почистить статусы задачек в этом дне и в последующих днях (делается это легко). Планировщик обработает эти задачки ещё раз. Так же есть процедура backfill (https://airflow.apache.org/cli.html), можно с помощь неё перезапустить определенный период в даге.
Эта часть у нас пока плохо организована. Здесь ещё предстоит много работы. Нашему DWH всего год. Куда двигаться в целом понятно: у каждого разраба свои репы, система пул реквестов, скрипт копирования прод таблиц/данных в песочницу для разработчиков (в рамках одного hadoop кластера).
1. Если у тебя информатика и ты плотно на ней сидишь, то не думаю что тебе что-то даст Airflow. Разве что если только поможет открыть глаза на что более светлое ;) Про стоимость конечно глупо говорить. Про скорость разработки и добавления на среду новых процессов, вот про про что нужно говорить. Про кодогенерацию, про сравнительную простоту масштабирования. Про возможность делать кастом операторы стоит говорить.
2. У нас в хранилище для батч уровня да, только Airflow. Есть такая стратегия, сейчас всё хранилище строится на опенсорс.
3. Кейсы ты имеешь ввиду что? Падений? Или требования которые было непонятно как решить на текущей сборке Airflow? Падения были, разрешали сами, + стековерфло, +гитхаб. Требования которае не могли бы решить, тут как мне кажется если задача адекватная, и источник в меру адекватный и алгоритм в меру адекватный, то для airflow проблем не будет, т.к. есть PythonOperator на котором в целом можно решить достаточно заковыристые задачи по получению данных. Ты можешь мне подкинуть задачу, я могу тебе на шагах расписать как это будет реализовано на Airflow.
Если делать масштабирование Airflow на Mesos, в чем преимущество?
Мой мир никогда не будет прежним…
postgresql->
.net service-> logstash -> kafka ->spark streaming -> hive— > Informatica -> MSSql — не? :)Можете потом свои наработки продать Informatica, они назовут это модным словом адаптер (PowerExchange for GT.m) :)
«Риалтаймовость» — это круто! Желаю успехов и удачи в новых релизах! :)
И ещё. Не сочтите за придирку. Но, можно ли назвать то, что у вас получилось репликацией? По сути у вас просто получился ETL из NoSQL источника (GT.m) в ODS (Oracle)?
Пара вопросов.
— Не понял про триггеры. Получается что триггеры можно вешать на CDI?
— Иерархические ну или объектные СУБД удобны «отсутствием» схемы данных (ваш пример про 2 и 22 телефона). Как в этом случае формируется структура таблицы на стороне ODS? И поддерживаете или же думаете реализовывать поддержку репликации DDL? А может это вопрос как раз к механизму создания таблиц аудита на стороне Profile.