Выбор ядра ноутбука в Microsoft Fabric

Записные книжки в Microsoft Fabric поддерживают три типа ядра: Python, Spark и T-SQL. Ядро Spark поддерживает четыре языка — PySpark, SparkSQL, Scala и SparkR— все они поддерживаются одинаковыми вычислительными ресурсами Spark. В этом руководстве основное внимание уделяется решению между ядром Python и ядром Spark, так как эти ядра являются наиболее распространенным вариантом для рабочих нагрузок проектирования данных. Оба работают в одной и той же среде ноутбука, но различаются по модели вычислений, масштабируемости, возможностям движка и совместимости с Delta Lake. В этом руководстве представлена сбалансированная оценка, которая поможет вам выбрать правильное ядро и избежать распространенных ошибок о затратах и производительности.

Important

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

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

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

вычисление ядра Python

Ядро Python работает на одноузловой машине, которая по умолчанию использует 2 vCores (1 CU), и его можно настроить на запуск с количеством до 64 vCores (32 CU). Эта среда не имеет распределенного выполнения. Стартовый пул инициализируется примерно за 5 секунд, поэтому он хорошо подходит для интерактивной работы.

Вычисление ядра Spark

Ядро Spark использует пулы Spark с несколькими параметрами конфигурации:

Конфигурация кластера Виртуальные ядра, доступные исполнителям Время начала сеанса CU, потреблённые после начала сеанса
Начальный пул (по умолчанию) 8-ядерные рабочие узлы, включено автомасштабирование; запускается с одного узла и автоматически масштабируется до одного выделенного рабочего узла в течение нескольких минут с момента начала сеанса ~5 секунд 8 CU (минимум, после упреждающего масштабирования)
Одноузловой*, 8 виртуальных ядер (через пул Starter) 8-ядерный исполнитель и драйвер совместно используют один и тот же узел ~5 секунд (с предварительно прогретым пулом) 4 ЦС
Одноузловой*, настраиваемый пул с 4 виртуальными ядрами 4-ядерный исполнитель и драйвер совместно используют один и тот же узел. Требуется настраиваемый пул; запуск сеанса обычно занимает 3–5 минут. 2 CUs
Настраиваемый пул с несколькими узлами Масштабируется с ростом размера кластера Запуск сеанса обычно составляет от 3 до 5 минут. Меняется

При использовании начального пула одноузловой сеанс Spark с 8 виртуальными ядрами запускается примерно за 5 секунд — это сопоставимо с ядром Python. Одноузловой кластер Spark сохраняет стоимость на уровне ядра Python, при этом предоставляя доступ ко всем встроенным возможностям Spark, включая нативный механизм выполнения (Native Execution Engine, NEE).

Note

Существует два способа настройки пулов Spark с одним узлом. Для большинства рабочих нагрузок обычно рекомендуется использовать первый метод — одиночный узел с избыточным выделением ресурсов. Второй метод, классический одноузловой режим, лучше подходит при ресурсоёмких процессах драйвера, но ограничивает объём ресурсов, которые могут использовать исполнители Spark.

  • Избыточно подготовленный одноузловой: начните со пула Spark (то есть стартового пула), настроенного с включенными автомасштабированием и динамическим выделением, при этом для автомасштабирования задан диапазон от 1 до > 1 узла. Создайте элемент среды, ссылающийся на пул Spark, и задайте число исполнителей равным 1. Блокноты в этой среде создаются с одноузловым кластером Spark, где драйвер и исполнительный процесс совместно используют все ресурсы.
  • Классический один узел: создайте пул Spark с максимальным числом узлов, равным 1. Эта конфигурация работает независимо от того, включены или отключены автомасштабирование и динамическое выделение, так как этот выбор не влияет на стратегию выделения ресурсов. Блокноты, использующие этот пул Spark, имеют 50 % виртуальных ядер, выделенных драйверу, а остальные 50 % — исполнителям.

