DP-900: cómo entender y usar consultas analíticas con KQL en Azure Data Explorer

João Barros 11 de September de 2026 5 min de lectura

Voy a enseñar la competencia: comprender y usar consultas analíticas con Kusto Query Language (KQL) en Azure Data Explorer — una competencia útil para el DP-900 porque demuestra cómo explorar grandes volúmenes de datos de telemetría y registros en Azure. KQL se usa ampliamente en escenarios de observabilidad, IoT y analytics, y mostrar que sabes construir consultas eficientes e interpretarlas es relevante para comprender cargas de trabajo analíticas en el examen.

Lo que necesitas saber

Azure Data Explorer es un servicio optimizado para ingestión y consulta de grandes cantidades de datos de series temporales y registros. El lenguaje usado para consultar esos datos es Kusto Query Language (KQL). KQL es declarativa y orientada a pipelines: transformas un conjunto de registros mediante una secuencia de operadores, separados por una barra vertical (|). Ese enfoque facilita la lectura y la composición de transformaciones complejas, porque cada operador recibe una tabla y devuelve otra.

Ejemplo simple: imagina una tabla llamada Telemetry con columnas Timestamp, DeviceId, Temperature. Para obtener la temperatura media por hora por dispositivo:

Telemetry
| where Timestamp >= ago(24h)
| summarize AvgTemp = avg(Temperature) by bin(Timestamp, 1h), DeviceId
| order by Timestamp asc

El operador where filtra, summarize agrega, y bin agrupa por intervalos de tiempo. En entornos reales, puedes tener, por ejemplo, 10 millones de filas por día en una tabla de telemetría; por eso es crítico limitar el periodo y aplicar filtros pronto para reducir la cantidad de datos procesados.

Cómo funciona

KQL procesa datos en fases: consulta la tabla, aplica filtros, proyecta columnas, agrega y ordena. Los operadores más importantes para DP-900 son:

where: filtra filas (usar pronto para rendimiento).
project: selecciona/renombra columnas, reduce el ancho de las filas.
summarize: agrega (avg, count, sum, min, max) y es esencial para métricas.
bin: agrupa timestamps en intervalos regulares (1m, 1h, 1d).
extend: crea columnas calculadas sin eliminar las existentes.
join: combina dos tablas (similar a SQL JOIN), útil para unir metadatos.

Ejemplo con columnas calculadas, join y ordenación:

let recent = Telemetry | where Timestamp >= ago(7d);
let devices = Devices | project DeviceId, Location, FirmwareVersion;
recent
| extend TempF = Temperature * 9/5 + 32
| where TempF > 80
| summarize Count = count(), AvgF = avg(TempF) by DeviceId, bin(Timestamp, 1d)
| join kind=leftouter devices on DeviceId
| order by AvgF desc

let facilita reutilizar subconsultas; el join añade metadatos como ubicación. En clusters bien configurados puedes procesar cientos de miles de eventos por segundo; en situaciones de desarrollo es común probar con ventanas de una hora o un día para iterar más rápido.

En la práctica

Paso a paso para construir una consulta analítica útil en Azure Data Explorer:

Identifica la tabla y las columnas necesarias (ej.: Telemetry, Timestamp, DeviceId, Temperature).
Aplica un filtro temporal con where Timestamp >= ago(...) para reducir el volumen inicialmente — por ejemplo, empieza con ago(1d) al probar y solo amplía a 30 días cuando la lógica esté correcta.
Proyecta solo las columnas que necesitas: | project Timestamp, DeviceId, Temperature para reducir I/O y memoria.
Crea columnas calculadas con extend si necesitas transformar datos (ej.: convertir unidades o extraer partes de strings).
Agrega con summarize usando by y, para series temporales, bin para agrupar por intervalos regulares.
Ordena y limita el resultado con order by y take si es necesario para dashboards o depuración.

Ejemplo completo — detectar dispositivos con picos recientes de temperatura y listar los top 50:

Telemetry
| where Timestamp >= ago(1d)
| summarize MaxTemp = max(Temperature) by DeviceId
| where MaxTemp > 75
| order by MaxTemp desc
| take 50

Este patrón es útil para alimentar un dashboard que muestre los 50 dispositivos con mayores picos en las últimas 24 horas e integrar con alertas.

Errores comunes

Filtrar demasiado tarde: aplicar where solo después de operaciones pesadas (join/aggregate) aumenta costes y tiempo. Filtra lo antes posible para reducir los datos procesados.
Usar summarize sin by correcto: olvidar bin en series temporales produce agregaciones por timestamps distintos y resultados poco útiles.
No limitar datos para depuración: al probar, usar take o intervalos cortos para evitar leer datos en exceso y provocar consultas lentas o costosas.
Hacer joins sin clave apropiada o sin limitar la tabla secundaria: joins mal construidos pueden multiplicar resultados y aumentar el coste.

Cómo practicar

Practica en el portal de Azure con un cluster Azure Data Explorer o usa la experiencia gratuita de Azure (ver políticas de costes). Crea tablas de ejemplo con 100k a 10M de registros para entender el comportamiento bajo carga. Para la preparación del DP-900, Microsoft dispone de un Practice Assessment OFICIAL gratuito — úsalo para evaluar conocimientos sin recurrir a preguntas reales del examen. Consulta también la study guide oficial de Microsoft para DP-900, donde están descritas las skills measured y enlaces a laboratorios prácticos y documentación de KQL.

En resumen

KQL es orientada a pipelines: operadores encadenados transforman los datos paso a paso; cada operador produce una tabla que alimenta al siguiente.
Filtra pronto con where, agrega con summarize y usa bin para series temporales; estas prácticas reducen costes y aceleran consultas.
Evita operaciones costosas sin filtros; prueba con muestras cortas (take) e itera con ventanas pequeñas antes de escalar a 30 días o más.
Practica en Azure y usa el Practice Assessment oficial y la study guide de Microsoft — ambos gratuitos — para preparar el DP-900, y experimenta con materiales de ejemplo con decenas de miles a millones de registros para ganar confianza en escenarios reales.