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

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

En esta lección me centro en una competencia práctica del DP-700: optimizar consultas con Kusto Query Language (KQL) en entornos de Fabric. Saber optimizar KQL es crucial para respuestas rápidas, reducción de costes y una buena experiencia de los usuarios de informes, dashboards y pipelines de ingestión. Consultas ineficientes pueden transformar un análisis simple en tareas que duran minutos u horas y generan costes elevados por I/O y computación.

Qué necesitas saber

Kusto Query Language (KQL) es el lenguaje usado para consultar tablas en varios componentes de Fabric (por ejemplo, Explorer y algunos data pools). Optimizar consultas significa reducir tiempo de ejecución, uso de CPU/memoria e I/O de disco/red. Los conceptos clave que debes dominar son:

Filtrado temprano: aplicar where/filters lo antes posible para reducir el número de filas procesadas — idealmente antes de operaciones costosas como joins y agregaciones.
Project: seleccionar solo las columnas necesarias para reducir transferencia de datos y ancho de fila; reducir de decenas de columnas a 3–5 puede cortar el volumen de datos por 10x o más.
Summarize y bin(): las agregaciones deben planearse; usar bin() para agrupar timestamps reduce complejidad y permite al motor optimizar agregaciones temporales.
Join eficiente: preferir joins por hash cuando el motor lo soporta; reducir cada lado del join (filtrar y projectar) y evitar joins cruzados (cartesianos).
Materializar resultados: usar materialized views, caching o persistir resultados intermedios cuando una consulta se ejecuta con frecuencia (por ejemplo, dashboards con actualización cada 5 minutos).

Ejemplo conceptual: imagina una tabla Telemetry con 100 millones de filas (aprox. 100 GB) y 50 columnas. Una consulta que lea todas las columnas para solo calcular una media sobre 7 días puede leer 100 GB; aplicando where timestamp y project para 3 columnas puedes reducir el volumen leído a ~2–5 GB y bajar el tiempo de segundos/minutos a unos pocos segundos.

Cómo funciona en la práctica

A continuación muestro transformaciones paso a paso, con snippets KQL reales y explicaciones de por qué cada cambio mejora el rendimiento. Asumiré un ejemplo típico: Telemetry con millones de filas por día.

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

Problemas: aunque el where esté presente, si la tabla tiene muchas columnas y el motor se ve obligado a leer bloques enteros, puede aún transferir mucha información. Además, ordenar sin necesidad puede forzar una etapa global de ordenación.

// Mejorada: filtra y projecta temprano, reduce datos antes del summarize
Telemetry
| where Timestamp >= ago(7d)
| project Timestamp, DeviceId, Value
| summarize AvgValue = avg(Value) by DeviceId, bin(Timestamp, 1h)
| order by Timestamp desc

Explicación: project reduce el ancho de la fila — por ejemplo, de 1 KB a 80 B por fila — disminuyendo la cantidad de datos movidos entre nodos. Aplicar bin() en el agrupamiento permite al motor agrupar por ventanas fijas, lo que normalmente acelera agregaciones temporales y reduce la cardinalidad de los grupos.

// Si solo algunos dispositivos son relevantes, filtrar primero por DeviceId
let devices = datatable(DeviceId:string)["devA","devB","devC"];  // ejemplo con 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 un conjunto pequeño de DeviceId reduce considerablemente el volumen: si la tabla tiene 50M de filas por semana y solo el 0,5% son de esos dispositivos, pasas de 50M a 250k filas — una reducción de 200x.

Para joins:

// Join ineficiente: join de tablas grandes sin prefiltrar
Telemetry
| where Timestamp >= ago(7d)
| join kind=inner Devices on DeviceId

// Mejor: reducir cada lado antes del 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

Prefiltrar y projectar reduce el coste del hash join y el movimiento de datos. En escenarios prácticos, reducir cada tabla al 5–10% del tamaño original puede transformar un join que consumía 30 GB de memoria en una operación que pasa fácilmente por 2–3 GB.

Errores comunes

Mantener SELECT * (o equivalente) y no projectar columnas innecesarias: esto aumenta I/O y latencia.
Aplicar filtros tarde en la pipeline: colocar where después de joins/agregaciones obliga al motor a procesar conjuntos mucho mayores.
Ignorar la cardinalidad antes de joins/agregaciones: unir tablas con elevada cardinalidad sin reducir previamente puede causar picos de memoria y fallos por falta de recursos.
Ordenar cuando no es necesario: order by puede forzar etapas de shuffle/disco; evítalo en pipelines intermedios a menos que realmente necesites los datos ordenados.

Cómo practicar

Para practicar, usa entornos de entrenamiento de Fabric y conjuntos de datos públicos (por ejemplo, telemetría, logs o conjuntos de GitHub). Experimenta midiendo tiempos antes/después: por ejemplo, ejecuta una consulta inicial y registra el tiempo de ejecución y bytes leídos; aplica project/where temprano y compara. Microsoft pone a disposición un Practice Assessment OFICIAL y gratuito para el DP-700 y una study guide gratuita con temas y recursos — consulta esos materiales oficiales para orientar tu práctica. Evita copiar preguntas de exámenes; el objetivo es dominar las competencias para ser eficaz en el trabajo real.

En resumen

Filtrar temprano y projectar solo las columnas necesarias reduce significativamente el coste de las consultas KQL — a menudo 10x–200x en el volumen de datos procesados.
Planifica joins: prefiltra y reduce cardinalidad antes de unir tablas grandes para evitar picos de memoria.
Usa bin() y summarize de forma apropiada para agregaciones temporales; considera materializar vistas para consultas repetidas y dashboards con actualizaciones frecuentes.
Practica en el entorno Fabric, mide antes/después y usa el Practice Assessment y la study guide oficiales de Microsoft para prepararte de forma responsable y eficaz.