Рекомендации по производительности в Data Warehouse Fabric

Применимо к:✅ Warehouse в Microsoft Fabric

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

Подсказка

Для комплексных межнапряженных рекомендаций по оптимизации стратегий таблиц Delta, включая рекомендации по таблицам, записываемым с использованием Spark или зеркально отображаемым, которые используются в Data Warehouse Fabric, см. статью Обслуживание и оптимизация таблиц рабочих нагрузок.

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

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

Статистика

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

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

Подсказка

Для пользователей Lakehouse статистика ACE-Cardinality может использовать сведения из файлов журнала Delta ваших таблиц, чтобы быть более точной. Убедитесь, что таблицы Delta, созданные Spark, включают количество строк таблицы с помощью: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Дополнительные сведения см. в статье "Настройка автоматизированной статистики таблиц" и управление ими в Fabric Spark.

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

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

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

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

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

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

Кэширование в памяти и диске в Data Warehouse Fabric полностью прозрачно и автоматически включено. Кэширование умно сокращает потребность в удаленных чтениях из хранилища путем использования локальных кэшей. Data Warehouse 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.

Это важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отправьте запрос к конечной точке аналитики SQL

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

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

Подсказка

Следующие рекомендации применяются к использованию Spark для обработки данных в лейкхаусе, который может быть запрошен через конечную точку 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".

Кластеризация данных

Вы также можете выполнять кластеризацию данных по определенным столбцам в CREATE TABLE и CREATE TABLE AS SELECT инструкциях T-SQL (CTAS). Кластеризация данных работает путем хранения строк с аналогичными значениями в смежных расположениях на хранилище в процессе записи данных.

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

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

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

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

Для получения дополнительной информации о типах данных, поддерживаемых Fabric Data Warehouse, см. раздел Типы данных в Fabric Data Warehouse.

Подсказка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Копировать в

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

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

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

Data Warehouse 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 Storage с помощью OPENROWSET

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

Дополнительные сведения и примеры запроса внешних данных см. в статье Запрос внешних файлов озера данных с использованием Fabric Data Warehouse или конечной точки SQL Analytics.

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

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

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

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

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

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

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

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

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

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

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

Предварительная обработка уплотнения данных

Структура Data Warehouse интеллектуально и активно избегает конфликтов записи между фоновыми задачами сжатия и операциями пользователей. Начиная с октября 2025 г. включено предварительное сжатие данных.

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

По-прежнему возможны конфликты одновременной записи с фоновым сервисом сжатия данных Fabric Data Warehouse. Можно создать конфликт записи-записи с сжатием данных, например, если приложение использует явную транзакцию и выполняет неконфликтную работу (например, INSERT) перед конфликтующей операцией (UPDATE, DELETE, MERGE). Сжатие данных может быть успешно завершено, вследствие чего явная транзакция впоследствии завершится неудачей из-за конфликта. Дополнительные сведения о конфликтах при одновременной записи или обновлении см. в разделе Транзакции в таблицах Warehouse в Microsoft Fabric.

V-Order в хранилище данных Fabric

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on