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

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

Tip

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

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

Фоновый процесс отвечает за сканирование lakehouse'ов на наличие изменений и поддержание конечной точки SQL-аналитики в актуальном состоянии для всех изменений, зафиксированных в lakehouse'ах рабочей области. Платформа Microsoft 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 создает издержки и отрицательно влияет на производительность запросов. Чтобы обеспечить прогнозируемую и эффективную производительность, сохраняйте хранилище таблиц, чтобы каждый файл Parquet содержал две миллионы строк. Это число строк обеспечивает сбалансированный уровень параллелизма без фрагментирования набора данных на чрезмерно небольшие срезы.

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

Установите maxRecordsPerFile на значение 2 000 000 до внесения изменений в данные.
Выполните изменения данных (прием данных, обновления, удаление).
Установите значение maxFileSize на 4 ГБ.
Выполните команду OPTIMIZE. Подробнее об использовании OPTIMIZE см. в разделе Запуск обслуживания таблиц в Lakehouse.

Следующий скрипт предоставляет шаблон для этих действий и должен выполняться в лейкхаусе:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Чтобы поддерживать оптимальный размер файлов, периодически выполняйте операции оптимизации Delta, такие как OPTIMIZE, особенно для таблиц, в которые часто вносятся инкрементальные вставки, обновления и удаления. Эти операции обслуживания сжимают небольшие файлы в соответствующие размеры, что помогает эффективно обрабатывать запросы в конечной точке аналитики SQL.

Note

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

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

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

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

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

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

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

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

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

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

# 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-05-26