认识RisingWave

先说一个几乎所有做实时数仓的团队都踩过的坑。

老板说："我要一个实时大屏，订单数据变了，屏上 1 秒内就得变。"

听起来是一句话的事。你去搭，发现要这么搭：Debezium 抓 MySQL 的 binlog，推给 Kafka；Kafka 喂给 Flink，Flink 写 Java/SQL 作业做聚合；算完的结果再写进 Redis 或者某个 OLAP 库，前端才能查。

四个系统，四套部署，四份监控，四种故障姿势。作业跑了三个月，某天大屏数字不对了——你得挨个排查：是 binlog 断了？Kafka 积压了？Flink 的 checkpoint 失败了？还是下游写库写漏了？一天就这么没了。

更离谱的是，老板下周又说："这个指标口径改一下。"——你得改 Flink 作业、重新打包、重新提交、状态还没法复用，历史数据得重跑。

**RisingWave 想干的事很简单：把这四个系统，压缩成一个。**而你要写的，只是一句 CREATE MATERIALIZED VIEW。

实时数仓的复杂度，八成不是"计算"本身带来的，而是"系统太多"带来的。少一个系统，少一半故障。

什么是 RisingWave

RisingWave 是一个开源的流数据库（Streaming Database），用 Rust 编写，Apache 2.0 协议开源。

官方给自己的最新定位是：面向 Agentic AI 的事件流平台（event streaming platform for agentic AI）。它把数据摄取、流式处理、低延迟服务、Iceberg 湖仓管理这四件事，统一进了一个兼容 PostgreSQL 的系统里。

翻译成人话——它同时是三个东西：

一个流处理引擎（干 Flink 的活）
一个能被直接查询的数据库（干 Redis / OLAP 的活）
一个湖仓写入与管理层（干 Iceberg 表维护的活）

官方文档写得很直白：RisingWave 用来替代传统的事件流技术栈（Debezium + Kafka + Flink + 服务型数据库）。

它最关键的一个设计选择是：你不用学新框架，你只要会 SQL。RisingWave 走的是 PostgreSQL 线协议（wire protocol），意味着 psql、JDBC、DBeaver、Grafana、任何 Postgres 生态的工具，都能直接连上去，就跟连一个普通 Postgres 一样。

它是怎么工作的

整条链路四个字：摄取 → 处理 → 服务 → 存储。

摄取（Ingest）：数据库 CDC（PostgreSQL / MySQL / SQL Server，直接读事务日志）、消息队列（Kafka、Pulsar、Kinesis）、Webhook（SaaS 应用的 HTTP 事件）、对象存储与数仓的历史批量数据。所有数据源统一成 SQL 里的表，流和表可以随便 Join
处理（Process）：增量计算。上游数据变了，只重算受影响的那部分结果，不是每次查询都全表扫一遍。端到端新鲜度低于 100 毫秒
服务（Serve）：计算结果维护在 RisingWave 内部的行存里，用标准 SQL 直接查，p99 延迟 10–20 毫秒。不用轮询、不用预热缓存、不用管 TTL
存储（Store）：长期数据写进 Apache Iceberg 表。RisingWave 自己就托管 Iceberg REST Catalog，还顺手把 compaction、小文件合并、快照清理这些脏活干了，不需要额外工具

增量计算：为什么它能又快又省

这是 RisingWave 最值得理解的一件事，也是它跟"普通数据库"的分水岭。

传统数据库的视图（View）是查的时候才算：你每查一次，它就把底层数据重新扫一遍、算一遍。数据量大了，查询就慢。

传统数据库的物化视图（Materialized View）是定时刷新：半小时刷一次，好处是查得快，坏处是数据最多能"新鲜"到半小时前。

RisingWave 的物化视图是第三条路：数据一到，立刻增量更新结果，且永远是最新的。

举个例子。你要统计"每个商品的实时销售额"。来了一笔新订单：

普通视图：把一亿行订单重新聚合一遍
定时物化视图：等下一次调度，可能是 30 分钟后
RisingWave：只把这一笔订单的金额，加到对应商品的那一行上。毫秒级完成

数据量涨到十亿行，第三种方式的单次更新成本几乎不变——因为它算的永远只是"增量"，不是"存量"。

这就是为什么后面那些案例里，计算资源能降 70%、90% 以上。不是 Rust 写得有多神，是"只算变化的部分"这个思路，本身就比"每次全算一遍"便宜一个数量级。