Производительность по масштабу рабочей нагрузки

Сравнительные тесты Fabric Spark с Native Execution Engine и одномашинных Python-движков (таких как Pandas, DuckDB или Polars) на сквозных ELT-нагрузках показывают четкие закономерности в зависимости от масштаба данных:

Масштаб данных (в сжатом виде) Преимущество двигателя
Ультра-малый (< ~140 МБ) Механизмы Python с одним компьютером (DuckDB, Polars) быстрее.
Small (~1–2 ГБ) Механизмы Python по-прежнему имеют преимущество, но Fabric Spark с NEE становится конкурентоспособным по мере увеличения числа ядер, доступных для каждого механизма, особенно при операциях с интенсивной записью.
Малый–средний (~10–13 ГБ) Fabric Spark с собственным механизмом выполнения не уступает по производительности большинству одномашинных движков или превосходит их. Одномашинные механизмы Python могут сталкиваться с ошибками нехватки памяти (OOM) при меньшем числе vCore.
Средний и выше (~100 ГБ+) Для большинства рабочих нагрузок Spark в Fabric с собственным механизмом выполнения является самой быстрой и надежной средой.

Масштабирование за пределы малых данных

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

Совместимость Delta Lake

Совместимость Delta Lake является критически важным фактором при выборе двигателя. Fabric Spark обеспечивает встроенную полнофункциональную поддержку Delta Lake, тогда как в средах выполнения Python могут быть существенные пробелы в функциональности:

Important

Следующая таблица поддержки функций отражает состояние каждого механизма по состоянию на июнь 2026 г. и основана на результатах прямого тестирования с использованием Fabric Spark Runtime 1.3 и 2.0. Экосистема Python с открытым исходным кодом (OSS) для Delta Lake быстро развивается — delta-rs, DuckDB и Polars регулярно выпускают новые версии, в которых периодически расширяется поддержка протокола Delta. Всегда проверяйте соответствие текущей документации и заметкам о выпуске для каждого обработчика перед использованием определенной функции в рабочей среде:

Функция Delta Lake Fabric Spark delta-rs (Python) DuckDB Поларс
Чтение таблиц Delta ✅ ✅ ✅ ✅
Запись разностных таблиц ✅ ✅ Добавление, перезапись (в том числе на основе предиката), UPDATE, DELETE, MERGE ⚠️ Только операции INSERT (требуется ATTACH ... (TYPE delta, READ_WRITE)); UPDATE/DELETE/MERGE не поддерживаются; используйте delta-rs для остальных операций записи. ⚠️ Добавление, перезапись (в том числе на основе предиката), только слияние; нет UPDATE/DELETE
Гарантии ACID / оптимистическое управление параллелизмом ✅ ✅ ⚠️ INSERT работает только в режиме добавления; нет встроенного обнаружения конфликтов; используйте delta-rs с фиксацией версии для изоляции при сценарии «чтение-перед-записью» ⚠️ OCC для операций записи; операции чтения в Polars выполняются вне границ транзакции — требуется явное закрепление версии для изоляции сценария «чтение-затем-запись»
Эволюция схемы при записи ✅ ✅ ❌ Нет эволюции схемы в INSERT ✅
Сопоставление столбцов ✅ ❌ ✅ ❌
Векторы удаления (чтение) ✅ ❌ ✅ ✅
Векторы удаления (запись) ✅ ❌ ❌ ❌
Расширение типов (чтение) ✅ ❌ ✅ ❌
Расширение типов (запись) ✅ ❌ ❌ ❌
Пропуск файла ✅ ✅ ✅ ✅
Секционированные записи ✅ ✅ ❌ Используйте delta-rs для записи с партиционированием ✅
Жидкая кластеризация (запись) ✅ ❌ ❌ ❌
Путешествие по времени ✅ ✅ ✅ ✅
RESTORE ✅ ✅ ❌ Восстановление таблиц с помощью delta-rs ❌ Восстановление таблиц с помощью delta-rs
Поверхностный клон (создание) ✅ ❌ ❌ ❌
Поверхностное клонирование (чтение) ✅ ❌ ❌ ❌
Отслеживание строк ✅ ⚠️ Считывает и записывает успешно, но отслеживание _metadata строк недоступно; конвейеры, использующие row_id для дедупликации или отслеживания измененных данных (CDC), должны использовать Spark для чтения. ⚠️ Чтение и запись выполняются успешно, но отслеживание строк _metadata недоступно; конвейеры, использующие row_id для дедупликации или CDC, должны использовать Spark для чтения. ⚠️ Чтение и запись выполняются успешно, но отслеживание строк _metadata недоступно; конвейеры, использующие row_id для дедупликации или CDC, должны использовать Spark для чтения.
Столбцы идентификаторов (чтение) ✅ ✅ ✅ ✅
Столбцы идентификаторов (запись) ✅ ❌ ❌ ❌
Созданные столбцы (чтение) ✅ ✅ ✅ ✅
Созданные столбцы (запись) ✅ ❌ ❌ ❌
Изменение канала данных (чтение) ✅ ✅ ❌ Используйте delta-rs для чтения ленты изменённых данных ❌ Используйте delta-rs для чтения ленты изменённых данных
Изменение канала данных (запись) ✅ ❌ ❌ ❌
Контрольные точки V2 (только чтение) ✅ ❌ ✅ ❌
Чекпойнты V2 (запись) ✅ ❌ ❌ ❌
Интервал контрольной точки ✅ Настраиваемая (по умолчанию 10) ⚠️ Настраиваемая (по умолчанию 100) ❌ INSERT не записывает чекпоинты; журнал растёт без ограничений без внешнего обслуживания средствами delta-rs ⚠️ Настраиваемая (по умолчанию 100)
ОПТИМИЗИРОВАТЬ ✅ ✅ ❌ Оптимизация с помощью delta-rs ❌ Оптимизация с помощью delta-rs
Автоматическое сжатие ✅ ❌ ❌ ❌
ВАКУУМ ✅ ❌ Риск: накопление потерянных файлов ❌ Риск: накопление потерянных файлов ❌ Риск: накопление потерянных файлов
ВАКУУМ ЛАЙТ ✅ ✅ ❌ Очистка Lite с помощью delta-rs ❌ Очистка Lite с помощью delta-rs

Ключевые последствия:

  • Новые возможности Delta: поддержка более новых возможностей Delta Lake, включая расширение типов, контрольные точки v2, liquid clustering, столбцы идентификаторов, операции записи в Change Data Feed и чтение при shallow clone, в Python-движках OSS либо непоследовательна, либо отсутствует. Если конвейер данных зависит от любой из этих функций, используйте Fabric Spark. Рассматривайте среды Python как дополнение к Spark для конкретных задач (небольшие операции чтения, локальная разработка, простые дозаписи), а не как замену общего назначения.

  • Векторы удаления: векторы удаления — это рекомендуемая практика для таблиц Delta (включены по умолчанию, начиная с Fabric Spark Runtime 2.0), поскольку они значительно повышают производительность операций MERGE, UPDATE и DELETE благодаря стратегии слияния при чтении. Модуль Python (delta-rs, DuckDB или Polars) не поддерживает запись векторов удаления. Если вы используете любой модуль Python для записи в таблицы с включенными векторами удаления, возникают ошибки совместимости.

  • Гарантии ACID: не все Python двигателя предоставляют собственные гарантии ACID. Delta-rs поддерживает оптимистический контроль параллелизма (OCC) для операций объединения, обновления и удаления. Однако междвижковые конвейеры, в которых DuckDB или Polars выполняют чтение, а delta-rs — запись, требуют явного закрепления версий с обеих сторон для поддержания изоляции операций чтения и записи. DuckDB INSERT — это операция только для добавления без обнаружения конфликтов.

  • Контрольные точки: не все механизмы Python записывают контрольные точки, а те, которые записывают, по умолчанию делают это каждые 100 коммитов, а не каждые 10 коммитов, как в Spark. DuckDB INSERT никогда не записывает чекпойнты, что приводит к неограниченному росту журнала транзакций Delta. Рекомендуется задать меньший интервал создания контрольных точек в delta-rs и Polars, а также регулярно выполнять обслуживание delta-rs для таблиц, записываемых с помощью DuckDB.

  • Отслеживание строк: Все среды Python могут читать из таблиц с включенным отслеживанием строк и записывать в них, но столбец _metadata, содержащий row_id и row_commit_version, недоступен вне Spark. Конвейеры, использующие row_id для дедупликации или CDC, должны использовать Spark для чтения.

  • OPTIMIZE и VACUUM: Python подсистемы используют библиотеку deltalake для сжатия и вакуума. Хотя delta-rs может быть быстрым для этих операций, этот подход требует дополнительного управления зависимостями, а сами операции координируются встроенными средствами не так, как в Spark. Таблицы, написанные исключительно с помощью подсистем Python, накапливают небольшие файлы и несвязанные журналы транзакций без явного обслуживания.

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

Зрелость ядра и поддержка Microsoft

Поддержка Spark в Fabric

Fabric Spark — это собственный форк Microsoft проекта Apache Spark с открытым исходным кодом. Microsoft поддерживает и поставляет среду выполнения, то есть:

  • Microsoft поддерживает внутреннее устройство Spark и Delta Lake в полном объеме, включая Native Execution Engine (NEE), построенный на базе Velox и Apache Gluten.
  • Вы можете создавать обращения в службу поддержки по вопросам работы Spark, планов запросов, проблем с памятью и ошибок движка.
  • Улучшения производительности регулярно внедряются с обновлениями среды выполнения Fabric — ваш существующий код работает быстрее без каких-либо изменений в коде.

поддержка подсистемы Python

Microsoft не поддерживает форк OSS-проектов для Python, таких как DuckDB или Polars. Поддержка ограничивается проблемами в интеграциях OneLake, входящих в состав среды выполнения Fabric, например с проверкой подлинности или доступом к файловой системе. Если вы столкнулись с регрессией производительности, ошибкой обработчика или сломанным API между версиями библиотек, необходимо напрямую взаимодействовать с сообществами с открытым исходным кодом для этих библиотек.

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

Реальный опыт создания комплексных тестов ELT с этими двигателями подчеркивает значимые различия в операционной зрелости:

  • Spark: код, написанный для одной версии среды выполнения, работает на более новых версиях без изменений и выполняется быстрее благодаря постоянным инженерным инвестициям Microsoft. Пользовательский интерфейс Spark и телеметрия Fabric обеспечивают мониторинг в реальном времени, предоставляя полную прозрачность активных запросов, планов выполнения и истории выполнений заданий.
  • DuckDB и Polars: изменения в API и поведении между версиями могут требовать рефакторинг кода по мере развития обработчиков и развития API. Обе подсистемы не имеют динамического мониторинга, когда задание выполняется дольше, чем ожидалось, нет эквивалента пользовательскому интерфейсу Spark, чтобы понять, что происходит. Для аутентификации в OneLake могут потребоваться обходные пути, зависящие от версии.
  • Накладные расходы компонуемого стека данных: использование DuckDB или Polars для полноценного ELT-процесса обычно означает, что приходится объединять несколько библиотек (например, DuckDB для сканирования и преобразования данных, delta-rs для записи и сопровождения). Совместимость библиотеки должна поддерживаться между компонентами и должна рассматриваться в любое время, когда версия библиотеки обновляется за пределы того, что поставляется в среде выполнения.

Руководство по принятию решений

Используйте ядро Python, если

  • Объём ваших данных небольшой — менее 1 ГБ в сжатом виде, — и наибольшее значение имеет чистая производительность движков, работающих на одной машине.
  • Вы создаете упрощенную оркестрацию API, интеграцию REST/gRPC или автоматизацию потока управления, где распределенные вычислительные ресурсы добавляют ненужные затраты.
  • Вы выполняете быстрое интерактивное исследование небольших наборов данных, где задержка нерегламентированного запроса является приоритетом.
  • Для рабочей нагрузки требуется более старая версия Python, чем то, что поставляется в текущей среде выполнения Fabric Spark.
  • Вы понимаете и принимаете ограничения функции Delta Lake для используемого модуля Python.

Используйте ядро Spark, когда

  • Объём данных составляет 1 ГБ или более в сжатой форме, либо вы ожидаете, что объём данных достигнет такого масштаба.
  • Вам нужна полная совместимость с Delta Lake, включая векторы удаления, сопоставление столбцов, расширение типов, OPTIMIZE, VACUUM и гарантии ACID.
  • Вам требуются возможности промышленного уровня, такие как переменные среды, управление библиотеками на уровне элементов, высокая степень параллелизма и планирование заданий по принципу FAIR, или «первым поступил — первым обслужен» (FIFO).
  • Вам нужны мониторинг в реальном времени и полная видимость работы выполняемых задач.
  • Вы используете собственные API Spark, такие как MLlib, Spark SQL или Spark Streaming.
  • Вы хотите Microsoft сквозную поддержку подсистемы обработки данных.
  • Требуется возможность масштабирования от одного узла до вычислений с несколькими узлами без перезаписи кода.
  • Необходимо создать записные книжки в PySpark, SparkSQL, Scala или SparkR.

Подсказка

Для рабочих нагрузок объёмом от 1 ГБ и более в сжатом виде рекомендуется начать с одноузлового кластера Spark с 8 виртуальными ядрами, используя стартовый пул. Вы получаете почти мгновенное время начала сеанса, полные Fabric возможности Spark, включая NEE, и возможность масштабирования до нескольких узлов при необходимости — все при работе с одним узлом, например ядром Python.

Основные различия на первый взгляд

Категория Ядро Python Ядро Spark
Вычисления по умолчанию Одноузловая виртуальная машина (VM) с 2 виртуальными ядрами (с возможностью масштабирования до 64 виртуальных ядер) Начальный пул: рабочие узлы с 8 vCore и автомасштабированием
Минимальная конфигурация с одним узлом 2 виртуальных ядра 8 виртуальных ядер (стартовый пул, запуск примерно за 5 с); 4 виртуальных ядер (настраиваемый пул, более долгий запуск)
Время запуска ~5 секунд ~5 секунд (начальный пул); длиннее для пользовательских пулов
Распределенное выполнение нет Yes
Поддерживаемые языки Python PySpark, SparkSQL, Scala, SparkR
версия Python Доступно несколько версий Привязана к версии среды выполнения Fabric Spark
Delta Lake (полная поддержка функций) нет Yes
Мониторинг в реальном времени Limited Полный (страница мониторинга заданий и пользовательский интерфейс Spark)
поддержка модуля Microsoft Только интеграции с OneLake Полная поддержка среды выполнения
доступ к библиотеке Python pip install pip install + элементы окружения
API на основе Spark (MLlib, Streaming) нет Yes
Возможности продуктивной среды (переменные среды, окружения) Limited Full
Поддержка высокой конкурентности нет Yes
V-Order для быстродействующих семантических моделей Direct Lake нет Yes
Кэш хранилища объектов, позволяющий ускорить повторение операций чтения Зависит от движка (у DuckDB есть встроенное кэширование, у Polars — нет) Да (интеллектуальный кэш)
Масштабирование до нескольких узлов нет Yes

