---
url: /risingwave/introduction.md
description: >-
  RisingWave是什么？用Rust写的开源流数据库，一条SQL替掉Debezium+Kafka+Flink+Redis四件套，兼容PostgreSQL，亚100毫秒新鲜度，3.0版本转向Agentic
  AI，五分钟搞懂下一代实时数据平台
---

# 认识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](https://github.com/risingwavelabs/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。

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