Рекомендации по производительности в хранилище данных Fabric

Область применения:✅ хранилище в Microsoft Fabric

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

Сведения о мониторинге производительности хранилища см. в статье Monitor Fabric Data Warehouse.

Оптимизация типов данных

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

Дополнительные сведения о типах данных, поддерживаемых хранилищем данных Fabric, см. в разделе "Типы данных" в хранилище данных Fabric.

Сопоставление типов данных с семантикой данных

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

• Используйте дату, время или datetime2(n) для темпоральных значений вместо хранения их в виде строк.
• Используйте целые типы для числовых значений, если форматирование (например, начальные нули) не требуется.
• Используйте типы символов (char, varchar), когда необходимо сохранить форматирование (например, числа, которые могут начинаться с нуля, коды продуктов, числа с дефисами).

Используйте типы данных для целых чисел

При хранении таких значений, как идентификаторы, счетчики или другие целые числа, предпочитайте целочисленные типы (smallint, int, bigint) вместо десятичных типов decimal/numeric. Целые типы требуют меньше памяти, чем типы данных, которые позволяют использовать цифры справа от десятичной запятой. В результате они позволяют ускорить арифметические операции и операции сравнения, а также повысить производительность индексирования и запросов.

Учитывайте диапазоны значений для каждого целочисленного типа данных, поддерживаемого хранилищем данных Fabric. Дополнительные сведения, int, bigint, smallint (Transact-SQL).

Рассмотрите возможность использования десятичной и числовой точности и масштабирования

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

• Предвидите ожидаемый рост и потребности вашего склада. Например, если вы планируете хранить не более четырех цифр справа от десятичной запятой, используйте десятичную (9,4) или десятичную (19,4) для наиболее эффективного хранения.
• Всегда указывайте точность и масштаб при создании десятичного/числового столбца. При создании в таблице, определенной как простоdecimal, без указания (p,s)точности и масштабирования, создается decimal(18,0)десятичный/числовой столбец. Десятичное число с точностью 18 потребляет 9 байт хранилища на строку. Масштаб 0 не сохраняет данные справа от десятичной запятой. Для многих целых бизнес-чисел smallint, int, bigint гораздо эффективнее decimal(18,0). Например, любое девятизначное целое число может храниться в виде целочисленного типа данных для 4 байтов хранилища на строку.

Для полной информации см. числовой и десятичный (Transact-SQL).

Рассмотрим, когда следует использовать varchar вместо char

Используйте varchar(n) вместо char(n) для строковых столбцов, если не требуется явное заполнение фиксированной длины. Столбец varchar сохраняет только фактическую длину строки для каждой строки, плюс небольшие накладные расходы, и уменьшает объём неиспользуемого пространства, что повышает эффективность операций ввода-вывода.

• Используйте varchar(n) для таких значений, как имена, адреса и описания, так как они имеют широкие значения переменных. Статистика и оценка затрат запросов более точны, если длина типа данных является более точной для фактических данных.
• Используйте char(n), когда вы знаете, что строка будет фиксированной длиной каждый раз. Например, хранение строки в виде символа(9) имеет смысл, если строка 000000000 всегда равна 9 числовым символам, которые могут начинаться с нуля.
• Длина n в объявлении типа данных столбца — это количество байт, необходимых для хранения. Для кодировок многобайтовых наборов символов, таких как UTF-8, в хранилище данных Fabric латинские символы и цифры требуют 1 байт памяти. Однако существуют символы Юникода, для которых требуется более 1 байта, например японские символы, требующие хранения 3 байта, поэтому количество символов Юникода на самом деле может быть меньше длины nтипа данных. Дополнительные сведения см. в разделе char и varchar Arguments.

Избегайте значений NULL-столбцов, когда это возможно

Определите столбцы, как NOT NULL если модель данных разрешает. По умолчанию в столбце таблицы допускаются значения NULL. Столбцы, допускающие значение NULL, имеют следующие характеристики:

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

