DP-700: optimizar consultas Kusto Query Language (KQL) em Fabric

João Barros 26 de August de 2026 5 min de leitura

Nesta lição foco numa competência prática do DP-700: optimizar consultas com Kusto Query Language (KQL) em ambientes do Fabric. Saber optimizar KQL é crucial para respostas rápidas, redução de custos e boa experiência dos utilizadores de relatórios, dashboards e pipelines de ingestão. Consultas ineficientes podem transformar uma análise simples em tarefas que demoram minutos ou horas e geram custos elevados por I/O e computação.

O que precisas de saber

Kusto Query Language (KQL) é a linguagem usada para interrogar tabelas em vários componentes do Fabric (por exemplo, Explorer e alguns data pools). Optimizar consultas significa reduzir tempo de execução, uso de CPU/memória e I/O de disco/rede. Os conceitos-chave que deves dominar são:

Filtragem precoce: aplicar where/filters o mais cedo possível para reduzir o número de linhas processadas — idealmente antes de operações dispendiosas como joins e agregações.
Project: seleccionar apenas as colunas necessárias para reduzir transferência de dados e largura de linha; reduzir de dezenas de colunas para 3–5 pode cortar o volume de dados por 10x ou mais.
Summarize e bin(): agregações devem ser planeadas; usar bin() para agrupar timestamps reduz complexidade e permite ao motor optimizar agregações temporais.
Join eficiente: preferir joins por hash quando o motor o suporta; reduzir cada lado do join (filtrar e projectar) e evitar joins cruzados (cartesianos).
Materializar resultados: usar materialized views, caching ou persistir resultados intermédios quando uma consulta é executada frequentemente (por exemplo, dashboards com actualização a cada 5 minutos).

Exemplo conceptual: imagina uma tabela Telemetry com 100 milhões de linhas (aprox. 100 GB) e 50 colunas. Uma consulta que leia todas as colunas para apenas calcular uma média sobre 7 dias pode ler 100 GB; aplicando where timestamp e project para 3 colunas podes reduzir o volume lido para ~2–5 GB e baixar o tempo de segundos/minutos para alguns segundos.

Como funciona na prática

A seguir mostro transformações passo a passo, com snippets KQL reais e explicações de porquê cada mudança melhora o desempenho. Vou assumir um exemplo típico: Telemetry com milhões de linhas por dia.

// Consulta inicial (ineficiente):
Telemetry
| where Timestamp >= ago(7d)
| summarize AvgValue = avg(Value) by DeviceId, bin(Timestamp, 1h)
| order by Timestamp desc

Problemas: embora o where esteja presente, se a tabela tiver muitas colunas e o motor for obrigado a ler blocos inteiros, pode ainda transferir muita informação. Além disso, ordenar sem necessidade pode forçar uma etapa global de ordenação.

// Melhorada: filtra e projecta cedo, reduz dados antes do summarize
Telemetry
| where Timestamp >= ago(7d)
| project Timestamp, DeviceId, Value
| summarize AvgValue = avg(Value) by DeviceId, bin(Timestamp, 1h)
| order by Timestamp desc

Explicação: project reduz a largura da linha — por exemplo, de 1 KB para 80 B por linha — diminuindo a quantidade de dados movimentados entre nós. Aplicar bin() no agrupamento permite ao motor agrupar por janelas fixas, o que normalmente acelera agregações temporais e diminui a cardinalidade dos grupos.

// Se apenas alguns dispositivos são relevantes, filtrar primeiro por DeviceId
let devices = datatable(DeviceId:string)["devA","devB","devC"];  // exemplo com 3 dispositivos
Telemetry
| where Timestamp >= ago(7d) and DeviceId in (devices)
| project Timestamp, DeviceId, Value
| summarize AvgValue = avg(Value) by DeviceId, bin(Timestamp, 1h)

Usar um conjunto pequeno de DeviceId reduz consideravelmente o volume: se a tabela tiver 50M de linhas por semana e apenas 0,5% forem desses dispositivos, passas de 50M para 250k linhas — uma redução de 200x.

Para joins:

// Join ineficiente: join de tabelas grandes sem pré-filtrar
Telemetry
| where Timestamp >= ago(7d)
| join kind=inner Devices on DeviceId

// Melhor: reduzir cada lado antes do join
let Tsmall = Telemetry | where Timestamp >= ago(7d) | project DeviceId, Timestamp, Value;
let Dsmall = Devices | project DeviceId, Region;
Tsmall
| join kind=inner (Dsmall) on DeviceId

Pré-filtrar e projectar reduz o custo do hash join e a movimentação de dados. Em cenários práticos, reduzir cada tabela para 5–10% do tamanho original pode transformar um join que consumia 30 GB de memória numa operação que passa facilmente por 2–3 GB.

Erros comuns

Manter SELECT * (ou equivalente) e não projectar colunas desnecessárias: isto aumenta I/O e latência.
Aplicar filtros tarde na pipeline: colocar where após joins/agregações obriga o motor a processar conjuntos muito maiores.
Ignorar cardinalidade antes de joins/agregações: juntar tabelas com elevada cardinalidade sem reduzir previamente pode causar picos de memória e falhas por falta de recursos.
Ordenar quando não é necessário: order by pode forçar etapas de shuffle/disco; evita-o em pipelines intermédios a não ser que realmente precises dos dados ordenados.

Como praticar

Para praticar, usa ambientes de treino do Fabric e conjuntos de dados públicos (por exemplo, telemetria, logs ou conjuntos do GitHub). Experimenta medir tempos antes/depois: por exemplo, executa uma consulta inicial e regista o tempo de execução e bytes lidos; aplica project/where precoce e compara. A Microsoft disponibiliza um Practice Assessment OFICIAL e gratuito para o DP-700 e uma study guide gratuita com tópicos e recursos — consulta esses materiais oficiais para orientar a tua prática. Evita copiar perguntas de exames; o objetivo é dominar as competências para seres eficaz no trabalho real.

Em resumo

Filtrar cedo e projectar apenas as colunas necessárias reduz significativamente o custo das consultas KQL — muitas vezes 10x–200x no volume de dados processados.
Planeia joins: pré-filtra e reduz cardinalidade antes de juntar tabelas grandes para evitar picos de memória.
Usa bin() e summarize de forma apropriada para agregações temporais; considera materializar vistas para consultas repetidas e dashboards com actualizações frequentes.
Pratica no ambiente Fabric, mede antes/depois e usa o Practice Assessment e study guide oficiais da Microsoft para te preparares de forma responsável e eficaz.