Como juntar tabelas com join em KQL: passo a passo

Combinar dados de duas tabelas é uma das tarefas mais comuns em análise de dados — e em KQL faz-se com o operador join. Se trabalhas com Real-Time Analytics no Microsoft Fabric, saber juntar telemetria com tabelas de referência (sensores, clientes ou produtos) é essencial. Este guia mostra-te como fazer um join em KQL, passo a passo, com exemplos que podes copiar e correr já.

Pré-requisitos

• Um KQL Queryset num workspace do Microsoft Fabric (ou qualquer editor de Azure Data Explorer).
• Noções básicas de KQL: usar o pipe | e o operador project.
• Não precisas de carregar dados: os exemplos criam as tabelas com datatable.

Passo 1: Criar duas tabelas de exemplo

Para praticares sem depender de dados já carregados, vamos gerar duas tabelas na hora. O operador datatable cria tabelas temporárias diretamente na consulta, ideais para testar ideias sem tocar nos teus dados reais. Uma tem os sensores e a sua localização; a outra, as leituras de temperatura. Repara que o sensor 1 tem duas leituras e que existe uma leitura do sensor 4, que não aparece na tabela de sensores.

let Sensores = datatable(SensorId: int, Local: string)
[
    1, "Lisboa",
    2, "Porto",
    3, "Faro"
];
let Leituras = datatable(SensorId: int, Temperatura: real)
[
    1, 21.5,
    2, 19.8,
    1, 22.1,
    4, 30.0
];
Leituras
| take 10

Corre a consulta para confirmar que a tabela Leituras tem quatro linhas.

Passo 2: O primeiro join

Vamos juntar cada leitura à informação do seu sensor. A tabela à esquerda do join é a Leituras; entre parênteses fica a tabela da direita; e on SensorId indica a coluna comum. Lê o join da esquerda para a direita: para cada linha da Leituras, o KQL procura uma correspondência na Sensores. Usamos kind=inner para ficar só com as linhas que existem nas duas tabelas.

Leituras
| join kind=inner (Sensores) on SensorId
| project SensorId, Local, Temperatura

O resultado tem três linhas: as duas leituras do sensor 1 (Lisboa) e a do sensor 2 (Porto). O sensor 4 desaparece porque não existe na tabela Sensores.

Passo 3: Cuidado com o join por omissão (o erro mais comum)

Se te esqueceres do kind=, o KQL assume innerunique — e o resultado pode surpreender-te. Este tipo de join elimina primeiro as chaves repetidas da tabela da esquerda antes de juntar. O comportamento existe por razões de desempenho, mas é uma fonte frequente de confusão.

Leituras
| join (Sensores) on SensorId
| project SensorId, Local, Temperatura

Agora só aparecem duas linhas: uma das leituras do sensor 1 foi descartada. Por isso, indica sempre o kind de forma explícita para não perderes dados sem querer.

Passo 4: Manter as linhas sem correspondência com leftouter

E se quiseres ver também o sensor 4, mesmo sem localização conhecida? Usa kind=leftouter, que mantém todas as linhas da tabela da esquerda, tenham ou não correspondência.

Leituras
| join kind=leftouter (Sensores) on SensorId
| project SensorId, Local, Temperatura
| sort by SensorId asc

Agora tens quatro linhas. A linha do sensor 4 aparece com Local vazio, sinalizando que não houve correspondência.

Dica: o lado esquerdo do join é também o que o motor carrega em memória. Em consultas com muitos dados, coloca a tabela mais pequena à esquerda — mas lembra-te de que isso muda também quais as linhas que o leftouter preserva.

Verificar o resultado

Para confirmares que percebeste cada tipo de join, compara as contagens: o inner devolve 3 linhas, o innerunique por omissão devolve 2, e o leftouter devolve 4. É um bom hábito verificar sempre o número de linhas depois de um join: mudanças inesperadas na contagem costumam ser o primeiro sinal de um tipo de join errado.

Conclusão

Já consegues juntar tabelas em KQL, escolher o tipo de join certo e evitar a armadilha do innerunique. O próximo passo é experimentar o operador lookup, uma alternativa otimizada para enriquecer dados a partir de uma tabela de referência pequena. Qual é a tabela de referência que vais juntar à tua telemetria primeiro?