Прием и подготовка данных в хранилище

Копировать в

Команда T-SQL COPY INTO — это рекомендуемый способ приема данных из Azure Data Lake Storage в хранилище данных Fabric. Дополнительные сведения и примеры см. в разделе "Загрузка данных в хранилище с помощью инструкции COPY".

Рассмотрите следующие рекомендации для оптимальной производительности:

• Размер файла: Убедитесь, что каждый файл, который вы загружаете, находится в пределах от 100 МБ до 1 ГБ для максимальной скорости обработки. Это помогает оптимизировать процесс приема и повысить производительность.
• Количество файлов: Чтобы максимально повысить производительность параллелизма и запросов, необходимо создать большое количество файлов. При этом при сохранении минимального размера файла в 100 МБ рекомендуется создавать максимальное количество файлов.
• Параллельная загрузка: Использование нескольких COPY INTO инструкций, выполняемых параллельно, для загрузки данных в разные таблицы. Такой подход может значительно уменьшить окно ETL/ELT из-за параллелизма.
• Размер емкости. Для больших объемов данных рекомендуется масштабировать до большей емкости Fabric, чтобы получить дополнительные вычислительные ресурсы, необходимые для размещения дополнительного количества параллельных обработки и больших объемов данных.

Хранилище данных Fabric также поддерживает BULK INSERT инструкцию, синоним COPY INTO. Эта же рекомендация применяется к BULK INSERT инструкции.

CTAS или INSERT

Используйте КОМАНДУ CREATE TABLE AS SELECT (CTAS) или INSERT в сочетании с SELECT FROM командами Lakehouse table/shortcut. Эти методы могут быть более эффективными и эффективными, чем использование конвейеров, что позволяет ускорить и более надежную передачу данных. Дополнительные сведения и примеры см. в разделе "Прием данных в хранилище" с помощью Transact-SQL.

Концепция увеличения уровня параллелизма и масштабирования до большей емкости Fabric также применяется к операциям CTAS/INSERT для повышения пропускной способности.

Чтение данных из Azure Data Lake Storage или хранилища Blob с помощью OPENROWSET

Функция OPENROWSET позволяет считывать CSV-файлы или файлы Parquet из Azure Data Lake или Azure Blob Storage без загрузки в Склад данных. Дополнительные сведения и примеры см. в разделе "Обзор содержимого файла" с помощью функции OPENROWSET.

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

• Паркет: Попробуйте использовать Parquet вместо CSV или преобразовать CSV в Parquet, если вы часто запрашиваете файлы. Parquet — это столбцовый формат. Так как данные сжимаются, размер файла меньше, чем CSV-файлы, содержащие те же данные. Хранилище данных Fabric пропускает столбцы и строки, которые не нужны в запросе, если вы читаете файлы Parquet.
• Размер файла: Убедитесь, что каждый файл, который передается, идеально находится в диапазоне от 100 МБ до 1 ГБ для максимальной скорости обработки. Это помогает оптимизировать процесс приема и повысить производительность. Лучше иметь файлы одинакового размера.
• Количество файлов: Чтобы максимально повысить производительность параллелизма и запросов, необходимо создать большое количество файлов. При этом при сохранении минимального размера файла в 100 МБ рекомендуется создавать максимальное количество файлов.
• Раздел: Разделите данные, сохраняя секции в разные папки или имена файлов, если рабочая нагрузка фильтрует их по столбцам секционирования.
• Оценка: Попробуйте установить ROWS_PER_BATCH соответствие количеству строк в базовых файлах, если вы чувствуете, что вы не получаете ожидаемой производительности.
• Размер емкости: Для больших объемов данных рекомендуется масштабировать до большего SKU (ассортиментной единицы), чтобы получить больше вычислительных ресурсов, необходимых для размещения дополнительного количества параллельной обработки и больших объемов данных.

Избегайте постепенных вставок, обновлений и удалений

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

