Поделиться через

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

  • Статья

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

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 рекомендует использовать DLT с улучшенным автомасштабированием для потоковых рабочих нагрузок.

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

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

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

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

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

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

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

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

Мониторинг затрат

Используйте Диспетчер затрат Azure для анализа затрат Azure Databricks. Теги области вычислений и рабочего пространства также передаются в Azure Cost Manager. Дополнительные сведения см. в разделе "Кластеры тегов" для определения стоимости.

Теги кластеров для атрибуции затрат

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

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

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

Теги ресурсов Azure Databricks можно использовать в средствах анализа затрат на портале Azure.

Внедрение систем наблюдаемости для отслеживания и распределения затрат.

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

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

Смотрите Блог: Интеллектуальное балансирование оптимизации затрат и надежности на Databricks

Регулярное предоставление общего доступа к отчетам о затратах

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

Мониторинг и управление затратами на исходящий трафик Delta Sharing

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

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

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

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

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

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

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