предисловие

С ростом компании возникает все больше и больше требований к автономной разработке приложений для больших данных.Эти требования включают, помимо прочего, автономную синхронизацию данных (автономная синхронизация между MySQL/Hive/Hbase/Elastic Search и т. д.), автономную вычисления (Hive/MapReduce/Spark и т. д.), планирование времени, запрос текущих результатов и оповещение о сценариях сбоя и т. д.

Прежде чем создать единую платформу для разработки больших данных, она столкнулась с рядом проблем:

• Многочисленные порталы разработки и планирования затрудняют повторное использование проектов или компонентов между различными бизнес-подразделениями и в то же время приводят к большим затратам на эксплуатацию и обслуживание.
• Среда Hadoop не дружелюбна к коллегам по бизнес-команде (помимо знакомства с бизнесом, вам также необходимо более глубокое понимание лежащего в основе фреймворка)
• Повторяющаяся работа по разработке (например, направляющие таблицы, планирование и другие модули, которые можно использовать повторно, но которые необходимо повторять в нескольких проектах)
• Частые межведомственные потребности в общении и обсуждениях

Чтобы решить различные проблемы, с которыми столкнулись выше, ссылаясь на решения для больших данных других компаний в отрасли, мы разработали и внедрилиПлатформа разработки больших данных (Data Platform, сокращенно DP), через визуальный интерактивный интерфейс, для решения различных сред и инструментов, связанных с автономными вычислениями больших данных.

В этой статье будет представлен системный дизайн DP и его реализация в Youzan, в том числе:

• Системный дизайн DP, включая архитектурный дизайн и дизайн модуля планирования с акцентом
• Текущий статус посадки
• Резюме и перспективы

Проектирование платформы для разработки больших данных

Архитектурный дизайн

Рисунок 1 Схема архитектуры системы DP

Платформа разработки больших данных включает в себя модуль планирования (на основе вторичной разработки воздушного потока с открытым исходным кодом), базовые компоненты (включая модуль синхронизации общедоступных данных/управление полномочиями и т. д.), сервисный уровень (управление жизненным циклом задания/управление ресурсами/распределение тестовых задач/подчиненный управление и т. д.) и мониторинг (машинные ресурсы/журналы/мониторинг на основе прогнозов). Конкретные функции и обязанности этих модулей:

• **Модуль планирования задач:** Поддержка нескольких очередей и распределенного планирования на основе приоритета задачи. На основе воздушного потока с открытым исходным кодом была проведена вторичная разработка, и основные новые функции включают в себя: * Добавить несколько типов задач (datax/datay/экспорт почты/экспорт es/Spark и т. д.) * В соответствии с восходящей и нисходящей связью и важностью задачи, рассчитайте глобальный приоритет задачи и запланируйте ее в соответствии с глобальным приоритетом (высокий приоритет будет выполнен первым, а низкий приоритет войдет в очередь для ожидания) * Отображение зависимостей задач Cross-Dag (на основе глобального Dag зависимости кросс-Dag устанавливаются путем чтения и записи информации таблицы Hive о задачах) * Очистить одним щелчком все зависимые нижестоящие узлы от текущего узла (поддерживает кросс-Dag)
• **Базовый модуль:** Включая автономную полную/добавочную синхронизацию данных, добавочную синхронизацию на основе Binlog, экспорт Hive ES/mail, синхронизацию MySQL с Hbase (в разработке) и т. д., см. рис. 2.

Рисунок 2. Автономный режим синхронизации данных, поддерживаемый DP (стрелки указывают на поток данных)

• **Сервисный модуль: **Отвечает за управление жизненным циклом заданий, включая создание (изменение) заданий, тестирование, выпуск, эксплуатацию и обслуживание и т. д. При развертывании службы используется режим «ведущий/подчиненный», как показано на рис. 3. в * Главный узел поддерживает высокую доступность и горячий перезапуск (другой узел предоставляет услуги во время перезапуска, поэтому он не знает о пользователях). Основными обязанностями Мастер-узла являются управление жизненным циклом заданий, распределение тестовых заданий, управление ресурсами, мониторинг Слейвов по пульсу и т.д. * Ведомые узлы распределяются в кластере планирования и используют общие машины с рабочими узлами Airflow. Основной обязанностью узла Slave является выполнение команд, раздаваемых Master (включая тесты, скрипты мониторинга машин и т. д.), обновление ресурсов (через Gitlab) и т. д.

