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

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

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

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

Матрица записи и чтения сценариев

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

Метод записи Механизм чтения Ожидаемые пробелы Рекомендуемая стратегия
Пакет Spark Spark Нет пробелов Конфигурации записи Spark по умолчанию достаточно
Пакет Spark Конечная точка аналитики SQL Нет пробелов Включение автоматического сжатия и оптимизации записи
Стриминг Spark Spark Маленькие файлы возможны Автоматическое сжатие и оптимизация записи с помощью запланированной оптимизации
Стриминг Spark Конечная точка аналитики SQL Небольшие файлы и контрольные точки Автоматическое сжатие, оптимизация и запись, разделение уровней медальона
Склад Spark Нет пробелов Система-управляемая оптимизация обрабатывает макет.
Склад Конечная точка аналитики SQL Нет пробелов Система управления оптимизацией обрабатывает макет

Оптимальные макеты файлов по движку

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

Руководство по конечной точке аналитики SQL и хранилищу данных Fabric

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

  • Размер целевого файла: около 400 МБ на файл
  • Размер группы строк: около 2 миллионов строк на группу строк
  • V-Order: повышает производительность чтения на 10%

Склад использует эти критерии для обнаружения кандидатов на сжатие:

  • Перегрузка файла таблицы превышает 10%
  • Логически удаленные строки таблицы — более 10%
  • Размер таблицы превышает 1024 строк

Во время выполнения сжатия процесс выбирает кандидатов на основе следующих критериев:

  • Любой файл меньше 25% идеального размера (на основе количества строк)
  • Любой файл содержит более 20% удаленных строк

Spark

Spark является надежным при чтении различных размеров файлов. Для оптимальной производительности:

  • Размер целевого файла: 128 МБ до 1 ГБ в зависимости от размера таблицы
  • Размер группы строк: 1 млн до 2 миллионов строк на группу строк
  • V-Order: не требуется для производительности чтения в Spark, что может увеличить нагрузку на запись на 15-33%

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

  • Таблицы под 10 ГБ: целевой размер 128 МБ
  • Таблицы размером более 10 ТБ: до 1 ГБ целевой размер

Power BI Direct Lake

Для оптимальной производительности Direct Lake:

  • Размер целевой группы строк: 8 миллионов или более строк для каждой группы строк для оптимальной производительности
  • V-Order: критично для повышения эффективности запросов с холодным кэшем на 40-60%
  • Количество файлов: свести к минимуму количество файлов, чтобы сократить затраты на перекодирование
  • Согласованные размеры файлов: важно для прогнозируемой производительности запросов

Семантические модели Direct Lake работают лучше всего в следующих условиях:

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

Дополнительные сведения см. в статье "Общие сведения о производительности запросов Direct Lake".

Зеркалирование

Зеркалирование автоматически определяет размер файлов на основе объема таблицы.

Размер таблицы Число строк в группе строк Строки на файл
Небольшой (до 10 ГБ) 2 миллиона 10 млн
Средний (10 ГБ до 2,56 ТБ) 4 млн 60 миллионов
Большой (более 2,56 ТБ) 8 млн 80 миллионов

Написание шаблонов и конфигураций

Шаблоны записи Spark

Для записи Spark используются следующие конфигурации по умолчанию:

Конфигурация Значение по умолчанию Description
spark.microsoft.delta.optimizeWrite.fileSize 128 МБ Размер целевого файла для оптимизированных операций записи
spark.databricks.delta.optimizeWrite.enabled Зависит от профиля Включает автоматическое объединение файлов
spark.databricks.delta.autoCompact.enabled Disabled Включает сжатие после записи
spark.sql.files.maxRecordsPerFile Unlimited Максимальное количество записей на файл

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

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

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

Шаблоны записи в хранилище

Хранилище автоматически оптимизирует структуру данных во время записи.

  • V-Order включен по умолчанию для оптимизации чтения.
  • Автоматическое сжатие выполняется в качестве фонового процесса.
  • Управление контрольными точками обрабатывается автоматически.

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

Операции обслуживания таблиц

Команда OPTIMIZE

Команда OPTIMIZE объединяет небольшие файлы в большие файлы:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Это важно

Команда OPTIMIZE — это команда Spark SQL. Его необходимо запустить в средах Spark, таких как записные книжки, определения заданий Spark или интерфейс обслуживания Lakehouse. Конечная точка аналитики SQL и редактор запросов SQL хранилища не поддерживают эту команду.

Дополнительные сведения см. в разделе "Сжатие таблиц".

Автоматическое сжатие

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

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

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

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

