AI时代实时分析三大范式：基于Apache Doris与SelectDB的实践

过去半年，我先后帮三个团队搭AI应用背后的实时分析链路，底层都用了 Apache Doris 和 SelectDB。一开始只觉得这引擎顺手，直到某次在客户现场复盘时才意识到——大家以为自己在做完全不同的项目，画到纸上几乎都是同一张依赖图：左边是实时数据源，中间一个在线分析引擎，右边站着一群 AI 组件，要么是模型推理，要么是大模型 Agent。

有个团队在做智能客服，希望把会话过程中的实时行为特征喂给模型，让机器人当场判断用户是不是要投诉。有个团队在做大模型 BI，想让业务人员直接问“华东区今天新客转化率为什么跌了”，系统自动拉实时指标。还有个团队上线了编程助手，他们最关心的不是模型效果榜，而是每个 Agent 决策链路里到底哪一步在浪费时间。这三个需求看起来分属完全不同的领域，最终都不约而同回到了同一个底座：Apache Doris + SelectDB。

我不是来写产品广告的。这篇文章想把我在这些项目里反复看到的东西整理出来：AI 时代的实时分析，其实可以收敛成三种可复用的范式。每种范式对应一类典型的业务价值，也有它自己的工程约束和坑点。如果你正在规划“AI 应用接入实时数据”这件事，这篇文章应该能帮你少走不少弯路。

1. AI 时代的数据消费方变了：实时分析不再只是一张报表

先说清楚一个问题：为什么非要在“实时分析”前面加上“AI 时代”四个字？难道以前实时分析就不重要吗？当然重要，但过去几十年，实时分析的主要消费方式是“人看”。BI 报表、实时大屏、运营仪表盘，最终都是给人决策用的。既然最终用户是人，那对延迟的容忍度、对查询模式的要求、对数据口径的理解方式，都相对固定。

AI 出现以后，数据消费方变得复杂了。除了人，还有模型，还有 Agent。一个模型在推荐、定价、风控的推理时刻，需要最新特征。一个自然语言问答系统在回答“现在华东区新客转化率是多少”的瞬间，如果数据还停留在昨天，它给出的答案再流畅也没有意义。一个 AI Agent 在执行用户的复杂任务时，系统需要实时判断它是不是卡在某个工具调用上。这些场景的共同特征是“数据直接被程序消费”，而不是先给人看一眼、再由人判断。

传统实时分析链路常见的长这样：业务库通过 CDC 进 Kafka，Flink 或 Spark Streaming 做完清洗聚合，再写进 Doris、ClickHouse 这类 OLAP 引擎，最后接 API 给前端。这个链路本身不过时，过时的是“计算完成之后只服务报表”的思维方式。到了 AI 时代，同样的链路需要回答的往往是以下几类问题：

• 这个用户最近 10 分钟有没有对某个商品表现出高意向？模型要基于这个动态特征调整推荐排序。
• 华东区今天实时的新客转化率，相比昨天同一时刻是升是降？大模型需要引用这个指标来回答业务人员。
• 刚才那个 Agent 会话里，某个工具调用已经重试了六次，是不是该主动干预或切换策略？

这三种问题分别代表模型要吃的“口粮”、大模型要调用的“事实”、Agent 要监控的“状态”。它们恰恰对应我下面要讲的三大范式。

1.1 传统实时链路里三个“追不上”

我在实际项目中总结过，传统链路有三个地方是很难追上的。

第一，时效追不上。很多团队的所谓实时，实际是小时级或者十分钟级。规则任务每五分钟跑一次，结果导入宽表，再建接口。这个延迟对人工决策没有太大问题，可模型推理是按毫秒算的。当用户点了一个商品，推荐系统必须在200毫秒内把“最近5分钟浏览倾向”这个特征算出来。十分钟才更新一次的特征，几乎等于没有特征。

