ES|QL 终于有视图了,常用查询可以变成一个虚拟索引

简介: ES 9.4 给 ES|QL 加了 Views:把一段查询定义成有名字的视图,之后在 FROM 里当索引用。

ES 9.4 给 ES|QL 加了 Views:把一段查询定义成有名字的视图,之后在 FROM 里当索引用。本文讲清定义方式、嵌套与分支上限、预览阶段的限制,以及它和子查询、FORK 怎么选。

反复出现的那几段查询

写 ES|QL 的时候,总有几段查询会反复出现:固定的过滤条件、固定的字段重命名、固定的派生字段。以前要么每次复制粘贴,要么在应用层封一层。

9.4 加进来的 ES|QL Views,给了一个更直接的办法:把这段查询定义成一个有名字的视图,之后在 FROM 里当索引用。

先把状态说清楚,免得你看完就想往生产上放:9.4 技术预览,而且 serverless 不可用。官方 esql-views.md 文档头部写的是 stack: preview 9.4.0、serverless: unavailable(v9.5.4 文档 4–5 行)。

它到底是什么

先看官方是怎么定义的(12–17 行):

A view is a virtual index with fields that are produced from the output of an ES|QL query.
Each view has a name and a definition. The definition is a complete ES|QL query, with source commands and processing commands.
The view name can be used within an index pattern in the FROM command of any normal ES|QL query, as well as within another view definition.
When the main query is executed, all referenced views are also executed independently.
This ensures up-to-date results from all source indexes referenced by both the main query and the view definitions themselves.
The final output combines all these results into a single list, including any duplicate rows.

拆开看有五点:

  • 视图是个虚拟索引,字段来自一条 ES|QL 查询的输出。
  • 它有名字和定义,定义就是一条完整的 ES|QL 查询(source 命令 + 处理命令都有)。
  • 这个名字可以用在任何查询的 FROM 索引模式里,也可以被另一个视图引用。
  • 主查询执行时,被引用的视图会各自独立执行,所以拿到的是源索引的最新数据,不是缓存快照。
  • 结果合并成一个列表,重复行会保留,不会帮你去重。

官方列的四种适用场景

官方列了四种场景(19–26 行),翻过来就是:

  • 复用一段命名查询:把常用的管道包成视图,之后按名字引用,不用每个请求都重复一遍。
  • 抽象通用转换:把重命名、类型转换、派生字段集中在一个地方,用的人只看到一组稳定的列,不用关心底层结构。
  • 组合多个预处理过的数据源:一个源定义一个视图,各自带自己的过滤或聚合,然后在一条 FROM 里一起查。
  • 给下游工具减负:看板、告警、临时分析的人直接查 FROM my_view,不用知道背后是哪些索引、哪些命令。

第三条我个人觉得最实用——以前要在一个查询里合并几个口径不同的数据源,只能写很长的管道或者在应用层拼。

怎么定义,怎么用

用 REST API 定义。假设有这样一条查询(这是官方示例,views_plain_addresses):

FROM addresses
| RENAME city.country.name AS country
| EVAL country = CASE(country == "United States of America", "United States", country)
| STATS count=COUNT() BY country

结果是:

count:long country:keyword
1 Japan
1 Netherlands
1 United States

把它定义成视图(42–52 行):

PUT /_query/view/country_addresses
{
    "query": """
        FROM addresses
        | RENAME city.country.name AS country
        | EVAL country = CASE(country == "United States of America", "United States", country)
        | STATS count=COUNT() BY country
        """
}

然后直接查视图名,输出跟上面那条查询一模一样(views_country_addresses 示例):

FROM country_addresses

用起来就跟普通索引一样。官方说法是(63–68 行):FROM 后面是逗号分隔的索引或视图名列表,支持通配符和 date-math。

几个要注意的行为:

  • 一边有、另一边没有的字段,会填 null(77 行)。
  • 视图可以嵌套,深度上限 10(82 行)。
  • 分支因子上限 8,而且 views、subqueries、FORK 是共用这个额度的(86–88 行)。官方举的例子:一个索引模式里引用 4 个视图 + 4 个子查询可以,再多一个就超限,查询直接失败。