Дополнительные сведения см. в разделе "Автоматическое сжатие".

Оптимизация записи

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

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Оптимизация записи полезна для:

  • Секционированные таблицы
  • Таблицы с частыми небольшими вставками
  • Операции, касающиеся многих файлов (MERGE, UPDATE, DELETE)

Сжатие предварительной записи (оптимизация записи) обычно менее затратно, чем сжатие после записи (оптимизация). Дополнительные сведения см. в разделе "Оптимизация записи".

Команда VACUUM

Команда VACUUM удаляет старые файлы, на которые журнал таблиц Delta больше не ссылается:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Срок хранения по умолчанию составляет 7 дней. Установка более коротких периодов хранения влияет на возможности перемещения по времени Delta и может вызвать проблемы с одновременными средствами чтения или записи.

Дополнительные сведения см. в разделе "Обслуживание таблиц Lakehouse".

Оптимизация V-Order

V-Order — это оптимизация во время записи, которая применяет сортировку, кодировку и сжатие VertiPaq к файлам Parquet.

  • Power BI Direct Lake: улучшение производительности на 40–60% для запросов с использованием холодного кэша
  • Конечная точка аналитики SQL и хранилище: производительность чтения увеличена примерно на 10%
  • Spark: отсутствие преимущества при чтении; записи выполняются на 15-33% медленнее

Когда включать V-Order

V-Order обеспечивает наибольшее преимущество:

  • Таблицы уровня "Золотой слой", обслуживающие Power BI Direct Lake
  • Таблицы часто запрашиваются через конечную точку аналитики SQL
  • Рабочие нагрузки с большим объемом чтения, в которых производительность записи менее важна

Когда не следует использовать V-Order

Рассмотрите возможность отключения V-Order для:

  • Таблицы бронзового слоя, ориентированные на скорость приема
  • Конвейеры Spark -to-Spark, в которых SQL и Power BI не используют данные
  • Рабочие нагрузки с высокой нагрузкой на запись, в которых задержка данных является критической

Настройка V-Order

По умолчанию V-Order отключен в новых рабочих областях Fabric. Для включения:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Чтобы выборочно применить V-Order на основе использования Direct Lake, рассмотрите возможность автоматизации включения V-Order для таблиц, используемых в семантических моделях Direct Lake. Таблицы, не используемые Direct Lake, могут оставаться без V-Order для повышения производительности записи.

Дополнительные сведения см. в разделе "Оптимизация таблицы Delta Lake" и "V-Order".

Кластеризация Liquid и Z-Order

Кластеризация Жидкости

Liquid Clustering — это рекомендуемый подход для организации данных. В отличие от традиционного секционирования, Liquid Clustering:

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

Включите кластеризацию Liquid при создании таблицы:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-Order (порядок по оси Z)

Z-Order копирует связанные данные в одних и том же файлах, чтобы повысить производительность запросов при предикатах фильтра.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Используйте Z-Order, когда:

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

Рекомендации по архитектуре Medallion

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

Бронзовый слой (посадочная зона)

Бронзовые таблицы оптимизированы для производительности записи и низкой задержки при приеме данных.

  • Приоритет оптимизации: скорость инжестации над производительностью чтения
  • Секционирование: допустимо, но не рекомендуется для новых реализаций
  • Небольшие файлы: допустимо, так как фокус находится на скорости приема
  • V-Order: не рекомендуется (добавляет затраты на запись)
  • Автоматическое сжатие: Включите для уменьшения размера небольших файлов, но его можно пожертвовать ради скорости обработки данных
  • Векторы удаления: Включить для таблиц с шаблонами слияния

Бронзовые таблицы не должны использоваться непосредственно в конечных точках анализа SQL или пользователями Power BI Direct Lake.

Серебряный слой (курированная зона)

Таблицы Silver балансируют производительность чтения и записи.

  • Приоритет оптимизации: баланс между приемом и производительностью запросов
  • Размеры файлов: умеренный (128–256 МБ) для поддержки операций записи и чтения
  • V-Order: Необязательно; включите, если использование конечной точки аналитики SQL или Power BI является значительным.
  • Liquid Clustering или Z-Order: рекомендуется повысить производительность запросов
  • Автоматическое сжатие и оптимизация записи: включение на основе последующих требований
  • Векторы удаления: включите для таблиц, которые часто обновляются
  • Запланированная оптимизация: Выполнять агрессивно для поддержания структуры файла