第二，查询模式追不上。传统 BI 的分析查询是“重聚合、低并发”：一个看板可能几秒出结果，几十个并发就很高了。但 AI 应用一旦把特征或指标服务化，每天要面对的是高并发的点查和短查询，一个集群可能同时被几十个特征服务实例访问，每个查询只要几条记录。OLAP 引擎却常常被用来做全表扫描或大聚合，这两种模式完全不是一回事。

第三，反馈闭环追不上。传统数据仓库很少需要把线上数据回写给模型。AI 来了之后，模型的推理结果、用户反馈、误报标记，都需要重新进入分析系统。它们既用于在线监控，也用于下一轮模型训练。这意味着分析引擎不能只在数据流的末端读数据，还得作为一个被写入、修改、查询的中转节点存在。

1.2 为什么我用 Apache Doris 和 SelectDB 作为观察样本

这篇文章围绕 Apache Doris + SelectDB 来写，是因为它是我最近一年实际用得最多的组合，也刚好踩中了 AI 时代数据架构的几个关键点：支持高并发点查、有面向更新场景的主键模型、原生能消费 Kafka 流、SQL 生态完整。

SelectDB 是 Apache Doris 核心团队创立的商业化产品，底层仍然是 Doris 内核。我这边主要用的是 SelectDB 的商业版本，纯开源自建也一样能跑通下面这些实践。差异主要在云上托管、数据权限、多集群管理等外围能力，SQL 和数据模型层面几乎没有区别。

后面的三个范式，我都在这个底座上真实跑过，不是纸面推演。下面直接进正题。

2. 三大范式全貌：它们分别解决哪一类 AI 需求

在开始讲细节之前，我觉得有必要把三个范式的整体轮廓先画出来。避免你读着读着陷入某个具体案例，忘记自己身处哪个分支。

• 范式一：面向模型推理的实时特征管道。核心逻辑是“把数据算成模型可用的特征”。它解决的是模型如何拿到最新鲜的上下文。
• 范式二：面向人的对话式实时分析。核心逻辑是“让大模型成为数据入口”。它解决的是用户如何用自然语言从实时数仓拿到准确答案。
• 范式三：面向 AI 应用自身的实时观测与反馈闭环。核心逻辑是“把 AI Agent 当作一个业务系统来监控和优化”。它解决的是 AI 应用本身如何被观测、如何持续迭代。

这三个范式不是产品形态上的划分，而是数据流向的划分：数据流进模型、数据流到人、数据流回 AI 应用自身。从系统架构角度看，一个成熟的 AI 数据平台往往同时具备这三种流向，并且共用同一个底层存储与计算引擎。

下面这张表能帮你看清三个范式的区别和联系。

这三个范式落地在同一套引擎上，不代表要用三个集群。更实际的做法是部署一套 Doris/SelectDB 集群，用不同的数据库、账号和工作负载组做隔离。三种数据流经常有交叉，比如范式二里的“大模型回答”结果，本身也是范式三要采集的事件。分开物理部署反而会破坏数据关系，维护成本也会翻倍。

2.1 范式一：数据变成模型的“实时口粮”

先说范式一，因为它的业务价值最直接，也最容易量化。

在推荐系统或者智能客服里，模型通常不能只依赖用户注册时的静态画像。用户今天看了什么、前十分钟是否对某个商品反复停留、当前会话里情绪是否升级，这些特征都高度依赖实时数据。过去很多团队用离线 ETL 每天算一次特征，第二天凌晨灌进 Redis 或者 HBase，模型上线后用户的行为已经变了。AI 应用如果只拿到“昨天的你”，很多个性化体验都是空话。

范式一的思路是：把实时计算的结果统一落到一张可更新的特征宽表里，特征服务再以高并发点查方式读取。Doris 在这个链路中既是一个实时特征的计算引擎，也是一个面向在线推理的特征数据库。它不需要你去单独维护一套 Redis、一套 ClickHouse、一套调度任务。Kafka 里的行为事件持续导入到 Doris，主键模型负责对同一用户的特征做更新，外部服务通过 SQL 用主键抓取最新特征。

