导读：

KaptureCX 是一家专注于客户支持自动化平台的企业，服务于电子商务、医疗保健、金融等多个垂直领域的客户。随着业务的增长，其数据平台面临着**海量工单状态频繁更新（Heavy Upserts）以及复杂多表关联查询（Heavy Joins）**的双重挑战。

本文档详细记录了 KaptureCX 如何将其核心业务分析引擎从 ClickHouse 迁移至 StarRocks，并引入 RisingWave 与 Kafka 重构实时 CDC（变更数据捕获）摄取链路，最终实现了查询性能从数十分钟到毫秒级的飞跃，并将报表交付周期从数周缩短至 1 天，同时为底层的 AI 代理（Agentic Data Plane）打下了坚实的数据基础。

业务背景与初始架构的痛点

1.业务特性与数据规模

• 多租户与动态需求：KaptureCX 服务于不同行业的客户，没有单一固定的 Schema 或统一的仪表板可以满足所有需求。报表需求高度动态，通常需要针对特定客户进行 5-6 张表的多表 Join。

• 高频状态流转：核心业务数据是“工单（Ticket）”。一个工单从创建、排队、分配给客服、转交到最终关闭，平均会经历 15 次状态突变（Mutations/Updates）。每天会生成数百万个这样的工单。

• 海量日志数据：除了业务数据，系统还会产生海量的应用日志和语音机器人转录数据，峰值达到 250k 事件/秒。

2.初始架构：ClickHouse 的局限性

最初，KaptureCX 采用 ClickHouse 作为主要的分析数据库。对于不可变数据（Immutable Data，如上述的应用日志和点击事件），ClickHouse 表现极其出色，至今仍被保留用于日志分析。但在处理核心工单业务时，ClickHouse 暴露出了严重的瓶颈：

2.1 Upsert（更新插入）带来的 CPU 灾难：

1. 为了处理工单状态更新，他们使用了 ClickHouse 的 ReplacingMergeTree 引擎。

2. 查询时必须强制使用 FINAL 关键字来获取最新版本的数据，这极其消耗计算资源。

3. 底层存在大量重复数据，必须通过 Cron 定时任务手动触发 OPTIMIZE ... FINAL（合并压缩命令）来去重。每次执行 Merge 命令时，CPU 使用率都会瞬间飙升至 100%，导致系统在业务高峰期不可用。

2.2 多表 Join 性能孱弱：

1. 由于业务需求动态，无法将所有数据打平（Flatten）成宽表，必须依赖 Join。

2. ClickHouse 早期版本缺乏完善的基于成本的优化器（CBO），执行 Join 查询时性能极差。

核心分析引擎重构：引入 StarRocks

1.解决高频更新：主键模型 (Primary Key Engine)

• StarRocks 提供了原生的主键表。当插入具有相同主键的多条记录时，StarRocks 会在后台自动执行高效的去重操作（Automatic Deduplication），确保查询时直接读取到最新状态的数据。

• 收益：彻底摒弃了手动 Merge 操作，消除了 CPU 飙升的隐患，完美契合了工单一天 15 次状态变更的业务场景。

2.解决复杂关联：并置连接 (Colocate Joins) 与哈希分桶

这是 KaptureCX 架构中最核心的优化手段。StarRocks 采用 MPP（大规模并行处理）架构，数据分布在多个 BE（Back End）节点上。

• 哈希分桶（Hash Bucketing）：KaptureCX 按照客户 ID（customer_id / CM ID）对表进行哈希分桶（例如设置为 32 个 Bucket）。这意味着，特定客户的所有数据都会被路由并存储在同一个特定的 BE 节点上。

• 并置组（Colocate Group）：当仪表板需要 Join 表 A、表 B 和表 C 时，如果这三张表分布在不同的节点，Join 操作会产生大量的网络数据传输（Network Hop），导致延迟增加。通过在建表时为这些表声明相同的 Colocate Group，StarRocks 会强制将属于同一个客户的表 A、表 B、表 C 的数据分片存储在同一个物理 BE 节点上。

• 收益：在执行多表 Join 时，BE 节点只需在本地内存和磁盘中完成计算，零网络 Shuffle，查询延迟被压缩到了极致。

3.智能查询规划：CBO 优化器