• Увеличение задержки запросов из-за неэффективного сканирования файлов.
• Более высокие затраты на хранение и вычислительные ресурсы.
• Повышенная зависимость от процессов фонового сжатия.

Рекомендуемые подходы.

• Пакетные транзакции, которые записываются в хранилище данных Fabric.
  • Например, вместо множества небольших INSERT операторов, заранее подготовьте данные вместе и вставьте данные в одну INSERT инструкцию.
• Используйте COPY INTO для массовых вставок и выполняйте обновления и удаления в пакетах по возможности.
• Сохраняйте минимальный импортированный размер файла размером 100 МБ, чтобы обеспечить эффективное формирование группы строк.
• Для получения дополнительных указаний и лучших практик по приему данных см. Лучшие практики по приему данных в хранилище.

Сжатие данных

В хранилище данных Fabric сжатие данных — это процесс фоновой оптимизации в хранилище данных Fabric, который объединяет небольшие, неэффективные файлы Parquet в меньшее число, более крупные файлы. Часто эти файлы создаются частыми трикл INSERT, UPDATE или DELETE операциями. Сжатие данных уменьшает фрагментацию файлов, повышает эффективность группы строк и повышает общую производительность запросов.

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

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

V-Order in Fabric Data Warehouse

V-Order — это оптимизация процесса записи для формата файла Parquet, которая позволяет быстро считывать данные в Microsoft Fabric. V-Order in Fabric Data Warehouse повышает производительность запросов, применяя сортировку и сжатие к файлам таблиц.

По умолчанию V-Order включен во всех хранилищах, чтобы обеспечить, чтобы операции чтения, особенно аналитические запросы, были максимально быстрыми и эффективными.

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

Прежде чем решить отключить V-Order, пользователи должны тщательно проверить производительность рабочей нагрузки, чтобы убедиться, что компромисс оправдан. Распространенный шаблон — использовать промежуточное хранилище с отключенным V-Order для приема данных с высокой пропускной способностью, их преобразования и загрузки исходных данных в хранилище данных с поддержкой V-Order для повышения производительности чтения. Дополнительные сведения см. в разделе "Отключение V-Order on Warehouse в Microsoft Fabric".

Клонирование таблиц вместо копирования таблиц

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

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

• Клонированные таблицы также копируют все основные функции безопасности из источника, включая Row-Level безопасность (RLS), Column-Level безопасность (CLS) и динамическое маскирование данных (DDM), без необходимости повторного применения политик после клонирования.
• Клоны можно создавать на определенный момент времени в течение периода хранения данных, поддерживая возможности перемещения по времени.
• Клонированные таблицы существуют независимо от их источника, изменения, внесенные в источник, не влияют на клон, и изменения клона не влияют на источник. Источник или клон можно удалить отдельно друг от друга.

Производительность запросов

Статистика

Статистика — это сохраненные объекты, представляющие данные в столбцах таблиц. Оптимизатор запросов использует статистику для выбора и оценки стоимости плана запроса. Конечная точка SQL аналитики для хранилища данных Fabric и Lakehouse используется для автоматического поддержания и обновления статистики гистограммы, статистики средней длины столбцов и статистики кардинальности таблиц. Дополнительные сведения см. в разделе "Статистика" в хранилище данных Fabric.

• Команды CREATE STATISTICS и UPDATE STATISTICS T-SQL поддерживаются для статистики гистограммы с одним столбцом. Их можно использовать, если между преобразованиями таблицы и рабочей нагрузкой запроса достаточно большое окно, например во время периода обслуживания или другого простоя. Это снижает вероятность того, что запросы SELECT вначале будут вынуждены обновлять статистику.
• Попробуйте определить схему таблицы, которая поддерживает четность типов данных в общих сравнениях столбцов. Например, если вы знаете, что столбцы часто сравниваются друг с другом в предложении или используются в WHERE качестве JOIN ... ON предиката, убедитесь, что типы данных соответствуют. Если невозможно использовать одинаковые типы данных, используйте аналогичные типы данных, совместимые с неявным преобразованием. Избегайте явных преобразований данных. Дополнительные сведения см. в разделе "Преобразование типов данных".