进阶一点的用法

一个 FROM 里合并多个视图。 官方示例定义了三个视图 country_airports、country_addresses、country_languages,分别从三个源索引统计每个国家的文档数,然后一起查(99–112 行)。同一个国家会在多个视图里都出现,于是产生多行;想要合并就再套一层 STATS ... SUM(count) BY country。通配符也能用,比如把所有 country_* 视图一次性查出来再做 SUM。

视图里可以写 LOOKUP JOIN。 这个挺实用:

PUT /_query/view/airports_mp_filtered
{
    "query": """
        FROM airports
        | RENAME abbrev AS code
        | LOOKUP JOIN airports_mp ON abbrev == code
        | WHERE abbrev IS NOT NULL
        | DROP code
       """
}

这个视图里的行,都是 airports 里能在 airports_mp 索引匹配到 abbrev 的那些(125–139 行)。官方还举了个用法:把视图和索引写进同一个 FROM,对比"只在 airports 里的"和"在视图里的"各有多少。

限制,这部分要认真看

视图在预览阶段,限制不算少(官方限制片段):

  • 视图定义里基本不能用 FORK 和子查询,除非分支点能通过 query compaction 合并掉。
  • 嵌套和分支可以组合,但分支点不能超过一个。视图里可以有子查询,但那个视图就不能再和其他视图一起用了。
  • 跨集群:不支持远端视图。FROM cluster:view 只会去匹配远端的同名索引;如果远端真有个视图,查询会失败。反过来,如果远端有个索引跟本地视图同名,查询也会失败。
  • 查询参数不能用在视图定义里,所以主查询传的参数不会影响视图结果。
  • 已知问题:主查询上的 Query DSL 过滤,目前会作用到视图定义里的源索引上,后续版本会改成作用于视图的输出——这个行为变化要留意。METADATA 在视图内外的行为也还会变。

说白了,跨集群和参数这两块,现阶段基本别指望。

视图、子查询、FORK 怎么选

这三个是近亲,官方专门做了对比(对比片段)。用一句话区分:

  • FORK:对同一份已有数据做并行多分支处理,每个分支拿到的输入行和列都一样;一个查询只能有一个 FORK。
  • 子查询:每个分支可以有自己的 FROM,来源可以完全不同。
  • 视图:可复用的命名查询,当虚拟索引用。

它们的共同点也很明确:都是查询时才执行(所以结果是最新的)、列取并集(缺的填 null)、最大分支数都是 8、一般不允许嵌套分支(视图能通过 compaction 绕一部分)。

还有两条容易忽略:

  • 视图名在索引命名空间里唯一,不能和已有索引同名,反过来也一样。
  • 视图可以嵌套,但不能循环引用(viewA → viewB → viewC → viewA 不行),循环是在主查询执行时才检测的。
项 结论
版本 9.4 起,技术预览
Serverless 不可用
定义方式 PUT /_query/view/<name>,body 里是完整 ES QL 查询
用法 FROM 里当索引用,支持通配符和 date-math
结果 各视图独立执行后合并,重复行保留,缺列填 null
嵌套深度 10
分支上限 8(views + subqueries + FORK 共用)
主要限制 视图内一般不能用 FORK/子查询;不支持远端视图;不能用查询参数

写在最后

视图解决的是一个很朴素的问题:同一段 ES|QL 别再到处复制。如果你的看板、告警里反复出现同一段查询,值得把它抽成视图试一下,尤其是"把几个口径不同的数据源合到一条 FROM 里"这种场景,视图会比手写长管道清爽得多。

但要记住它还是技术预览:跨集群和查询参数这两块现在基本用不了,嵌套深度、分支数也有上限。先在测试环境和内部看板上试,别急着把核心告警迁过来。

参考

本文对照 Elasticsearch v9.5.4 标签的官方文档与 v9.5.0 标签的发布说明核对,示例均取自官方示例文件。撰写时未启动集群、未运行测试。

