[Перевод] Чему мы научились при переходе с Cron на Airflow

задняя часть Командная строка Программа перевода самородков Spark
[Перевод] Чему мы научились при переходе с Cron на Airflow

Прошлой осенью в отделе обработки данных VideoAmp произошли серьезные изменения. В то время команда состояла из трех инженеров данных и системного инженера, которые тесно сотрудничали с нами. Мы коллективно определили, как оптимизировать технический долг компании.

В то время группа данных была единственным владельцем всех пакетных заданий, которые получали отзывы из нашего хранилища RTB, загружали их в базу данных Postgres и заполняли пользовательский интерфейс из базы данных Postgres. Если эти задания завершатся неудачно, пользовательский интерфейс устареет, и наши внутренние трейдеры и внешние клиенты будут иметь только устаревшие данные, на которые можно положиться. Поэтому соблюдение соглашений об уровне обслуживания для этих заданий имеет решающее значение для успеха платформы. Большинство этих заданий созданы на Scala и используют Spark. Эти пакетные задания управляются с помощью Cron, встроенного в Linux инструмента планирования.

Преимущества Крона

Мы обнаружили, что некоторые из основных проблем, вызванных Cron, даже перевешивают преимущества. Cron встроен в Linux и не требует установки. Кроме того, Cron довольно надежен, что делает его привлекательным вариантом. Поэтому Cron — отличный выбор для проверки концепции проекта. Но это не работает хорошо, когда используется в масштабе.

Файлы Crontab: как раньше планировалось выполнение приложений

Недостатки Крона

Первая проблема с Cron заключается в том, что изменения в файле crontab трудно отследить. Файл crontab содержит расписания для заданий, выполняемых на этом компьютере, которые являются межпроектными, но не отслеживаются в системе управления версиями и не интегрированы в процесс развертывания одного проекта. Вместо этого инженеры вносят правки по мере необходимости, но не записывают сроки или зависимости проекта.

Вторая проблема заключается в том, что эффект работы не прозрачен. Журналы Cron выводятся на сервер, на котором выполняется задание, а не где-то централизованно. Как разработчик узнает, удалась работа или нет? Анализ журналов для получения этих сведений обходится дорого, независимо от того, просматривают ли разработчики их сами или им нужно предоставлять их группам нижестоящих инженеров.

Наконец, повторный запуск невыполненных заданий целесообразен и труден. По умолчанию Cron устанавливает только несколько переменных среды. Начинающие разработчики часто удивляются, когда узнают, что команды bash, хранящиеся в файле crontab, не производят тот же результат, что и их терминал, потому что настройки в их профиле bash не существуют в среде Cron. Это требует от разработчика создания всех зависимостей пользовательской среды, которая выполняет команду.

Очевидно, что многие инструменты должны быть построены поверх Cron, чтобы добиться успеха. Хотя мы немного разобрались с этим, мы знаем, что есть много более мощных опций с открытым исходным кодом. Вся наша команда использовала такие инструменты оркестровки, как Luigi, Oozie и другие нестандартные решения, но в конечном итоге этот опыт оставил нас недовольными. И Airflow AirBnB может быть выбран для инкубатора Apache, что означает, что он хорошо принят.

Настройка и миграция

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

Этот метадб содержит важную информацию, такой как односторонний цикл (DAG) и списки задач, эффекты работы и результаты, и переменные для отправки сигналов на другие задачи. Метад по воздушным потокам может быть построен сверху реляционной базы данных, такой как PostgreSQL или SQLite. Благодаря этой зависимости воздушный поток может быть продлен до одного экземпляра. Мы пропустили виртуальную машину PostgreSQL для нашей другой команды на платформе Amazon RDS (их спринты развития закончились, они больше не используют этот пример).

Хост Airflow установлен на нашей виртуальной машине разработки Spark и является частью нашего кластера Spark. LocalExecutor настроен на этом хосте и запускает планировщик и пользовательский интерфейс для Airflow. После установки на экземпляре в нашем искровом кластере наше задание имеет разрешения на выполнение необходимых искровых зависимостей. Это ключ к успешной миграции и причина, по которой предыдущие попытки не увенчались успехом.

