RisingWave: 用一套系统替换 Kafka、Flink 和数据库的流处理平台
用于代理 AI 的事件流平台。持续大规模地实时摄取、转换和服务事件流。
秒懂
- 它是什么？
- RisingWave 是一个面向 agentic AI 的事件流平台，用 SQL 统一了摄取、处理和查询。本文分析它的架构、部署方式、适用场景和局限。
- 适合谁用？
- RisingWave 适合那些需要低延迟查询和持续增量计算的团队，尤其是构建实时仪表盘、特征存储或监控告警系统的场景。它不适合已经深度依赖 Flink 的复杂流处理逻辑，也不适合需要完全自控存储层和查询引擎的团队。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个系统，替换四个组件
传统的事件流处理栈由多个独立系统拼成：Debezium 负责数据库变更捕获，Kafka 负责传输，Flink 负责计算，最后还要一个数据库来服务查询。每一跳都增加延迟，每个系统都要单独运维。RisingWave 的目标是把这条链路压缩成一个系统，用 SQL 统一处理摄取、转换和查询。它的 README 明确说，这是为 agentic AI 和实时应用设计的，这些场景需要数据始终新鲜，并且能以低延迟被查询。对于不想维护四套基础设施的团队，这个定位有直接的吸引力。但要注意，这种整合也意味着你被绑定在一个系统的能力边界内，而不是四个系统的组合能力。
摄取、计算、服务的具体机制
RisingWave 的摄取层覆盖三类来源：Webhook 走 HTTP，数据库变更走原生 CDC（支持 PostgreSQL、MySQL 等，通过事务日志读取），事件流走 Kafka、Pulsar、Kinesis 等消息队列。还有从 S3 和数据仓库做批量导入的路径。所有源统一到同一个 SQL 接口下，流和表可以自由 join。计算层是增量计算，上游数据变化时只重算受影响的结果，而不是每次查询都全量重算。这是物化视图保持实时更新的核心机制。服务层把查询结果存在内部行存里，文档声称 p99 延迟在 10 到 20 毫秒。这个数字是官方宣称的，实际效果取决于你的数据规模、查询模式和磁盘缓存配置。
存储层：行存与 Iceberg 的分工
RisingWave 把内部状态、表和物化视图放在对象存储（S3 或等价物）上，而不是内存里。README 说这样成本大约是 RAM 的百分之一，而且支持弹性扩展，不用重新平衡数据，故障恢复也在秒级。对于延迟敏感的工作负载，可以用磁盘缓存把热数据钉在本地 SSD 或 EBS 上，保持 p99 查询延迟在 10 到 20 毫秒。长期存储走 Apache Iceberg 表，RisingWave 直接托管 Iceberg REST catalog，并自动处理压缩、小文件优化和快照清理。Iceberg 查询通过 Apache DataFusion 执行，这是一个向量化查询引擎。因为 Iceberg 是开放格式，Spark、Trino、DuckDB 也能读。这里有个明显的取舍：行存负责低延迟服务，Iceberg 负责持久化和分析，两者由同一个系统管理，但你失去了对存储引擎的独立选择权。
60 秒启动与部署选项
README 提供了一个 60 秒的快速启动命令：curl -L https://risingwave.com/sh | sh。这是最简单的体验方式，适合先跑起来看看。生产部署有三条路径：Docker Compose、Kubernetes 加 Helm、Kubernetes 加 Operator。文档里都有对应的指南。连接方式走 PostgreSQL 线协议，所以 psql、JDBC 和任何 Postgres 兼容工具都能直接用。对 agent 来说，RisingWave 提供了 MCP 服务器、CLI 和 Skills，让 AI 代理可以直接查询和操作 RisingWave，不需要自定义集成。这个设计很贴合 agentic AI 的定位，但要注意，MCP 服务器和 Skills 的具体能力在 README 里没有展开，需要去文档确认。
成本效率背后的架构权衡
把状态放在对象存储是 RisingWave 的核心设计决策。成本优势明显，但延迟和一致性需要额外机制来弥补。磁盘缓存解决了热数据的延迟问题，但缓存未命中时，查询可能要回源到对象存储，延迟会显著上升。README 没有给出缓存未命中时的延迟数据。另一个隐含的权衡是，对象存储的写入一致性通常比本地磁盘弱，RisingWave 如何保证物化视图的实时性，文档没有详细说明。对于需要强一致性和极低延迟的金融交易场景，这个设计可能不是最优解。但对于监控、仪表盘、特征存储这类容忍轻微延迟波动的场景，成本节省是实打实的。
用 SQL 统一，但别忽略 Iceberg 的绑定
RisingWave 把 Iceberg 集成作为开放性卖点，但这也是一种绑定。你选择 RisingWave，就意味着长期数据会以 Iceberg 格式存储，查询引擎是 DataFusion。虽然 Iceberg 是开放格式，其他引擎能读，但你的写入路径和表维护都由 RisingWave 管理。如果你想换掉 RisingWave，数据迁移是可行的，但你的实时管道和物化视图逻辑都需要重写。相比之下，如果你直接用 Kafka 加 Flink，数据流和状态是解耦的，替换某个组件相对容易。RisingWave 的整合模式降低了初始复杂度，但提高了退出成本。
局限与替代方案
RisingWave 的一个明显局限是，它把流处理、查询和存储绑定在一个系统里。如果你的团队已经有成熟的 Flink 技能和定制的 Kafka 管道，迁移到 RisingWave 可能意味着重写所有逻辑。另一个局限是，README 提到的端到端新鲜度低于 100 毫秒，查询延迟 10 到 20 毫秒，这些数字都是理想情况下的宣称值，没有提供测试环境的具体配置。替代方案是保留传统组件组合：Debezium 做 CDC，Kafka 做传输，Flink 做计算，再用一个 Postgres 或 ClickHouse 做服务。这个方案更灵活，每个组件可以独立扩展和替换，但运维复杂度高得多。另一个替代是使用 Apache Flink 的 SQL 功能配合 Iceberg 表，但你需要自己管理状态存储和查询层。RisingWave 的价值在于把这些组件整合成一个可管理的单元，代价是灵活性。
维护、升级与许可
RisingWave 的活跃开发体现在频繁的版本发布上，最近有 v3.0.3、v3.0.2 和 v3.0.1，间隔约一个月。这意味着你需要跟上升级节奏，否则会积累技术债。升级成本取决于你的部署方式：Docker Compose 升级简单，Kubernetes 用 Helm 或 Operator 可以自动化，但你必须测试物化视图的兼容性。许可采用 Apache-2.0，允许商用、修改和再分发，没有 copyleft 约束。但注意，README 提到使用 Scarf 进行匿名安装统计，可以退出，这需要在部署前配置。对于合规敏感的团队，这个遥测机制需要审查。
编辑结论
RisingWave 适合那些需要低延迟查询和持续增量计算的团队，尤其是构建实时仪表盘、特征存储或监控告警系统的场景。它不适合已经深度依赖 Flink 的复杂流处理逻辑，也不适合需要完全自控存储层和查询引擎的团队。采用前需要验证三点：一是检查你的数据源是否在官方支持的列表内，特别是 CDC 源的类型和版本；二是确认 10 到 20 毫秒的 p99 查询延迟在磁盘缓存配置下能否在你的工作负载中复现；三是评估将 Iceberg 作为长期存储后，你的分析查询是否能接受 DataFusion 执行引擎的语义差异。RisingWave 的 Apache-2.0 许可允许商用和修改，但如果你需要闭源发行版，要注意其开源核心之外可能存在的商业限制。
社区笔记