Рекомендации по производительности конечной точки аналитики SQL

Конечная точка аналитики SQL позволяет запрашивать данные в lakehouse с помощью языка T-SQL и протокола TDS.

Tip

Подробные рекомендации, охватывающие разные рабочие нагрузки, по оптимизации таблиц Delta для потребления конечными точками аналитики SQL, включая рекомендации по размеру файлов и группам строк, подробнее см. в разделе "Обслуживание и оптимизация таблиц для разных рабочих нагрузок".

Каждый lakehouse имеет одну конечную точку аналитики SQL. Количество конечных точек аналитики SQL в рабочей области соответствует количеству lakehouse и зеркальных баз данных, развернутых в данной рабочей области.

Фоновый процесс отвечает за сканирование lakehouse'ов на наличие изменений и поддержание конечной точки SQL-аналитики в актуальном состоянии для всех изменений, зафиксированных в lakehouse'ах рабочей области. Платформа Fabric прозрачно управляет процессом синхронизации. При обнаружении изменений в Lakehouse, фоновый процесс обновляет метаданные, и конечная точка аналитики SQL отражает изменения, зафиксированные в таблицах Lakehouse. В обычных условиях эксплуатации задержка между lakehouse и конечной точкой аналитики SQL составляет менее одной минуты. Фактический период времени может варьироваться от нескольких секунд до минут в зависимости от многих факторов, которые рассматриваются в этой статье. Фоновый процесс выполняется только в том случае, если конечная точка аналитики SQL активна и останавливается через 15 минут бездействия.

Guidance

Автоматическое обнаружение метаданных отслеживает изменения, зафиксированные в lakehouses, и действует как единственный экземпляр для рабочей области Fabric. Если вы наблюдаете повышенную задержку синхронизации изменений между lakehouses и конечной точкой аналитики SQL, это может быть связано с большим количеством lakehouses в рамках одной рабочей области. В таком сценарии рассмотрите возможность переноса каждого озера в отдельную рабочую область, так как этот подход позволяет масштабировать автоматическое обнаружение метаданных.
Файлы Parquet неизменяемы по дизайну. При обновлении или удалении таблица Delta добавляет новые файлы Parquet с изменениями, что со временем увеличивает количество файлов в зависимости от частоты обновлений и удалений. Если вы не выполняете обслуживание по расписанию, такая схема со временем создает дополнительную нагрузку при чтении, и эта ситуация влияет на время, необходимое для синхронизации изменений с конечной точкой SQL Analytics. Чтобы устранить эту проблему, запланируйте регулярные операции по обслуживанию таблиц Lakehouse.
В некоторых сценариях можно увидеть, что изменения, зафиксированные в lakehouse, не отображаются в связанной конечной точке аналитики SQL. Например, можно создать новую таблицу в Lakehouse, но она еще не указана в конечной точке аналитики SQL. Или вы можете записать большое количество строк в таблицу в lakehouse, но эти данные ещё не видны в конечной точке SQL-аналитики. У вас есть возможность начать синхронизацию метаданных по запросу.
Процесс автоматической синхронизации не поддерживает все функции Delta. Дополнительные сведения о функциональных возможностях, поддерживаемых каждым обработчиком в Fabric, см. в разделе " Взаимодействие с форматом таблицы Delta Lake".
Если в ходе процесса извлечения, преобразования и загрузки (ETL) происходит чрезвычайно большой объём изменений в таблицах, возникает ожидаемая задержка, пока не будут обработаны все изменения.

Оптимизация таблиц Lakehouse для запроса конечной точки аналитики SQL

Когда конечная точка SQL-аналитики считывает таблицы, хранящиеся в lakehouse, производительность запросов во многом зависит от физической организации лежащих в основе файлов Parquet. Движок параллелизирует сканирование на уровне файла Parquet. Слишком много маленьких файлов увеличивает нагрузку на файлы и метаданные, а слишком мало крупных файлов ограничивает параллелизм сканирования.

Для таблиц, написанных Spark, используйте настройки по умолчанию в Fabric Spark runtime 2.0 или новее. Эти среды выполнения по умолчанию включают адаптивный размер целевых файлов, чтобы подбирать оптимальный размер целевого файла для каждой таблицы — от 128 МБ для небольших таблиц до 1 ГБ для крупнейших таблиц. Избегайте установки статических целей или произвольного лимита по числу строк поверх стандартных конфигураций. Ограничение строк не учитывает ширину строк и может создавать небольшие файлы для узких таблиц.

