Оптимизация затрат Databricks для рабочих нагрузок

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

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

Порядок действий имеет значение. Сначала получите данные о затратах, которым можно доверять, запретите заведомо расточительные конфигурации, отделите интерактивную работу от плановых производственных заданий, проверьте Photon на полных запусках и используйте spot-ресурсы только там, где допустимы прерывания. SQL далее в статье позволяет регулярно находить владельцев, SKU, пустые интервалы обслуживания и дорогие запросы, не притворяясь, будто каждая системная таблица обеспечивает идеальную атрибуцию.

Сначала измерьте стоимость результата

Базовая оценка должна объединять расход Databricks, облачный счет и результат рабочей нагрузки. system.billing.usage хранит DBU и другие оплачиваемые единицы, а system.billing.list_prices содержит исторические прейскурантные цены Databricks. Ни в одной из таблиц нет стоимости виртуальных машин, дисков, сети и облачных сервисов из аккаунта вашего провайдера. Если оптимизировать только строку Databricks, вы видите половину машины.

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

• Владелец и центр затрат из обязательных тегов, а не из имени кластера
• Успешные запуски и бизнес-результат, например обновленные разделы или обслуженные отчеты
• Прейскурантная стоимость Databricks, договорная стоимость, если ее предоставят финансисты, и стоимость облачной инфраструктуры
• Процентили времени выполнения, число сбоев и стоимость повторов
• Целевой уровень сервиса, который ограничивает уменьшение ресурсов и применение spot-узлов

Прейскурантная цена удобна для сравнения, даже если договор дает скидки. Не выдавайте ее за сумму счета. Финансистам стоит отдельно сопоставить фактические договорные ставки, а экспорт облачных затрат должен распределять расходы на виртуальные машины и хранилище по тем же тегам рабочей области, среды, владельца и нагрузки. Если у нагрузки нет этих тегов, пометьте затраты как нераспределенные, а не делите их поровну. Равное распределение поощряет команду, которая не отметила свои вычисления.

Выберите знаменатель, который команда не сможет улучшить, сократив полезную работу. Стоимость часа стимулирует уменьшать окно доступности, но ничего не говорит о результате. Стоимость успешного запуска подходит при стабильном размере пакета; стоимость обработки терабайта лучше при меняющемся объеме входных данных; стоимость часа обслуживания дашборда подходит общему SQL warehouse. Держите рядом с ценой задержку и долю сбоев, чтобы никто не мог объявить экономией нарушение целевого уровня сервиса.

Первый отчет должен разделять универсальные вычисления, вычисления заданий, SQL warehouses, конвейеры и serverless-продукты по billing_origin_product и sku_name. Такое разделение обнаруживает архитектурные решения. Плановый notebook на универсальном кластере не требует настройки Spark. Нагрузку поместили не туда, из-за чего команда платит предсказуемую надбавку и плохо контролирует остановку.

Политики кластеров должны делать дешевый путь обычным

Политика кластера контролирует стоимость только тогда, когда ограничивает дорогие варианты. Политика из необязательных значений по умолчанию остается советом, который исчезает, как только кто-то копирует старый кластер. Правила политик Databricks могут фиксировать, разрешать, запрещать или ограничивать параметры вычислений, включая autotermination_minutes, autoscale.max_workers, runtime_engine, cluster_type, облачные настройки доступности и виртуальный атрибут dbus_per_hour. Параметры, которых нет в политике, остаются без ограничений.

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

Этот пример для AWS намеренно строгий. Замените типы узлов, предел DBU и словарь тегов значениями, проверенными в вашем аккаунте:

{
  "cluster_type": {"type": "fixed", "value": "job"},
  "autotermination_minutes": {"type": "fixed", "value": 15, "hidden": true},
  "autoscale.min_workers": {"type": "fixed", "value": 1, "hidden": true},
  "autoscale.max_workers": {"type": "range", "minValue": 1, "maxValue": 12, "defaultValue": 4},
  "runtime_engine": {"type": "allowlist", "values": ["PHOTON", "STANDARD"], "defaultValue": "PHOTON"},
  "dbus_per_hour": {"type": "range", "maxValue": 40},
  "aws_attributes.availability": {"type": "fixed", "value": "SPOT_WITH_FALLBACK"},
  "aws_attributes.first_on_demand": {"type": "fixed", "value": 1},
  "custom_tags.owner": {"type": "unlimited", "isOptional": false},
  "custom_tags.cost_center": {"type": "unlimited", "isOptional": false},
  "custom_tags.environment": {"type": "allowlist", "values": ["dev", "stage", "prod"]}
}

