Родной движок выполнения для инженерии данных в Fabric

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

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

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

Когда следует использовать собственный исполнительный механизм

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

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

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

Включите собственный механизм выполнения

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

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

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

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

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

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

4. Установите флажок Включить нативный движок выполнения.

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

   

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

Включение для блокнота или определения задания Spark

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

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

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

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

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

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

%%pyspark
spark.conf.set('spark.native.enabled', 'false')   

%%spark  
spark.conf.set("spark.native.enabled", "false")   

%%sparkr
library(SparkR)
sparkR.conf("spark.native.enabled", "false")

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

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

%%pyspark
spark.conf.set('spark.native.enabled', 'true')   

%%spark  
spark.conf.set("spark.native.enabled", "true")   

%%sparkr
library(SparkR)
sparkR.conf("spark.native.enabled", "true")

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

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

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

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

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

Объяснение DataFrame

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

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

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

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

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

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

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

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

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

Ограничения

Хотя подсистема машинного выполнения (NEE) в Microsoft Fabric значительно повышает производительность заданий Apache Spark, в настоящее время она имеет следующие ограничения:

Существующие ограничения

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

• Неподдерживаемые форматы файлов: запросы к форматам JSON, XML, и CSV не ускоряются встроенной системой выполнения. Они по умолчанию возвращаются в обычный модуль JVM Spark для выполнения.

• Режим ANSI не поддерживается: подсистема машинного выполнения не поддерживает режим ANSI SQL. Если этот параметр включен, выполнение вернется к подсистеме Vanilla Spark.

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

  CAST(order_date AS DATE) = '2024-05-20'
  

Другие рекомендации и ограничения

• Несоответствие приведения типов из десятичного в число с плавающей точкой: При приведении из DECIMAL в FLOAT Spark сохраняет точность, преобразуя в строку и выполняя синтаксический анализ. NEE (через Velox) напрямую преобразует из внутреннего int128_t представления, что может привести к погрешностям в округлении.

• Ошибки конфигурации часового пояса : установка нераспознанного часового пояса в Spark приводит к сбою задания в NEE, в то время как JVM Spark обрабатывает его корректно. Рассмотрим пример.

  "spark.sql.session.timeZone": "-08:00"  // May cause failure under NEE
  

• Несогласованное округление:round() функция ведет себя по-разному в NEE из-за зависимости std::roundот компонента, который не воспроизводит логику округления Spark. Это может привести к числовым несоответствиям в результатах округления.

• Отсутствует проверка на дублирование ключей в функции map(): когда spark.sql.mapKeyDedupPolicy установлено значение EXCEPTION, Spark выдает ошибку для дублирующихся ключей. В настоящее время NEE пропускает эту проверку и позволяет запросу ошибочно завершаться успешно.
  Пример:

  SELECT map(1, 'a', 1, 'b'); -- Should fail, but returns {1: 'b'}
  

• Изменение порядка при collect_list() сортировке: при использовании DISTRIBUTE BY и SORT BY Spark сохраняет порядок элементов в collect_list(). NEE может возвращать значения в другом порядке из-за различий в перетасовке, что может привести к несоответствию ожидаемых значений для логики, чувствительной к порядку.

• Несоответствие промежуточного типа для collect_list() / collect_set(): Spark использует BINARY в качестве промежуточного типа для этих агрегаций, в то время как NEE использует ARRAY. Это несоответствие может привести к проблемам совместимости во время планирования или выполнения запросов.

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

• Среда выполнения Apache Spark в Fabric
• Что такое autotune для конфигураций Apache Spark в Fabric?