而且它还有一层"存算分离"的省钱设计：所有中间状态、表、物化视图，都存在 S3 这类对象存储上，官方的说法是比放内存便宜约 100 倍。热数据则用弹性磁盘缓存（本地 SSD / EBS）兜住延迟。带来的额外好处是：扩缩容不用搬数据，故障恢复以秒计。

RisingWave 的核心特点

一个系统顶四个：摄取、处理、服务、存储全包，砍掉 Debezium + Kafka + Flink + 服务库的拼装成本
PostgreSQL 兼容：走 PG 线协议，psql / JDBC / 现有 BI 工具零改造直连
纯 SQL 开发：流处理逻辑就是 CREATE MATERIALIZED VIEW，不用写 Java、不用打 JAR 包、不用提交作业
增量计算：只算变化部分，端到端新鲜度 < 100ms，服务查询 p99 10–20ms
存算分离：状态存对象存储，成本约为内存的 1/100，秒级故障恢复、弹性扩缩容不搬数据
原生 CDC：直连 PostgreSQL / MySQL / SQL Server 读事务日志，不必先架一套 Debezium
Iceberg 原生集成：托管 REST Catalog、自动 compaction 与快照清理，支持 Iceberg V3 表格式
分布式强一致：靠 Barrier 机制保证多个物化视图之间的结果强一致，不是"最终一致"
丰富连接器：Kafka、Pulsar、Kinesis、MQTT、Pub/Sub、JDBC、Delta Lake、StarRocks、OpenSearch、HTTP、WebSocket……
Exactly-once 语义：CDC 与 Sink 端的精确一次投递保障
Rust 编写：无 JVM，无 GC 停顿，也不用调那一堆玄学的堆内存参数
开源免费：Apache 2.0 协议，可自由商用

对很多团队来说，最大的吸引力其实不是性能，而是不用再养一个会写 Flink 的人。会 SQL 的数据分析师，自己就能上手改实时口径。

RisingWave 3.0：从"流数据库"转向 AI 的实时上下文层

2026 年 6 月 11 日，RisingWave 发布了 3.0 大版本，最新维护版本是 v3.0.2（2026 年 7 月 24 日）。官方自己说这是"迄今为止最大的一次发布"，主题很明确——做 Agentic AI 的实时数据平台。

这个转向的逻辑其实挺硬：AI 智能体的生命周期是"摄取新信息 → 维护上下文 → 基于当前状态推理 → 触发下游动作"，每一步都需要新鲜数据。而绝大多数向量数据库有个默认假设——你检索的语料是"冻结"的：批量灌进去，跑一遍 embedding，然后就不动了。真实业务里数据每秒都在变，这个假设根本不成立。

3.0 的重点更新：

能力	说明
Apache Iceberg V3	支持 V3 表格式、排序键、可配置 Parquet 属性，强化实时湖仓
原生 pgvector 摄取	向量数据可以直接流式进来，服务语义检索与 RAG 场景
WebSocket source / HTTP sink	低延迟拉事件进来，也能把结果动态路由推给外部 API，触发下游动作
DataFusion 成为默认批处理引擎	批查询性能、SQL 兼容性、内存管理全面提升
物化视图自动复用	优化器发现已有 MV 能回答某个批查询，自动改写复用，省延迟也省算力
SQL 成为运维接口	备份、Schema 演进、连接器改密码、调 backfill 并行度……都能用 SQL 干
Exactly-once 强化	Delta Lake、JDBC 等 Sink 的精确一次投递
PostgreSQL 18 CDC	跟进 PG 最新版本

其中"SQL 成为运维接口"这条，值得单独说一句。它意味着不只是人能用 SQL 查数据，AI 智能体也能用同一套 SQL 安全地管理和运维流式作业。官方还提供了 risingwave-mcp（MCP Server），你可以直接让 Claude Code、Cursor 这类工具连上去生成并执行 SQL。

另外提醒一句迁移用户：3.0 弃用了 Maxwell、Canal、Citus 三个 CDC 源，用到的要提前规划。

从"流数据库"到"AI 的实时上下文层"，这个定位迁移不算蹭热点。智能体最缺的从来不是模型，是能实时读到、且读得准的上下文。

谁在用 RisingWave

讲架构容易空对空，看几个真实落地的。

乾象投资 —— 计算资源砍掉 95%，实盘交易在跑

乾象是一家管理规模突破 100 亿元人民币的量化私募，团队核心成员来自 Stanford、CMU、Facebook 和 Google。他们要给交易行为做实时风控告警：监测账户活跃性、现金充足性、交易合规性。