目录
相关文章
|
24天前
|
人工智能 JSON API
全网刷屏的 Jev 模型正式开放!一手实战测评 + 保姆级教程
全网爆火的 Jev 模型是什么?有什么用?怎么使用?怎么接入 AI 编程工具?效果真的好么?傻子可懂的 Jev 保姆级实战教程 + 项目实战测评来啦
9471 31
|
1天前
|
云安全 人工智能 运维
当攻击全面Agent化,你的安全防御能否跟上AI Speed?
多起客户侧AK泄露事件应急的真实观察
1154 0
|
10天前
|
存储 人工智能 并行计算
大模型本地部署终端选型方法论:以 Qwen3.8-27B 为例的四档分层完整流程
本文提出一套大模型本地部署终端选型方法论:定约束、定档位、定框架、定参数四步决策法,配合入门、主力、质量、无损四档分层模型。以 Qwen3.8-27B 实测数据为例,逐环节解读显存、带宽、存储、散热、系统、预算等要素,给出面向不同预算的优选方案、决策自查清单与市场观察框架。文末前瞻 AI 笔记本的 CPU+GPU 与统一内存两条路线,论证四步决策法在新品类上的延续性。
|
9天前
|
人工智能 JSON 自然语言处理
2026 年 Jev 决策模型深度拆解:原理解读、实战测评与保姆级落地教程
有一款特殊AI模型在开发者圈子刷屏,它摒弃传统大模型擅长的对话聊天能力,专注做高速结构化决策,它就是TypeSafe AI推出的Jev模型。该模型由ChatGPT共同发明人Diogo Almeida主导研发,定位为**System One Model(系统一模型)**,对标人类大脑快速直觉判断的思维模式,在响应延迟、调用成本、结构化输出稳定性上相比传统生成式大模型有着巨大差异。本文会完整拆解Jev底层原理、三大核心原语能力、适用业务场景,同时提供可直接运行的curl、Python代码示例,并且结合多组实测数据,客观分析模型优势与能力边界,帮助普通开发者和AI应用从业者快速上手落地。
710 1
|
5天前
|
人工智能 JSON 自然语言处理
2026 年 Jev 决策模型全解析:核心原理拆解,性能实战测评与落地部署教程
有一款特殊AI模型在开发者圈子刷屏,它摒弃传统大模型擅长的对话聊天能力,专注做高速结构化决策,它就是TypeSafe AI推出的Jev模型。该模型由ChatGPT共同发明人Diogo Almeida主导研发,定位为System One Model(系统一模型),对标人类大脑快速直觉判断的思维模式,在响应延迟、调用成本、结构化输出稳定性上相比传统生成式大模型有着巨大差异。本文会完整拆解Jev底层原理、三大核心原语能力、适用业务场景,同时提供可直接运行的curl、Python代码示例,并且结合多组实测数据,客观分析模型优势与能力边界,帮助普通开发者和AI应用从业者快速上手落地。
465 0
|
22天前
|
人工智能 测试技术 API
最近全网爆火的 Jev 到底是什么?适合干什么、怎么用,一篇讲透!
Jev是TypeSafe AI推出的“系统一模型”,不生成文本,专做毫秒级结构化决策:Choice(多选)、Score(打分)、Noul(是非概率)。响应快193倍、成本低444倍,适合工单路由、内容审核、测试定级等高频判断场景。
2539 4
最近全网爆火的 Jev 到底是什么?适合干什么、怎么用,一篇讲透!
|
3天前
|
存储 缓存 测试技术
QWT 3D 模块重构记:旧渲染管线改进介绍及实时瀑布图示例
QWT 3D模块完成重大重构:解耦窗口与图形(Plot+Item),摒弃OpenGL 1.x固定管线,迁至Core Profile着色器渲染;支持多图元同场景叠加,并以实时3D瀑布图验证——滑动窗口、固定色域、64帧×256点达61fps。兼容Qt 5.12+/6,LGPL协议。
174 120
|
16天前
|
Windows
【保姆级】.NET Framework 3.5离线安装教程(2026最新实测)
.NET Framework 3.5是微软经典运行库,专为兼容老软件、老游戏设计。Win7自带,Win10/11需手动启用(在线或离线安装)。它与4.x系列并存不冲突,缺它会导致“找不到组件”报错。本文详解两种安装方式及常见问题解决,小白也能轻松上手。(239字)
2063 0