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

Собственный обработчик выполнения для Fabric Spark

  • Статья

Собственный механизм выполнения — это улучшение выполнения заданий Apache Spark в Microsoft Fabric. Этот векторизованный механизм оптимизирует производительность и эффективность запросов Spark, выполняя их непосредственно в инфраструктуре Lakehouse. Простая интеграция подсистемы означает, что она не требует изменений кода и избегает блокировки поставщика. Он поддерживает API Apache Spark и совместим с средой выполнения 1.3 (Apache Spark 3.5) и работает с форматами Parquet и Delta. Независимо от расположения данных в OneLake или при доступе к данным через сочетания клавиш, собственный механизм выполнения повышает эффективность и производительность.

Собственный модуль выполнения значительно повышает производительность запросов при минимизации операционных затрат. Он обеспечивает замечательное повышение скорости, достигая до четырех раз быстрее производительности по сравнению с традиционными OSS (открытый код программным обеспечением) Spark, как проверено тестом TPC-DS 1TB. Подсистема работает над широким спектром сценариев обработки данных, начиная от обычных приемов данных, пакетных заданий и задач ETL (извлечение, преобразование, загрузка) для сложных аналитических данных и адаптивных интерактивных запросов. Пользователи получают преимущества от ускорения обработки, повышенной пропускной способности и оптимизированного использования ресурсов.

Модуль машинного выполнения основан на двух ключевых компонентах OSS: Velox, библиотеке ускорения баз данных C++, представленной Meta, и Apache Клейковина (инкубирование), средний уровень, отвечающий за разгрузку выполнения обработчиков SQL на основе JVM на собственных ядрах, представленных Intel.

Примечание.

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

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

Собственный механизм выполнения предлагает решение для выполнения запросов в крупномасштабных наборах данных; он оптимизирует производительность с помощью собственных возможностей базовых источников данных и минимизации затрат, связанных с перемещением данных и сериализацией в традиционных средах Spark. Подсистема поддерживает различные операторы и типы данных, включая хэш-агрегат свертки, присоединение к вложенным циклам широковещательной трансляции (BNLJ) и точные форматы меток времени. Тем не менее, чтобы полностью воспользоваться возможностями подсистемы, следует рассмотреть его оптимальные варианты использования:

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

Дополнительные сведения об операторах и функциях, поддерживаемых машинным обработчиком выполнения, см . в документации Apache Gluten.

Включение собственного обработчика выполнения

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

Внимание

Собственный модуль выполнения поддерживает последнюю версию среды выполнения ga, которая является средой выполнения 1.3 (Apache Spark 3.5, Delta Lake 3.2). С выпуском собственного модуля выполнения в среде выполнения 1.3 поддержка предыдущей версии — runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4) прекращена. Мы рекомендуем всем клиентам обновиться до последней версии среды выполнения 1.3. Обратите внимание, что если вы используете модуль машинного выполнения в среде выполнения 1.2, машинное ускорение скоро будет отключено.

Включение на уровне среды

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

  1. Перейдите к параметрам среды.

  2. Перейдите к вычислениям Spark.

  3. Перейдите на вкладку "Ускорение ".

  4. Установите флажок Enable native Execution Engine.

  5. Сохраните и опубликуйте изменения.

    Снимок экрана: включение собственного обработчика выполнения в элементе среды.

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

Внимание

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

В соответствии с политикой замораживания развертывания Microsoft Azure во время дня благодарения и черной пятницы мы перепланировали развертывание для региона Северной части США (NCUS) до 6 декабря и восточного региона США до 9 декабря. Мы ценим ваше понимание и терпение в течение этого напряженного времени.

Включение для определения заданий Записной книжки или Spark

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

%%configure 
{ 
   "conf": {
       "spark.native.enabled": "true", 
   } 
}

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

Внимание

Перед запуском сеанса Spark необходимо выполнить настройку собственного обработчика выполнения. После запуска spark.shuffle.manager сеанса Spark параметр становится неизменяемым и не может быть изменен. Убедитесь, что эти конфигурации задаются в %%configure блоке в записных книжках или в построителе сеансов Spark для определений заданий Spark.

Управление уровнем запроса

Механизмы включения собственного обработчика выполнения на уровнях клиента, рабочей области и среды, легко интегрированных с пользовательским интерфейсом, находятся в активной разработке. В то же время можно отключить собственный обработчик выполнения для конкретных запросов, особенно если они включают операторы, которые в настоящее время не поддерживаются (см . ограничения). Чтобы отключить, задайте для конфигурации Spark spark.native.enabled значение false для конкретной ячейки, содержащей запрос.

%%sql 
SET spark.native.enabled=FALSE;