原来用某主流 OLAP 数据库（文中称 X 系统），撞上三堵墙：官方建议 QPS 只有 100，高并发查询扛不住；只能保证最终一致性，为了不出错连 Join 都不敢用；水平扩展会直接让查询变慢。

换成 RisingWave 之后的数据很能说明问题：

处理上万 QPS 的输入消息，秒级延迟输出告警
计算节点数量降低一半的同时，数据实时性提高 3 倍
入库 P90 延迟从秒级降到亚秒级
同样的监控业务：未用物化视图的 X 系统集群要数百核，精细调优后要数十核，而 RisingWave 十核以内搞定——相比前者省下 95% 以上计算资源，相比后者也省了至少 70%

这套系统已经跑在实盘交易生产环境里。对量化机构来说，敢让它上实盘，本身就是最重的一票。

KaptureCX —— 每秒 25 万事件，报表从 20 分钟到毫秒级

KaptureCX 做客服自动化平台，客户横跨电商、医疗、金融。它的数据有两个变态特征：一个工单从创建到关闭平均要经历 15 次状态变更，每天产生数百万个这样的工单；再加上应用日志和语音机器人转录，峰值达到 25 万事件/秒。

原来用 ClickHouse，被 Upsert 折磨得够呛——得靠 ReplacingMergeTree + 查询时强制 FINAL，还要定时跑 OPTIMIZE FINAL 去重，每次合并 CPU 直接飙到 100%，业务高峰期系统直接不可用。

重构后的链路是：MySQL Binlog → RisingWave → Kafka → StarRocks。

他们没直接用 Debezium，理由很实在：万一下游集群崩了要重建，希望几分钟内重放数据，而不是花几天从源库重拉、把白天的 MySQL 生产负载拖垮。RisingWave 的状态和 Checkpoint 持久化在 S3 上，正好扛住这个需求。

结果：复杂业务报表从原来的 15–20 分钟，压到毫秒级；定制化看板的交付周期从数周缩短到 1 天。

Kaito —— 一个人，两周，1000+ 实时看板

Kaito 是总部在西雅图的金融科技公司，背后站着 Dragonfly、Sequoia（红杉）、Jane Street，做的是业内首个基于大模型的金融搜索引擎。

把 RisingWave 部署到 GKE 集群后，一位数据工程师，用两周时间，在单个 RisingWave 集群上建了 1000 多个面向用户的分析看板（物化视图），全部投入生产。

一个人两周 1000 个看板——这个数字的真正含义不是"RisingWave 快"，而是流处理的开发门槛被拉到了写 SQL 的水平。原来这活得排期给数据工程团队，现在写 SQL 的人自己就干完了。

初体验：5 分钟跑通

装它，一行就够（单机模式，本地玩够用）：

bash

curl -L https://risingwave.com/sh | sh

然后启动：

bash

risingwave

习惯 Docker 的话：

bash

docker run -it --pull=always -p 4566:4566 -p 5691:5691 \
  risingwavelabs/risingwave:latest single_node

macOS 用 Homebrew 也行：

bash

brew tap risingwavelabs/risingwave
brew install risingwave
risingwave

连它——注意，就是普通的 psql，端口 4566：

bash

psql -h localhost -p 4566 -d dev -U root

到这一步你应该已经感觉到点什么了：它长得就像一个 Postgres。

用它。来个实时风控的经典场景：建一张信用卡交易表，然后揪出"1 分钟内消费超过 5000"的可疑卡。

sql

-- 建表
CREATE TABLE credit_card_transactions (
  card_id VARCHAR,
  amount  DECIMAL,
  ts      TIMESTAMP
);

-- 塞几条数据
INSERT INTO credit_card_transactions (card_id, amount, ts)
VALUES
  ('card_123', 1200.00, '2022-01-01 10:00:00'),
  ('card_123', 1800.00, '2022-01-01 10:00:20'),
  ('card_123', 1900.00, '2022-01-01 10:00:40'),
  ('card_456', 4000.00, '2022-01-01 10:01:00'),
  ('card_456',  950.00, '2022-01-01 10:01:30');

重点来了——用物化视图定义告警规则，1 分钟滚动窗口：

sql

CREATE MATERIALIZED VIEW fraud_alerts AS
SELECT
  card_id,
  window_start,
  window_end,
  SUM(amount) AS total_amount
FROM
  TUMBLE(
    credit_card_transactions,  -- 源表
    ts,                        -- 事件时间列
    INTERVAL '1 minute'        -- 窗口大小
  )