Глоссарий

  • Транзакции ACID: набор свойств (атомарность, согласованность, изоляция, устойчивость), гарантирующий надежную обработку операций баз данных. Delta Lake реализует семантику ACID с помощью управления оптимистичным параллелизмом и журналов транзакций.
  • Оптимистичный контроль параллелизма (OCC): стратегия управления параллелизмом, при которой транзакции выполняются без блокировок, а затем при фиксации проверяется, что не произошло конфликтующих изменений. Delta Lake использует OCC; междвижковые конвейеры (например, чтение через Polars с последующей записью через delta-rs) требуют явной фиксации версии для сохранения изоляции.
  • Автоматическое сжатие: функция Delta Lake в среде выполнения Spark Fabric, которая автоматически объединяет небольшие файлы в более крупные после операций записи, уменьшая фрагментацию файлов без отдельного шага OPTIMIZE.
  • Поток изменений данных (CDF): функция Delta Lake, которая регистрирует изменения на уровне строк в таблице (вставка, обновление, удаление), обеспечивая инкрементальную обработку данных и работу конвейеров CDC. Только Fabric Spark поддерживает запись метаданных ленты изменений данных (CDF); Python-движки с открытым исходным кодом могут читать, но не записывать эти метаданные.
  • Сопоставление столбцов: функция Delta Lake, которая позволяет переименовать или удалить столбцы без перезаписи базовых файлов Parquet. Поддерживается Fabric Spark; не поддерживается delta-rs или Polars.
  • delta-rs: реализация Rust с открытым исходным кодом протокола Delta Lake с привязками Python (deltalakeпакет PyPI). Обеспечивает поддержку чтения и записи Delta в средах Python с открытым исходным кодом, но поддерживает более узкий набор функций, чем delta-spark, которые лежат в основе среды выполнения Fabric Spark.
  • Векторы удаления: оптимизация Delta Lake, которая использует подход merge-on-read, чтобы сократить объем данных, перезаписываемых во время операций MERGE, UPDATE и DELETE. Включен по умолчанию в Fabric Spark Runtime 2.0; не поддерживается для записи подсистемой Python OSS.
  • Планирование FAIR: политика планирования Spark, которая выделяет ресурсы кластера справедливо для параллельных заданий, обеспечивая отсутствие монополизирования одного задания в кластере.
  • Планирование FIFO: политика планирования в Spark, которая запускает задания в порядке «первым пришёл — первым обслужен», отдавая приоритет заданию, отправленному первым.
  • Liquid Clustering: функция Delta Lake, которая постепенно реорганизует данные для оптимальной производительности запросов, не требуя явного секционирования. Поддерживается только Fabric Spark.
  • NEE (Native Execution Engine): векторизованный движок запросов на C++, созданный на основе Velox и Apache Gluten и ускоряющий нагрузки Fabric Spark. NEE доступна без дополнительных затрат на вычислительные ресурсы и не требует изменений кода.
  • Отслеживание строк: функция Delta Lake, которая присваивает каждой строке стабильные row_id и row_commit_version с помощью столбца _metadata. Все подсистемы могут считывать и записывать в таблицы с включенным отслеживанием строк, но только Fabric Spark может получить доступ к содержимому столбца_metadata.
  • Пул Spark: общий вычислительный ресурс для выполнения распределенных рабочих нагрузок Spark. Начальный пул предоставляет предварительно подготовленные узлы для почти мгновенного времени начала сеанса (~5 секунд) с автомасштабированием, включенным по умолчанию.
  • V-Order: оптимизация записи в Fabric, которая сортирует и сжимает данные Parquet таким образом, что повышает производительность чтения для семантических моделей Direct Lake в Power BI и других путей чтения в Fabric.
  • Интеллектуальный кэш: интеллектуальный кэш дисков в Fabric Spark, который ускоряет повторяющиеся операции чтения одних и того же файлов таблицы Delta путем кэширования данных файлов локально на узлах исполнителя.

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

  • Last updated on