Золотой слой (зона обслуживания)

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

  • Приоритет оптимизации: производительность чтения для аналитики
  • Размеры файлов: большие (400 МБ до 1 ГБ) для оптимальной производительности SQL и Power BI
  • V-Order: Требуется для Power BI Direct Lake; рекомендуется для конечной точки аналитики SQL
  • Жидкая кластеризация: требуется для оптимизации пропуска файлов
  • Оптимизация записи: требуется для согласованных размеров файлов
  • Запланированная оптимизация: проведение с усиленной интенсивностью для поддержания оптимального макета

Оптимизируйте золотые таблицы по-разному на основе основного механизма потребления:

Движок потребления V-Order Размер целевого файла Размер группы строк
Конечная точка аналитики SQL Да 400 МБ 2 миллиона строк
Power BI Direct Lake Да 400 МБ до 1 ГБ 8+ миллион строк
Spark Необязательно 128 МБ до 1 ГБ 1–2 миллиона строк

Несколько копий таблиц

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

  • Таблица Silver, оптимизированная для обработки Spark
  • Таблица Gold, оптимизированная для конечной точки аналитики SQL и режима Power BI Direct Lake
  • Конвейеры данных, которые преобразуют и помещают правильную структуру на каждом слое

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

Определение работоспособности таблицы

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

Проверка файлов Parquet непосредственно

Вы можете просмотреть папку с таблицами в OneLake, чтобы проверить размеры отдельных файлов формата Parquet. Здоровые таблицы имеют равномерно распределенные размеры файлов. Искать:

  • Согласованные размеры файлов: файлы должны быть примерно одинаковыми (в пределах 2x друг от друга).
  • Не очень маленькие файлы: файлы в 25 МБ указывают на фрагментацию.
  • Не очень большие файлы: файлы размером более 2 ГБ могут уменьшить параллелизм.

Неравномерное распределение размера файла часто означает отсутствие сжатия или несогласованных шаблонов записи в разных заданиях.

ОПТИМИЗАЦИЯ DRY RUN в Spark SQL

Используйте параметр DRY RUN для предварительного просмотра файлов, подлежащих оптимизации, без выполнения сжатия.

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Команда возвращает список файлов, которые будут перезаписаны во время оптимизации. Используйте следующее:

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

Распределение размера файла

Используйте следующий подход для анализа размеров и распределения файлов:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Распределение может быть искажено, так как файлы, близкие к началу таблицы или из определённого раздела, могут быть не оптимизированы.

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

Определение потребностей оптимизации

На основе подсистемы потребления сравните фактические размеры файлов с целевыми размерами:

Engine Размер целевого файла Если файлы меньше Если файлы больше
Конечная точка аналитики SQL 400 МБ Запуск OPTIMIZE Файлы допустимы
Power BI Direct Lake 400 МБ до 1 ГБ Запуск OPTIMIZE VORDER Файлы допустимы
Spark 128 МБ до 1 ГБ Включение автоматического сжатия Файлы допустимы

История таблиц и журнал транзакций

Просмотрите журнал таблиц, чтобы понять шаблоны записи и частоту обслуживания:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Рекомендации по настройке

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

Свойства таблицы сохраняются на протяжении сеансов и гарантируют согласованное поведение всех заданий и авторов.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Конфигурации уровня сеанса применяются только к текущему сеансу Spark и могут вызвать несогласованную запись, если разные сеансы используют разные конфигурации.

Включение размера адаптивного целевого файла

Адаптивное целевое значение размера файла автоматически настраивается в зависимости от размера таблицы.

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Эта функция:

  • Начинается с небольших файлов (128 МБ) для небольших таблиц
  • Масштабируется до 1 ГБ для таблиц размером более 10 ТБ
  • Автоматически переоценивает во время OPTIMIZE операций

Включение целевых объектов сжатия на уровне файлов

Запрет перезаписи ранее сжатых файлов при изменении размеров целевых объектов:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Сводка рекомендаций

Уровень Автоматическое сжатие Оптимизация-запись V-Order Кластеризация Жидкости Запланированная оптимизация
Бронза Включение (необязательно) Enable нет нет Необязательно
Серебро Enable Enable Необязательно Да Aggressive
Золото Enable Enable Да Да Aggressive

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

  • Spark-to-Spark: сосредоточьтесь на оптимизации размера файла; V-Order является необязательной настройкой.
  • Spark-to-SQL: включить оптимизацию записи и автоматическое сжатие; целевые файлы 400 МБ с 2 миллионами групп строк.
  • Потоковый ввод данных: автоматическая компакция; планирование дополнительных OPTIMIZE заданий для потребителей SQL.
  • Power BI Direct Lake: включите V-Order; нацелиться на группы строк объемом 8+ миллионов; выполните OPTIMIZE VORDER.

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

  • Last updated on