При фильтрации таблиц lakehouse по столбцу временной метки до среды выполнения Apache Spark 3.5.0 статистика на уровне групп строк для столбцов временной метки не создается. Отсутствие статистики затрудняет системам, таким как Fabric Warehouse, применение устранения групп строк (также известного как пропуск данных или выдвижение предикатов), что является оптимизацией производительности, пропускающей неуместные группы строк во время выполнения запроса. Без этих статистических данных фильтрация запросов с включением столбцов метки времени может потребовать сканировать больше данных, что приводит к значительному снижению производительности. Вы можете обновить среду выполнения Apache Spark в Fabric. Apache Spark 3.5.0 и более поздних версий могут создавать статистику на уровне строк для столбцов метки времени. Затем необходимо заново создать таблицу и загрузить данные для генерации статистики на уровне групп строк.

Производительность холодного кэша

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

Холодный запуск обычно происходит, когда:

• Данные загружаются из OneLake в память, так как к ним обращаются впервые и они ещё не кэшированы.
• Если доступ к данным осуществляется в первый раз, выполнение запроса задерживается до автоматического создания необходимой статистики .
• Хранилище данных Fabric автоматически приостанавливает узлы после некоторого периода бездействия для снижения затрат и добавляет узлы в рамках автомасштабирования. Возобновление или создание узлов обычно занимает менее одной секунды.

Эти операции могут увеличить длительность запроса. Холодные запуски могут быть частичными. Некоторые вычислительные узлы, данные или статистика уже могут быть доступны или кэшируются в памяти, а запрос ожидает, пока другие будут доступны. Дополнительные сведения см. в разделе Кэширование в хранилище данных Fabric.

Вы можете обнаружить эффекты холодного запуска, вызванные получением данных из удаленного хранилища в память, запрашивая представление queryinsights.exec_requests_history . data_scanned_remote_storage_mb Проверьте столбец:

• Значение data_scanned_remote_storage_mb, отличное от нуля, указывает на холодный запуск. Данные извлеклись из OneLake во время выполнения запроса. Последующие представления должны быть доказуемо более быстрыми queryinsights.exec_requests_history.
• Нулевое значение data_scanned_remote_storage_mb — это идеальное состояние, в котором кэшируются все данные. Для обслуживания результатов запроса не требуется никаких изменений узла или данных из OneLake.

Запросы к таблицам со строковыми столбцами

Используйте наименьшую длину строкового столбца, которая может содержать значения. Склад Fabric постоянно улучшается. Однако при использовании больших строковых типов данных может возникнуть неоптимальная производительность, особенно при работе с большими объектами (LOB). Например, для customer_name типа данных столбца учитывайте бизнес-требования и ожидаемые данные и используйте соответствующую длину n при объявлении varchar(n), например varchar(100), вместо varchar(8000) или varchar(max). Статистика и оценка затрат запросов более точны, если длина типа данных является более точной для фактических данных.

• В T-SQL хранилища данных Fabric см. рекомендации по выбору соответствующей длины для строковых типов данных.
• Строковые столбцы таблицы Lakehouse без определенной длины в Spark распознаются хранилищем Fabric как varchar(8000). Для оптимальной производительности используйте CREATE TABLE инструкцию в SparkSQL, чтобы определить строковый столбец как varchar(n), где n максимальная длина столбца, которая может содержать значения.

Транзакции и параллелизм

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

Хранилище данных Fabric поддерживает транзакции, совместимые с ACID, с помощью изоляции моментальных снимков. Это означает:

• Операции чтения и записи можно сгруппировать в одну транзакцию с помощью стандартной T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK)
• Семантика "всё или ничего": если транзакция охватывает несколько таблиц и одна операция завершается сбоем, вся транзакция откатывается.
• Согласованность чтения: SELECT запросы в транзакции видят согласованный моментальный снимок данных, не затронутый одновременными записями.

