ES|QL Elasticsearch y su impacto en las consultas de datos
Aprende cómo usar ES|QL en Elasticsearch, el nuevo lenguaje de consultas de Elastic. Descubre sus características clave, los motivos de su creación y ejemplos prácticos para realizar consultas eficientemente.
Artículo elaborado por:
Analista Programador especializado en Java y Spring Boot con interés en Clean Code, legibilidad y buenas prácticas.
Desarrollador Full Stack especializado en Angular y NodeJs, con interés en Machine Learning e Inteligencia Artificial.
Introducción a ES|QL
El 7 de noviembre de 2023, George Kobar, Bahubali Shetti y Mark Settle anunciaron en el blog de Elastic la disponibilidad de la vista previa técnica de su nuevo lenguaje de consulta. Un año más tarde, en octubre de 2024, asistimos a un curso en el que se nos presentó en detalle este nuevo lenguaje.
El objetivo de este artículo es compartir lo que aprendimos durante aquella presentación: describir las principales características del nuevo lenguaje de Elastic, explicar las razones que motivaron su creación y mostrar algunos ejemplos prácticos de cómo usar ES|QL en Elasticsearch.
Contenidos
- Evolución de Elasticsearch y motivación de ES|QL
- ¿Qué es ES|QL?
- Características clave de ES|QL
- Sintaxis de ES|QL
- Casos de uso y beneficios específicos para soluciones de Elastic
- Cómo empezar con ES|QL
- Práctica con ejemplos reales
- Conclusiones
- Referencias
1. Evolución de Elasticsearch y motivación de ES|QL
1.1. Elasticsearch Query DSL
Elasticsearch Query DSL fue el primer lenguaje de búsqueda adoptado por Elastic, permitiendo realizar consultas con filtros, agregaciones y otras operaciones. Este DSL basado en JSON se convirtió en la columna vertebral del endpoint de la API _search.
Con el tiempo, y a medida que aumentaban las necesidades de los usuarios, fueron incorporando nuevas capacidades al Query DSL, como el uso de scripting y diversas funcionalidades relacionadas con la seguridad.
1.2. Limitaciones previas identificadas
Aunque las ampliaciones a Elasticsearch Query DSL fueron bien recibidas, seguían sin cubrir todas las necesidades de los usuarios. Con el tiempo quedó claro que hacía falta un enfoque más unificado y potente para trabajar con datos en Elastic.
En concreto, los usuarios querían un lenguaje de búsqueda que permitiese:
- Realizar todo el ciclo de análisis desde una única interfaz.
- Unificar la investigación de seguridad, observabilidad y problemas en producción en una sola búsqueda.
- Mejorar el rendimiento mediante capacidades avanzadas como el procesamiento concurrente en grandes volúmenes de datos.
2. ¿Qué es ES|QL?
Elasticsearch Query Language (ES|QL) es el nuevo lenguaje de consulta basado en tuberías que permite filtrar, transformar y analizar datos de forma más sencilla y potente.
A diferencia de lenguajes anteriores como Query DSL, ES|QL lo han diseñado para que podamos explorar la información de nuestro Elasticserach de forma más directa y accesible. Es decir, ES|QL está pensado para ser más fácil de leer y de escribir, haciéndolo más accesible para los usuarios independientemente de su nivel técnico.
Un cambio clave es que ahora todo el trabajo lo vamos a realizar desde una única pantalla en la vista Discover de Kibana. Con esto evitaremos los “cambios de contexto” constantes que estamos experimentando ahora trabajando desde la vista de Dev Tools. La interfaz unificada ofrece autocompletado, acceso a la documentación y, lo más importante, la visualización inmediata de los resultados.
ES|QL está impulsado por un nuevo motor de búsqueda por lo que puede incorporar capacidades avanzadas como el procesamiento concurrente lo que mejora significativamente la velocidad y la eficiencia, independientemente de la estructura o procedencia de los datos.
El lenguaje está experimentando una evolución acelerada con cada nueva versión. En la actualidad, ofrece una amplia gama de comandos, funciones y operadores, que se presentan a continuación.
3. Características clave de ES|QL
3.1. Tuberías (pipes)
ES|QL utiliza una sintaxis basada en tuberías o pipes (|) para procesar datos de forma secuencial. Cada orden representa un paso en la transformación, y el resultado de una operación se convierte en la entrada de la siguiente. Este enfoque permite construir consultas complejas mediante una composición clara y legible, similar a una tubería de procesamiento que existen en otros lenguajes y formas de trabajar.
La filosofía detrás de ES|QL es:
- Simplicidad y legibilidad: diseñado para ser fácil de escribir y entender, incluso para usuarios con distintos niveles técnicos. También tiene como objetivo tener una curva de aprendizaje menor para aquellos con conocimientos SQL, dada las analogías y similitudes en su forma.
- Procesamiento paso a paso: cada etapa se aplica de manera ordenada, lo que facilita el análisis y la depuración.
- Flexibilidad y potencia: permite filtrar, transformar, agregar y analizar datos sin necesidad de scripts complejos.
- Unificación del flujo de trabajo: combina búsqueda, análisis y visualización en un solo lenguaje, reduciendo la complejidad y acelerando la obtención de resultados.
3.2. Nuevo motor, ejecución paralela y arquitectura
ES|QL no solo sirve para análisis y agregaciones, sino que también potencia la búsqueda avanzada en Elasticsearch, ofreciendo un lenguaje unificado que combina filtrado y búsqueda por relevancia. Esto permite crear consultas más expresivas y fáciles de mantener.
- Filtrado: Se utiliza para eliminar documentos que no cumplen condiciones específicas (por ejemplo, coincidencias exactas, rangos de fechas, valores numéricos). Es rápido porque no calcula relevancia, ideal para consultas determinísticas.
- Búsqueda: Además de filtrar, ordena resultados por relevancia mediante un puntaje (score), aplicando análisis de texto avanzado (sinónimos, coincidencias difusas), priorizando los elementos en caso de que este orden sea determinante.
4. Sintaxis de ES|QL
4.1. Sintaxis básica
ES|QL es un lenguaje tipo SQL para consultar datos en Elasticsearch, usando una arquitectura de tubería o “pipeline”:
source-command | processing-command1 | processing-command2Cada consulta debe comenzar con una orden fuente (ej. FROM). Las órdenes se separan con | (tubería o “pipe”), lo que permite encadenar transformaciones.
Para los identificadores se usan comillas (`) si no empieza por letra, _ o @, o si se contiene caracteres no alfanuméricos. Para delimitar un literal (string), se usan las comillas dobles (“).
FROM logs-* | WHERE status_code >= 400 | LIMIT 104.2. Órdenes fuente o de origen
Una orden fuente o de origen ES|QL genera una tabla, generalmente con datos de Elasticsearch.
Fuente: elastic.co
Una consulta ES|QL debe comenzar con un comando de origen como, por ejemplo:
- FROM: obtiene datos de índices, data streams o alias. Soporta comodines (logs-*) y comodines en fechas (logs-2025.11. *) y puede incluir metadatos.
FROM index_pattern [METADATA fields]- ROW: crea una fila con valores.
ROW column1 = value1[, ..., columnN = valueN]4.3. Órdenes de procesamiento
Las órdenes de procesamiento ES|QL cambian una tabla de entrada agregando, eliminando o cambiando filas y columnas. Queremos destacar:
- WHERE: filtra filas según condición.
- KEEP / DROP: selecciona o elimina columnas.
- STATS … by: agregación y agrupación.
- SORT: ordena resultados.
- LIMIT: restringe número de filas.
- EVAL: crea o modifica columnas.
Las órdenes de procesamiento se pueden encadenar con las tuberías (|). Cada orden opera sobre la tabla generada por la orden anterior y el resultado final de una consulta es la tabla producida por la última orden de la cadena.
Fuente: elastic.co
4.4. Funciones
ES|QL ofrece una batería de funciones para trabajar con los datos. Dentro de las funciones existen gran variedad de operadores, donde podemos destacar:
- Agregación: COUNT(), SUM(), AVG(), MIN(), MAX()
- Texto: CONCAT(), UPPER(), LOWER()
- Fecha/Hora: DATE_TRUNC(), NOW()
- Conversión: CAST()
4.5. Funciones de búsqueda en ES|QL
ES|QL ofrece varias funciones para realizar búsquedas textuales y filtrado avanzado dentro de consultas. Estas funciones se utilizan principalmente en la cláusula WHERE y son las que contribuyen al cálculo de relevancia (score).
4.5.1. Principales funciones de búsqueda
- MATCH(campo, texto)
- Realiza coincidencias de texto en un campo específico.
- Usa analizadores configurados en el índice para tokenizar y normalizar el texto.
- MATCH_PHRASE(campo, frase)
- Busca coincidencias exactas de una frase completa.
- Útil para consultas donde el orden y proximidad de las palabras es importante.
- QSTR(campo, consulta)
- Permite usar la sintaxis de Query String para consultas más complejas.
- Soporta operadores como AND, OR, comodines y rangos.
- KQL(campo, consulta)
- Integra el Kibana Query Language, pensado para usuarios que ya trabajan con Kibana.
- Facilita la transición entre búsquedas en Kibana y ES|QL.
4.5.2. Características comunes
- Solo se pueden usar en condiciones WHERE.
- Son las únicas funciones que afectan el cálculo del puntaje de relevancia y se combinan con METADATA _score para ordenar resultados por relevancia.
4.5.3. Ejemplos básicos de consulta
Busca documentos que contengan la palabra “error” en el campo message:
FROM logs
| WHERE MATCH(message, "error")
| LIMIT 10Busca la frase exacta “critical failure” en el campo message:
FROM logs
| WHERE MATCH_PHRASE(message, "critical failure")
| LIMIT 5Consulta compleja usando operadores lógicos y comodines:
FROM logs
| WHERE QSTR(message, "error AND (timeout OR crash*)")
| LIMIT 1Integración con Kibana Query Language:
FROM logs
| WHERE KQL(message, "status:500 AND extension:php")
| LIMIT 204.6. Puntuación en la búsqueda
La funcionalidad para obtener resultados con puntuación permite que ES|QL no solo filtre documentos, sino que también los ordene por relevancia, similar al comportamiento del API de búsqueda tradicional en Elasticsearch.
4.6.1. ¿Qué es el scoring?
- Cada documento recibe un puntaje (score) que indica como de bien coincide con la consulta.
- Este puntaje se calcula considerando:
- Frecuencia del término (TF): Cuántas veces aparece el término en el documento.
- Frecuencia inversa del documento (IDF): Qué tan común es el término en todo el índice.
- Normalización por longitud: Da más peso a coincidencias en campos más cortos.
Para obtener resultados clasificados por relevancia, debe solicitar explícitamente la puntuación con “METADATA _score” y ordenar por puntuación. Sin esto, incluso las funciones de búsqueda como MATCH solo filtrarán los documentos sin clasificarlos.
Sin METADATA _score: todas las operaciones son solo de filtrado, incluso las funciones MATCH, QSTR y KQL. Los documentos coinciden o no coinciden, no se produce ninguna clasificación.
Con METADATA _score: las funciones de búsqueda contribuyen a las puntuaciones de relevancia, mientras que las operaciones de filtrado (condiciones de rango, coincidencias exactas) no afectan a la puntuación. Debe utilizar explícitamente SORT _score DESC para ver primero los resultados más relevantes.
Esto le permite controlar totalmente cuándo utilizar el filtrado rápido y cuándo la búsqueda basada en la relevancia, más lenta pero más potente.
4.6.2. Ejemplos básicos
Esto devuelve los documentos más relevantes primero:
FROM books METADATA _score
| WHERE MATCH(title, "Shakespeare") OR MATCH(plot, "Shakespeare")
| SORT _score DESCAquí se tiene en cuanta la calificación del lector para priorizar resultados (con filtro de prioridad personalizado):
FROM books METADATA _score
| WHERE MATCH(title, "Shakespeare") OR MATCH(plot, "Shakespeare")
| WHERE _score > 2 // Filtra resultados poco relevantes
| EVAL new_score = _score + rating/5
| SORT new_score DESC4.6.3. Ejemplos avanzados que incluyen búsquedas semánticas e híbridas
Busca documentos relacionados con el concepto “cloud security” usando embeddings en un campo semantic_text:
FROM documents METADATA _score
| WHERE SEMANTIC_MATCH(semantic_text, "cloud security")
| LIMIT 10Uso: Ideal para consultas donde el significado importa más que las palabras exactas.
Combina búsqueda tradicional y semántica, ajustando pesos:
FROM documents METADATA _score
| WHERE MATCH(title, "cloud") OR SEMANTIC_MATCH(semantic_text, "cloud security")
| EVAL hybrid_score = (_score * 0.7) + (semantic_score * 0.3)
| SORT hybrid_score DESC
| LIMIT 10Uso: Perfecto para mejorar relevancia combinando coincidencias exactas y contexto semántico.
Filtra por fecha y tipo de documento junto con búsqueda semántica:
FROM documents METADATA _score
| WHERE SEMANTIC_MATCH(semantic_text, "data privacy") AND doc_type = "report" AND @timestamp >= NOW() - INTERVAL 30 DAYS
| LIMIT 155. Casos de uso y beneficios específicos para soluciones de Elastic
ES|QL introduce una nueva forma de interactuar con los datos en Elasticsearch, permitiendo realizar búsquedas, agregaciones, transformaciones y correlaciones dentro de una única consulta secuencial. Esta capacidad lo convierte en una herramienta especialmente valiosa en áreas donde la velocidad, la iteración continua y la mezcla de datos heterogéneos son fundamentales. A continuación, se detallan los principales casos de uso y los beneficios que aporta en cada uno.
5.1. Seguridad con Elastic Security
En entornos de ciberseguridad, la capacidad de explorar datos de manera fluida es clave para identificar amenazas. ES|QL facilita este proceso gracias a su sintaxis basada en pipes, que permite construir consultas de forma progresiva, añadiendo filtros, transformaciones o cálculos conforme avanza la investigación.
Una de las funciones más relevantes en este ámbito es el comando ENRICH, que permite correlacionar datos internos (como direcciones IP, usuarios o procesos) con fuentes externas de inteligencia de amenazas. Esto habilita un análisis contextual inmediato, evitando pasos adicionales o consultas paralelas.
Además, ES|QL permite definir campos nuevos, normalizar información y realizar agregaciones directamente en la consulta. Esto reduce significativamente la complejidad típica de las investigaciones y ayuda a detectar patrones anómalos con mayor rapidez.
Resumiendo, aporta una experiencia más ágil para los analistas y mejora la eficacia en la respuesta ante incidentes.
En un entorno de seguridad, un caso típico es la búsqueda de procesos potencialmente maliciosos (por ejemplo, uso anómalo de PowerShell) y su correlación con contexto adicional.
from logs-endpoint.events-*
| where event.category == "process"
and process.name == "powershell.exe"
| stats ejecuciones = count() by host.name, user.name, process.command_line
| enrich ti-endpoint-reputation on host.name with risk_level, risk_score
| sort risk_score desc | limit 20Con este ejemplo:
- from selecciona los índices de eventos de endpoint.
- where filtra solo eventos de procesos relacionados con powershell.exe.
- stats agrupa y cuenta ejecuciones por equipo, usuario y línea de comandos.
- enrich añade información de reputación del host desde una tabla de contexto (por ejemplo, un índice de “asset management” o de “risk scoring”).
- sort y limit ayudan a priorizar los resultados más críticos para el analista.
Este patrón permite al equipo de seguridad centrarse primero en los sistemas con mayor riesgo y disponer del contexto necesario sin abandonar la misma consulta.
5.2. Observabilidad unificando logs, métricas y trazas
Los equipos de observabilidad necesitan correlacionar datos provenientes de diferentes fuentes: logs de aplicaciones, métricas de infraestructura, trazas distribuidas, eventos de red, entre otros. ES|QL unifica este proceso, permitiendo consultar y transformar todos estos datos desde un único punto.
Esta capacidad reduce el ruido en las alertas mediante agregaciones más precisas, facilita el análisis de tendencias y acelera el proceso de diagnóstico cuando surge un problema. Además, al integrarse de forma natural con las herramientas de visualización y alertado de Elastic, una consulta de ES|QL puede reutilizarse en cuadros de mando, reglas de alerta o paneles de investigación.
El resultado es una mejora notable en el tiempo medio de resolución (MTTR) y una mejor colaboración entre equipos de desarrollo, operaciones y SRE.
En observabilidad, un uso habitual consiste en identificar servicios cuya latencia media supera un umbral aceptable, a partir de datos de trazas o APM.
from traces-apm-*
| where transaction.type == "request"
| stats avg_duration_us = avg(transaction.duration.us) by service.name
| eval avg_duration_ms = avg_duration_us / 1000
| where avg_duration_ms > 500
| sort avg_duration_ms descAquí:
- Se parte de índices de trazas (traces-apm-*).
- Se filtran solo transacciones de tipo petición (transaction.type == «request»).
- stats calcula la duración media por servicio.
- eval convierte la duración media a milisegundos.
- Un segundo where aplica un umbral (500 ms) para centrarse solo en servicios “lentos”.
- sort ordena de mayor a menor latencia, ayudando a priorizar el análisis.
Con una única consulta, los SRE pueden detectar rápidamente qué servicios degradan la experiencia de usuario y profundizar en su diagnóstico.
5.3. Búsqueda general y transformación de datos
Más allá de seguridad y observabilidad, ES|QL extiende las capacidades de búsqueda de Elasticsearch, permitiendo construir flujos de análisis más ricos sin necesidad de scripts ni herramientas externas.
ES|QL permite:
- combinar búsqueda, filtrado, agregación y cálculo en una sola consulta
- crear pipelines de análisis fácilmente iterativos
- trabajar con datos estructurados y no estructurados de manera homogénea
- evitar la exportación de datos a sistemas externos para su procesamiento
Esto lo convierte en una herramienta versátil tanto para análisis ad-hoc como para flujos operativos complejos, y reduce la carga de mantenimiento al eliminar lógica distribuida entre múltiples consultas o lenguajes.
from logstash-*
| stats avg_bytes = avg(bytes) by geo.src
| eval avg_bytes_kb = round(avg_bytes / 1024, 2)
| enrich geo-data on geo.src with country, continent
| keep avg_bytes_kb, geo.src, country, continent
| limit 10En esta consulta:
- stats calcula el promedio de bytes por origen geográfico (geo.src).
- eval transforma el valor a kilobytes y lo redondea a dos decimales.
- enrich utiliza una tabla de datos geográficos (geo-data) para añadir país y continente.
- keep selecciona solo las columnas relevantes para el análisis.
- limit restringe el número de filas mostradas, por ejemplo, para una vista rápida o una demo.
Este tipo de patrón es muy útil para cuadros de mando, exploración ad-hoc o informes ejecutivos, ya que combina métrica, contexto y simplificación en una única consulta.
5.4. Beneficios transversales: eficiencia, velocidad y simplicidad operativa
Aunque cada área obtiene ventajas específicas, ES|QL aporta una serie de beneficios comunes a cualquier caso de uso:
- Mayor rendimiento: gracias a un motor de ejecución dedicado y optimizado para consultas encadenadas y paralelizadas.
- Eficiencia operativa: las operaciones de búsqueda, enriquecimiento, cálculo y transformación se realizan de manera integrada.
- Reducción de complejidad: la sintaxis secuencial en pipes permite construir consultas comprensibles y mantenibles, incluso cuando el análisis es complejo.
- Mejor experiencia de usuario: la integración completa en Kibana ofrece autocompletado, visualización automática de resultados y una edición mucho más fluida.
- Flexibilidad absoluta: permite trabajar con datos de diferentes orígenes y estructuras sin necesidad de preprocesamiento.
Impulsado por un motor de búsqueda robusto, ES|QL ofrece capacidades avanzadas con procesamiento concurrente, lo que permite realizar búsquedas a través de múltiples fuentes y estructuras de datos.
No existe ninguna traducción ni transpilación intermedia hacia Query DSL. Cada consulta escrita en ES|QL se analiza directamente: primero se desglosa y se interpreta su significado, luego se valida su exactitud y finalmente se optimiza para garantizar el mejor rendimiento posible. A partir de ahí, el sistema genera un plan de ejecución distribuido que se ejecuta en varios nodos del clúster. El resultado son búsquedas extremadamente más rápidas que funcionan de manera nativa sin configuraciones adicionales. A modo de ejemplo, cada noche registran evaluaciones comparativas para diferentes tipos de búsqueda:
Cada noche realizan una comparativa del rendimiento de las consultas
6. Cómo empezar con ES|QL
6.1. Requisitos y entorno necesario
ES|QL está disponible en vista previa técnica a partir de la versión 8.11 de Elasticsearch. En nuestro caso ya contamos con esta versión, pero si no dispones de una instancia actualizada (o simplemente quieres probar las nuevas funcionalidades) siempre puedes trabajar en local sin complicaciones.
Para montar tu entorno local solo necesitas dos cosas:
- Docker Desktop
- Ejecutar el script oficial:
curl -fsSL https://elastic.co/start-local | shTodos los pasos están documentados en la página oficial de Elastic (https://www.elastic.co/docs/deploy-manage/deploy/self-managed/local-development-installation-quickstart) lo que hace que el proceso sea muy sencillo. En menos de cinco minutos está instalado Docker Desktop y levantado un entorno completo con Elastic y Kibana listo para probar.
Terminando el proceso de instalación
Nuestro Elastic + Kibana en local
6.2. Datos de prueba
Perfecto, tenemos un entorno en local listo, pero ¡sin datos! Ahora podemos optar por rellenar nuestro Elastic con datos de prueba proporcionados en el mismo Kibana o dar de alta nuestro índice y añadir los documentos que queramos.
Eligiendo la opción “Add sample data”
6.3. Invitación a experimentar
Recuerda que si tu proyecto ya trabaja con una instancia de Elasticsearch en la versión 8.11, puedes lanzarte a probar ES|QL directamente desde la vista Discover de Kibana. Y si no es el caso, ponerse al día tampoco tiene mucho misterio: levantar en local tu propio entorno de Elastic + Kibana te llevará menos de cinco minutos. ¿Que ni siquiera tienes esos cinco minutos? Pues no pasa nada: en la web de Elastic tienes una demo guiada lista para usar. Vamos, que ya no hay excusas para no darle una oportunidad a ES|QL.
6.4. Ejemplo práctico
Una de las grandes ventajas del nuevo lenguaje es que el equipo de Elastic lo ha integrado de forma orgánica en la vista Discover de Kibana. Esto nos permite trabajar directamente sobre los datos como lo haríamos en cualquier herramienta de gestión de bases de datos, ya sea DBeaver, MySQL u otras similares.
En el ejemplo que mostramos a continuación, queremos recuperar 10 documentos que contengan alguna referencia a ES|QL en su resumen y que además estén en la versión 9.x. Mientras que con el clásico Query DSL esta consulta nos llevaría algo más de tiempo, en ES|QL la sintaxis resulta casi idéntica a lo que escribiríamos en SQL, haciendo el proceso mucho más intuitivo:
FROM kibana_sample_data_elasticsearch_documentation
| WHERE version == "9.x"
| WHERE ai_summary LIKE "*ES|QL*"
| KEEP product_name, version, ai_summary
| LIMIT 10
Ejemplo de consulta en ES|QL
7. Práctica con ejemplos reales
7.1. Comparativa DSL vs ES|QL
Las instancias de Elastic de Edicom ya incluyen la opción “Try ES|QL” en Kibana, lo que nos permite probar el nuevo lenguaje directamente sobre nuestros propios índices. A continuación mostramos ejemplos reales de consultas que ya están funcionando en nuestros productos (en concreto, en Edicom Downloads) con el objetivo de comparar cómo formulamos la búsqueda utilizando Query DSL y cómo se expresa la misma lógica empleando ES|QL.
7.2. Número de documentos por semana
En la vista inicial disponemos de un Dashboard que recibe al usuario con una serie de gráficos. Hay varios ejemplos muy interesantes pero para este primer caso nos centramos en el gráfico de “Documentos por semana”.
Edicom Downloads: vista Dashboard centrada en Documentos por semana
7.2.1. Consulta original
Este gráfico obtiene sus datos de la consulta original:
{
"query": {
"bool": {
"must": [
{
"term": {
"username": "usuario@dominio"
}
}
]
}
},
"aggs": {
"histogram_aggregation_key": {
"date_histogram": {
"field": "lastModify",
"calendar_interval": "week"
}
}
}
}7.2.2. Consulta traducida
Hemos formulado la nueva consulta en ES|QL como:
FROM index-name
| WHERE username == "usuario@dominio"
| EVAL week = DATE_TRUNC(1 week, lastModify)
| STATS count(*) BY week
| SORT weekDetalles de la conversión:
- from: index-name debe sustituirse por el índice o patrón de índices sobre el que realizamos la consulta.
- El filtro where username == … reproduce el comportamiento del term de la consulta original.
- La orden eval nos permite crear un nuevo valor calculado. En este caso concreto, usando la función DATE_TRUNC redondeamos a la baja la fecha de última modificación en intervalos de una semana.
- stats count(*) by week en combinación con el valor obtenido en la orden anterior (eval) nos permite crear un histograma de las fechas truncadas obtenidas en dicho paso, dándonos como resultado final el número de ocurrencia de documentos en cada semana.
7.2.3. Resultado
Lanzamos la nueva consulta en el propio Kibana y podemos observar que nos ofrece los mismos resultados que la consulta original pero ahora con un lenguaje mucho más legible:
Resultado de la búsqueda del número de documentos por semana
7.3. Estado y número de documentos totales
El siguiente gráfico que nos gustaría analizar se trata del que está en la esquina inferior izquierda, se trata del “Estado de los documentos” y tiene forma de tarta.
Edicom Downloads: vista Dashboard centrada en Estado de los documentos
7.3.1. Consulta original
La consulta original en Elasticsearch filtra los documentos cuyo campo username coincide con un valor específico y, a continuación, realiza una agregación por el campo state.
{
"query": {
"bool": {
"must": [
{
"term": {
"username": "usuario@dominio"
}
}
]
}
},
"aggs": {
"terms_aggregation_key": {
"terms": {
"field": "state",
"min_doc_count": 1
}
}
}
}7.3.2. Consulta traducida
En ES|QL, esta misma operación se expresa de forma más sencilla y legible mediante pipelines:
FROM index-name | WHERE username == "usuario@dominio" | STATS COUNT() BY stateDetalles de la conversión:
- from index-name debe sustituirse por el índice o patrón de índices sobre el que realizas la consulta.
- El filtro where username == … reproduce el comportamiento del term de la consulta original.
- El comando stats count() by state equivale a la agregación terms realizada sobre el campo state.
7.3.3. Resultado
Lanzamos la nueva consulta en el propio Kibana y podemos observar que nos ofrece los mismos resultados que la consulta original en apenas 3 líneas de código.
Resultado de la búsqueda del estado de los documentos
7.4. Tamaño total de los documentos
El último gráfico que vamos a analizar se trata del sumatorio del tamaño de todos los documentos con los que ha trabajado el usuario en Edicom Downloads. Este gráfico figura en la esquina superior derecha y, aunque parece el más sencillo, esconde su cierta complejidad.
Edicom Downloads: vista Dashboard centrada en Tamaño
7.4.1. Consulta original
La consulta original requiere los agregados de los 3 campos que forman el tamaño de los documentos descargados a través de la herramienta Edicom Downloads. En concreto:
{
"query": {
"bool": {
"must": [
{
"term": {
"username": "usuario@dominio"
}
},
{
"terms": {
"state": [
"ZIPPED"
]
}
}
]
}
},
"aggs": {
"terms_aggregation_key": {
"terms": {
"field": "username",
"min_doc_count": 1
},
"aggs": {
"documentSize": {
"sum": {
"field": "documentSize"
}
},
"graphicSize": {
"sum": {
"field": "graphicSize"
}
},
"metadataSize": {
"sum": {
"field": "metadataSize"
}
}
}
}
}
}La página web muestra el resultado redondeado a MB por lo que para este caso vamos a lanzar la consulta original a través del Dev Tools para ver los resultados:
Consulta original en Dev Tools
7.4.2. Consulta traducida
En ES|QL, esta la operación anterior se expresa de esta forma:
FROM index-name
| WHERE username == "usuario@dominio" AND state == "ZIPPED"
| STATS documentSize = SUM(documentSize), graphicSize = SUM(graphicSize), metadataSize = SUM(metadataSize)Detalles de la conversión:
- from index-name debe sustituirse por el índice o patrón de índices sobre el que realizas la consulta.
- El filtro where username == … reproduce el comportamiento del term de la consulta original.
- El comando stats sum(x) equivale a la agregación realizada sobre el campo x.
En este caso creamos tres nuevas columnas para imitar el comportamiento original.
7.4.3. Resultado
Lanzamos la nueva consulta en el propio Kibana y podemos observar que los resultados de los tres campos coinciden con la nueva consulta realizada en ES|QL:
Resultado de la búsqueda del tamaño total de los documentos
8. Conclusiones
ES|QL supone un avance significativo en la forma de consultar y analizar datos dentro del ecosistema de Elastic, al ofrecer una experiencia más sencilla, potente y coherente.
Gracias al nuevo motor Elasticsearch Query Engine, las búsquedas pueden ejecutarse de forma concurrente en múltiples tareas, lo que incrementa de manera notable la velocidad y eficiencia en la recuperación de información. Este nuevo motor de búsqueda también introduce capacidades avanzadas de agregación, cálculo y transformación de datos dentro de una única consulta, y se espera que futuras versiones amplíen estas posibilidades mediante funcionalidades como joins y estadísticas en línea.
Asimismo, la integración con la vista Discover de Kibana permite generar visualizaciones, cálculos y agregaciones de forma inmediata, lo que acelera la obtención de información valiosa para la toma de decisiones.
Finalmente, ES|QL incorpora capacidades avanzadas de alerta que permiten detectar patrones relevantes basados en valores agregados, reduciendo el volumen de falsos positivos y proporcionando notificaciones más precisas y accionables.
Por lo que concluimos que el equipo de Elastic ha estado buscando la manera de unificar a todos sus clientes en un mismo lenguaje en el que centrar sus esfuerzos en forma de nuevos desarrollos y ES|QL es ese lenguaje.
9. Referencias
Contexto e introducción:
Sintaxis y funciones básicas:
- https://www.elastic.co/docs/reference/query-languages/esql
- https://www.elastic.co/es/blog/getting-started-elasticsearch-query-language
Sintaxis de filtrado y búsqueda avanzada:
Rendimiento:
Demostración en local:
Demostración guiada: