Оркестрация — это убийство времени.

Сколько времени вы потратили на управление задачами в оркестраторе? Сотни часов? Тысячи? Независимо от того, что это было, такая деятельность была малоценной, и вы, вероятно, тоже так считали.

Основная проблема заключается в том, что оркестратор пытается контролировать операции с данными, вместо того чтобы позволить операциям быть вытекающими из данных.

Почему у нас есть оркестраторы?

Короткий ответ: наследие.

Как написала Луиза (Louise), оркестратор данных — это "программное решение или платформа, отвечающая за автоматизацию и управление потоком данных между различными системами, приложениями и местами хранения". Я бы дополнил ее мысль тем, что, в конечном счете, оркестратор — это stateful-решение по управлению выполнением скриптов.

Оглядываясь назад, можно сказать, что необходимость в оркестрации данных возникла из-за сложности логики запуска, когда простое планирование скриптов не учитывало зависимостей. Один сценарий зависел от другого, и в центре должен был находиться программный компонент, который не только запускал бы весь процесс, но и обеспечивал старт отдельных этапов только после успешного завершения всех предшествующих зависимостей. 

Как отдельный кирпичик, оркестратор служит множеству целей, основными из которых являются:

• Сохранение состояния: отслеживание того, что произошло, а что нет. Вероятно, является основной функцией оркестратора.

• Функция триггера: фактический механизм выполнения скрипта, часто с использованием набора параметров, заданных на уровне поставленной задачи или выполняемого джоба.

• Обеспечение ограничений зависимости (Directed Acyclic Graphs, DAG. Направленный ациклический граф): сортировка того, какой из скриптов должен быть выполнен перед тем или другим, и убедиться в отсутствии циклов.

• Surface логи: обеспечивают полное представление о состоянии задач, которое служит точкой входа для поиска и устранения неисправностей.

В чем проблема?

Подсказка: дело в оркестрации.

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

Но, в интересах сохранения эффективности, проблема оркестраторов сводится к двум вещам: они просто еще один кирпичик в стеке, и, что самое главное, новые технологии данных в них не нуждаются.

Чем занимаются после оркестрации?

Операциями с данными "точно в нужное время".

Замещение оркестратора означает устранение оверхеда синхронизации, и главный способ сделать это — постараться сделать так, при котором время выполнения не столь значительное. В настоящее время это означает имплементацию асинхронной обработки, либо высокочастотных батчей (небольшой пакет данных).

Высокочастотные батчи

Давайте сначала разберем высокочастотные батчи, потому что я рассматриваю это как аберрацию

Высокочастотный батчинг — это выполнение этапов обработки с очень высокой частотой (согласно стандартов применения пакетного режима) — например, каждые 5 минут или около того. При этом можно рассматривать почти каждую самостоятельную задачу как асинхронную. Это помогает сделать отдельные задачи независимыми, без необходимости иметь в управлении stateful-оркестратора, но заставляет вас идти по самому “темному пути” одного из самых сложных компромиссов: маневренность в ущерб стоимости.

Каждый, кто пытался масштабировать запуск высокочастотных батчей, сталкивался с двумя проблемами. Во-первых, задержка быстро увеличивается — не нужно иметь глубокий граф зависимостей, чтобы высокочастотные задачи перестали коррелировать с высокодоступными датасетами. И во-вторых, ценообразование — больная тема. Большинство решений для работы с данными не рассчитаны на такое использование по простой причине: выполнение оператора LEFT JOIN каждые 5 минут означает избыточное сканирование тонны данных. 

Асинхронная обработка

Асинхронная обработка или системы непрерывного действия — подумайте об инкрементных движках, таких как потоковые процессоры, базы данных реального времени и в некоторой степени базы данных HTAP (Hybrid Transaction/Analytical Processing. Гибридная транзакционно-аналитическая обработка) — не требуют оркестратора, поскольку они непрерывны по своей природе, а данные самообновляются: изменение мгновенно отражается в потребительских системах и даунстрим представлениях/таблицах.