StarRocks 的 FE（Front End）节点内置了强大的 CBO（Cost-Based Optimizer）。当面临 4-5 张表的复杂 Join 时，FE 能够自动评估表的数据量和分布，智能决定哪张表作为驱动表、采用何种 Join 顺序，从而生成最优的执行计划。

4.无缝迁移：MySQL 协议兼容

KaptureCX 所有的内部微服务原本都是基于 MySQL 构建的。由于 StarRocks 高度兼容 MySQL 协议，业务团队在迁移时，只需在环境变量中修改数据库连接字符串（Domain/URL），无需重写应用层代码。

实时数据摄取链路：RisingWave + Kafka

解决了分析引擎的问题后，如何将遗留 MySQL 数据库中的数据实时、稳定地同步到 StarRocks 成为了新的挑战。

1.为什么不直接使用 Debezium？

传统的做法是使用 Debezium 读取 MySQL Binlog 直接推送到 Kafka。但 KaptureCX 认为，如果下游的 StarRocks 集群发生崩溃或需要重建，他们希望能在几分钟内快速重放（Replay）数据，而不是花费几天时间从源头 MySQL 重新拉取（这会影响白天 MySQL 的生产工作负载）。因此，他们需要一个具备强大状态管理和持久化能力的流处理中间件。

2.引入 RisingWave 作为流处理核心

他们选择了 RisingWave（一个基于 Rust 编写的高并发流处理数据库，可视为 Flink 的现代替代品）。

• 内置 CDC：RisingWave 原生支持连接 MySQL 读取 Binlog。

• S3 状态检查点（Checkpointing）：RisingWave 会将中间状态和 Checkpoint 持久化到 S3 对象存储中。这使得系统具备极高的容错性，一旦发生故障，可以迅速从 S3 恢复并重放数据。

• 云原生与易部署：整个 RisingWave 和 StarRocks 集群都通过 Helm 部署在 Kubernetes (K8s) 上，扩缩容极其方便（只需增加 Compute Nodes）。

3.最终的实时摄取链路 (Data Pipeline)

最终的数据流向设计为：MySQL (Binlog) -> RisingWave -> Kafka -> StarRocks (Routine Load)

• Kafka 的缓冲作用：为什么在 RisingWave 和 StarRocks 之间还要加一层 Kafka？因为在实际运行中，MySQL 可能会出现突发的 CDC 变更洪峰（Spiky Loads）。Kafka 在这里充当了减震器（Buffer）的角色，吸收瞬时流量，随后 StarRocks 的 Routine Load 任务会以微批处理（Micro-batch，通常几秒一次）的方式从 Kafka 平滑地摄取数据，防止 StarRocks 被瞬间压垮。

业务成果与 AI 赋能 (Business Outcomes & AI)

通过这套现代化的实时分析架构，KaptureCX 取得了显著的业务收益：

1. 性能呈指数级提升：过去在传统 MySQL 上生成复杂的业务报表需要 15 到 20 分钟；迁移到 StarRocks 后，仪表板的加载和查询时间缩短到了毫秒级（Milliseconds）。

2. 研发效能大幅提高：过去交付一个新的定制化仪表板需要数周时间（涉及后端排期、手动写 ETL 等）。现在，数据团队只需在 StarRocks 中编写包含复杂 Join 的 SQL 视图（Views），并直接对接内部自研的 BI 工具（类似 Metabase），1 天之内即可交付所有需求。

3. 构建 Agentic Data Plane（代理数据平面）：

• 基于 StarRocks 极速的查询响应能力，KaptureCX 在其之上构建了完全自动化的 AI 数据平面。

• 他们集成了 大语言模型 (LLM) 和 MCP (Model Context Protocol) 服务器。LLM 可以直接生成 SQL，通过 MCP 服务器在 StarRocks 上执行查询，获取数据后返回给用户，实现了智能化的数据问答与洞察。

总结

KaptureCX 的实践是一个典型的现代实时数据栈演进案例。他们巧妙地利用了 RisingWave 的流式 CDC 与状态管理能力、Kafka 的缓冲削峰能力，以及 StarRocks 的主键模型和 Colocate Join 特性，成功解决了一个高频更新、复杂关联、且要求极低延迟的苛刻业务场景。