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

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

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

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

Поддерживаемые операторы перенаправляются из Spark на основе JVM на векторизированный путь выполнения C++, обеспечивая обработку с использованием columnar и ускоренное обработка с помощью SIMD, с собственной поддержкой форматов Parquet и Delta. Нативный механизм сохраняет ключевые оптимизации запросов Fabric Spark, включая адаптивное выполнение запросов (AQE), переписывание на основе затрат, обрезку столбцов и оптимизацию предиката, поэтому эти оптимизаторы остаются полностью активными при разгрузке операторов. Движок также поддерживает параллельную загрузку моментальных снимков Delta и ускоряет операции, которые получают преимущества от Z-упорядочения и кластеризации Liquid в таблицах Delta, что обеспечивает дополнительный прирост производительности для упорядоченных макетов данных.

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

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

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

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

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

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

Внимание

Собственный обработчик выполнения поддерживает среду выполнения 1.3 (Apache Spark 3.5, Delta Lake 3.2) и Runtime 2.0 (Apache Spark 4.1, Delta Lake 4.1)).

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

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

  1. Перейдите в рабочую область, содержащую среду, и выберите среду. Если у вас нет созданной среды, см. статью Создать, настроить и использовать среду в Fabric.

  2. В разделе вычислений Spark выберите "Ускорение".

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

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

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

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

Внимание

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

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

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

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

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

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

Механизмы для включения Native Execution Engine на уровнях арендатора, рабочей области и среды, бесшовно интегрированные с пользовательским интерфейсом, находятся в активной разработке. В то же время можно отключить собственный обработчик выполнения для конкретных запросов, особенно если они включают операторы, которые в настоящее время не поддерживаются (см . ограничения). Чтобы отключить, задайте для конфигурации 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, чтобы найти запрос, который вам нужно проверить. Чтобы получить доступ к веб-интерфейсу Spark, перейдите к определению задания Spark и запустите его. На вкладке Запуски выберите ... рядом с именем приложения и выберите Открыть веб-интерфейс Spark. Вы также можете получить доступ к пользовательскому интерфейсу Spark на вкладке монитора в рабочей области. Выберите записную книжку или конвейер на странице мониторинга - это обеспечивает прямую ссылку на интерфейс Spark для активных заданий.

снимок экрана, показывающий, как перейти к веб-интерфейсу Spark.

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

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

Объяснение DataFrame

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

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

Оповещения советника Fabric Spark

Помощник Fabric Spark обеспечивает видимость аварийного переключения в режиме реального времени во время выполнения ячеек блокнота. Когда оператор или сегмент плана возвращается к Spark, работающему на основе JVM, вместо использования собственного пути, Advisor показывает оповещение непосредственно в выходных данных ячейки записной книжки, что помогает быстро определять неподдерживаемые операторы или конфигурации, не покидая записную книжку. Эти оповещения можно использовать для диагностики ситуации, когда не применяется native offload, и принятия решения о корректировке запроса или конфигурации.

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

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

Снимок экрана, показывающий резервный механизм.

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

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

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

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

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

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

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

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

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

Ограничения

Хотя нативный движок исполнения (NEE) в Fabric значительно повышает производительность для задач Apache Spark, в настоящее время у него есть следующие ограничения. Несколько элементов, связанных с корректностью, применявшихся к Runtime 1.3 (Apache Spark 3.5), разрешены в Runtime 2.0 (Apache Spark 4.1); Каждый элемент указывает время выполнения, к которому он применяется.

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

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

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

  • Режим ANSI (только для Runtime 1.3): В Runtime 1.3 (Apache Spark 3.5) нативный движок выполнения не поддерживает режим ANSI SQL. Если включить режим ANSI SQL, выполнение возвращается к стандартному движку Spark. В Runtime 2.0 (Apache Spark 4.1) поддерживается режим ANSI SQL: операторы переносятся на нативный движок, а семантика ошибок ANSI (например, деление на ноль и некорректные касты) выполняется согласованно с JVM Spark.

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

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

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

Note

Десятичная трансляция, часовой поясround(), дубликат ключа иcollect_set()/collect_list() элементы в этом разделе применимы к Runtime 1.3 (Apache Spark 3.5) и разрешаются в Runtime 2.0 (Apache Spark 4.1).map() Они сохраняются для пользователей, которые всё ещё работают на Runtime 1.3.

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

  • Ошибки настройки часового пояса (Runtime 1.3; решено в Runtime 2.0): В Runtime 1.3 установка нераспознанного часового пояса в Spark приводит к неудаче задания в NEE, тогда как Spark JVM справляется с этим без проблем. Рассмотрим пример.

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

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

  • Функция проверки map() дубликатов ключа (Runtime 1.3; решено в Runtime 2.0): При spark.sql.mapKeyDedupPolicy установке EXCEPTION Spark выдаёт ошибку для дублирующих ключей. В Runtime 1.3 NEE пропускает эту проверку и позволяет запросу выполняться некорректно. В Runtime 2.0 NEE стабильно повышает DUPLICATED_MAP_KEY с JVM Spark.
    Пример:

    SELECT map(1, 'a', 1, 'b'); -- Should fail with duplicate keys

  • Дисперсия порядка в collect_list() с сортировкой (Runtime 1.3; разрешено в Runtime 2.0): При использовании DISTRIBUTE BY и SORT BY, Искра сохраняет порядок элементов в collect_list(). В Runtime 1.3 NEE может возвращать значения в другом порядке из-за различий в тасовке, что приводит к несоответствию ожиданий для логики, чувствительной к порядку.

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

  • Управляемые частные конечные точки, необходимые для доступа к хранилищу (все времена): Когда включён Native Execution Engine (NEE) и если задачи Spark пытаются получить доступ к аккаунту хранения с помощью управляемой приватной конечной точки, необходимо настроить отдельные управляемые приватные конечные точки как для Blob (blob.core.windows.net), так и для DFS / File System (dfs.core.windows.net), даже если они указывают на одну и ту же учетную запись хранения. Нельзя повторно использовать одну и ту же конечную точку для обоих. Это ограничение может потребовать дополнительной сетевой конфигурации при включении нативного движка исполнения в рабочем пространстве, где управляются частные конечные точки к аккаунтам хранения.

Посмотрите это видео о движке выполнения Fabric espresso

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

  • Last updated on