Рис. 3 Схема развертывания DP

• **Модуль мониторинга: **Обеспечивает всесторонний мониторинг и раннее предупреждение о машинах, ресурсах и задачах планирования кластера планирования. По степени детализации и размерности мониторинг делится на три категории: * _Базовый мониторинг: _ Комбинируйте мониторинг эксплуатации и обслуживания (процесс, ввод-вывод и т. д.) и пользовательский мониторинг (включая мониторинг колебаний цепочки задач, мониторинг времени вывода ключевой задачи и т. д.) для выполнения базового мониторинга и оповещения на ведущем узле DP и рабочем узле. узел. * _Мониторинг журнала: _путем сбора журналов, созданных при запуске задачи в Kafka, а затем анализа и анализа с помощью Spark Steaming, времени начала и окончания каждой задачи, владельца и количества используемых ресурсов (объем чтения и записи MySQL, использование ЦП/памяти Yarn, занятость слотов планирования и т. д.), вы можете дополнительно анализировать журнал выполнения задач Yarn в реальном времени и находить такие данные, как перекос данных и информацию о стеке ошибок. Наконец, эти данные сохраняются в NoSQL (например, Redis) для дальнейшей обработки и отображения. * _Мониторинг предсказания задачи: _Предскажите время начала/окончания задачи, моделируя планирование задачи (фактически не выполняя задачу) на определенный период времени заранее, и в то же время вы можете знать список задач, которые может произойти сбой и истечет время ожидания, а затем выполнить задачу до возникновения проблемы.

       * 现阶段已经实现的功能：分析可能失败的任务列表（失败的原因可能是DB的配置发生更改、上游的节点失败等）并发送告警信息；基于过去一段时间的运行时间数据，模拟整个任务调度，可以计算出任务的开始/结束时间以及超时告警。
       * 未来规划：任务的运行时长不是基于过去的数据，而是通过读取的数据量、集群资源使用率、任务计算复杂程度等多个特征维度来预测运行时长。
  

Дизайн планирования задач

Планирование задач платформы разработки больших данных относится к периодическому выполнению пользовательского кода в течение периода времени (указанного временем начала/окончания) в соответствии с периодом планирования, указанным в конфигурации задания (указанным crontab) после выпуска задания. . Проблемы, которые необходимо решить при планировании задач, включают:

1. Как поддерживать разные типы задач?
2. Как обеспечить высокий уровень параллелизма при планировании задач (необходимо обрабатывать сотни выполнений задач в секунду в часы пик)?
3. Как обеспечить, чтобы относительно важные задачи (задачи хранилища данных) получали приоритет для получения ресурсов и выполнения?
4. Как добиться балансировки нагрузки (в основном, ресурсов ЦП/памяти) на нескольких машинах планирования?
5. Как обеспечить высокую доступность расписания?
6. Как удобно отображать статус планирования задач, журналы и другую информацию?

Чтобы решить вышеупомянутые проблемы, мы исследовали множество сред с открытым исходным кодом (Azkaban/Oozie/Airflow и т. д.) и, наконец, решили использовать Airflow + Celery + Redis + MySQL в качестве модуля планирования задач DP в сочетании с В соответствии с бизнес-сценариями и потребностями компании, выполненной более глубокой настройки, предлагаются следующие решения (см. рис. 4):

Рис. 4. Планирование задач на основе Airflow + Celery + Redis + MySQL

