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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация наблюдаемости для отслеживания и оплаты расходов

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

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

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

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

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

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

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

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

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

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

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

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

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