一个OLAP引擎，凭什么吃掉监控和AI

导语： 数据库行业有个反复上演的剧本：专用引擎先跑出来，然后被通用引擎慢慢吃掉。最近 ClickHouse 的动作把这个剧本又往前推了一步——一边推出 TimeSeries 引擎做「Prometheus 平替」，一边把 AI 函数直接塞进 SQL。监控、检索、AI 加工，一个 OLAP 引擎全都要。这不是功能堆砌，而是数据引力在起作用：数据在哪，计算就得去哪。这篇文章拆解 ClickHouse 的这轮扩张，以及它真正想动谁的奶酪。

📈 先动谁的奶酪？监控栈的老三样

每一个运维团队都懂什么叫「三套栈、三份成本」。

一个典型的互联网公司可观测性体系长这样：指标用 Prometheus，日志归日志系统管，链路追踪再单独一套。三套系统、三种存储、三种查询语法，报警规则写三遍，数据关联靠人肉对时间戳。规模小的团队还能忍，数据量一上来，存储成本和人力成本都在指数级膨胀。

这笔账可以算得更具体。以一个日增指标样本量在千万级的中型团队为例：单套 Prometheus 本身并不贵，贵的在于规模化之后的连锁反应——Thanos/VictoriaMetrics 这类长期存储层的运维、Grafana 之外的日志系统（如 ELK，冷数据存储往往是成本大头）、以及三套系统各需的人力。行业里常见的观察是：可观测性支出随数据量接近线性增长，而其中存储占了整个监控 TCO 的一半以上。这也是为什么「统一存储」的叙事在采购决策里始终有号召力。

ClickHouse 这次推出的 TimeSeries Engine，打的正是这个痛点。官方的说法很直白：drop-in Prometheus replacement——你可以把 Prometheus 的指标数据直接存进 ClickHouse Cloud，用熟悉的 PromQL 来查询，不用改写成一堆 SQL。

关键不在「能存指标」，而在「不用改查询」。

这句定位值得细品。很多数据库做时序支持，最后都卡在一个地方：运维工程师写惯了 PromQL，你让他迁移存储、再把查询全部重写成 SQL，迁移成本高到没人愿意动。ClickHouse 选择兼容 PromQL 语法，等于把迁移门槛降到「换个存储后端」这一步，学习成本几乎为零。

更深一层是数据合流的价值。指标、日志、追踪三份数据落进同一个引擎之后，关联分析就不再需要跨系统导数据了——一次故障排查，PromQL 查指标曲线，SQL 查对应时间窗的日志，两步在同一个引擎里完成。

用一张图看这个变化：

而 ClickHouse 想要的世界是这样的：

产业逻辑很清楚：监控数据的本质是大规模时序写入加聚合查询，这恰好是列式 OLAP 引擎的主场。ClickHouse 不是在做一个新能力，而是把自己的老本行往前端推了一步。在性能侧，ClickHouse 处理时序聚合的老底子是公开可查的：单节点每秒百万级行的写入吞吐、对时间戳列压缩后通常能把原始数据压到十分之一左右的存储占用，这两个数字正是时序监控场景最看重的两项指标。Prometheus 生态的强项是采集协议和社区插件，存储层的替代空间一直是存在的——这次 ClickHouse 是明牌要拿下这一层。

💡 SQL里直接调用AI，比听起来重要

真正的转折点，是 AI 变成了数据库的一个内置函数。

ClickHouse 推出的 AI Functions，能力清单包括：分类、生成、翻译、Embedding 向量化、语义搜索，还有成本控制——全部可以直接从 SQL 里调用。

这个事情小看的人很多。过去两年，企业想把 AI 接进数据流程，标准动作是：从数仓里导数据、写 Python 脚本、调 API、把结果再写回数据库。数据在数据库和 AI 管道之间来回搬运，链路长、出错点多、成本不透明。工程团队常见的抱怨是：模型调用费和存储搬运费各算各的，没人说得清一条数据的 AI 加工成本到底是多少。

成本账也可以算一算。按主流 LLM API 的量级估算：一次 Embedding 调用约在百万 token 几美分到一毛多的区间，一次生成类调用的成本则可能高出一到两个数量级。对一个要给千万级文档做向量化入库的项目，模型调用费可能就是数千到数万美元的量级——这还没算数据搬运的存储和计算开销。内置 AI 函数的真正卖点之一，就是把这笔账从「跨系统黑箱」变成 SQL 层可以逐条归因、逐条设限的明细账。

SQL 内置 AI 函数改变的是这个工作流。一条 SELECT 加上一个 AI 函数调用，分类、翻译、向量化在数据所在的位置直接完成，不再需要搭一条独立的管道。尤其是成本控制被做成了函数体系的一部分，意味着团队可以在 SQL 层面对 AI 调用做预算约束，而不是月底拿到账单才发现超支。