Снимок экрана: отключение собственного обработчика выполнения в записной книжке.

После выполнения запроса, в котором отключен собственный обработчик выполнения, необходимо повторно включить его для последующих ячеек, задав spark.native.enabled значение true. Этот шаг необходим, так как Spark выполняет ячейки кода последовательно.

%%sql 
SET spark.native.enabled=TRUE;

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

Существует несколько методов, чтобы определить, был ли оператор в задании Apache Spark обработан с помощью собственного обработчика выполнения.

Пользовательский интерфейс Spark и сервер журнала Spark

Перейдите к серверу журнала Spark или пользовательского интерфейса Spark, чтобы найти нужный запрос. В плане запроса, отображаемом в интерфейсе, найдите все имена узлов, которые заканчиваются суффиксом Преобразователя, NativeFileScan или VeloxColumnarToRowExec. Суффикс указывает, что собственный обработчик выполнения выполнил операцию. Например, узлы могут быть помечены как RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinTransformer или BroadcastNestedLoopJoinExecTransformer.

Снимок экрана: проверка визуализации DAG, которая заканчивается суффиксом Преобразователя.

Объяснение кадра данных

Кроме того, можно выполнить df.explain() команду в записной книжке, чтобы просмотреть план выполнения. В выходных данных найдите те же суффиксы Преобразователя, NativeFileScan или VeloxColumnarToRowExec . Этот метод позволяет быстро проверить, обрабатываются ли определенные операции машинным обработчиком выполнения.

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

Резервный механизм

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

Снимок экрана: резервный механизм.

Снимок экрана: проверка журналов, связанных с резервным механизмом.

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

Чтобы лучше понять, как подсистема машинного выполнения применяется к sql-запросам и операциям DataFrame, а также для детализации до уровней этапов и операторов, можно обратиться к пользовательскому интерфейсу Spark и серверу журнала Spark для получения более подробных сведений о выполнении собственного модуля.

Вкладка "Подсистема собственного выполнения"

Чтобы просмотреть сведения о сборке и выполнении запросов, перейдите на новую вкладку "Клейковина SQL / Кадр данных". Таблица "Запросы" содержит аналитические сведения о количестве узлов, работающих в собственном обработчике, и тех, кто возвращается к JVM для каждого запроса.

Снимок экрана: вкладка собственного обработчика выполнения.

Граф выполнения запросов

Вы также можете щелкнуть описание запроса для визуализации плана выполнения запросов Apache Spark. Граф выполнения предоставляет собственные сведения о выполнении на этапах и их соответствующих операциях. Цвета фона отличают обработчики выполнения: зеленый представляет собственный обработчик выполнения, а светло-синий цвет указывает, что операция выполняется на подсистеме JVM по умолчанию.

Снимок экрана: граф выполнения запросов.

Ограничения

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

  • Некоторые операции, связанные с разностями, не поддерживаются (пока мы активно работаем над ним), включая операции слияния, проверки контрольных точек и векторы удаления.
  • Некоторые функции и выражения Spark несовместимы с собственным обработчиком выполнения, такими как определяемые пользователем функции (ОПРЕДЕЛЯЕМЫЕ пользователем функции) и array_contains функция, а также структурированная потоковая передача Spark. Использование этих несовместимых операций или функций в составе импортированной библиотеки также приведет к возврату к подсистеме Spark.
  • Сканирование из решений хранилища, использующих частные конечные точки, пока не поддерживается (пока мы активно работаем над ним).
  • Модуль не поддерживает режим ANSI, поэтому он выполняет поиск и после включения режима ANSI автоматически возвращается в vanilla Spark.

При использовании фильтров дат в запросах важно убедиться, что типы данных на обеих сторонах сравнения соответствуют, чтобы избежать проблем с производительностью. Несогласованные типы данных могут не привести к увеличению выполнения запросов и могут потребовать явного приведения. Всегда убедитесь, что типы данных левой стороны (LHS) и справа (RHS) сравнения идентичны, так как несовпаденные типы не всегда будут автоматически приведение. Если несоответствие типов неизменяемо, используйте явное приведение для сопоставления типов данных, например CAST(order_date AS DATE) = '2024-05-20'. Запросы с несовпаденными типами данных, требующими приведения, не будут ускорены машинным обработчиком выполнения, поэтому обеспечение согласованности типов имеет решающее значение для поддержания производительности. Например, вместо order_date = '2024-05-20' того order_date , где находится DATETIME и строка DATE, явно приведение order_date , чтобы DATE обеспечить согласованные типы данных и повысить производительность.

Просмотрите видео Fabric Espresso из группы инженеров продуктов о собственном обработчике выполнения

Связанный контент