Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:✅ Endpoint de análise de SQL e Armazém de Dados no Microsoft Fabric
O clustering de dados no Fabric Data Warehouse organiza dados para um desempenho de consulta mais rápido e redução do uso de computação. Este tutorial explica as etapas para criar tabelas com clustering de dados, desde a criação de tabelas clusterizadas até verificar sua eficácia.
Pré-requisitos
- Uma conta de locatário do Microsoft Fabric com uma assinatura ativa.
- Certifique-se que você tenha um workspace habilitado para o Microsoft Fabric: Criar um workspace.
- Verifique se você já criou um Warehouse. Para criar um novo Warehouse, consulte Criar um Warehouse no Microsoft Fabric.
- Compreensão básica do T-SQL e da consulta de dados.
Importar dados de exemplo
Este tutorial usa o conjunto de dados de exemplo do NY Taxi. Para importar os dados do NY Taxi para o seu armazém de dados. Use o tutorial Carregar Dados de Exemplo para Data Warehouse.
Crie uma tabela com clustering de dados
Para este tutorial, precisamos de duas cópias da tabela NYTaxi: uma cópia regular da tabela conforme importada do tutorial e uma cópia que utiliza agrupamento de dados. Use o seguinte comando para criar uma nova tabela usando CREATE TABLE AS SELECT (CTAS), com base na tabela NYTaxi original:
CREATE TABLE nyctlc_With_DataClustering
WITH (CLUSTER BY (lpepPickupDatetime))
AS SELECT * FROM nyctlc
Observação
O exemplo pressupõe o nome da tabela fornecido ao conjunto de dados do NY Taxi no tutorial Carregar Dados de Exemplo para Data Warehouse. Se você usou um nome diferente para sua tabela, ajuste o comando para substituir nyctlc pelo nome da tabela.
Esse comando cria uma cópia exata da tabela NYTaxi original, mas com os dados agrupados na coluna lpepPickupDatetime. Em seguida, usamos essa coluna para consulta.
Consultar dados
Execute uma consulta na tabela NYTaxi e repita exatamente a mesma consulta na tabela NYTaxi_With_DataClustering para comparação.
Observação
Para essa análise, é benéfico examinar o desempenho de cache frio de ambas as execuções, ou seja, sem usar os recursos de cache do Fabric Data Warehouse. Portanto, execute cada consulta exatamente uma vez antes de examinar os resultados no Query Insights.
Usamos uma consulta que geralmente é repetida no Warehouse. Essa consulta calcula o valor médio da tarifa por ano entre as datas 2008-12-31 e 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');
Observação
A opção de rótulo usada nesta consulta é útil quando comparamos os detalhes dessa consulta da tabela Regular com a que posteriormente utiliza clustering de dados por meio das visualizações do Query Insights.
Em seguida, repetimos exatamente a mesma consulta, mas na versão da tabela que usa o clustering de dados:
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');
A segunda consulta usa o rótulo Clustered para nos permitir identificar essa consulta posteriormente com o Query Insights.
Verificar a eficácia do clustering de dados
Depois de configurar o clustering, você pode avaliar sua eficácia usando o Query Insights. O Query Insights no Fabric Data Warehouse captura dados históricos de execução de consulta e os agrega em insights acionáveis, como identificar consultas de execução longa ou executadas com frequência.
Nesse caso, usamos o Query Insights para comparar a diferença nos dados verificados entre os casos regulares e clusterizados.
Utilize a seguinte consulta:
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;
Essa consulta busca detalhes da exibição exec_requests_history . Para obter mais informações, consulte queryinsights.exec_requests_history (Transact-SQL).
A consulta filtra os resultados das seguintes maneiras:
- Busca apenas linhas que contêm o
NYTaxitexto no nome do comando (como foi usado nas consultas de teste) - Busca apenas linhas em que o valor do rótulo seja regular ou agrupado
Observação
Pode levar alguns minutos para que os detalhes da consulta fiquem disponíveis no Query Insights. Se a consulta do Query Insights não retornar resultados, tente novamente após alguns minutos.
Executando esta consulta, observamos os seguintes resultados:
Ambas as consultas têm uma contagem de linhas de 6 e tempos de envio semelhantes. A Clustered consulta mostra total_elapsed_time_ms de 1794, allocated_cpu_time_ms de 1676, e data_scanned_remote_storage_mb de 77.519. A Regular consulta mostra total_elapsed_time_ms de 2651, allocated_cpu_time_ms de 2600 e data_scanned_remote_storage_mb de 177.700. Esses números demonstram que, embora ambas as consultas tenham retornado os mesmos resultados, a Clustered versão usou aproximadamente 36% menos tempo de CPU do que a Regular versão e verificou aproximadamente 56% menos dados em disco. Nenhum cache foi usado em qualquer execução de consulta. Esses são resultados significativos para ajudar a reduzir o tempo de execução da consulta e o consumo, e tornar a lpepPickupDatetime coluna uma forte candidata ao agrupamento de dados.
Observação
Esta é uma tabela pequena, com aproximadamente 76 milhões de linhas e 2 GB de volume de dados. Embora essa consulta retorne apenas seis linhas em sua agregação (uma para cada ano no intervalo), ela verifica aproximadamente 8,3 milhões de linhas no intervalo de datas fornecido antes da agregação dos resultados. Dados de produção reais com volumes de dados maiores podem fornecer resultados mais significativos. Seus resultados podem variar com base no tamanho da capacidade, nos resultados armazenados em cache ou na simultaneidade durante as consultas.