注意这里的组合拳：Embedding 生成、语义搜索加上向量检索能力，ClickHouse 实际上是把「数据加工 + 向量存储 + 语义检索」整条链路收进了同一个引擎。这直接改变了 RAG 类应用的数据架构——文档入库、切分、向量化、检索，原本至少三个系统的活，现在理论上一个引擎能跑通。

我判断这一步的战略意义大于功能本身：当 AI 能力以函数形式沉淀在查询引擎里，AI 就从「数据团队的另一个项目」变成了「数据分析的一个操作符」。 这跟当年数据库内置 JSON 支持、地理空间函数的逻辑一模一样——新数据类型成熟的标准，就是它变成 SQL 里顺手的函数。

🗺️ 向量数据库三国杀，选型没有标准答案

在 ClickHouse 伸手之前，向量检索市场已经打得热火朝天。

博主牙克稀做过一次主流向量数据库的科普对比，结论很务实：不用四个都装一遍，按场景选就够了。这里把三个主流选项的定位整理成一张表：

三个产品的分化路径很有代表性。Qdrant 走的是「顺滑起步」路线，功能面齐全，中小团队开箱即用；Milvus 从一开始就冲着大规模 ANN 去的，云原生架构在数据量上去之后的扩容和分布式是它的护城河，企业级检索场景经常被点名；Weaviate 则选了一个差异化切口——把对象和向量存在一起，语义检索可以叠上结构化过滤，适合「语义 + 条件」这种混合查询需求。

这张表对采购决策者最大的价值是：向量数据库不是一个品类，而是三条不同的产品路线。规模、过滤需求、部署方式，三个变量决定了你的答案。

但 ClickHouse AI Functions 的出现，给这个格局加了一个新变量：如果你的向量数据本来就是从业务数据、日志、文档里加工出来的，那「在数据原地生成向量、原地检索」的方案，可能比「ETL 到专用向量库」更省事。专用向量库的优势在极致的检索性能和超大规模场景——毫秒级的召回延迟、亿级向量的分布式索引；而一体化引擎的优势在数据链路短、运维成本低——少一套 ETL，少一份同步延迟，代价通常是查询延迟高一个档位。两条路线的竞争才刚刚开始。

⚠️ 吞并游戏的底层逻辑：数据引力

专用数据库的每次繁荣，都在为通用引擎的下一次扩张铺路。

回头看 ClickHouse 这两步棋，表面是功能发布，底层是同一个物理规律：数据引力。数据存放的位置会产生引力，计算、查询、加工能力会不断向数据汇聚的地方迁移。反过来讲，把数据搬运到计算所在的地方，成本永远高于把计算推到数据旁边。

这个规律解释了过去十年数据库行业的整轮整合：数仓吃掉 ETL 工具的活，湖仓一体吃掉数据湖和数据仓的边界，现在轮到时序监控和向量检索被 OLAP 引擎纳入版图。每类专用数据库在早期靠专用引擎的性能优势立足，等数据规模普及、场景标准化之后，通用引擎用一个「够用 + 便宜 + 少一套系统」的组合拳反打，专用玩家被迫向上走更极端的性能或更深的场景。

ClickHouse 的时序和 AI 两步棋，正是这个剧本的标准展开：

把四块能力拼起来看，ClickHouse 的野心图已经很清楚：可观测性（指标、日志、追踪）是一个场景，数据加工 + 语义检索（RAG）是另一个场景，两个场景共享同一个存储底座和同一套 SQL 接口。它不再只是一个「快」的分析引擎，而是在往「一站式数据平台」的位置走。

对用户来说，这轮整合的账很好算：少一套系统，就少一份许可证或云服务账单、少一套运维流程、少一个数据同步环节的故障点。在降本增效成为主旋律的当下，「合」的吸引力远大于「专」的吸引力。

🚧 别急着拆栈：融合的代价与边界

一体化是方向，但一体化的边界同样真实。

给这轮热潮泼一点冷水是必要的。

兼容语法≠对等性能：PromQL 兼容的真实边界

第一个边界藏在 PromQL 兼容的细节里。目前 ClickHouse 的 PromQL 支持覆盖的是查询语言的核心面——rate、sum、avg 这类基础聚合与函数，histogram_quantile 这类直方图分位数计算，以及区间向量操作，这些日常写面板和临时排查用得最多的部分基本能跑通。但 Prometheus 的完整体系远不止查询语法：recording rules、alerting rules、Service Discovery、各 exporter 的生态约定，这些都不在「兼容」的射程之内。

换句话说，drop-in 指的是「把 Prometheus 当存储后端用 PromQL 查」这一层，而不是「把整个 Prometheus 换掉」。采集端仍需保留（或改用远程写入），告警逻辑要么继续跑在 Prometheus 上，要么迁移到其他告警系统。对已经有成熟告警体系的团队，这反而是个可以接受的边界；但对想「一步到位换栈」的团队，中间还差着一整层生态工程。

性能上也要留个心眼：Prometheus 单机在数百万活跃时间序列时会出现内存和查询压力，这是它需要长期存储层的根本原因；ClickHouse 在存储规模和聚合吞吐上有结构性优势，但高频短查询的延迟、以及 PromQL 到 SQL 翻译层的开销，需要在自己的负载上实测，不能拿官方基准直接外推。

AI 函数进 SQL≠数据工程消失：成本账要重新算

第二个边界在 AI 这条线。函数进了 SQL，不等于工程问题消失了——数据质量治理、模型效果评估、失败重试、幂等性这些活儿依然存在，只是从 Python 脚本里挪到了数据库里。

成本上同样需要重新算账。内置 AI 函数省掉了数据搬运的成本，但模型调用的单价没有变：假设一个团队要给 500 万条客户工单做分类加摘要，按每次调用平均消耗上千 token 估算，仅模型调用费就可能到数千美元量级；如果不加预算控制，一个写错的 UPDATE 语句触发全表重算，账单翻倍是分分钟的事。这也是为什么「成本控制做成函数体系的一部分」这个细节值得加分——但它替代不了事前的调用量估算和事后的用量审计。SQL 化降低的是工程复杂度，不是模型单价。

向量场景的分化仍会持续

第三个边界在向量这条线。Qdrant 的轻快（单节点起步极低、过滤检索性能扎实）、Milvus 的分布式规模能力（十亿级向量场景的成熟案例）、Weaviate 的混合查询（BM25 + 向量的融合检索），各有真实的技术纵深，短期内不会被一体化引擎抹平。

可以给一个粗略的分界线做参考：向量规模在千万级以内、且向量只是业务链路的一环（比如给日志和工单加语义搜索），一体化引擎的「省一套系统」通常赢；向量规模到了亿级、或检索延迟是产品体验的核心指标（比如以搜索为核心业务的公司），专用引擎在索引结构和召回优化上的纵深仍然难以替代。

分场景的行动建议

所以我的建议是分场景判断，并且用几个可操作的问题来切：

• 监控栈：已经在用 ClickHouse、指标规模中等（日增样本千万级以内）、被多套监控栈成本困扰的团队，TimeSeries 引擎值得做一次 PoC——重点测高频短查询延迟和 PromQL 兼容度，而不是只看写入吞吐；告警体系复杂的团队，先想清楚告警层留在哪里再动存储层。
• AI 加工链路：数据加工链路上有大量 AI 调用需求的团队，AI Functions 能砍掉一条搬运管道——但上线前先跑一次小样本的成本核算，把单条数据的加工成本算清楚，再决定是否全量。
• 向量检索：先问自己一个问题——语义检索是核心业务还是辅助功能。是辅助，一体化方案的数据链路优势通常更划算；是核心，专用向量库的性能纵深目前仍是更稳妥的选择。

小结： ClickHouse 这轮动作的本质，不是发明了什么新技术，而是顺着数据引力，把时序和 AI 两个已经标准化的场景收进自己的版图。专用数据库的繁荣期正在向整合期过渡，未来一两年的看点是：Prometheus 存储层的替代速度，以及 AI 函数能否成为 SQL 的标配。

🔭 结语：算好「几套系统」这笔账

回头看这篇文章拆的三条战线——监控栈、AI 加工、向量检索，ClickHouse 的打法是一致的：不跟专用引擎比极限性能，而是比总拥有成本。少一套系统省下的，不只是许可证和云账单，还有运维人力、数据同步的故障点、以及团队在不同查询语法之间切换的心智成本。这些隐性成本平时不出现在任何一张报价单上，却在每一次故障排查、每一个交接班、每一份季度预算里反复出现。

但数据引力不是万能的。这次拆解的边界同样清晰：PromQL 兼容覆盖不到告警与采集生态，AI 函数省不掉模型单价和效果评估，向量场景的极致性能仍握在专用玩家手里。一体化引擎吃下的是「标准化之后的大多数场景」，留给专用数据库的，是最 extreme 的那部分需求——而这部分需求，往往恰恰是专用玩家的利润来源。

对数据团队而言，真正该关注的不是某个产品的发布，而是「维护几套系统」这笔账，每一季度都该重新算一遍：数据规模变了、团队人力变了、某个场景从辅助变成了核心，答案就可能反转。技术选型没有一劳永逸，只有持续的复算。