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

Рекомендации по повышению эффективности производительности

  • Статья

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

1. Вертикальное масштабирование, горизонтальное масштабирование и линейная масштабируемость

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

  • Вертикальное масштабирование: вертикальное масштабирование путем добавления или удаления ресурсов с одного компьютера, обычно ЦП, памяти или GPU. Обычно это означает, что рабочая нагрузка останавливается, перемещается на более крупный компьютер и перезапускается. Существуют ограничения на вертикальное масштабирование: может быть не более большой компьютер, или цена следующего большего компьютера может быть запрещена.
  • Горизонтальное масштабирование: горизонтальное масштабирование путем добавления или удаления узлов из распределенной системы. При достижении ограничений вертикального масштабирования решение выполняется горизонтально: распределенные вычисления используют системы с несколькими компьютерами (называемыми кластерами) для выполнения рабочих нагрузок. Важно понимать, что для этого рабочие нагрузки должны быть подготовлены к параллельному выполнению, как поддерживается подсистемами платформы Databricks Data Intelligence, Apache Spark и Photon. Это позволяет объединить несколько недорогих компьютеров в более крупную вычислительную систему. Если требуется больше вычислительных ресурсов, горизонтальное масштабирование добавляет в кластер больше узлов и удаляет их, когда они больше не нужны. Хотя технически нет ограничений (и подсистема Spark выполняет сложную часть балансировки нагрузки), большое количество узлов увеличивает сложность управления.
  • Линейная масштабируемость, что означает, что при добавлении дополнительных ресурсов в систему связь между пропускной способностью и ресурсами используется линейная. Это возможно только в том случае, если параллельные задачи независимы. В противном случае промежуточные результаты для одного набора узлов потребуются для дальнейшего вычисления другого набора узлов в кластере. Обмен данными между узлами включает перенос результатов по сети из одного набора узлов в другой набор узлов, что занимает значительное время. В целом распределенные вычисления имеют некоторые затраты на управление распределением и обменом данными. В результате небольшие рабочие нагрузки набора данных, которые можно проанализировать на одном узле, могут быть еще медленнее при запуске в распределенной системе. Платформа аналитики данных Databricks предоставляет гибкие вычисления (один узел и распределенный) для удовлетворения уникальных потребностей рабочих нагрузок.

2. Использование бессерверных архитектур

Использование бессерверных вычислений

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

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

Databricks предоставляет управляемые службы для различных рабочих нагрузок:

  • Бессерверные хранилища SQL для рабочих нагрузок SQL

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

  • Бессерверные задания для эффективных и надежных рабочих процессов

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

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

  • Бессерверные вычисления для записных книжек

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

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

Служба модели ИИ Мозаики предоставляет единый интерфейс для развертывания, управления и запроса моделей ИИ. Каждая модель, которую вы обслуживаете, доступна в качестве REST API, которую можно интегрировать в веб-приложение или клиентское приложение.

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

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

Общие сведения о приеме данных и шаблонах доступа

С точки зрения производительности шаблоны доступа к данным , такие как "агрегаты и точка доступа" или "сканирование и поиск", ведут себя по-разному в зависимости от размера данных. Большие файлы более эффективны для запросов сканирования, а небольшие файлы лучше подходят для поиска, так как требуется читать меньше данных, чтобы найти определенные строки.

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

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

Использование параллельных вычислений, где это полезно

Значение времени является важным измерением при работе с данными. Хотя многие варианты использования можно легко реализовать на одном компьютере (небольшие данные, немногие и простые вычислительные шаги), часто используются варианты обработки больших наборов данных, длительное время выполнения из-за сложных алгоритмов или повторения 100-х и 1000-х раз.

Кластерная среда платформы Databricks — это отличная среда для эффективного распределения этих рабочих нагрузок. Он автоматически параллелизирует запросы SQL на всех узлах кластера и предоставляет библиотеки для Python и Scala , чтобы сделать то же самое. Под капотом подсистемы Apache Spark и Photon анализируют запросы, определяют оптимальный способ параллельного выполнения и управляют распределенным выполнением устойчивым способом.

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

Одним из самых простых способов использования параллельных вычислений является Delta Live Tables. Вы объявляете задачи и зависимости задания в SQL или Python, а затем Delta Live Tables обрабатывает планирование выполнения, эффективную настройку инфраструктуры, выполнение заданий и мониторинг.

Для специалистов по обработке и анализу данных pandas — это пакет Python, который предоставляет удобные структуры данных и средства анализа данных для языка программирования Python. Однако Pandas не масштабируется до больших данных. API Pandas в Spark заполняет этот пробел, предоставляя эквивалентные API pandas, которые работают в Apache Spark.

Кроме того, платформа поставляется с параллельными алгоритмами машинного обучения в стандартной библиотеке машинного обучения MLlib. Он поддерживает использование многофакторной поддержки нескольких GPU. Глубокое обучение также можно параллелизировать с помощью распространителя DeepSpeed или TorchDistributor.

Анализ всей цепочки выполнения

Большинство конвейеров или шаблонов потребления включают цепочку систем. Например, при использовании средств бизнес-аналитики производительность влияет на несколько факторов:

  • Сам инструмент бизнес-аналитики.
  • Соединитель, который подключает средство бизнес-аналитики и подсистему SQL.
  • Обработчик SQL, в который средство бизнес-аналитики отправляет запрос.

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

Предпочитать более крупные кластеры

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

Примечание.

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

Использование собственных операций Spark

Определяемые пользователем функции (ОПРЕДЕЛЯЕМЫЕ пользователем функции) — отличный способ расширить функциональные возможности Spark SQL. Однако не используйте определяемые пользователем функции Python или Scala, если существует собственная функция:

