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

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

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

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

Командам платформы данных приходится управлять принципиально разными заинтересованными сторонами — от менеджмента до инженеров. Часто эти две команды имеют противоположные цели, и менеджеров платформ можно зажать с обеих сторон.

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

«Наш генеральный директор хочет, чтобы я снизил затраты на облако и обеспечил соблюдение наших соглашений об уровне обслуживания, чтобы наши клиенты были довольны».

Хорошо, так в чем проблема?

«Проблема в том, что я не могу ничего изменить напрямую, мне нужна помощь других людей, и это узкое место»

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

Что сдерживает команду платформы?

  • Команды по работе с данными выходят за рамки технических возможностей.Настройка кластеров или сложных конфигураций (Databricks, Snowflake) — это трудоемкая задача, и команды по работе с данными предпочли бы сосредоточиться на реальных конвейерах и коде SQL. Многие инженеры не обладают необходимыми навыками, структурой поддержки или даже не знают, сколько стоит их работа. Выявление и решение коренных причин проблем также является сложной задачей, которая мешает просто обеспечить работоспособность конвейера.
  • Слишком много уровней абстракции.Давайте просто увеличим масштаб одного стека: Databricks запускает собственную версию Apache Spark, которая работает на виртуализированных вычислениях облачного провайдера (AWS, Azure, GCP) с различными сетевыми параметрами. , и разные варианты хранения (DBFS, S3, Blob), и кстати все можно обновлять самостоятельно и произвольно в течение года. Количество опций огромно, и пользователи платформы не могут гарантировать, что все актуально и оптимально.
  • Устаревший код.Одна из печальных реалий – это всего лишь устаревший код. Часто команды в компании меняются, люди приходят и уходят, и со временем знания о какой-то конкретной работе могут исчезнуть. Этот эффект еще больше затрудняет настройку или оптимизацию конкретной работы.
  • Перемены пугают. Существует врожденный страх перемен. Если производственная работа выполняется, хотим ли мы рисковать и вносить в нее изменения? На ум приходит старая поговорка: «Если что-то не сломано, не чини это». Часто этот страх реален: если работа не идемпотентна или есть другие побочные эффекты, неудачная работа может вызвать настоящую головную боль. Это создает психологический барьер даже для попыток улучшить производительность труда.
  • В масштабе слишком много рабочих мест. Обычно менеджеры платформ контролируют сотни, если не тысячи производственных рабочих мест. Будущий рост компании гарантирует, что это число будет только увеличиваться. Учитывая все вышеизложенное, даже если у вас есть местный эксперт, приходить и корректировать задания по одному просто нереально. Хотя это может сработать для нескольких избранных высокоприоритетных задач, большая часть рабочих нагрузок компании остается более или менее без внимания.

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

Что означает управление с обратной связью по замкнутому контуру для конвейера?

Сегодняшние конвейеры представляют собой так называемую систему «открытого цикла», в которой задания просто выполняются без какой-либо обратной связи. Чтобы проиллюстрировать то, о чем я говорю, на рисунке ниже показано, где «Задание 1» выполняется каждый день со стоимостью 50 долларов за запуск. Допустим, бизнес-цель состоит в том, чтобы эта работа стоила 30 долларов. Что ж, до тех пор, пока кто-нибудь действительно что-то не сделает, в обозримом будущем эта стоимость останется на уровне 50 долларов — как видно на графике зависимости стоимости от времени.

Что, если бы вместо этого у нас была система, которая фактически возвращала бы выходные статистические данные задания, чтобы можно было улучшить развертывание на следующий день? Это будет выглядеть примерно так:

Здесь вы видите классическую петлю обратной связи, где в данном случае желаемая заданная точка стоит 30 долларов. Поскольку это задание выполняется каждый день, мы можем получить обратную связь о реальной стоимости и отправить ее в блок обновления конфигурации, который учитывает разницу в стоимости (в данном случае 20 долларов США) и в результате применить изменение в Задании 1. конфигурации. Например, блок обновление конфигурации может уменьшить количество узлов в кластере Databricks.

Как это выглядит в производстве?

На самом деле это происходит не за один кадр. Модель «обновления конфигурации» теперь отвечает за настройку инфраструктуры, чтобы попытаться снизить стоимость до 30 долларов. Как вы можете себе представить, со временем система улучшится и в конечном итоге достигнет желаемой стоимости в 30 долларов, как показано на изображении ниже.

