Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к:✅ Конечная точка аналитики SQL и хранилище в Microsoft Fabric
Кластеризация данных в Хранилище данных Fabric упорядочивает данные для повышения производительности запросов и уменьшения использования вычислительных ресурсов. В этом руководстве описаны шаги по созданию таблиц с кластеризации данных, от создания кластеризованных таблиц до проверки их эффективности.
Предпосылки
- Учетная запись клиента Microsoft Fabric с активной подпиской.
- Убедитесь, что у вас есть рабочая область с поддержкой Microsoft Fabric: создайте рабочую область.
- Убедитесь, что вы уже создали хранилище. Сведения о создании нового хранилища см. в статье "Создание хранилища в Microsoft Fabric".
- Базовое понимание T-SQL и запрос данных.
Импорт демонстрационных данных
В этом руководстве используется пример набора данных такси Нью-Йорка. Чтобы импортировать данные такси Нью-Йорка в хранилище. Используйте учебник по загрузке примеров данных в хранилище данных .
Создайте таблицу с кластеризацией данных
Для работы с этим руководством требуется две копии таблицы NYTaxi: обычная копия таблицы, импортируемая из учебника, и копия, использующая кластеризацию данных. Используйте следующую команду, чтобы создать новую таблицу с помощью CREATE TABLE AS SELECT CTAS на основе исходной таблицы NYTaxi:
CREATE TABLE nyctlc_With_DataClustering
WITH (CLUSTER BY (lpepPickupDatetime))
AS SELECT * FROM nyctlc
Замечание
В этом примере предполагается, что в руководстве по загрузке образцов данных в хранилище данных набору данных такси Нью-Йорка присвоено имя таблицы. Если для таблицы использовалось другое имя, измените команду, чтобы заменить nyctlc ее именем таблицы.
Эта команда создает точную копию исходной таблицы NYTaxi, но с кластеризациями данных в столбце lpepPickupDatetime . Затем мы используем этот столбец для запроса.
Запрос данных
Запустите запрос в таблице NYTaxi и повторите тот же запрос в таблице NYTaxi_With_DataClustering для сравнения.
Замечание
Для этого анализа полезно взглянуть на производительность холодного кэша обоих запусков, т. е. без использования функций кэширования хранилища данных Fabric. Таким образом, запустите каждый запрос ровно один раз, прежде чем просмотреть результаты в Query Insights.
Мы используем запрос, который часто повторяется в хранилище. Этот запрос вычисляет среднюю сумму тарифа по годам между датами 2008-12-31 и 2014-06-30:
SELECT
YEAR(lpepPickupDatetime),
AVG(fareAmount) as [Average Fare]
FROM
NYTaxi
WHERE
lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY
YEAR(lpepPickupDatetime)
ORDER BY
YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Regular');
Замечание
Параметр метки, используемый в этом запросе, полезен при сравнении сведений запроса Regular этой таблицы с запросом, который использует кластеризацию данных позже с помощью представлений Query Insights.
Затем мы повторяем тот же запрос, но в версии таблицы, которая использует кластеризацию данных:
SELECT
YEAR(lpepPickupDatetime),
AVG(fareAmount) as [Average Fare]
FROM
NYTaxi_With_DataClustering
WHERE
lpepPickupDatetime BETWEEN '2008-12-31' AND '2014-06-30'
GROUP BY
YEAR(lpepPickupDatetime)
ORDER BY
YEAR(lpepPickupDatetime) DESC
OPTION (LABEL = 'Clustered');
Второй запрос использует метку Clustered , чтобы разрешить нам определить этот запрос позже с помощью Query Insights.
Проверка эффективности кластеризации данных
После настройки кластеризации можно оценить его эффективность с помощью Query Insights. Аналитика запросов в хранилище данных Fabric записывает данные о выполнении исторических запросов и объединяет их в полезные аналитические сведения, такие как определение длительных или часто выполняемых запросов.
В этом случае мы используем Аналитику запросов для сравнения различий в данных, отсканированных между обычными и кластеризованными вариантами.
Используйте следующий запрос:
SELECT
label,
submit_time,
row_count,
total_elapsed_time_ms,
allocated_cpu_time_ms,
result_cache_hit,
data_scanned_disk_mb,
data_scanned_memory_mb,
data_scanned_remote_storage_mb,
command
FROM
queryinsights.exec_requests_history
WHERE
command LIKE '%NYTaxi%'
AND label IN ('Regular','Clustered')
ORDER BY
submit_time DESC;
Этот запрос извлекает сведения из представления exec_requests_history. Дополнительные сведения см. в разделе queryinsights.exec_requests_history (Transact-SQL).
Запрос фильтрует результаты следующим образом:
- Извлекает только строки, содержащие
NYTaxiтекст в имени команды (как было использовано в тестовых запросах). - Извлекает только строки, в которых значение метки было обычным или кластеризованным
Замечание
Для получения сведений о запросе в Службе "Аналитика запросов" может потребоваться несколько минут. Если запрос Query Insights не возвращает результатов, повторите попытку через несколько минут.
При выполнении этого запроса мы наблюдаем следующие результаты:
Оба запроса имеют по 6 строк и аналогичное время отправки. Запрос Clustered показывает total_elapsed_time_ms 1794, allocated_cpu_time_ms 1676 и data_scanned_remote_storage_mb 77,519. Запрос Regular показывает total_elapsed_time_ms 2651, allocated_cpu_time_ms 2600 и data_scanned_remote_storage_mb 177,700. Эти числа показывают, что, хотя оба запроса возвращали одинаковые результаты, Clustered версия использовала примерно 36% меньше времени ЦП, чем Regular версия, и сканировала примерно 56% меньше данных на диске. В любом выполнении запроса не использовался кэш. Это важные результаты, которые помогут сократить время выполнения запросов и использование и сделать lpepPickupDatetime столбец надежным кандидатом для кластеризации данных.
Замечание
Это небольшая таблица с примерно 76 миллионами строк и объемом данных 2 ГБ. Несмотря на то, что этот запрос возвращает только шесть строк в агрегировании (по одному за каждый год в диапазоне), он сканирует примерно 8,3 миллиона строк в диапазоне дат, предоставленных перед агрегированием результатов. Фактические рабочие данные с большими объемами данных могут обеспечить более значительные результаты. Результаты могут отличаться в зависимости от размера емкости, кэшированных результатов или параллелизма во время запросов.