当然，真实推荐系统往往在前面还会架一层 Redis 或内存缓存，抵挡超高QPS。但 Doris/SelectDB 在这个过程中至少承担了两个不可替代的职责：一是把秒级新鲜度和复杂 SQL 聚合能力放在同一份数仓数据上，二是在模型特征回刷、校验和上线时提供一个能随时用 SQL 做数据质量核查的源头。

2.2 范式二：大模型变成数据入口，但别让它真的碰数据

范式二是我个人认为最容易翻车、也最有想象空间的一个方向。简单说，就是让业务人员用自然语言提问，大模型根据问题生成查询意图，底层由 Doris 实时执行，返回真实指标。

这里的关键词是“真实指标”。大模型再聪明，也不能凭空算数。一个业务问题是“华东区今天新客下单转化率比昨天怎么样”，大模型并不知道订单表在哪、哪个字段代表新客、华东区应该用什么维度过滤。它如果把业务库连接和数据库账号随便拿来折腾，轻则口径错误，重则把生产集群查挂。

真正可行的架构是语义层 + 查询引擎 + 大模型三层分工：语义层维护指标定义、维度字典和权限边界；Doris 负责所有真实数据的计算；大模型只负责“理解问题、组织参数、解释结果”。大模型的输出不是 SQL，而是一份结构化查询意图，比如指标名、维度条件、时间范围。后端拿这份意图去查 Doris，再把结果交给大模型总结成一句话。这样，大模型既不会产生幻觉数字，也不会误用数据库账号。

范式二在业务上的最终形态是“指标助手”。它不会完全替代固定报表，而是把高频的临时取数需求从提报表工单变成一句对话。

2.3 范式三：Agent 本身成为被实时分析的业务系统

范式三是我最近半年感受最深的一个变化。过去我们监控一个搜索推荐系统，靠的是 QPS、延迟、内存这类传统指标。但 AI Agent 上线后，光是系统级指标远远不够。你还需要知道用户在会话里走到了哪一步、Agent 为什么连续调用了同一个工具、知识库召回结果是否匹配预期、大模型这次回答实际消耗了多少 token、用户最后有没有给出正向反馈。

这些问题不能只靠日志或者链路追踪解决。传统 Trace 系统擅长回答“哪一步报错了”，但很难回答“哪一步没报错却在浪费钱”或者“哪种失败模式正在影响用户完成率”。要把这些问题回答好，需要把 Agent 的事件流当成业务数据采集下来，用实时分析引擎做漏斗和聚合。

范式三的数据流是这样的：Agent 每执行一步动作就产生一条结构化事件，事件进 Kafka，SelectDB 通过 Routine Load 持续消费，落到明细表中。实时任务分析这些事件，会得到会话完成率、平均重试次数、工具调用异常分布等指标。这些指标一方面驱动监控告警，另一方面把失败案例回流成评估集，用来调 Prompt、选模型、做下一轮 Agent 版本实验。整个过程如果用一张拓扑图表示，就会看到一个闭环：Agent 产生数据、数据驱动分析、分析结果回到模型迭代。

2.4 三种范式的分界线并不在产品上，而在数据流上

很多文章会把这三个范式拆成三个独立产品，比如“特征平台”“智能BI”“可观测性工具”。但我更愿意把它们看成同一套数据底座上的三条数据通路。

你可以在一个 Doris 集群里建三个库：feature 存放实时特征宽表，semantic_metrics 存放指标库和维度维度映射结果，agent_event 存放 Agent 运行事件。三套数据共享同一套权限、备份和查询引擎，却服务完全不同的消费方。对这种架构，最重要的事情不是一开始就选“最新最好的引擎”，而是想清楚你现在要打通哪条数据流。下面我开始逐个范式说落地细节。

3. 范式一拆解：用 Doris 做秒级新鲜的实时特征池

先明确一个前提：这里说的特征池，不是搜索引擎倒排索引那种毫秒级 KV 存储。它服务的模型特征往往是几十到几百列的大宽表，既可能是用户维度，也可能是商品、会话或者事件维度。模型特征服务需要“按 ID 批量取一行”，并且这一行要能持续被新事件更新。如果你把需求翻译成数据库语言，就是“一张支持高频 Upsert 的超大宽表，还要能高并发按主键点查”。这正好接近 Doris 的主键模型场景。