Все это может звучать хорошо и модно, но вы, возможно, почесываете затылок и спрашиваете: «Что это за волшебный блок «обновление конфигурации»?» Ну вот тут-то резина встречается с дорогой. Этот блок представляет собой математическую модель, которая может вводить числовую дельту цели и выводить конфигурацию инфраструктуры или, возможно, изменение кода.

Это непросто сделать, и это будет варьироваться в зависимости от цели (например, затраты, время выполнения или использование). Эта модель должна фундаментально предсказать влияние изменения инфраструктуры на бизнес-цели, а это непростая задача.

Никто не может предсказать будущее

Одна тонкая вещь заключается в том, что ни одна модель «обновления конфигурации» не является точной на 100%. В 4-й синей точке вы действительно можете видеть, что в какой-то момент стоимость возрастает. Это связано с тем, что модель пытается спрогнозировать изменения в конфигурациях, которые снизят затраты, но поскольку ничто не может предсказать со 100% точностью, иногда локально это будет неверно, и в результате стоимость может вырасти за один прогон. пока система «обучается».

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

Большое «ну и что?» — Ставьте любую цель и идите

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

Допустим, мы хотим, чтобы время выполнения задания составляло менее 1 часа (или SLA). Мы можем позволить вышеописанной системе настраивать конфигурации до тех пор, пока не будет достигнуто соглашение об уровне обслуживания. Или что, если это сложнее: цель по стоимости и соглашению об уровне обслуживания одновременно? Никаких проблем: система может оптимизироваться для достижения ваших целей по многим параметрам. Помимо стоимости и времени выполнения, другими целями бизнес-сценариев использования являются:

  • Использование ресурсов. Независимо от стоимости и времени выполнения, правильно ли я использую имеющиеся у меня ресурсы?
  • Энергоэффективность. Потребляю ли я минимально возможное количество ресурсов, чтобы минимизировать выбросы углекислого газа?
  • Отказоустойчивость. Действительно ли моя работа устойчива к сбоям? То есть хочу ли я переназначить его на случай, если меня вытеснят, или на случай, если доступных экземпляров SPOT не будет?
  • Масштабируемость. Масштабируется ли моя работа? Что, если у меня произойдет всплеск входных данных в 10 раз, моя работа рухнет?
  • Задержка. Соответствуют ли мои задания целевым показателям задержки? Цели по времени ответа?

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

До сих пор мы были довольно абстрактными. Давайте углубимся в некоторые конкретные варианты использования, которые, мы надеемся, будут интересны людям:

Пример функции 1. Группировка должностей по бизнес-целям

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

Что, если вы хотите масштабно снизить затраты? Что делать, если вы хотите изменить время выполнения (или SLA) многих заданий одновременно? Прямо сейчас вы бы застряли, умоляя инженеров помочь вам изменить все задания (удачи).

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

Здесь мы видим, что цвет каждого задания соответствует отдельной бизнес-цели, определенной в SLA. Система управления с обратной связью по замкнутому циклу незаметно меняла размер кластера/склада, различные конфигурации или даже настраивала целые конвейеры, чтобы попытаться достичь целей выполнения SLA с наименьшими затратами. Обычно более длительное время выполнения работ приводит к снижению затрат.

Пример функции 2. Автоматическое восстановление заданий

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

На рисунке ниже показана основная концепция. Давайте пройдемся по примеру слева направо:

  • Начало. Допустим, у вас есть работа, и со временем объем данных увеличивается. Обычно ваш кластер остается прежним, и в результате затраты и время выполнения увеличиваются.
  • Начать обратную связь. Со временем время выполнения приближается к требованию SLA, и система управления обратной связью срабатывает при появлении зеленой стрелки. На этом этапе система управления меняет кластер, чтобы он оставался ниже красной пунктирной линии, минимизируя при этом затраты.
  • Изменение кода. В какой-то момент разработчик вносит в код новое обновление, что приводит к резкому увеличению стоимости и времени выполнения. Система управления с обратной связью срабатывает и настраивает кластер для лучшей работы с новым изменением кода.

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

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

Заключение

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

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

В нашем следующем посте мы покажем реальную реализацию этой системы применительно к Databricks Jobs, чтобы вы могли поверить, что то, о чем мы говорим, реально!

Хотите узнать больше об элементах управления замкнутого цикла для конвейеров Databricks? Свяжитесь с Джеффом Чоу и остальными членами Команды Sync.

Связанный контент