Если вы используете среду выполнения Fabric Spark 1.3, включите адаптивный целевой размер файла и целевые параметры уплотнения на уровне файла, которые доступны как дополнительные функции.

Для повышения производительности конечной точки SQL-аналитики V-Order не требуется, так как Spark записывает файлы Parquet с использованием сжатия Snappy, что позволяет сократить объём операций ввода-вывода при чтении и записи.

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

Включите автоуплотнение для рабочих нагрузок, где периодически добавленная синхронная задержка записи приемлема. Автоуплотнение — это функция Spark, которая работает только тогда, когда в таблице слишком много маленьких файлов.
Планируйте периодические задания OPTIMIZE для рабочих нагрузок, в которых периодически возникающая дополнительная задержка из-за автоматического уплотнения не позволяет соблюдать SLA по обновлению данных.
Запускайте VACUUM с учетом требований к сроку хранения данных и возможности отката во времени, чтобы удалить файлы, на которые журнал Delta больше не ссылается. VACUUM уменьшает задержанное хранилище, но не улучшает активную структуру файла.
Избегайте партиционирования по высококардинальному признаку и пользовательских настроек модуля записи, которые приводят к созданию множества мелких файлов.

Если вы не используете автоматическое сжатие, для выявления таблиц, требующих обслуживания, используйте конвейер данных и хранимую процедуру T-SQL sys.sp_get_table_health_metrics перед запуском OPTIMIZE. См. руководство: Оптимизация таблиц Lakehouse на основе проверок работоспособности.

Note

Сведения об общем обслуживании таблиц Lakehouse см. в разделе Запуск обслуживания таблиц из Lakehouse.

Факторы, влияющие на размер раздела

Выбор столбца секционирования для таблицы Delta в Lakehouse также влияет на то, сколько времени требуется для синхронизации изменений с конечной точкой SQL Analytics. Число и размер секций столбца секций важны для производительности:

Столбец с высокой кардинальностью (состоящий преимущественно или полностью из уникальных значений) приводит к большому количеству партиций. Большое количество секций отрицательно влияет на производительность проверки обнаружения метаданных на наличие изменений. Если кардинальность столбца высока, выберите другой столбец для разделения на части.
Размер каждой секции также может повлиять на производительность. Используйте столбец, который обеспечивает разделение размером не менее 1 ГБ (или близким к 1 ГБ). Следуйте лучшим практикам по обслуживанию и разбиению таблиц Delta. См. пример скрипта для получения сведений о разделах, чтобы оценить разделы с помощью скрипта Python.

Большой объём небольших файлов Parquet увеличивает время, необходимое для синхронизации изменений между лейкхаусом и связанной с ним конечной точкой аналитики SQL. В таблице Delta может оказаться большое количество файлов Parquet по одной или нескольким причинам:

Если выбрать секцию для таблицы Delta с большим количеством уникальных значений, таблица секционируется по каждому уникальному значению и может быть пересекундирована. Выберите столбец раздела, который не имеет высокой кардинальности, и обеспечивает индивидуальные разделы не менее 1 ГБ каждый.
Скорость приема данных при пакетной и потоковой обработке может также привести к образованию небольших файлов в зависимости от частоты и размера записываемых изменений в "озере данных". Например, может возникнуть небольшой объем изменений, поступающих в lakehouse, что приводит к небольшим паркетным файлам. Чтобы устранить эту проблему, реализуйте регулярное обслуживание таблиц Lakehouse.

Пример скрипта для сведений о разделе

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

Во-первых, укажите путь ABFSS для вашей таблицы Delta в переменной delta_table_path.
- Путь ABFSS к делта-таблице можно получить из портала Fabric обозревателя. Щелкните правой кнопкой мыши имя таблицы, а затем выберите COPY PATH из списка параметров.
Скрипт выводит все разделы для таблицы Delta.
Скрипт выполняет итерацию по каждой секции, чтобы вычислить общий размер и количество файлов.
Скрипт выводит сведения о секциях, файлах на секции и размер каждой секции в ГБ.

Полный скрипт можно скопировать из следующего блока кода:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Автоматически созданная схема в конечной точке анализа SQL Lakehouse

Для каждой таблицы Delta в Lakehouse конечная точка аналитики SQL автоматически создает таблицу в соответствующей схеме. Подсистема конечных точек аналитики SQL основана на подсистеме Fabric Data Warehouse.

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-08-27