3.1 为什么不能只靠 Redis，也不能只靠 Flink

凡是做过特征工程的人，第一反应通常是“特征当然放 Redis”。Redis 的 QPS 确实高，但它的模型太简单了。几十个特征列要对应不同数据类型的字段、还要做范围过滤和条件更新，硬塞进 Redis 的 string 或 hash 里，维护成本非常高。更麻烦的是，离线和实时两套特征逻辑经常对不上。离线特征用 Hive SQL 算，实时特征用 Redis 的命令拼，口径不一致几乎无法避免。

Flink 也能做实时特征，但它更适合做“事件流上的计算”，而不是一个存储系统。把 Flink 状态做大、再做外部查询，难度和风险都很高。真正合适的做法是让流处理负责“清洗和粗粒度的聚合”，最终的实时特征表落到一个能支持 SQL 查询的分析引擎里。这也是我为什么强调：AI 特征工程需要一个“事实的单一来源”，而不只是一个大号缓存。

在实际项目中，我的做法是把 Kafka 里的用户行为事件直接通过 Doris 的 Routine Load 导入到明细表，然后用周期调度的 SQL 任务或者简单的流处理链路把关注特征收紧到一张特征宽表。用户特征更新不需要每次都重算全量，只需要根据增量事件做 upsert。这就在数据模型上同时拿到了离线表结构的灵活性、实时流的时效性、点查的高性能。

3.2 建表模型和更新策略怎么选

如果你已经决定用 Doris 做实时特征池，第一步就是要选对数据模型。我强烈建议特征类表使用 Unique Key 模型，并且开启 Merge-On-Write。原因很简单：特征表通常是主键唯一的一张宽表，要求同一个用户/商品/会话 ID 的新数据能覆盖旧数据，而不是像明细日志那样不断追加。

一个典型的用户实时特征表，建表可以这样写：

sql复制CREATE TABLE user_feature_realtime
(
    user_id             VARCHAR(64) NOT NULL,
    city_id             INT,
    gender              TINYINT,
    total_orders        BIGINT DEFAULT '0',
    order_cnt_1d        BIGINT DEFAULT '0',
    order_cnt_1h        BIGINT DEFAULT '0',
    click_cnt_10m       BIGINT DEFAULT '0',
    cart_cnt_1h         BIGINT DEFAULT '0',
    recent_category_ids VARCHAR(2048),
    ltv_30d             DECIMAL(12, 2),
    updated_at          DATETIME
)
UNIQUE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 48
PROPERTIES
(
    "replication_num" = "3",
    "unique_key_merge_on_write" = "true"
);

表结构有两个细节值得注意。一是主键只保留 user_id，不要带上时间字段，否则每次写入会按主键新增而不是覆盖，特征表会无限膨胀。二是 updated_at 只是业务字段，不能放进主键，真正的变更排序要依赖导入时 Doris 对同一主键的后到覆盖规则。如果你需要做“部分列更新”，比如只想更新某个特征列，推荐使用 Routine Load 的 partial_columns 能力，避免每次把几十列全量拼接一遍。

使用上，模型服务可以通过 JDBC 或者 HTTP 接口做批量点查：

sql复制SELECT user_id, click_cnt_10m, order_cnt_1h, recent_category_ids
FROM user_feature_realtime
WHERE user_id IN ('u_1001', 'u_1002', 'u_1003');

这个查询返回的是三行特征，通常可以在毫秒级完成。如果业务需要数千甚至数万 QPS，让特征服务直接打 Doris 的 9030 端口会显得有点重。更稳妥的办法是前面加一个薄查询层，用 Redis 做短时间缓存，或部署 SelectDB 提供的 JDBC 连接池。Doris 的天然强项仍然是批量化和高吞吐，点查要做得极刚性，需要配合资源隔离和预热。

3.3 计算能下推就下推，别让特征服务变成“傻缓存”

范式一最容易出现的误区，是只把 Doris 当成一张“用来存放别人算好的结果的表”。如果所有特征值都在 Flink 或业务应用里算完，再写入 Doris，那依然是一套割裂的链路，实时特征与离线特征的一致性没有从根上解决。

正确的思路是把能够用 SQL 表达的窗口聚合尽量下推到 Doris 或 Flink 导入链路的边缘。比如“用户最近 10 分钟的点击次数”，Kafka 里的原始事件会持续进明细表，Doris 可以通过物化视图或者定时任务周期性地聚合成特征结果，再写回特征宽表。这样数据从一个源头进去，加工逻辑全部集中在同一个引擎里，链路最短，出问题时排查范围也最小。

当然，如果窗口逻辑特别复杂，或者涉及多流 Join 和多层状态，Doris 当前不是最适合做状态管理的地方。我的经验是：复杂流计算用 Flink，算完之后再批量写入 Doris；简单但高频的实时特征，尽量在 Doris 内部搞定，减少一套“可能挂的实时作业”。

3.4 范式一的几个真实坑

第一个坑是主键热点。如果你的特征服务只集中在少数几个用户上，分桶再均匀也没有用。比如大主播开播瞬间，海量下游会同时请求同一位主播的特征。这时 DISTRIBUTED BY HASH(anchor_id) 会让所有点查都打到一个 bucket，形成热点。这种场景要主动改造特征键结构，例如把主键设计成 (anchor_id, shard_id)，查询时拆成多个并发小查询再合并，让热点分散。

第二个坑是频繁小导入。有些团队把每个用户的行为事件都当作一次单独导入，Routine Load 里设置了每次只处理几条数据。这会产生大量小版本，compaction 压力飙升，最终查询变慢。正确做法是把导入节奏控制在秒级或十秒级批量，而不是每条都触发一次 commit。在流式计算端增加一个窗口攒批逻辑，能明显提升 Doris 的稳态性能。

第三个坑是只关心点查，忘了数据质量核查。特征表一旦出错，模型会规模化犯错，而且很难被发现。我的习惯是每次大版本特征上线前，都会在 Doris 上写几条跨源核对 SQL，把实时特征表和离线特征表做一次总量对比。只要偏差超过阈值，线上特征服务要能自动熔断切换。

4. 范式二拆解：大模型负责说话，Doris 负责算数

范式二是我见过落地时最容易让“非技术出身的业务方”眼前一亮的方向。但也是技术团队最容易被大模型的“聪明表现”带偏、最后踩进大坑的方向。这里我先放一条铁律：不要让大模型直接连 Doris 去生成 SQL、执行 SQL。你可以在离线环境里让它做实验，但不能在生产环境开放裸 SQL。

原因很简单。大模型生成的 SQL 在语法上可能完全正确，但它对数据表的理解可能是错的。比如“新客”这个字段，不同团队有三套定义：有人认为是首次下单用户，有人认为是首次访问用户，还有人认为是近90天未下单用户。大模型如果只看到 is_new_user 字段，它不会知道这个字段背后是哪套定义。它生成的 SQL 天然会掩盖口径矛盾，让结果看起来正确，实际上完全不可比。

范式二的正确打开方式，是把语义层放在大模型和数据之间。语义层承担了两件事：第一，把物理表字段映射成业务指标；第二，把权限、维度表和查询约束管起来。大模型在语义层之上工作，而不是直接面对底层几百个物理表。

4.1 “指标注册 + 查询意图生成”这条链路怎么搭

我在实际项目里推荐的链路是这样的：

1. 用户提问：“华东区今天新客下单转化率多少，跟昨天比怎么样？”
2. 大模型先识别用户问题中的业务实体，把它转化为一个结构化查询意图 JSON，例如 metric: new_customer_order_rate，dimension: region，filter: region=华东，period: today vs yesterday。
3. 后端根据查询意图 JSON，去语义层找到物理指标定义和表名，再拼装成 Doris SQL。
4. SQL 在 Doris 的资源隔离组中执行，返回结果。
5. 大模型拿到结果后，用户友好地解释：“华东区今天新客下单转化率是 1.84%，较昨日下降 0.23 个百分点。”