Для тех, кто еще не слишком хорошо знаком с потоковой передачей, это разница между операциями с данными Pull и Push: первые требуют постоянного запуска действий, которые вы хотели бы выполнить (как, например, в модели ETL/ELT), в то время как вторые пассивно и инкрементально вычисляют и распространяют точки данных. Никакой оркестрации! Каждая задача - это почти как микросервис, своего рода сервис данных.

К сожалению, Бенуа (Benoit) уже опередил меня в цитировании документации "Почему не Airflow", поэтому я избавлю вас от этого. Но, как упоминалось ранее, одной из основных проблем оркестраторов является совместимость: вы просто не можете организовать оркестрацию всего подряд. Это добавляет сложности и задержку в ваши операции с данными и в целом является “крайне эффективным способом” потратить много времени в неделю на деятельность, которая в конечном итоге будет не нужна. 

Представьте себе, что если бы все, что вы запускаете в продакшн, должно было быть оркестрировано, то это стало бы смертью agile. Действительно, почему это все еще происходит в мире данных? (Риторический вопрос, пожалуйста, обратитесь к первым абзацам в статье).

Что же это за новый набор инструментов?

Он уже здесь, в некотором роде.

Если вы тратите время на то, чтобы фиксить Airflow DAG, извините за выражение, но это вряд ли будет вашим самым большим вкладом в развитие компании. К счастью, альтернативы уже есть, так что выбор за техно-политическим руководством вашей организации. Что касается создания дата-сервисов, то все варианты асинхронной обработки данных, упомянутые ранее, уже существуют и работают в масштабах предприятия рядом с вами.

Чего действительно не хватает, так это какой-то формы многократно используемого уровня управления с базовыми требованиями: обеспечить соблюдение ациклических и директивных аспектов правил зависимостей, а также вывести оперативные команды и статусы на центральный уровень для удобства. Это скорее общий инструмент DataOps, который наследует некоторые обязанности Оркестратора, особенно в части метаданных и применения команд, хотя и не вмешивается в жизненный цикл задач — следовательно, больше не является обязательной частью стека. Именно здесь тренд "активных метаданных" мог бы стать интересным ходом, выступая в роли пассивного наблюдателя за происходящим, при этом активно не вмешиваясь в операции с данными.

В Popsink у нас нет дополнительного кирпичика для оркестрации, и это экономит нам время и деньги. В итоге для удобства мы создали собственную плоскость управления, отчасти потому, что некоторые открытые стандарты сегодня несовместимы с концепцией отсутствия оркестратора (например, OpenLineage, построенный на основе того, что задания имеют "начало" и "конец").

Тем не менее, это отлично работает: джобы теперь представляют собой асинхронные конструкции с пассивными потребителями, которым не нужно извлекать данные при выполнении предопределенных условий. Если использовать метафору, которая мне нравится: теперь мы используем трубы (pipes) вместо ведер (buckets). Здесь тратится гораздо меньше усилий, поэтому можно откинуться на спинку кресла и наблюдать за потоком данных.

Заключительные слова

Вы сделали это!

Во многих организациях дата-продукты все еще являются результатом длительной обработки данных, которая требует множества оркестраций. Но это совсем не обязательно, решения уже существуют, например, упомянутые Хьюбертом (Hubert) конструкторы потоковых рабочих процессов или то, над чем мы работаем в Popsink.

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

Потребуется еще немного времени для достижения полного паритета возможностей и появления хороших стандартов многократного использования, особенно потому, что нынешние системы активных метаданных и  lineage-системы  глубоко укоренились в оркестраторах, но потенциал уже имеется.

Пришло время двигаться дальше по жизни.

Как подготовить БД Clickhouse для загрузки данных и их эффективного использования? Как связать все воедино, начиная от хранилища и метода загрузки данных, заканчивая графиками? Ответы на эти вопросы вы можете получить на открытом уроке «Визуализация данных на основе Clickhouse и Apache Superset». В результате этой встречи вы:

• Получите понимание об одном и способов построения хранилища, направленного на визуализацию информации.

• Познакомитесь с современными инструментами формирования отчетности.

• На прикладных примерах проведете практическое применение теоретических знаний.

Урок пройдет в рамках онлайн-курса "Data Warehouse Analyst". Записывайтесь на занятие по ссылке.