Поделиться через


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

Применимо к:✅ Конечная точка аналитики SQL и хранилище в Microsoft Fabric

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

Предпосылки

Импорт демонстрационных данных

В этом руководстве используется пример набора данных такси Нью-Йорка. Чтобы импортировать данные такси Нью-Йорка в хранилище. Используйте учебник по загрузке примеров данных в хранилище данных .

Создайте таблицу с кластеризацией данных

Для работы с этим руководством требуется две копии таблицы 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 миллиона строк в диапазоне дат, предоставленных перед агрегированием результатов. Фактические рабочие данные с большими объемами данных могут обеспечить более значительные результаты. Результаты могут отличаться в зависимости от размера емкости, кэшированных результатов или параллелизма во время запросов.