Переход с Cron на Airflow сопряжен с особыми трудностями. Поскольку Airflow поставляется с планированием задач, нам пришлось изменить наше приложение, чтобы оно могло принимать данные в новом формате. К счастью, Airflow предоставляет необходимую метаинформацию для планирования сценариев через переменные. Мы также убрали приложения для большинства встроенных инструментов, таких как push-оповещения и сигналы. В конце концов, мы разбили многие приложения на более мелкие задачи, чтобы следовать парадигме DAG.

Пользовательский интерфейс Airflow: разработчики могут четко определить по пользовательскому интерфейсу, какие Dags стабильны, а какие менее надежны и нуждаются в укреплении.

уроки выучены

  1. Приложение раздутоеПри использовании Cron логика планирования должна быть тесно связана с приложением. Каждое приложение должно выполнять всю работу DAG. Эта дополнительная логика маскирует единицу работы, которая является ядром цели приложения. Это затрудняет параллельную отладку и разработку. После перехода на Airflow идея размещения задач в группе обеспечения доступности баз данных позволила команде разработать мощные сценарии, ориентированные на эту единицу работы, при этом сводя к минимуму нашу рабочую нагрузку.
  2. Оптимизирован рендеринг пакетных заданий.Благодаря пользовательскому интерфейсу Airflow эффект пакетных заданий для группы данных становится прозрачным для команды и других инженерных отделов, которые полагаются на наши данные.
  3. Инженеры данных с разными наборами навыков могут работать вместе, чтобы построить воронкуНаша команда инженеров данных использует Scala и Python для выполнения заданий Spark. Airflow предоставляет нашей команде знакомый промежуточный уровень для установления протоколов между приложениями Python и Scala, что позволяет нам поддерживать инженеров с обоими навыками.
  4. Путь расширения нашего пакетного планирования заданий очевиден.При использовании Cron наше планирование ограничено одной машиной. Масштабирование приложения требует от нас создания координационного слоя. Airflow предоставляет нам готовые расширения. С Airflow путь от LocalExecutor к CeleryExecutor четко виден, от CeleryExecutor на одной машине к нескольким воркерам Airflow.
  5. Повторное выполнение заданий стало прощеС Cron нам нужно выполнить команды Bash, и мы надеемся, что наша пользовательская среда достаточно похожа на среду Cron, чтобы иметь возможность воспроизвести проблему для отладки. Сегодня с помощью Airflow любой инженер данных может напрямую просматривать журналы, анализировать ошибки и повторно запускать невыполненные задачи.
  6. Соответствующий уровень оповещенияДо Airflow все оповещения о пакетных заданиях отправлялись в почтовый ящик оповещений нашего приложения для потоковой передачи данных. С помощью Airflow команда создала оператора Slack, который может вызываться всеми группами обеспечения доступности баз данных для отправки push-уведомлений. Это позволяет нам отделить срочные уведомления об ошибках из нашего стека RTB от важных, но не срочных уведомлений из наших пакетных заданий.
  7. Плохо работающая DAG может привести к сбою всей машины.Установите спецификации для ваших групп данных, чтобы контролировать внешние зависимости их заданий, чтобы они не влияли на соглашения об уровне обслуживания других заданий.
  8. Прокрутите журналы AirflowЭто само собой разумеется, но Airflow хранит журналы для всех приложений, которые он вызывает. Не забудьте правильно свернуть журналы, чтобы предотвратить выход из строя всей машины из-за нехватки места на диске.

Пять месяцев спустя команда разработчиков данных VideoAmp увеличилась почти втрое. Мы управляем 36 группами DAG, и их число продолжает расти! Airflow был расширен, чтобы все наши инженеры могли вносить свой вклад и поддерживать наш пакетный процесс. Простота инструмента делает его относительно безболезненным для начинающих инженеров. Команда быстро разрабатывает улучшения, такие как унифицированные push-оповещения для нашего слабого канала, обновление до Python3 Airflow, переход на CeleryExecutor и использование возможностей, которые может предложить Airflow.

Любые вопросы или комментарии можно задать прямо здесь или поделиться своим опытом ниже.

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из ИнтернетаНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллекти другие поля, если вы хотите видеть больше качественных переводов, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории