Рекомендации по оптимизации затрат

В этой статье рассматриваются рекомендации, поддерживающие принципы оптимизации затрат, организованные по принципу.

1. Выбор оптимальных ресурсов

Использование оптимизированных для производительности форматов данных

Чтобы получить большую часть платформы аналитики данных Databricks, необходимо использовать Delta Lake в качестве платформы хранения. Он помогает создавать более простые и более надежные конвейеры ETL и обеспечивает множество улучшений производительности, которые могут значительно ускорить рабочие нагрузки по сравнению с использованием Parquet, ORC и JSON. См . рекомендации по оптимизации в Azure Databricks. Если рабочая нагрузка также выполняется на вычислительных ресурсах, это напрямую сокращает время их активного использования, что ведет к снижению затрат.

Использование вычислений заданий

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

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

Использование хранилища SQL для рабочих нагрузок SQL

Для интерактивных SQL нагрузок хранилище Databricks SQL является наиболее экономичным движком. Ознакомьтесь с общими сведениями о ценах. Все хранилища SQL по умолчанию включают Photon, что ускоряет ваши существующие вызовы API SQL и DataFrame и снижает общую стоимость на рабочую нагрузку.

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

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

Платформа Azure Databricks предоставляет различные среды выполнения, оптимизированные для задач проектирования данных (Databricks Runtime) или задач машинного обучения (Databricks Runtime для Машинное обучение). Среды выполнения создаются для обеспечения наилучшего выбора библиотек для задач и гарантии того, что все предоставленные библиотеки обновлены и работают вместе оптимально. Среда выполнения Databricks выпускается на регулярной основе, обеспечивая повышение производительности между основными релизами. Эти улучшения производительности часто приводят к экономии затрат из-за более эффективного использования вычислительных ресурсов.

Использовать только графические процессоры для правильных рабочих нагрузок

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

Большинство рабочих нагрузок не используют библиотеки с ускорением GPU, поэтому они не получают преимущества от экземпляров с поддержкой GPU. Администраторы рабочей области могут ограничить компьютеры GPU и вычислительные ресурсы, чтобы предотвратить ненужное использование. См. запись блога “Действительно ли GPU столь дороги? Тестирование графических процессоров для инференса в кластерах Databricks”.

Использование бессерверных служб для рабочих нагрузок

Варианты использования бизнес-аналитики

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

• Завершает неактивные вычислительные ресурсы для экономии затрат.
• Быстро предоставляет вычислительные ресурсы, когда пользователь запрашивает новые или обновленные данные с помощью средства бизнес-аналитики.

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

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

Обслуживание моделей машинного обучения и искусственного интеллекта

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

Mosaic AI Model Serving использует бессерверные вычисления и обеспечивает высокую доступность и низкую задержку для развертывания моделей. Служба автоматически масштабируется вверх или вниз, чтобы удовлетворить изменения спроса, уменьшая затраты на инфраструктуру при оптимизации производительности задержки.

Использование правильного типа экземпляра

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

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

• Память, оптимизированная для машинного обучения, а также для интенсивных процессов shuffle и spill
• Вычислительные ресурсы, оптимизированные для структурированных рабочих нагрузок потоковой передачи и заданий обслуживания (например, оптимизация и вакуум)
• Хранилище, оптимизированное для рабочих нагрузок, которые получают выгоду от кэширования, таких как разовый и интерактивный анализ данных.
• GPU оптимизирован для конкретных рабочих нагрузок машинного и глубинного обучения
• Общее назначение в отсутствие конкретных требований

Выбор наиболее эффективного размера вычислительных ресурсов

Azure Databricks запускает один исполнитель на каждый рабочий узел. Таким образом, в контексте архитектуры Azure Databricks термины "исполнитель" и "рабочая роль" взаимозаменяемы. Размер кластера часто оценивают количеством рабочих ролей, но есть и другие перечисленные ниже важные факторы, которые следует учитывать.

• Общее число ядер (вычислений) исполнителя: общее количество ядер по всем исполнителям. Это определяет максимальный параллелизм вычислительного экземпляра.
• Общая память исполнителей: общий объем ОЗУ по всем исполнителям. Это определяет объем данных, которые можно хранить в памяти, прежде чем сбрасывать их на диск.
• Локальное хранилище исполнителя: тип и объем локального дискового хранилища. Локальный диск в основном используется для обработки разливов во время перемешивания и кэширования данных.

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

• Какое количество данных потребуется вашей рабочей нагрузке?
• Какова вычислительная сложность рабочей нагрузки?
• Откуда вы считываете данные?
• Как данные секционированы во внешнем хранилище?
• Какая степень параллелизма вам необходима?

Подробные сведения и примеры можно найти в разделе "Рекомендации по размеру вычислений".

Оценка подсистем запросов, оптимизированных для производительности

Photon — это высокопроизводительный нативный для Databricks векторизованный механизм запросов, который ускоряет рабочие нагрузки SQL и вызовы API DataFrame (для потока данных, ETL, стриминга, науки о данных и интерактивных запросов). Photon совместим с API Apache Spark, поэтому начать работать проще простого — без изменений кода и без привязки.

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

2. Динамическое выделение ресурсов

Использование автоматического масштабирования вычислений

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

Автоматическое масштабирование вычислительных ресурсов имеет ограничения при уменьшении размера кластера для потоковых аналитических нагрузок. Databricks рекомендует использовать декларативные конвейеры Lakeflow Spark с расширенным автомасштабированием для потоковых рабочих нагрузок.

Используйте автоматическое завершение

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

• Настройте автоматическое завершение для всех интерактивных вычислительных ресурсов. После указанного времени простоя вычислительный ресурс завершает работу. См. раздел "Автоматическое завершение".
• В случаях использования, когда вычислительные ресурсы требуются только в рабочее время, вычислительные ресурсы можно настроить с автоматическим завершением, а запланированный процесс может перезапустить вычисления (и, возможно, предварительно подготовленные данные при необходимости) утром, прежде чем пользователи вернутся на рабочий стол. См. CACHE SELECT.
• Если время запуска вычислений слишком длинное, рассмотрите возможность использования пулов кластеров, ознакомьтесь с рекомендациями по пулу. Пулы Azure Databricks — это набор неактивных экземпляров, готовых к использованию. Когда узлы кластера создаются с использованием неиспользуемых экземпляров, уменьшается время на запуск кластера и автоматическое масштабирование. Если в пулах нет неактивных экземпляров, они расширяются путем выделения нового экземпляра от поставщика экземпляров для удовлетворения запроса кластера.

Azure Databricks не начисляет Databricks Units (DBUs) во время простоя экземпляров в пуле, что приводит к экономии средств. Применяется тарификация, предусмотренная поставщиком экземпляров.

Использование политик вычислений для управления затратами

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

• Включите автоматическое масштабирование кластера с установленным минимальным количеством рабочих узлов.
• Включите автоматическое завершение кластера с разумным значением (например, 1 час), чтобы избежать оплаты за время простоя.
• Убедитесь, что можно выбрать только экономичные экземпляры виртуальных машин. Следуйте рекомендациям по настройке кластера. Ознакомьтесь с рекомендациями по настройке вычислений.
• Примените стратегию использования точечных экземпляров.

3. Мониторинг затрат и управление затратами

Управление затратами в Databricks является критически важным аспектом оптимизации облачных расходов при сохранении производительности. Процесс можно разбить на три ключевые области:

• Настройка
• Контроль
• Управление

Следующие рекомендации охватывают эти три области.

Настройка тегов для присвоения затрат

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

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

Начните тегирование с самого начала использования Databricks. Помимо тегов по умолчанию, заданных Databricks, как минимум, настройте настраиваемые теги _Business Units_ и _Projects_ заполните их для конкретной организации. Если необходимо различать затраты на разработку, качество и рабочую среду, попробуйте добавить тег Environment в рабочие области и вычислительные ресурсы.

Теги распространяются как на журналы использования, так и на ресурсы поставщика облачных служб для анализа затрат. Общие затраты включают Единицы обработки данных (DBUs), а также расходы на виртуальные машины, диски и связанные с ними сетевые затраты. Обратите внимание, что для бессерверных служб стоимость DBU уже включает затраты на виртуальную машину.

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

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

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

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

Мониторинг затрат для выравнивания расходов с ожиданиями

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

• Мониторинг использования в консоли учетной записи: Databricks предлагает панели ИИ/BI для управления затратами в консоли учетной записи, которые администраторы могут импортировать в любую рабочую область с поддержкой каталога Unity в своей учетной записи. Это позволяет отслеживать использование либо учетной записи, либо одной рабочей области.

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

• Отслеживание и управление затратами на использование Delta Sharing: В отличие от других платформ общего доступа к данным, Delta Sharing не требует репликации данных. Эта модель имеет множество преимуществ, но это означает, что поставщик облачных служб может взимать плату за исходящий трафик при отправке данных между облаками или регионами. См. Мониторинг и управление затратами на исходящий трафик Delta Sharing (для поставщиков), чтобы отслеживать и управлять расходами на исходящий трафик.

• Мониторинг затрат с помощью системных таблиц: системная таблица system.billing.usage позволяет отслеживать затраты. Пользовательские теги, применяемые к рабочим областям и вычислительным ресурсам, распространяются в эту системную таблицу. Вы можете отслеживать затраты на бессерверные вычисления, затраты наработу и модели обслуживания.

• Мониторинг затрат с помощью Диспетчера затрат Azure. Анализ затрат — это средство для анализа затрат в Azure. Теги ресурсов Azure Databricks доступны в этом средстве для подробного анализа.

Управление затратами для выравнивания использования с потребностями организации

Управление затратами выходит за рамки технической реализации, чтобы включить более широкие организационные стратегии:

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

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

4. Разработка экономичных рабочих нагрузок

Баланс всегда включено и активируется потоковая передача

Традиционно, когда люди думают о потоковой передаче, на ум приходят такие термины, как "в режиме реального времени", "24/7" и "всегда включенный". Если прием данных происходит в режиме реального времени, основные вычислительные ресурсы должны работать 24/7, что приводит к затратам в каждый час.

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

Баланс между экземплярами по запросу и избыточной емкостью

Точечные экземпляры используют преимущества избыточных ресурсов виртуальной машины в облаке, доступных по более низкой цене. Чтобы сэкономить затраты, Azure Databricks поддерживает создание кластеров с помощью точечных экземпляров. Databricks рекомендует, чтобы первый экземпляр (драйвер Spark) всегда должен быть виртуальной машиной по запросу. Spot-экземпляры — это хороший выбор для рабочих нагрузок, где допустимо увеличение времени выполнения, так как один или несколько Spot-экземпляров были вытеснены поставщиком облачных услуг.