Когда я пришла на проект, в нём уже было много всего: много данных, много источников, много задач в Airflow. Чтобы ощутить масштаб, достаточно, пожалуй, взглянуть на одну картинку:
Это – граф dbt-dag’а в Airflow. То есть это все представления и таблицы, которые создаёт dbt, обрабатывая по шагам разные данные для нашего проекта – от сырых данных до финальных таблиц.
Так было на момент моего прихода в проект полгода назад. С тех пор данных стало ещё чуть больше.
Вот с этого – «данных стало ещё чуть больше» - и началось всё самое интересное.
Тут я сделаю небольшое отступление – вся эта история стала наглядной благодаря двум идеям:
«Когда мы можем измерить то, о чём говорим, и представить это в виде чисел – мы точно знаем что-то об этом» - эта идея когда-то крепко засела в моей голове благодаря выступлению Дмитрия Аббакумова – лида Центра психометрики и учебной аналитики в Яндекс.Практикуме.
Где-то на просторах DataLearn почерпнула идею сделать дашборд качества/актуальности данных.
Эти две мысли подтолкнули меня начать собирать данные о том, какие статусы задач я вижу по утрам в Airflow. По утрам – потому что каждую ночь по расписанию Airflow обновляет все наши данные и таблицы…
Если сначала задачи в основном либо успешно отрабатывали, либо, если уж если случалась проблема - то у многих разом. Выглядело это так, что проблема в одном источнике вызывала проблемы в другом, и они порою сливались в какой-то снежный ком.
До поры до времени это вписывалось в рамки разумного, поскольку мне приходилось перезапускать утром в среднем около 14 задач. Но в то время я уже задумалась об улучшении и стала фиксировать сведения.
И правильно сделала – ведь дальше, когда проект продолжил развиваться, соединений прибавилось, а вместе с ними прибавилось и проблем. Теперь уже утро не начиналось как утро моей мечты – вот я беру чашечку кофе и начинаю спокойненько заниматься своими задачками… Нет. Теперь мне иногда хотелось просто схватиться за голову! Часто падали десятки задач – это могло быть и 50, и 60, и 70 соединений, которые мне предстояло перезапустить. В среднем падало уже около 25 задач, а однажды - весь scheduler Airflow - и вовсе не выдержал такой жизни.
Со временем проблемы только нарастали:
И особенно печально было от того, что ситуация стала напоминать клубок проблем – проценты падений по некоторым источникам часто доходили до 100:
Как же мне удалось добиться такого:
и распутать клубок накопившихся проблем?
Что ж, устраивайтесь поудобнее, я расскажу вам о 5 параметрах Airflow, которые мне помогли на этом тернистом пути (ведь размотала я клубок не сразу, а только методом проб и ошибок):
1. schedule_interval – без одновременных стартов
Во-первых, мы избавляемся от потенциально опасной ситуации – на scheduler Airflow не должно разом наваливаться слишком много задач. Распределяем время запуска источников более плавно и в целом в более широком диапазоне.
2. pool – поменьше
Вводим максимальное ограничение на количество одновременно выполняемых задач внутри источника (pool=1). Это помогает и для источников, внутри которых много соединений, и для «больших» источников (в которых много данных, например, как в Яндекс Метрике – миллионы строк), параллельно с которыми начинают работать и более «маленькие» (например, какие-нибудь плановые значения или справочники из Google Sheets или Яндекс Диска). Суть параметра – снизить конкуренцию за вычислительные ресурсы у параллельно работающих задач.
3. timeout – побольше
Досадная мелочь – но иногда крайне важная вещь. Для источников, по которым к вам загружается большой объём данных – необходимо проставить timeout свыше 3600 секунд. Иначе вы будете видеть ошибку там, где на самом деле источник справился (просто не в течение часа – это значение параметра в Airflow по умолчанию).
4. config_patch={'last_days': …} – в разумных пределах
Если ваш коннектор, например, загружает данные из социальных сетей, и таких соединений у вас достаточно много, возможно, стоить подобрать разумный диапазон дат для скачивания данных. Например, в моём проекте изначально это было немного разношёрстно, от 90 до 365 дней. Я сделала единый диапазон в 90 дней.
5.schedule_interval – с учётом длительности работы и количества задач внутри дага Да, это снова он, но под другим углом. Вишенка на торте моих экспериментов – это учёт не только среднего времени загрузки данных, но и объём соединений внутри каждого источника.
То есть мы сначала выясняем:
- примерную длительность выполнения каждого дага (в данном случае это источники данных)
- количество задач (в данном случае – соединений) внутри каждого дага
Затем расставляем время запуска дагов с учётом этих сведений:
Для простоты восприятия придадим нашим дагам цвет в зависимости от продолжительности их работы.
👀 Рядом с самой тёмной задачей (наибольшее время загрузки) расставляем самые светлые (наименьшее время) даги.
И придадим нашим дагам различный размер в зависимости от количества задач внутри.
👀 Рядом с большими дагами (с большим количеством задач внутри) расставляем даги поменьше.
Плюс если достаточно большой и тёмный даг (долгое время работы + много задач внутри) всё-таки соседствует с таким же – расставляем их по времени старта подальше друг от друга.
В сумме эти 5 пунктов и помогли мне повысить успешность загрузки данных в 5 раз - от в среднем 25 упавших задач к 5.
Конечно, в теории их можно попробовать свести к нулю, просто не ставя загрузки параллельно - то есть каждый новый даг запускать только после отработки предыдущего. Но тут надо помнить, что после загрузки данных из всех дагов с источниками их ещё должен обработать dbt-dag. А у нас ограничено время - ведь утром пользователей должны встречать дашборды с актуальными данными.
Поэтому продуманный подбор параметров Airflow + минимальная доработка аналитиком = готовые, свеженькие дашборды по утрам 🥐🫖. Теперь уже не надо хвататься за голову, а можно спокойно попить свой кофе 😉.