Политика оставляет драйвер на on-demand-ресурсе с помощью first_on_demand со значением 1, а рабочим узлам разрешает spot с резервным переходом. Она не доказывает, что двенадцать рабочих узлов или Photon экономически выгодны. Она ограничивает возможный ущерб и сохраняет возможность контролируемого теста. Azure и Google Cloud используют другие атрибуты провайдера, поэтому переносите замысел, а не имена полей AWS.

При развертывании политики есть неудобная граница: изменение определения не исправляет автоматически каждый работающий кластер и каждое задание, которое ссылается на другое определение. Соберите ID политик активных вычислений, завершите или измените несоответствующие интерактивные кластеры и обновите кластеры заданий через код развертывания. Затем уберите право создавать вычисления без ограничений. Дашборд, который находит нарушения, но оставляет путь создания открытым, только документирует завтрашние потери.

Photon должен доказать выгоду в контролируемом сравнении

Photon должен побеждать по полной стоимости запуска, а не на скриншоте одного ускорившегося этапа. Для поддерживаемых операций Spark SQL он заменяет исполнение собственным векторизованным движком, при этом Catalyst по-прежнему строит план запроса. Неподдерживаемые операции могут вернуться к стандартной среде Spark. UDF на Python и Scala, работа с RDD, Dataset API и потоковая обработка с состоянием могут ограничить или убрать выгоду, поэтому включение Photon в конвейере с множеством UDF способно повысить ставку DBU, не сократив дорогую часть.

Проведите сравнение A/B на одном снимке входных данных, одинаковой форме кластера, семействе среды выполнения, состоянии кеша и проверке результата. Выполните как минимум несколько репрезентативных запусков после того, как перестанут влиять стартовые эффекты. Запишите полное время, DBU, часы облачных инстансов, прочитанные байты, shuffle, сброс на диск, количество выходных строк и сбои. Рассчитайте обе составляющие:

Databricks cost = DBUs consumed * effective DBU price
Cloud cost      = instance hours * effective instance price + attached services
Run cost        = Databricks cost + cloud cost
Unit cost       = Run cost / successful business units produced

Допустим, стандартный движок расходует 18 DBU за 24 минуты, а Photon расходует 15 DBU за 11 минут. Результат обнадеживает, но решение все еще зависит от ставки SKU и времени жизни виртуальных машин. Если кластер задания столько же долго инициализируется или задача ждет внешний API, более короткий этап SQL может почти не повлиять на полную стоимость. И наоборот, более высокая ставка DBU все равно может дать более дешевый запуск, если кластер завершится гораздо раньше.

Изучите представление SQL/DataFrame в Spark UI для классических вычислений и профиль запроса в SQL warehouses. Операторы Photon визуально отличаются от стандартных, поэтому можно найти границы возврата к обычному исполнению. Не переписывайте все приложение из-за одного такого оператора. Сначала займитесь частью с наибольшим временем задач, объемом чтения, shuffle или сбросом на диск. Замена построчного UDF встроенными выражениями SQL часто улучшает переносимость и позволяет Photon обработать большую часть плана.

SQL warehouses уже используют Photon. Для интерактивного SQL сравнивайте serverless, pro и classic warehouse с учетом сетевых требований и характера спроса, а не пытайтесь отключить движок. Serverless там, где он доступен, быстрее запускается и управляет нагрузкой, но для его счета все равно нужны окно обслуживания и знаменатель конкуренции запросов. Warehouse может быстро отвечать, оставаться включенным в пустые часы и все равно обходиться дорого.

За spot-узлами должен стоять план восстановления

Spot-ресурсы подходят повторяемым распределенным рабочим узлам; они плохо подходят по умолчанию для хрупкого драйвера или задания с жестким сроком завершения. В AWS режим SPOT_WITH_FALLBACK может получить on-demand-инстансы, когда spot-ресурсы недоступны, а first_on_demand: 1 оставляет драйвер на on-demand-ресурсе. Такой шаблон убирает распространенную единственную точку прерывания и сохраняет экономию на рабочих узлах. Spot VM в Azure и Google Cloud ведут себя при вытеснении иначе и используют другие поля политик, но принцип размещения не меняется.

Классифицируйте задания до изменения доступности. Хороший кандидат для spot читает долговечные входные данные, идемпотентно пишет в Delta-таблицы, сохраняет контрольные точки долгой работы, допускает потерю рабочего узла и имеет запас в расписании для повтора. Плохой кандидат хранит необходимое состояние только в памяти, пишет во внешнюю систему без идемпотентности, выполняет одну огромную задачу на одном executor или обязан закончить за несколько минут до срока для клиента.

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

• Доля spot в часах рабочих узлов и доля резервного перехода
• Вытеснения, неудачные запуски и автоматические повторы
• Дополнительное время и повторные вычисления после потери узла
• Чистая экономия облачных расходов после стоимости повторов
• Нарушенные сроки завершения

Популярный совет предлагает перевести все рабочие узлы на spot и доверить ситуацию автомасштабированию. Он нравится тем, что скидка видна до измерения сбоев. Совет не работает, когда автомасштабирование запрашивает дефицитное семейство инстансов, резервный переход незаметно повышает долю on-demand или повторные вытеснения превращают долгий shuffle в оплачиваемый повтор вычислений. Разрешите два или три проверенных семейства рабочих узлов там, где поддерживаются гибкие типы, и настройте оповещения по доле резервного перехода и повторов.

Разделяйте стратегии для production и разработки. Разработка может терпеть меньшие кластеры, более быстрое завершение и больше прерываний. Для production часто нужен on-demand-драйвер, минимальный объем стабильных ресурсов и spot-узлы сверх этого минимума. Теоретически самый дешевый кластер бесполезен, если инженер вручную перезапускает его три раза.

Отделите плановые задания от ожидания людей

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

Автомасштабирование не исправляет завышенный минимум. Кластер с диапазоном от 8 до 40 рабочих узлов оплачивает как минимум восемь, даже когда нагрузку выдержат два. Определите минимум по наблюдаемой постоянной работе, затем ограничьте максимум результатами тестов конкуренции и памяти. Проверяйте задержку масштабирования, а не только пиковый размер. Задание, которое заканчивается раньше, чем новые узлы начинают приносить пользу, платит за широкий диапазон, которым не пользуется.

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

Для SQL warehouses настройте auto-stop под реальный характер запросов. Пятиминутные интервалы между обновлениями дашборда не оправдывают постоянные остановки и запуски, если от старта страдают пользователи, а warehouse без ночных запросов не должен работать всю ночь по привычке. Сравните моменты поступления запросов с событиями warehouse. Если он работает десять часов, но получает запросы в двух коротких окнах, настройте расписание или auto-stop вокруг этих окон и проверьте, что обновления дашборда по-прежнему укладываются в целевой срок.

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

Запросы к биллингу должны находить владельцев и исправления

Первый запрос по затратам должен сверять использование по владельцу, SKU и идентификатору рабочей нагрузки. Системные записи биллинга могут содержать строки ORIGINAL, RETRACTION и RESTATEMENT. Суммируйте usage_quantity; не считайте строки и не отбрасывайте отрицательные исправления. Запрос ниже присоединяет к каждой записи использования цену, действовавшую на момент ее окончания, и выводит прейскурантную стоимость. Нераспределенные затраты остаются видимыми.

WITH priced_usage AS (
  SELECT
    u.workspace_id,
    u.usage_date,
    u.sku_name,
    u.billing_origin_product,
    u.usage_metadata.cluster_id AS cluster_id,
    u.usage_metadata.job_id AS job_id,
    u.usage_metadata.warehouse_id AS warehouse_id,
    u.identity_metadata.run_as AS run_as,
    u.custom_tags['owner'] AS owner_tag,
    u.usage_quantity,
    u.usage_quantity * p.pricing.effective_list.default AS list_cost
  FROM system.billing.usage u
  LEFT JOIN system.billing.list_prices p
    ON u.cloud = p.cloud
   AND u.sku_name = p.sku_name
   AND u.usage_start_time >= p.price_start_time
   AND (u.usage_end_time < p.price_end_time OR p.price_end_time IS NULL)
  WHERE u.usage_date >= date_sub(current_date(), 30)
)
SELECT
  coalesce(owner_tag, run_as, 'UNALLOCATED') AS owner,
  billing_origin_product,
  sku_name,
  coalesce(job_id, warehouse_id, cluster_id, 'NO_RESOURCE_ID') AS resource_id,
  round(sum(usage_quantity), 2) AS usage_units,
  round(sum(list_cost), 2) AS databricks_list_cost
FROM priced_usage
GROUP BY ALL
HAVING abs(sum(usage_quantity)) > 0
ORDER BY databricks_list_cost DESC;

Ожидайте вывод вида owner | billing_origin_product | sku_name | resource_id | usage_units | databricks_list_cost. Если ваша среда SQL не приводит pricing.effective_list.default к нужному типу, сделайте это явно. Соединение с ценой учитывает время, потому что применение текущей цены к старому использованию переписывает историю. Договорные скидки и стоимость облачных виртуальных машин по-прежнему не входят в результат.

Теги могут отсутствовать или вводить в заблуждение, поэтому используйте системные метаданные как второй путь атрибуции. identity_metadata.run_as определяет учетную запись запуска для вычислений заданий, а биллинг SQL warehouse может содержать данные о владельце. Для классических универсальных кластеров и кластеров заданий присоедините usage_metadata.cluster_id к региональной истории system.compute.clusters и выберите версию конфигурации, чей change_time действовал в момент использования. Простое соединение по ID кластера может размножить записи при каждом изменении конфигурации.

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

История запросов находит потери, которые не называет биллинг

system.query.history дает сведения об исполнении запросов для SQL warehouses и поддерживаемых serverless-нагрузок, но не назначает точную сумму счета каждому выражению. Ресурсы warehouse делят параллельные запросы, запуск, простой и события масштабирования. Считайте распределение долларов по запросам оценкой, если вы не определили и не задокументировали метод. Сначала используйте историю запросов, чтобы расставить инженерные задачи по времени задач, прочитанным байтам, ожиданию в очереди и повторным исполнениям.

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

SELECT
  sha2(statement_text, 256) AS query_hash,
  any_value(left(regexp_replace(statement_text, '\s+', ' '), 180)) AS sample_sql,
  count(*) AS executions,
  round(sum(total_task_duration_ms) / 3600000.0, 2) AS task_hours,
  round(sum(execution_duration_ms) / 3600000.0, 2) AS wall_hours,
  round(sum(waiting_at_capacity_duration_ms) / 60000.0, 1) AS queued_minutes,
  round(sum(read_bytes) / pow(1024, 4), 3) AS tebibytes_read,
  sum(read_rows) AS rows_read,
  sum(produced_rows) AS rows_returned
FROM system.query.history
WHERE start_time >= date_sub(current_timestamp(), 14)
  AND execution_status = 'FINISHED'
GROUP BY query_hash
ORDER BY task_hours DESC
LIMIT 50;

Один запуск с большим чтением может быть оправдан. Запрос дашборда, который сотни раз читает одни и те же холодные данные, обычно дает лучшую цель, потому что исправление экономит деньги ежедневно. Сравните read_files и pruned_files, изучите столбцы фильтрации и проверьте, поддерживает ли структура таблицы реально используемые предикаты. Огромное отношение rows_read к rows_returned дает повод для проверки, но ничего не доказывает: агрегирование может обоснованно прочитать много строк и вернуть одну.

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

Чтобы найти пустые интервалы обслуживания, сопоставьте время поступления запросов с system.compute.warehouse_events. Рассчитайте минуты работы до первого запроса, интервалы между группами запросов и минуты после последнего. Затем сравните простой с настройками auto-stop и поведением запуска warehouse. Не относите весь простой к первому запросу или владельцу warehouse, не заявив об этом. Общим ресурсам нужно явное правило, например распределение по времени задач и отдельная категория нераспределенного простоя.

Проверьте одно изменение на всем счете нагрузки

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

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

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

Меняйте по одной переменной. Сначала перенесите драйвер на on-demand, а рабочие узлы на spot, либо сначала включите Photon, либо сначала измените форму рабочих узлов. Если поменять все три параметра и запуск станет дешевле, но менее надежным, вы не узнаете причину ни одного результата. Повторите кандидат на обычном объеме, в тяжелый день и как минимум в одном тесте сбоя или прерывания. Сравнивайте медианы обычной стоимости и дорогой хвост для планирования ресурсов.

Ведите простую запись решения для каждого кандидата. Запишите успешные запуски, медианную стоимость запуска, стоимость медленного запуска, медианную длительность, повторы и прохождение проверки результата. Поместите исходный вариант, вариант Photon и вариант со spot-узлами в отдельные строки журнала экспериментов.

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

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

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

Экономия сохраняется, только если кто-то отвечает за откат

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

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

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

В oleg.is я использую Team & AI Audit, чтобы связать инфраструктурные потери с породившим их инженерным процессом; фиксированная работа стоит $5,000, занимает пять рабочих дней и должна найти экономию не менее $50,000 в год, иначе проводится бесплатно. Это предложение полезно, когда внутри компании никто не отвечает за межкомандное расследование, но для применения правил из этой статьи внешний консультант не нужен.

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