Версия сайта для слабовидящих
Добавляя в наши курсы для дата-инженеров еще больше полезных примеров, сегодня рассмотрим, как Airbnb развивает Apache AirFlow и на практике используют эту платформу для создания, планирования и мониторинга конвейеров данных. Что такое Smart Sensor и как умные датчики экономят ресурсы на выполнение долгосрочных легковесных задач.
Легкие, долгие и ресурсоемкие: проблемы LRLW-задач в Apache Airflow
Типичный кластер Apache Airflow может поддерживать тысячи DAG’ов, в которых одновременно выполняются десятки тысяч задач. Например, еще в 2018 году в Airbnb в кластере Airflow работало несколько тысяч DAG’ов и более 30 тысяч задач. Такой объем рабочей нагрузки приводит к перегрузке базы данных Airflow и увеличивает стоимость кластера, требуя огромное количество ресурсов для поддержки множества параллельных задач. Чтобы сделать систему более стабильной и снизить расходы, дата-инженеры Airbnb решили оптимизировать Airflow. В частности, было обнаружено, что долгосрочные легковесные задачи (LRLW, long-running lightweight) тратят много ресурсов. Поэтому целесообразно объединить их, чтобы уменьшить затраты и устранить потери производительности. Сделать это можно с помощью такого элемента как интеллектуальный датчик (Smart Sensor), который впервые появился в Apache Airflow 2.0, о чем мы писали здесь.
Smart Sensor – это особый тип операторов, цель которого в ожидании определенного триггера, например, успешного завершения внешней задачи. Хотя датчики простаивают большую часть времени выполнения, они держат «рабочий слот», который потребляет ресурсы ЦП и памяти. Smart Sensor в Airflow 2.0 играет роль функции раннего доступа, которая выполняется как одна длительная задача, проверяет статус пакета задач Sensor и сохраняет информацию о состоянии датчика в базе данных метаданных.
По сути, умный датчик работает до тех пор, пока не будет достигнут определенный критерий или условие, например, наличие файла в HDFS или S3, создание раздела в Hive, успешное выполнение какой-либо другой внешней задачи или наступление конкретного момента времени. Именно дата-инженеры Airbnb впервые предложили и реализовали концепцию умного датчика в Apache AirFlow. А затем это вошло в крупный релиз платформы, вышедший в конце 2020 года.
Исследуя проблемы с производительностью AirFlow, дата-инженеры Airbnb обнаружили, что некоторые виды задач имеют одинаковые шаблоны LRLW. Это задачи датчиков, вложенные файлы DAG и SparkSubmitOperator.
При выполнении задачи датчик вызывает функцию poke(), чтобы периодически проверять достижение условия. Обычно период проверки, т.е. вызова poke() равен 3 минуты. Если эта функция вернула значение true, задачи датчика выполнены успешно, иначе – произошел сбой или истек заданный таймаут. Выполнение poke() происходит очень быстро, менее 100 мс, поэтому большую часть времени датчики бездействуют в ожидании. Срок службы задачи датчика — от времени проверки до момента выполнения условия, который может варьироваться от нескольких минут до нескольких дней.
SubDAG — еще один пример длительных легковесных задач. Эти подграфы используются для инкапсуляции набора задач в DAG, делая его сложную структуру более простой и читаемой. Запуск DAG создается для вложенного DAG в функции pre_execute(), а затем задача вложенного DAG меняет статус выполнения. SparkSubmitOperator также является примером долгосрочной легковесной задачи, когда клиент Spark в Airflow отправляет задание и опрашивает его до завершения. Все эти задачи после некоторой работы по инициализации переходят в облегченный, но длительный статус.
Таким образом, все LRLW-задачи имеют следующие общие черты:
- небольшое потребление ресурсов, т.к. рабочие процессы этих задач простаивают 99% времени;
- такие задачи часто составляют очень большую часть одновременно выполняемых задач в крупномасштабном кластере;
- много дублирующих задач — более 40% заданий датчиков дублируются, т.к. нижестоящие DAG обычно ждут одни и те же разделы от нескольких вышестоящих.
Для решения LRLW-задач дата-инженеры Airbnb и разработали Smart Sensor как сервис, который объединяет небольшие легковесные задачи в более крупные централизованные, чтобы снизить стоимость инфраструктуры Airflow и повысить стабильность кластера. Это особенно актуально для больших кластеров с большим количеством LRLW-задач. Что находится под капотом Smart Sensor, мы рассмотрим далее.
Как работает Smart Sensor
Сервис интеллектуальных датчиков поддерживает идею разделения продолжительности жизни задачи на несколько процессов и асинхронного режима для выполнения отложенных задач. Smart Sensor использует централизованные процессы для выполнения длительных задач в пакетном режиме вместо использования одного процесса для каждой задачи.
В сервисе Smart Sensor задача датчика выполняется в два этапа:
- сперва каждая задача анализирует DAG, получает объект задачи, запускает функцию pre_execute(), а затем регистрируется в сервисе Smart Sensor. При регистрации в базе метаданных Airflow сохраняется информация для опроса внешних ресурсов. После успешной регистрации задача завершается и освобождает рабочие слоты.
- далее несколько централизованных процессов (задачи Smart Sensor из встроенного DAG) продолжают проверять внутреннюю базу данных на наличие последних записей обо всех зарегистрированных задачах и выполнять функцию poke() для этих задач в пакетном режиме. Обычно одна задача Smart Sensor может легко справиться с несколькими сотнями LRLW-задач. Также сервис Smart Sensor также может объединять повторяющиеся задачи датчика в один экземпляр, чтобы сэкономить еще больше ресурсов.
Таким образом, Smart Sensor выполняет дедупликацию задач и балансирует рабочие нагрузки, определяя сегменты задач датчика. Если одновременно работает много датчиков, для их быстрого выполнения потребуется несколько задач Smart Sensor. Поэтому необходимо сбалансировать рабочую нагрузку всех задач Smart Sensor, например, назначая дублированные задачи одному и тому же интеллектуальному датчику.
В сервисе Smart Sensor сигнатура задания датчика называется poke_context – словарь аргументов, необходимых для выполнения этой функции. Два датчика с одним и тем же классом операторов и одним и тем же poke_context выполняют одну и ту же функцию poke(), и считаются дублированными задачами. Хэш-код poke_context для дублированных задач находится в определенном диапазоне, чтобы назначать их одному и тому же интеллектуальному датчику. Партиционирование или сегментирование также поддерживается в сервисе Smart Sensor. Например, Sensor1 и sensor2 имеют один и тот же poke_context, поэтому у них одинаковый хэш-код (hashcode) и шард-код (shardcode). Во время выполнения они будут обнаружены одним и тем же интеллектуальным датчиком, например, SmartSensor1 и проверяться с помощью poke() только один раз за цикл проверки.
Smart Sensor — это общая услуга для всех классов датчиков. Централизованная задача Smart Sensor — это общая структура для поддержки различных классов. Пока в классе есть функция poke() и аргумент для нее может быть сериализован, задачи Smart Sensor могут их поддерживать. Логи обрабатываются аналогично неконсолидированным процессам. Хотя выполнение задачи объединено в меньшее количество процессов, служба Smart Sensor поддерживает такую же возможность чтения или загрузки логов из пользовательского интерфейса Airflow. Пользователи могут читать журналы по URL-адресу исходной задачи датчика.
Smart Sensor можно легко применить к кластеру Airflow, включив или отключив этот сервис в конфигурации системного уровня в сеансе smart_sensor в airflow.cfg. Изменение прозрачно для отдельных пользователей, и нет необходимости изменять существующие DAG.
Первое практическое тестирование интеллектуальных датчиков в Airbnb помогло сократить количество одновременно выполняемых задач в часы пик более чем на 60%, а количество работающих сенсорных задач на 80%. Слоты процессов, необходимые для датчиков, уменьшились с 20 000 до 80. Благодаря меньшему количеству выполняемых задач также значительно снизилась загрузка базы данных. В частности, механизм дедупликации Smart Sensor сократил количество запросов к Hive Metastore примерно на 40%, снизил трафик и нагрузку на базовое хранилище данных. Читайте в нашей новой статье, как создать собственный сенсор в AirFlow.
Больше полезных примеров по организации ETL/ELT-процессов c Apache AirFlow для эффективной аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
