Cómo unir tablas con join en KQL: paso a paso

Combinar datos de dos tablas es una de las tareas más comunes en el análisis de datos, y en KQL se hace con el operador join. Si trabajas con Real-Time Analytics en Microsoft Fabric, saber unir la telemetría con tablas de referencia (sensores, clientes o productos) es esencial. Esta guía te muestra cómo hacer un join en KQL, paso a paso, con ejemplos que puedes copiar y ejecutar ya.

Requisitos previos

• Un KQL Queryset en un workspace de Microsoft Fabric (o cualquier editor de Azure Data Explorer).
• Nociones básicas de KQL: usar el pipe | y el operador project.
• No necesitas cargar datos: los ejemplos crean las tablas con datatable.

Paso 1: Crear dos tablas de ejemplo

Para practicar sin depender de datos ya cargados, vamos a generar dos tablas al vuelo. El operador datatable crea tablas temporales directamente en la consulta, ideales para probar ideas sin tocar tus datos reales. Una tiene los sensores y su ubicación; la otra, las lecturas de temperatura. Fíjate en que el sensor 1 tiene dos lecturas y en que existe una lectura del sensor 4, que no aparece en la tabla 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

Ejecuta la consulta para confirmar que la tabla Leituras tiene cuatro filas.

Paso 2: Tu primer join

Vamos a unir cada lectura con la información de su sensor. La tabla a la izquierda de join es Leituras; entre paréntesis va la tabla de la derecha; y on SensorId indica la columna común. Lee el join de izquierda a derecha: para cada fila de Leituras, KQL busca una coincidencia en Sensores. Usamos kind=inner para quedarnos solo con las filas que existen en las dos tablas.

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

El resultado tiene tres filas: las dos lecturas del sensor 1 (Lisboa) y la del sensor 2 (Porto). El sensor 4 desaparece porque no existe en la tabla Sensores.

Paso 3: Cuidado con el join por defecto (el error más común)

Si olvidas el kind=, KQL asume innerunique, y el resultado puede sorprenderte. Este tipo de join elimina primero las claves repetidas de la tabla de la izquierda antes de unir. El comportamiento existe por razones de rendimiento, pero es una fuente frecuente de confusión.

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

Ahora solo aparecen dos filas: una de las lecturas del sensor 1 se descartó. Por eso, indica siempre el kind de forma explícita para no perder datos sin querer.

Paso 4: Conservar las filas sin coincidencia con leftouter

¿Y si también quieres ver el sensor 4, aunque no tenga una ubicación conocida? Usa kind=leftouter, que conserva todas las filas de la tabla de la izquierda, tengan coincidencia o no.

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

Ahora tienes cuatro filas. La fila del sensor 4 aparece con Local vacío, indicando que no hubo coincidencia.

Consejo: el lado izquierdo del join es también el que el motor carga en memoria. En consultas sobre muchos datos, pon la tabla más pequeña a la izquierda, pero recuerda que eso también cambia qué filas conserva leftouter.

Comprobar el resultado

Para confirmar que has entendido cada tipo de join, compara los recuentos: el inner devuelve 3 filas, el innerunique por defecto devuelve 2, y el leftouter devuelve 4. Es un buen hábito comprobar siempre el número de filas después de un join: los cambios inesperados en el recuento suelen ser la primera señal de un tipo de join equivocado.

Conclusión

Ya sabes unir tablas en KQL, elegir el tipo de join adecuado y evitar la trampa del innerunique. El siguiente paso es probar el operador lookup, una alternativa optimizada para enriquecer datos desde una tabla de referencia pequeña. ¿Qué tabla de referencia unirás primero a tu telemetría?