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

Область применения:✅ конечная точка аналитики SQL в Microsoft Fabric

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

Подсказка

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

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

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

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

Конечная точка аналитики SQL управляет автоматически созданными таблицами, чтобы пользователи рабочей области не могли изменять их. Пользователи могут обогатить модель базы данных, добавив собственные схемы SQL, представления, процедуры и другие объекты базы данных.

Для каждой таблицы Delta в Lakehouse конечная точка аналитики SQL автоматически создает таблицу в соответствующей схеме. Для автогенерируемых типов данных схемы для конечной точки аналитики SQL см. раздел "Типы данных" в Microsoft Fabric.

Таблицы в SQL-аналитической конечной точке создаются с незначительной задержкой. После создания или обновления таблицы Delta Lake в озере таблица конечных точек аналитики SQL, которая ссылается на таблицу Delta lake, создается или обновляется автоматически.

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

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

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

Руководство

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

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

Когда конечная точка аналитики SQL считывает таблицы, хранящиеся в озере, производительность запросов сильно зависит от физического макета базовых файлов parquet.

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

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

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

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

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", 400 * 1024 * 1024 * 1024)

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

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

Замечание

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

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

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

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

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

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

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

Сначала необходимо указать путь ABSFF для дельта-таблицы в переменной 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']}")

Кері байланыс

Бет пайдалы болды ма?

Last updated on 2026-02-13