GROUP BY
  card_id, window_start, window_end
HAVING
  SUM(amount) > 5000;          -- 超过 5000 才告警

这条 SQL 一执行，RisingWave 就立刻开始持续跟踪它了。查一下，此刻没人超标：

sql

SELECT * FROM fraud_alerts;
-- (0 rows)

再插一笔，把 card_123 顶过 5000：

sql

INSERT INTO credit_card_transactions (card_id, amount, ts)
VALUES ('card_123', 600.00, '2022-01-01 10:00:50');

再查：

sql

SELECT * FROM fraud_alerts;
--  card_id  |     window_start     |      window_end      | total_amount
-- ----------+----------------------+----------------------+--------------
--  card_123 | 2022-01-01 10:00:00  | 2022-01-01 10:01:00  |      5500.00

**告警自己冒出来了。**你没刷新、没重跑、没写任何调度——这就是增量计算。

把上面的 CREATE TABLE 换成 CREATE SOURCE（接 Kafka 或者 MySQL CDC），这套逻辑一个字不用改，就是一个生产级的实时风控管道。这正是 RisingWave 最舒服的地方：本地怎么写，线上就怎么跑。

RisingWave vs Flink：到底该选谁

维度	Flink	RisingWave
开发方式	Java/Scala 作业，或 Flink SQL + 提交流程	纯 SQL，`CREATE MATERIALIZED VIEW` 即上线
结果查询	自身不可查，必须外接 Redis / OLAP	自带存储，直接 SQL 查，p99 10–20ms
状态存储	RocksDB 本地盘 + 远端 checkpoint	对象存储为主 + 本地缓存，扩缩容不搬数据
运行时	JVM，要调堆内存和 GC	Rust，无 GC 停顿
CDC 接入	一般还要配 Debezium / Flink CDC	原生内置 CDC
一致性	Checkpoint 机制	Barrier 机制，跨物化视图强一致
上手门槛	需要专门的 Flink 工程师	会 SQL 就行
生态成熟度	极其成熟，十年沉淀，什么场景都有人踩过	年轻，复杂 UDF/特殊算子场景仍有边界
适合	超大规模、逻辑极复杂、已有 Flink 团队	实时看板/风控/特征/湖仓，追求少运维、快交付

我的立场：如果你团队里已经有成熟的 Flink 基建和会调优的人，别为了换而换，Flink 的生态深度目前仍然赢。但如果你正准备从零搭一套实时链路，尤其是团队里 SQL 熟手多、专职流处理工程师少——RisingWave 能帮你省掉的，是未来两年里那些凌晨三点爬起来排查四个系统的夜晚。

也说句公道话：它不是万能的。**离线大批量 ETL、超复杂的自定义算子逻辑、需要极致压榨单机吞吐的场景，Flink 和 Spark 依然更合适。**RisingWave 的甜点区很清楚——持续更新、需要被随时查询的实时结果。

进阶

RisingWave 真正在推的，不是"又一个流处理引擎"，而是一个判断：实时数据系统正在变成 AI 的上下文层。智能体要的不是一份昨天的快照，而是此刻正在发生的事实。3.0 把 Iceberg V3、pgvector 摄取、HTTP sink、MCP Server 摞在一起，摆明了就是奔着这个未来去的。

对刚入门的同学，我的建议是别一上来就啃架构文档。先用上面那五行命令把它跑起来，写一个 CREATE MATERIALIZED VIEW，亲眼看着结果自己变——那一下的"原来还能这样"，比读十篇架构解析都管用。

如果你现在正被 Debezium + Kafka + Flink + Redis 这套四件套折磨，RisingWave 至少值得你花一个下午做次 POC。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。

认识RisingWave ​

什么是 RisingWave ​

它是怎么工作的 ​

增量计算：为什么它能又快又省 ​

RisingWave 的核心特点 ​

RisingWave 3.0：从"流数据库"转向 AI 的实时上下文层 ​

谁在用 RisingWave ​

初体验：5 分钟跑通 ​

RisingWave vs Flink：到底该选谁 ​

进阶 ​

认识RisingWave

什么是 RisingWave

它是怎么工作的

增量计算：为什么它能又快又省

RisingWave 的核心特点

RisingWave 3.0：从"流数据库"转向 AI 的实时上下文层

谁在用 RisingWave

初体验：5 分钟跑通

RisingWave vs Flink：到底该选谁

进阶