• На вопрос 1, На основе исходных типов задач Airflow компания DP настроила множество задач (реализуя Operator ), включая задачи импорта и экспорта на основе Datax, задачи Datay на основе Binlog, задачи экспорта электронной почты Hive, задачи экспорта Hive ElasticSearch и т. д.
• На вопрос 2, с одной стороны, управление параллельным количеством задач реализовано через метод Pool + Queue + Slot, предоставляемый Airflow, а задачи, которые не могут быть выполнены немедленно, ставятся в очередь в очередь. С другой стороны, через Celery может быть реализовано распределенное развертывание (горизонтальное расширение) любого количества воркеров Теоретически нет предела параллелизма для планирования.
• На вопрос 3, Основываясь на планировании очереди приоритетов, поддерживаемом самим Airflow, мы вычисляем глобальный приоритет каждого узла через глобальную DAG в соответствии с восходящими и нисходящими отношениями задач и отмечаем важные узлы задач с приоритетом. Это может гарантировать, что важные задачи будут запланированы в первую очередь, и обеспечить стабильность времени вывода важных задач.
• На вопрос 4, Во-первых, разные типы задач должны потреблять разные типы ресурсов, например, задачи Spark интенсивно используют память, задачи Datax интенсивно используют ЦП и т. д. Если задачи одного типа выполняются на одной машине, это легко чтобы привести к исчерпанию некоторых системных ресурсов, а другая часть ресурсов простаивает, и если на машине слишком много одновременных задач, легко вызвать такие проблемы, как OOM памяти и ЦП, постоянно переключающие контексты процесса. Итак, наше решение:
  • Разделите задачи на разные типы задач в соответствии с объемом требуемых ресурсов и поместите каждый тип задачи в отдельную очередь планирования для управления.
  • Установите разные слоты для каждой очереди, то есть максимально допустимое количество параллелизма.
  • Настройте несколько очередей одновременно для каждой рабочей машины
  • Основываясь на этих конфигурациях, мы можем гарантировать, что использование ЦП/памяти каждой рабочей машины остается в пределах относительно разумного диапазона использования, как показано на рис. 5.

Рис. 5. Использование памяти рабочими машинами планирования

• На вопрос 5, роли, задействованные в модуле планирования задач, включают Scheduler (производитель) и Worker (потребитель), поскольку Worker изначально представляет собой распределенное развертывание, поэтому недоступность некоторых машин не приведет к недоступности всего расписания (другие узлы могут продолжать работать). обслуживать). У планировщика есть одна проблема. Наше решение состоит в том, чтобы добавить резервный планировщик (см. рис. 3) в дополнение к узлу активного планировщика. Резервный узел будет периодически контролировать состояние активного узла. быть недоступным В этом случае Standby переключается на Active. Это обеспечивает высокую доступность Планировщика.
• На вопрос 6, собственная функция веб-дисплея Airflow уже относительно удобна.

статус кво

Проект DP начал разработку в январе 2017 года и был официально запущен в производство в июне.После N раундов функциональных итераций, простота использования и стабильность были значительно улучшены.В настоящее время кластер планирования включает 2 Master и 13 Slave (Scheduling) узлов (2 из которых используются для планировщика, остальные 11 используются для рабочих), поддерживают планирование более 7000 задач в день и соответствуют приложениям для хранилищ данных, центров обработки данных, бизнес-аналитики, товаров, платежей и других линеек продуктов.

Рис. 6. Диаграмма тенденций количества задач планирования DP

Типы миссий, которые в настоящее время поддерживаются DP, включают:

• Автономная синхронизация данных:
  • Полная/инкрементная синхронизация данных из MySQL в Hive (на основе вторичной разработки Datax)
  • Полная/инкрементная синхронизация данных из Hive в MySQL (на основе вторичной разработки Datax)
  • Из MySQL через Binlog, через Nsq/Hdfs/MapReduce Инкрементная синхронизация с Hive (Datay, собственная разработка)
  • Синхронизация из MySQL в Hbase (на основе вторичной разработки Datax)
  • Синхронизация из Hive в ElasticSearch (на основе вторичной разработки Datax)
• Задачи хаупа:
  • Hive/MapReduce/Spark/Spark SQL
• Другие задачи:
  • Экспорт данных таблицы Hive по электронной почте (поддерживает вложения в формате PDF/Excel/Txt)
  • Задачи скрипта в виде Python/Shell/Jar

Резюме и перспективы

После полутора лет непрерывной итерации и улучшения функций DP в настоящее время поддерживает планирование более 7000 задач в день.В то же время стабильность и простота использования также были значительно улучшены, что может удовлетворить ежедневные потребности пользователей в больших данных в автономном режиме. разработка Некоторые сценарии использования. В то же время мы также понимаем, что есть еще много моментов, которые можно изучить и улучшить при разработке больших данных.В будущем мы можем дополнительно улучшить функции платформы и улучшить взаимодействие с пользователем в следующих аспектах:

• Расширенные типы задач
• Дальнейшая интеграция других платформ или инструментов для достижения универсального опыта разработки больших данных.
• Предоставьте домашнюю страницу пользователя (пространство), инструменты ежедневной работы и обслуживания и страницу управления, что более удобно для централизованного управления задачами.
• Оптимизация управления журналом задач (включая быстрый поиск информации об ошибках/извлечение и анализ журналов Yarn и т. д.)