Поддержка транзакций хранилища Fabric:

• Язык определения данных (DDL) внутри транзакций: Вы можете включить CREATE TABLE в блок транзакций.
• Транзакции между базами данных: Поддерживается в одной рабочей области, включая чтение из конечных точек аналитики SQL.
• Откат на основе Parquet: Так как хранилище данных Fabric хранит данные в неизменяемых файлах Parquet, откат очень быстро выполняется. Откаты просто откатываются к предыдущим версиям файлов.
• Автоматическое сжатие данных и создание контрольных точек: Сжатие данных оптимизирует хранение и чтение, объединяя небольшие файлы Parquet и удаляя предварительно удалённые строки.
• Автоматическая контрольная точка: Каждая операция записи (INSERT, UPDATE, DELETE) добавляет новый файл журнала JSON в журнал транзакций Delta Lake. Со временем это может привести к сотням или тысячам файлов журналов, особенно в сценариях потоковой передачи или приема с высокой частотой. Автоматическая контрольная точка повышает эффективность чтения метаданных, объединяя журналы транзакций в единый файл контрольной точки. Без контрольных точек каждое чтение должно сканировать весь лог транзакций. При создании контрольной точки читается только последний файл контрольной точки и журналы, созданные после него. Это значительно сокращает анализ операций ввода-вывода и метаданных, особенно для больших или часто обновляемых таблиц.

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

Управление параллелизмом и изоляция

Хранилище данных Fabric использует исключительно изоляцию моментальных снимков. Попытки изменить уровень изоляции через T-SQL игнорируются.

Рекомендации по транзакциям

• Используйте явные транзакции мудро. Всегда COMMIT или ROLLBACK. Не оставляйте транзакции открытыми.
  • Держите транзакции короткими. Избегайте длительных транзакций, которые удерживают блокировки без необходимости, особенно для явных транзакций, содержащих DDL. Это может привести к возникновению противоречий с инструкциями в представлениях системного каталога (такими как sys.tables) и может вызвать проблемы с порталом Fabric, который полагается на представления системного каталога.
• Добавьте логику повторных попыток с задержкой в конвейерах или приложениях для обработки временных конфликтов.
  • Используйте экспоненциальную обратную передачу, чтобы избежать повторных штормов, которые ухудшают временные прерывания сети.
  • Дополнительные сведения см. в шаблоне повторных попыток.
• Отслеживайте блокировки и конфликты в хранилище.
  • Используйте sys.dm_tran_locks для проверки текущих блокировок.

Сокращение размера возвращаемого набора данных

Запросы с большим объемом данных в промежуточных этапах выполнения или в итоговом результате могут столкнуться с ухудшением производительности запросов. Чтобы уменьшить размер возвращаемого набора данных, рассмотрите следующие стратегии.

• Разделение больших таблиц в Lakehouse.
• Ограничение числа возвращаемых столбцов. SELECT * может быть дорогостоящим.
• Ограничить количество возвращаемых строк. Как можно больше фильтровать данные в хранилище, а не в клиентских приложениях.
  • Попробуйте отфильтровать данные перед выполнением операции соединения, чтобы уменьшить размер набора данных на ранних этапах выполнения запроса.
  • Фильтруйте столбцы с низкой кардинальностью, чтобы заранее сократить объём большого набора данных перед JOIN.
  • Столбцы с высокой кардинальностью идеально подходят для фильтрации и JOIN. Они часто используются в WHERE предложениях и получают преимущество от применения предиката на более ранней стадии выполнения запроса для фильтрации данных.
• В Хранилище данных Fabric не применяются ограничения первичных и уникальных ключей, поэтому столбцы с такими ограничениями не всегда подходят для объединения с помощью JOIN.

Планы запросов и подсказки запросов

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