这个链路中最难的不是让大模型理解自然语言，而是让查询意图和物理指标之间的映射稳定可靠。语义层需要先做指标注册，每个指标由以下信息描述：指标名称、归属主题域、计算公式、粒度、时间口径、所依赖的物理表以及过滤条件。维度类似，也需要统一“华东区”“今天”“近7天”这些业务表达到底对应哪些字段和取值范围。

一旦这套语义层建好，后续新增指标的成本会非常低。业务方要新看一个指标，只要在语义层里注册一次，大模型不需要重新微调，马上能通过自然语言查出来。如果只依赖大模型直接读表结构，每次加字段都要重新做调试，永远处于打补丁的状态。

4.2 为什么查询引擎选 Doris/SelectDB 而不是别的

范式二对查询引擎有比较苛刻的要求。第一，用户提问往往发生在白天的业务高峰，并发不会太低；第二，指标查询要求秒级返回，不能像跑离线报表那样等一分钟；第三，同一个问题可能会被反复问，Doris 的 SQL 缓存和物化视图能够减少重复计算。

Doris 的 MPP 架构和向量化执行引擎，对中间宽表的扫描和聚合效率比较高。它不像传统数仓那样依赖复杂的索引，建表简单，SQL 兼容性好，适合作为“指标层”的统一出口。SelectDB 在这之上还提供了比较完善的服务级托管能力，你不需要关心运维问题，权限控制和多集群隔离也更容易处理。

我见过团队一开始用 Redis 做指标查询，把每个指标预计算好塞进去。一开始只有几十个指标，效果还行。后来指标到了几百个，粒度组合爆炸，Redis key 数量失控。再想改成任意维度筛选时，整套预计算体系就得推倒重来。用一个 SQL 引擎做这件事，至少你保留了“任意组合查询”的能力，不会再被预计算设计钉死。

4.3 如何防止 Agent 把实时集群查挂

这是范式二的大坑。大模型在处理问题时，经常会生成两个很要命的操作：一个是忘了加时间范围过滤，直接扫全表；另一个是生成没有 LIMIT 的查询，结果集大到内存爆掉。这时候如果没有资源限制，一个用户随手问一句，就可能把整个实时分析集群的查询资源耗尽，业务方马上会大面积投诉。

在我实践过的部署里，Doris 侧至少要配置三层保护：

• 会话层：给 AI Agent 的数据库账号设置 query_timeout=30，执行内存上限 exec_mem_limit 控制在合理范围。
• 工作负载组：为 AI 查询单独划分资源组，设置最大并发数和排队时间，避免和核心报表任务互相抢占。
• 扫描行数限制：对单条查询可扫描的行数做硬上限，一旦超过立刻报错。

这三个保护可以在 Doris 或 SelectDB 中通过账号与资源组配置实现。一定要记住，范式二里真正不可控的因素不是 Doris，而是大模型的“自由发挥”。你的系统要把所有不确定性挡在查询引擎之外。

4.4 语义层与权限体系是一次性投入，别省

最后还是要强调，语义层一旦建好，它就不只是为 AI 服务了。之后任何团队要接新的数据应用，都可以直接基于语义层暴露指标 API，而不需要在应用侧反复写 SQL。权限体系也可以做到字段级：普通业务只能看汇总指标，不能下钻到用户明细；管理层可以看到团队级，看不到个人级。这项工作是一次性投入，后期收益极高。

我在多个客户现场看到的结果是，范式二最容易出成果、但也最需要耐心。前两周都在做指标调研和口径对齐，效果看起来很慢。一旦语义层稳定之后，后续新增问题的准确率会远高于“让大模型直接连着库裸跑”的方案。

5. 范式三拆解：AI 应用自己也要被实时数据喂养

范式三我从去年开始讲得越来越多。很多团队在把 Agent 产品放上线之前，都以为最大的难题是模型能力不够。上线之后才发现，真正影响用户体验的往往是系统稳定性、工具调用链条和成本控制。模型能力再强，如果在某个环节反复触发工具超时，用户早就流失了。

AI 应用的可观测性，和传统应用的可观测性有本质区别。传统监控只需要知道这个接口延迟高、报错了，但 AI Agent 的过程是复杂的决策链路，比如“用户提问->路由选择工具->知识库召回->模型生成->用户反馈”。只有把每一步都作为事件记录下来，放进分析引擎，才能知道整个链路哪一环成了瓶颈。

5.1 Agent 事件流应该怎么采集和建模

Agent 应用通常已经有日志、也有 OpenTelemetry 之类的链路追踪。但链路追踪解决的是调用拓扑，解决不了“业务语义”。你需要把每个 Agent 应用的行为定义成若干结构化事件，比如：

• 会话开始和结束；
• 每次大模型调用的模型名称、上下文长度、输出 token 数、消耗时长；
• 每次工具调用的工具名、参数摘要、结果状态、重试次数；
• 用户反馈的赞、踩、是否复制推荐内容；
• 最终任务是否成功、完成路径、所用时长。

这些事件不适合只存在普通日志文件里。因为你要做的是实时分析：比如每隔一分钟统计“当前正在重试的工具调用数量”。我把这类事件直接通过 Kafka 推给 Doris，用明细模型存储，每个 Agent 实例不需要自己维护一张独立表，统一进入 agent_event 大分区表。过程简单直接，避免在应用侧引入复杂数据管道。

5.2 实时漏斗和指标计算怎么做

事件进 Doris 后，最常用的分析手段是漏斗。假设你想知道“用户完成一次咨询的成功率”，每一步都有对应事件类型，实时漏斗 SQL 可以写成：

sql复制SELECT
    step,
    COUNT(DISTINCT session_id) AS sessions
FROM
(
    SELECT session_id,
           CASE
               WHEN event_name = 'session_start' THEN '会话开始'
               WHEN event_name = 'tool_call_success' THEN '工具成功'
               WHEN event_name = 'llm_reply_finish' THEN '回复完成'
               WHEN event_name = 'user_feedback_positive' THEN '用户正向反馈'
           END AS step,
           event_time
    FROM agent_event
    WHERE event_time >= NOW() - INTERVAL 1 HOUR
) t
WHERE step IS NOT NULL
GROUP BY step
ORDER BY sessions DESC;

当然，这个例子为了展示漏斗，简化了真实的会话窗口逻辑。实际系统里，你也可以用 Doris 的窗口函数把事件按 session 内的时间排序，再计算不同路径之间的转化率。比“平均首次回复时长”这种单点指标更能反映 Agent 质量。

除了漏斗，范式三还需要一类“异常模式”分析。比如找出连续多次工具失败并且最终没有完成的会话：

sql复制SELECT session_id, 
       COUNT() AS retry_cnt
FROM agent_event
WHERE event_name = 'tool_call_fail'
  AND event_time >= NOW() - INTERVAL 5 MINUTE
GROUP BY session_id
HAVING COUNT() >= 3
ORDER BY retry_cnt DESC
LIMIT 20;

这类查询如果定时每分钟跑一次，再配合告警，你就能做到“当某个 Agent 正在陷入死循环时，还在 5 分钟内就能被看见”。相比第二天才看离线日志，这个反应速度完全不是一个量级。

5.3 从“看见失败”到“让模型变好”的数据飞轮

范式三的最终价值不是监控，而是形成数据飞轮。过去我们做模型迭代，靠人工收集 bad case，把问题样例整理成 Excel，再交给算法团队标注。现在有了实时事件库，失败案例天然就在那里，你可以用 Doris 的导出能力把一段时间的 bad case 快速导出成训练集或评测集。