Причины.

  • Сериализация необходима для передачи данных между Python и Spark. Это значительно замедляет запросы.
  • Увеличение усилий по реализации и тестированию функциональных возможностей, которые уже существуют на платформе.

Если собственные функции отсутствуют и должны быть реализованы как определяемые пользователем Python, используйте пользовательские функции Pandas. Apache Arrow обеспечивает эффективное перемещение данных между Spark и Python.

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

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

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

Общие сведения о типе оборудования и рабочей нагрузки

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

Примечание.

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

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

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

В Azure Databricks доступно несколько типов кэширования. Ниже приведены характеристики каждого типа:

  • Использование кэша дисков

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

  • Избегайте кэширования Spark

    Кэш Spark (с помощью .persist() и.unpersist()) может хранить результат любых вложенных запросов и данных, хранящихся в форматах, отличных от Parquet (например, CSV, JSON и ORC). Однако, если используется в неправильных расположениях в запросе, он может использовать всю память и даже значительно замедлить запросы. Как правило, избегайте кэширования Spark, если вы точно не знаете, какое влияние будет.

  • Кэш результатов запроса

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

  • Кэширование пользовательского интерфейса Databricks SQL

    Кэширование всех запросов и устаревших панелей мониторинга на пользователя приводит к выполнению пользовательского интерфейса SQL Databricks.

Использование сжатия

Delta Lake в Azure Databricks может повысить скорость чтения запросов из таблицы. Одним из способов является объединение небольших файлов в более крупные. Вы активируете сжатие, выполнив команду OPTIMIZE. См. раздел Оптимизация макета файла данных.

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

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

Дополнительные сведения см. в разделе "Настройка Delta Lake" для управления размером файла данных.

Использование пропуска данных

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

Для достижения этого информация о пропуске данных автоматически собирается при записи данных в таблицу Delta (по умолчанию Delta Lake в Azure Databricks собирает статистику по первым 32 столбцам, определённым в схеме вашей таблицы). Delta Lake в Azure Databricks использует эти сведения (минимальные и максимальные значения) во время запроса для ускорения запросов. См . сведения о пропусках данных для Delta Lake.

Для пропуска данных можно применить следующие методы:

  • Z-упорядочивание — это метод размещения связанных сведений в одном наборе файлов. Эта совместное расположение автоматически используется в Azure Databricks алгоритмами пропуска данных Delta Lake. Это поведение значительно сокращает объем данных Delta Lake для чтения.

  • кластеризация "Liquid" упрощает решения относительно структуры данных и оптимизирует производительность запросов. Он заменит секционирование и z-упорядочение с течением времени. Databricks рекомендует кластеризацию жидкости для всех новых разностных таблиц. Кластеризация, позволяющая динамически изменять, предоставляет гибкость для переопределения ключей кластеризации без перезаписи существующих данных, что позволяет макетам данных эволюционировать в соответствии с аналитическими потребностями с течением времени. Databricks рекомендует кластеризацию жидкости для всех новых разностных таблиц.

    Таблицы со следующими характеристиками выигрывают от гибкой кластеризации:

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

Дополнительные сведения и методы см. в комплексном руководстве по оптимизации рабочих нагрузок Databricks, Spark и Delta Lake.

Включение прогнозной оптимизации для Delta Lake

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

Избегайте избыточного секционирования

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

Databricks рекомендует не разделять таблицы размером меньше 1 ТБ и разделять их только по столбцу, если предполагается, что данные в каждом разделе будут не менее 1 ГБ.

В то же время лучшее решение, чем секционирование— Z-упорядочение или более новая кластеризация Liquid (см. выше).

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

  • Рассмотрите возможность оптимизации соединения диапазона .

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

  • Используйте адаптивное выполнение запросов.

    Адаптивное выполнение запросов (AQE) — это переоптимизация запросов, которая применяется во время выполнения запроса. Они состоят из 4 основных функций:

    • Динамически изменяет объединение слиянием в широковещательное хэш-соединение.
    • Динамически объединяет секции после перетасовки обмена.
    • Динамически обрабатывает отклонение при соединении сортировочным слиянием и перетасовке при хэш-соединении.
    • Динамическое обнаружение и распространение пустых отношений.

    Рекомендуется включить AQE. Различные функции можно настроить отдельно.

Дополнительные сведения см. в комплексном руководстве по оптимизации нагрузок для Databricks, Spark и Delta Lake .

Выполните команду analyze table для сбора статистики таблицы

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

Предиктивная оптимизация автоматически запускает ANALYZE (общедоступная предварительная версия) в качестве команды для сбора статистики в управляемых таблицах каталога Unity. Databricks рекомендует включить прогнозную оптимизацию для всех управляемых таблиц каталога Unity, чтобы упростить обслуживание данных и сократить затраты на хранение. См. прогнозную оптимизацию для управляемых таблиц каталога Unity.

4. Запуск тестирования производительности в области разработки

Тестирование на основе репрезентативного данных рабочей среды

Выполните тестирование производительности для рабочих данных (только для чтения) или аналогичных данных. При использовании аналогичных данных такие характеристики, как том, макет файла и отклонение данных, должны быть похожи на рабочие данные, так как это оказывает значительное влияние на производительность.

Рассмотрите возможность предварительного потепления ресурсов

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

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

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

Определение узких мест

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

5. Мониторинг производительности

Мониторинг производительности запросов

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

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

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

Мониторинг рабочих нагрузок потоковой передачи

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

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

Мониторинг производительности задания

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