Reversed Orchestration Ben Stancil в очередном выпуске свой р | data будни

Reversed Orchestration

Ben Stancil в очередном выпуске свой рассылки рассуждает о недостатках текущего подхода к оркестрации как цепочек зависимых тасков, начиная от входных слоёв и заканчивая витринами.

https://benn.substack.com/p/down-with-the-dag

Одна из проблем — в увеличивающимся количестве графов, тасков и сущностей:

> In 2022, data engineers manage forests, not trees

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

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

Автор предлагает подойти с другой стороны — проставить всем сущностями требования по свежести данных: например, по 4 часа на главные витрины , на промежуточные сущности 12, вспомогательные справочники и того меньше. И пускай там под капотом система сама решает когда какую сущность грузить.

Из преимуществ такого подхода — сглаживание пиков по нагрузке на вычислительные мощности. Система сама должна прикидывать когда что запускать, чтобы попасть в ожидаемые границы SLA по всем сущностям (а не просто все считать раз в N часов по крону).

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