• Пользователи могут использовать SHOWPLAN_XML в SQL Server Management Studio для просмотра плана без выполнения запроса.
• Дополнительные указания запросов можно добавить в инструкцию SQL, чтобы предоставить дополнительные инструкции оптимизатору запросов перед созданием плана. Добавление подсказок запросов требует расширенных знаний о рабочих нагрузках запросов, поэтому обычно используется после реализации других рекомендаций, но проблема сохраняется.

Немасштабируемые операции

Хранилище данных Fabric основано на архитектуре массовой параллельной обработки (MPP), где запросы выполняются на нескольких вычислительных узлах. В некоторых сценариях выполнение с одним узлом оправдано:

• Для выполнения всего плана запроса требуется только один вычислительный узел.
• Поддерево плана может поместиться в одном вычислительном узле.
• Для удовлетворения семантики запроса необходимо выполнить весь запрос или часть запроса на одном узле. Например, TOP операции, глобальная сортировка и запросы, требующие сортировки результатов от параллельных выполнений для создания одного результата, или объединения результатов на заключительном этапе.

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

• Рассмотрите возможность уменьшения размера отфильтрованного набора данных запроса.
• Если семантика запроса не требует одноузлового выполнения, попробуйте выполнить распределенный план запросов с помощью FORCE DISTRIBUTED PLAN, например OPTION (FORCE DISTRIBUTED PLAN);.

Запрос конечной точки аналитики SQL

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

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

Выполняйте регулярное обслуживание таблиц Lakehouse

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

Оптимизация таблиц или сочетаний клавиш lakehouse с большим количеством небольших файлов

Наличие большого количества небольших файлов создает затраты на чтение метаданных файла. Используйте команду OPTIMIZE на портале Fabric или записной книжке для объединения небольших файлов в большие. Повторите этот процесс при значительном изменении количества файлов.

Чтобы оптимизировать таблицу в Fabric Lakehouse, откройте Lakehouse на портале Fabric. В обозревателе щелкните правой кнопкой мыши таблицу и выберите "Обслуживание". Выберите параметры на странице команд обслуживания запуска , а затем нажмите кнопку "Запустить сейчас".

Запрос таблиц или ярлыков в хранилище данных (lakehouse), расположенных в одном регионе

Fabric использует вычисления, где расположена емкость Fabric. Запрос данных, например, из Azure Data Lake Storage или OneLake, находящихся в другом регионе, приводит к ухудшению производительности из-за сетевой задержки. Убедитесь, что данные в одном регионе. В зависимости от требований к производительности рекомендуется хранить только небольшие таблицы, такие как таблицы измерений в удаленном регионе.

Фильтруйте таблицы и ярлыки лейкхауса на одних и тех же столбцах

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

Секционирование хорошо подходит для столбцов с низкой кардинальностью или столбцов с предсказуемой кардинальностью, таких как годы или даты. Дополнительные сведения см. в руководстве по Lakehouse: Подготовка и преобразование данных Lakehouse и загрузка данных в Lakehouse с использованием разбиения на разделы.

Кластеризация хорошо подходит для столбцов высокой выборки. Если у вас есть другие столбцы, которые вы часто используете для фильтрации, кроме столбцов секционирования, рассмотрите возможность кластеризации таблицы с помощью синтаксиса Spark SQL ZORDER BY. Дополнительные сведения см. в разделе "Оптимизация таблицы Delta Lake".

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

• Журнал выполнения запросов (30 дней)

  • queryinsights.exec_requests_history
  • queryinsights.exec_sessions_history

• Агрегированная аналитика

  • queryinsights.long_running_queries
  • queryinsights.frequently_run_queries

Дополнительные сведения о представлениях queryinsights см. в статье "Аналитика запросов" в хранилище данных Fabric.

• Динамические представления жизненного цикла запросов
  • sys.dm_exec_connections
  • sys.dm_exec_sessions
  • sys.dm_exec_requests

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

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

• Область поверхности T-SQL
• Мониторинг хранилища данных Fabric
• Что такое приложение метрик емкости Microsoft Fabric?