数据库和搜索引擎，开始互抄作业

两条发布，前后脚落地。ClickHouse 宣布可执行 UDF 在 ClickHouse Cloud 正式 GA，Elastic 则放出了 Elasticsearch 平台的 9.5 大版本。表面上都是例行更新，实际上是一次罕见的「互换基因」：列式分析引擎在补编程能力，搜索引擎在补列存和向量。数据库和搜索这两条曾泾渭分明的赛道，正在朝同一个点会师——谁的边界先被抹掉，谁就先失去定价权。

🧩 UDF 上线：ClickHouse 补上「最后一公里」

分析引擎的天花板，从来不是跑分，而是那些 SQL 写不出来的逻辑。

先讲一个所有数据团队都遇过的场景。一位做实时风控的数据工程师，特征加工逻辑里塞满了正则解析、多级条件判断、甚至要调外部接口补数据。纯 SQL 表达不了，怎么办？只能把数据从 ClickHouse 里导出去，丢给 Spark 或 Flink 加工，再写回来。数据每多搬一次，延迟涨一截，成本涨一截，一致性风险涨一截。过去几年，「分析引擎内做不了复杂逻辑」这件事，养活了一整条 ETL 管道产业。

这次的 GA 就是要砍掉这一段。可执行 UDF 现已在 ClickHouse Cloud 正式可用，覆盖 AWS、GCP、Azure 三朵云。真正的亮点不在「能写 UDF」本身——开源版本早已支持——而在工程配套的完整度：原生运行时、网络访问、可观测性，外加 API 和 Terraform 支持。

这四个词值得逐个掂量。原生运行时意味着 UDF 不再是性能黑洞；网络访问意味着可以在库内安全地调用外部服务；可观测性意味着出问题能查；Terraform 意味着 UDF 可以作为基础设施代码被版本化、被审计、被回滚。

圈子里流传的一种说法是：分析引擎竞争到今天，拼的已经不是单点跑分，而是工程完整度——谁能把「数据不动、计算过来」这个理想真正做成生产级能力，谁就能把对手的管道预算抢过来。

这背后的产业逻辑很清晰：分析引擎的护城河正在从「快」转向「闭环」。Terraform 支持暴露了 ClickHouse 的真实野心——它的目标客户不是写两条 SQL 的分析师，而是把数据平台当产品来运营的平台工程团队。UDF 的本质，是把计算推到数据旁边，而不是把数据推到计算旁边。省下的不只是机器成本，是整条搬运管道的建设和运维成本。

📊 Elastic 9.5：搜索引擎的列存反击

被「分析引擎」抢走的市场，要用「分析能力」抢回来。

再看另一边。过去几年，日志与可观测性市场的预算流向发生了肉眼可见的偏移，列式引擎在聚合分析上的优势被反复引用。运维团队自己心里也清楚：在 Kibana 里跑一个大时间窗的聚合，倒排索引的 doc-based 结构天生不是为 group by 设计的，要么慢，要么贵，要么又慢又贵。

Elastic 9.5 的 GA，就是对这个局面的正面回应。这一版有三个关键点：

第一，Columnar Mode（列存模式）。搜索引擎补列存，等于直接在对手的主场开战——聚合分析的性能故事，从此 Elastic 也能讲。

第二，VectorDB index mode 及自动校准（auto-calibration）。把自己变成 RAG 应用可以直接当向量库用的组件，而自动校准降低的是调参门槛——向量索引的参数调优一直是压在工程团队头上的一座小山，现在交给系统自己做。

第三，AI 驱动的告警分诊（alert triage），外加 Agent Builder 增强。安全运营是 Elastic 最黏、现金流最好的场景之一，把 AI 接进告警分诊，意味着从「帮你存日志」走向「替人看日志」，这是产品定位层面的一步棋。

拆完这三个点，Elastic 的战略意图已经写在脸上：检索是基本盘，列存是反击战，向量是通往 AI 应用的船票，AI 运维则是黏住存量客户的胶水。搜索引擎的差异化叙事，正在从「检索快」转向「检索+分析+AI 运维」三合一。业内一个普遍的判断是，这不会是最后一次——列存只是开始，Elastic 在分析纵深上的投入会持续加码。

⚔️ 会师：两条赛道为何长成了彼此

当两个产品互相抄对方的功能清单，说明市场只认一套考卷。

几乎每一家上规模公司的架构评审会上，都上演过同一场争论：为了聚合分析，要不要再引入一套 ClickHouse？反对者的理由永远一样——多一套引擎，就多一份运维，多一份数据一致性风险，多一支要养的团队。支持者的理由也永远一样——不引入，聚合就是慢。

这场争论之所以反复出现，是因为过去引擎能力是绑死在技术路线上的：倒排索引做检索，列存做分析，向量索引做相似度。而现在的变化是，这三种能力正在被解耦，再重新组合进同一个平台。看两张图就明白了：

左边的引擎往分析走，右边的引擎往检索走，终点指向同一个「统一数据平台」。为什么会这样？三个推力：

其一，存算分离的普及让索引能力可以模块化移植。列存、倒排、向量，本质都是对象存储之上的不同索引结构，技术上的移植门槛比十年前低得多。

其二，云上对象存储把不同索引形态的单位存储成本拉平了，差异化只能往运行时效率和运维体验下沉。

其三，AI 应用的数据形态——文本、向量、事件流——恰好横跨两个阵营。做 RAG 的团队既要全文检索又要向量检索，做可观测性的团队既要日志检索又要聚合分析，没人想为一份 workload 维护两套系统。

于是竞争的重心整体下移：从「你有什么索引」下沉到「你的运行时效率、云原生运维、可编程性和 AI 原生体验」。ClickHouse 的 UDF 加 Terraform，Elastic 的自动校准加告警分诊，本质上是同一场战争的两个正面战场。

💰 给选型者的三个判断

功能清单越像，选型越要回到工作负载本身。

两家的能力对照，摆到一张表上看最直观：

落到实际选型，一条简单的决策路径长这样：

在此基础上，给三个务实判断：

判断一：别急着砍引擎，先算搬运成本。 UDF 的价值不是多一个功能开关，而是让很多原本必须出库的加工逻辑留在库内。评估时把管道建设、运维和故障面一起算进 TCO，省的从来不是 license 钱，是整条管道。

判断二：可观测性市场会最先卷起来。 日志数据量最大、弹性要求最高、价格敏感度也最高，两家都会把最优的性价比压在这个场景上。如果你是日志重度用户，接下来一年的议价窗口值得等。

判断三：AI 原生功能要看落点，不看演示。 自动校准和告警分诊这类能力的真正价值，在于减少人的介入。评估时问一句「它替我的团队省了几个工程师的日常工时」，比看产品视频实在得多。

小结：数据库与搜索的边界消融，不是谁抄谁，而是数据形态变化倒逼的结果——AI 时代的工作负载天然横跨检索、分析和向量化，没有任何一种索引结构能单独吃下。接下来值得盯两个问题：ClickHouse 会不会补齐 AI 运维这块短板，Elastic 会不会补齐编程性这块短板。当两边的能力清单完全重合，真正的分水岭将回到最朴素的两件事——云上的单位成本，和出事之后的运维体验。对用户而言，最务实的原则始终没变：少一道数据搬运，就少一个故障点。