ES Columnar Mode：当搜索引擎开始做列式分析，数据栈怎么变
Elastic 自己承认了什么
2026 年 7 月 9 日，Elastic 官方工程博客发了一篇文章，标题是 Why Elasticsearch is becoming a columnar database。
这篇文章里有一句话值得反复读：
“When your job is to read and reason about a lot of data, columnar storage turns nearly every dimension of cost and performance in your favor.”
这是一个做了 16 年文档搜索引擎的团队，在自己的工程博客上承认：他们最初选择的架构，对于今天大部分用户真正在跑的工作负载（日志、指标、遥测、分析），是错误的选择。
ES 9.5 将引入 Columnar Mode（列式模式），9.6 GA。数据只存一份，按列组织，不需要的索引不建。
这不是”ES 加了个新功能”
很多人第一反应是”ES 又加了个存储引擎，跟以前加 doc_values、加 kNN 一样”。
不一样。
之前 ES 每加一个能力，都是在文档模型上”叠”——你要倒排索引，有；要列式读取，有 doc_values；要向量检索，有 HNSW。但底层数据始终存的是”文档”：一行 JSON，所有字段在一起，建索引时再按需拆。
Columnar Mode 改的是底层存储模型本身：数据不再按行存，而是按列存。
| 维度 | 文档模式（现有） | 列式模式（9.5 新增） |
|---|---|---|
| 存储方式 | 整行 JSON + 倒排索引 + doc_values | 按列独立存储，按需建索引 |
| 适合的工作负载 | 全文搜索、精确点查、相关性排序 | 大规模写入、分析聚合、长期保留 |
| 存储成本 | 高（一份数据多份副本） | 低（只存一次，按需索引） |
| 查询速度 | 搜索快，聚合慢 | 聚合快，全文搜索仍保留 |
| 典型数据 | 业务搜索、商品、用户文档 | 日志、指标、安全事件、遥测 |
关键点：两种模式并存，不是替换。 你可以按索引维度选择用哪种模式，API、SDK、下游集成全部不变。
对 MySQL-Doris-ES 三角的影响
在 之前的文章 里，我给出了一个三角分工框架：
MySQL 做事务 → ES 做搜索 → Doris 做分析
这个框架的核心假设是：ES 擅长搜索但不擅长分析。 所以分析交给 Doris，ES 只管搜索 + 向量。
现在这个假设被动摇了。
场景重估：当 ES 也能做列式分析
假设你有一个日志分析平台：
现在的架构：
1 | 应用日志 → Kafka → ES（搜索+告警） + Doris（统计分析） |
两个系统各存一份数据，各自的索引，各自的运维。
ES Columnar Mode 之后可能变成：
1 | 应用日志 → Kafka → ES Columnar Mode（搜索+告警+分析） |
一个集群，一份数据，既能全文搜索又能列式聚合。Doris 的角色被压缩。
但这不是”ES 替代 Doris”
先别急着下结论说”Doris 要被 ES 吃掉了”。几个关键区别：
1. 列式分析能力的成熟度不同
Doris 从第一天就是列式数据库，10 年打磨：向量化执行引擎、CBO 优化器、物化视图、Colocate Join、Runtime Filter。ES 的列式模式刚出来，9.5 才技术预览。列式存储 ≠ 列式数据库。 存储格式变了，查询优化器、执行引擎的成熟度还需要时间追赶。
2. 多表 JOIN 能力差距大
Doris 擅长的是多表 JOIN + 复杂聚合（星型模型、雪花模型）。ES 的 ES|QL 目前主要做单表聚合和过滤，多表 JOIN 不是它的主场。
如果你的分析场景是”日志按时间聚合 + 维度过滤”——ES Columnar Mode 够用。
如果你的分析场景是”事实表 JOIN 维度表 + 复杂窗口函数 + 多层子查询”——Doris 依然是更好的选择。
3. 实时写入模型不同
Doris 的 Routine Load / Stream Load 是为高吞吐实时写入设计的，写入即可查。ES 的写入模型为搜索优化，批量刷新（refresh interval）机制决定了写入到可查有延迟。
4. 生态和运维体系不同
Doris 有完整的数据建模方法论（拉链表、维度建模、物化视图自动路由）。ES 的分析能力还在早期，没有形成成熟的方法论。
我的判断：三角不会消失，但边界会移动
短期（2026 下半年）：无影响
9.5 才技术预览，9.6 才 GA。生产环境不会马上用。现有架构照常跑。
中期（2027）：日志/可观测性场景先变
ES Columnar Mode 最先冲击的是”日志 + 可观测性”场景。这些场景的数据特征是 append-only、分析型查询、长期保留——正好是列式存储的甜区。
如果你的 Doris 主要做日志分析，未来可能被 ES Columnar Mode 蚕食。
如果你的 Doris 做的是业务 BI 分析（多表 JOIN、复杂报表），ES 暂时威胁不到。
长期（2028+）：三角可能变两角
如果 ES 的列式分析能力成熟到可以替代 Doris 的大部分分析场景，那么三角可能收敛为：
1 | MySQL（事务） + ES（搜索 + 向量 + 列式分析） |
但这取决于 ES 的列式查询优化器和 JOIN 能力能否追上专用 OLAP 引擎。一个搜索引擎加一个列式存储层，不等于一个列式数据库。
对正在学 Spring AI + MySQL + Doris + ES 的人意味着什么
1. 不要因为 ES Columnar Mode 就砍掉 Doris
现在你的 Doris 该怎么用还怎么用。ES 9.5 还没 GA，等它成熟到能做复杂分析，至少 1-2 年。在此期间，Doris 的 OLAP 能力是确定性的。
2. 但要开始关注”数据存储冗余”问题
目前最常见的架构是：同一份数据，ES 存一份做搜索，Doris 存一份做分析，MySQL 存一份做事务。三份冗余。
ES Columnar Mode 的真正价值不是”ES 变强了”，而是”也许可以少存一份“。如果你的搜索和分析可以由同一个引擎处理，为什么要维护两个集群？
3. 关注 ES|QL 的发展
ES|QL（Elasticsearch Query Language）是 ES 的分析查询语言，是 Columnar Mode 的配套。如果 ES|QL 未来支持更复杂的 JOIN 和窗口函数，那 ES 对 Doris 的威胁就实质化了。
4. 不要被”统一平台”的叙事带偏
Elastic 的博客里有一段话说得很好：
“The pattern that’s starting to replace [fragmentation] is convergence… the right architecture for a modern data engine is one that takes data once, stores it efficiently, and exposes it to whatever workload the application happens to need.”
这个”融合”趋势是真实的——ClickHouse 在做、Doris 在做、ES 也在做。但”融合”不等于”一个引擎做所有事”。融合的终点是”少几个系统”，不是”只剩一个系统”。
更新已有判断
在 MySQL / Doris / ES 三角选型 一文中，我的判断是：
“这三个东西不是同类。每个补对方的能力，都需要付出代价。”
这个判断仍然成立，但需要补充：
ES Columnar Mode 是对”ES 不擅长分析”这个边界的第一次实质挑战。虽然短期内不会改变三角分工，但中期来看，日志/可观测性场景的 ES-Doris 边界会模糊化。长期来看，如果 ES 的列式分析能力成熟，三角可能收敛为两角。但列式存储 ≠ 列式数据库——存储格式变了，查询优化器和执行引擎的成熟度仍需时间。