我见过一个自动迭代链路是这样跑的：夜里零点，系统会自动从 Doris 中导出过去 24 小时内被用户明确“点踩”或“连续两次打断”的对话片段，清洗后形成批量评测集。第二天早上算法团队跑一轮评估，决定今天是否要调整 Prompt 或更换模型。实际效果可能不像“全自动闭环”那样完美，但至少 bad case 收集的周期从两周缩短到一天，这对 AI 应用迭代速度的提升是决定性的。

5.4 范式三的细节提醒

Agent 事件表可能增长很快，建议按时间分区，保留最近 30 到 90 天即可。不要把所有原始事件永久保留在实体表里。长期留存的应该是加工后的指标和精华 bad case，不是每一条调试日志。否则集群存储成本会被 Agent 系统“吃掉”，比你想的还要快。

另一个细节是时间字段。Agent 事件一定要携带两个时间：事件发生时间和事件写入时间。因为你从 Kafka 消费可能出现延迟，如果分析时只用事件写入时间，晚到的数据会污染近实时统计。Doris 明细模型支持分区裁剪，把分区键设成事件发生时间对应的日期，查询时才能准确扫描需要的数据。

6. 三种范式别一上来全做：启动顺序与避坑清单

看完全部三种范式，你可能会觉得每一条都很有道理，于是想“我都做”。我劝你先冷静一下。三个范式背后对应的是三个不同的平台化方向，它们的冷启动成本、技术难点和业务负责人都不一样。在没有明确价值验证之前就并行推进，很容易把团队资源拖垮。

6.1 先判断你当前最痛的场景是哪一个

如果你们的业务是靠模型做搜索、推荐、广告、风控，模型效果提升能直接换算成 GMV 或风险损失，那我强烈建议先做范式一。因为特征新鲜度对模型效果的影响最直接，而且你大概率已经有离线特征和线上推理服务，趁手的切入点很多。你不需要先建设一个庞大平台，只需要先把一两个关键特征实时化，跑 AB 实验证明收益。

如果你们的团队已经有很多业务人员经常在群里问“昨天的数据怎么和上个月口径不对”，或者报表中心被临时取数需求淹没，那范式二是最值得投入的。但要注意好高骛远，别指望第一个版本就支持“任意复杂问题”。先圈定十个核心指标，把语义层跑通，准确率稳定后，再逐步扩大范围。

如果你们已经有 Agent 产品在线上，例如客服机器人、编程助手、流程自动化 Agent，但你还说不清用户今天为什么失败、哪些流程消耗最多、不同模型版本的实际效果差异在哪里，那范式三优先级最高。它做起来不需要等数据团队，应用研发和算法合作就能启动，价值一个礼拜就能看见。

6.2 最小闭环怎么设计

对范式一，最小闭环是“一个关键特征 + 一个线上模型”。先找业务方确认提升最明显的特征，比如客服场景里“当前会话情绪指数”“最近5分钟用户是否多次重复提问”。构建好实时特征后，通过 AB 实验看这个特征对解决率或满意度的影响。不要做一堆特征，然后全堆上去，那样说不清到底是哪个特征起的效果。

对范式二，最小闭环是“一个指标 + 一个固定话术”。选一个最常被问、且当前数据表已经能稳定产出的指标，让大模型只回答这一个指标。测试它的理解能力、解释能力、异常情况处理能力。跑通之后再逐步扩展到几十个指标。很多团队失败是因为一上来就想做“万能的业务问答机器人”，结果边界完全失控。

对范式三，最小闭环是“一类 Agent + 一个漏斗”。先选定一个最重要的 Agent 产品，定义从会话开始到任务成功的三个关键节点，从日志里提取事件并写入 Doris。实时产出漏斗和失败样本列表。因为你只需要采集事件，不需要一开始就定义几十个指标，两天就能上线。

6.3 容易被忽略的隐性成本

搭建阶段最容易忽略的是数据成本和数据质量成本。数据成本不光是存储，还包括 Kafka 带宽、清洗任务的资源、Doris 集群的 compaction 开销。Agent 会话事件如果每个步骤都记录得非常详细，一天可能产生上亿行。建议在写入 Doris 之前做一次轻量裁剪，把冗余的上下文、内部调试字段去掉