Рекомендации по производительности Хранилища данных Synapse в Microsoft Fabric
Область применения:✅ хранилище в Microsoft Fabric
Это рекомендации, которые помогут вам понять производительность хранилища в Microsoft Fabric. В этой статье вы найдете рекомендации и важные статьи, на которые следует сосредоточиться. Хранилище в Microsoft Fabric — это платформа SaaS, где такие действия, как управление рабочими нагрузками, параллелизм и управление хранилищами, управляются внутренне платформой. Помимо этого внутреннего управления производительностью, вы по-прежнему можете повысить производительность, разрабатывая выполняемые запросы к хорошо разработанным хранилищам.
Производительность холодного запуска (холодный кэш)
Кэширование с локальным SSD и памятью выполняется автоматически. Первые 1-3 выполнения запроса выполняются заметно медленнее последующих выполнений. Если у вас возникают проблемы с производительностью холодного запуска, ниже приведены некоторые действия, которые могут повысить производительность холодного запуска:
Если производительность первого запуска имеет решающее значение, попробуйте создать статистику вручную. Ознакомьтесь со статьей статистики, чтобы лучше понять роль статистики и рекомендации по созданию статистики вручную для повышения производительности запросов. Однако если производительность первого запуска не является критической, вы можете полагаться на автоматическую статистику, которая будет создана в первом запросе и будет использоваться в последующих запусках (если базовые данные не изменяются значительно).
Если используется Power BI, используйте режим Direct Lake по возможности.
Метрики для мониторинга производительности
В настоящее время Центр мониторинга не включает хранилище. Если вы выберете хранилище данных, вы не сможете получить доступ к Центру мониторинга из панели навигации.
Администраторы Структуры смогут получить доступ к отчету об использовании емкости и метрик для актуальной информации для отслеживания использования емкости, включающей хранилище.
Мониторинг выполнения запросов с помощью динамических административных представлений (DMV)
Динамические административные представления (DMV) можно использовать для мониторинга состояния подключения, сеанса и запроса в хранилище.
Статистика
Хранилище использует обработчик запросов для создания плана выполнения для заданного SQL-запроса. При отправке запроса оптимизатор запросов пытается перечислить все возможные планы и выбрать наиболее эффективного кандидата. Чтобы определить, какой план требует наименьших накладных расходов, подсистема должна иметь возможность оценить объем работы или строк, которые могут обрабатываться каждым оператором. Затем, на основе стоимости каждого плана, он выбирает один с наименьшим объемом предполагаемой работы. Статистика — это объекты, содержащие соответствующие сведения о данных, чтобы оптимизатор запросов могли оценить эти затраты.
Вы также можете вручную обновить статистику после каждой загрузки данных или обновления данных, чтобы убедиться, что лучший план запроса можно создать.
Дополнительные сведения о статистике и способах расширения автоматически созданной статистики см. в разделе "Статистика в хранилище данных Fabric".
Рекомендации по приему данных
Существует четыре варианта приема данных в хранилище:
- COPY (Transact-SQL)
- Конвейеры данных
- Потоки данных
- Прием между складами
Чтобы определить, какой вариант лучше всего подходит для вас, и просмотреть некоторые рекомендации по приему данных, просмотрите данные приема.
Группирование инструкций INSERT в пакеты (избегайте вставок)
Однократная загрузка в небольшую таблицу с инструкцией INSERT, например показанная в следующем примере, может быть оптимальным подходом в зависимости от ваших потребностей. Однако если вам нужно загрузить тысячи или миллионы строк в течение дня, одноэлементные вставки не являются оптимальными.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Рекомендации по обработке этих сценариев простой нагрузки см . в рекомендациях по приему данных.
Уменьшение размера транзакций
Инструкции INSERT, UPDATE и DELETE выполняются в транзакции. В случае сбоя их нужно откатить. Чтобы сократить время выполнения отката, необходимо по возможности уменьшить размеры транзакций. Это можно сделать, разделив инструкции INSERT, UPDATE и DELETE на части. Например, если вы ожидаете, что операция INSERT будет выполняться 1 час, ее можно разделить на четыре части. Таким образом, время каждого выполнения сократится до 15 минут.
Рекомендуется использовать CTAS (Transact-SQL) для записи данных, которые вы хотите сохранить в таблице, а не с помощью DELETE. Если CTAS занимает то же время, это безопаснее выполняться, так как оно имеет минимальное ведение журнала транзакций и может быть отменено быстро при необходимости.
Объединение клиентских приложений и Microsoft Fabric
Если вы используете клиентские приложения, убедитесь, что вы используете Microsoft Fabric в регионе, близком к клиентскому компьютеру. Примеры клиентских приложений включают Power BI Desktop, SQL Server Management Studio и Azure Data Studio.
Использование структуры данных схемы звезды
Схема звезды упорядочивает данные в таблицы фактов и таблицы измерений. Это упрощает аналитическую обработку путем денормализации данных из высоко нормализованных систем OLTP, приема транзакционных данных и корпоративных основных данных в общую, очищаемую и проверенную структуру данных, которая сводит к минимуму соединения во время запроса, уменьшает количество строк считывания и упрощает агрегирование и группирование.
Дополнительные рекомендации по проектированию хранилища см. в таблицах в хранилище данных.
Уменьшение размера результирующих наборов запросов
Сокращение размеров результирующих наборов запросов помогает избежать проблем на стороне клиента, вызванных большими результатами запроса. Наборы результатов редактора SQL-запросов ограничены первыми 10 000 строками, чтобы избежать этих проблем в этом пользовательском интерфейсе на основе браузера. Если вам нужно вернуть более 10 000 строк, используйте SQL Server Management Studio (SSMS) или Azure Data Studio.
Выбор оптимального типа данных для производительности
При определении таблиц используйте наименьший тип данных, поддерживающий данные, так как это позволит повысить производительность запросов. Эта рекомендация важна для столбцов CHAR и VARCHAR. Если самое длинное значение в столбце состоит из 25 знаков, столбец необходимо определить как VARCHAR(25). Избегайте определения всех столбцов символов с большой длиной по умолчанию.
По возможности используйте целочисленные типы данных. Операции SORT, JOIN и GROUP BY выполняются быстрее на основе целых чисел, чем на основе символьных данных.
Поддерживаемые типы данных и дополнительные сведения см. в разделе "Типы данных".
Производительность конечной точки аналитики SQL
Сведения и рекомендации по производительности конечной точки аналитики SQL см . в рекомендациях по производительности конечных точек аналитики SQL.
Сжатие данных
Сжатие данных объединяет небольшие файлы Parquet в меньшее число, более крупные файлы, что оптимизирует операции чтения. Этот процесс также помогает эффективно управлять удаленными строками, устраняя их из неизменяемых файлов Parquet. Процесс сжатия данных включает повторное написание таблиц или сегментов таблиц в новые файлы Parquet, оптимизированные для производительности. Дополнительные сведения см. в блоге : автоматическое сжатие данных для хранилища Fabric.
Процесс сжатия данных легко интегрируется в хранилище. По мере выполнения запросов система определяет таблицы, которые могут воспользоваться сжатием и выполнить необходимые оценки. Нет ручного способа активировать сжатие данных.