实时数仓技术路线对比：Flink + Kafka vs RisingWave vs Materialize

实时数仓技术路线对比：Flink + Kafka vs RisingWave vs Materialize

一、实时数仓为什么突然火了

2026 年有个趋势特别明显：越来越多的业务方在问"能不能给我一个实时的看板"。以前他们能接受 T+1（第二天出数据），现在要求 T+0（当天实时更新），甚至在直播、风控、推荐场景里要求"秒级"。

这不是业务方变挑剔了，而是实时数据确实能带来真金白银的收益。举个例子：一个电商大促场景，如果能实时监控各品类的转化率，运营就可以在活动进行中调整资源位，而不是等深夜复盘时才发现"原来这个品根本没流量"。

然而，"实时"不是白送的。传统离线数仓架构（T+1 批处理）的成本可能是 1，那实时数仓的成本起步就是 5—10。所以选对技术路线，直接决定你能不能"用得起"实时数仓。

先上一张决策流程图：

二、Flink + Kafka：老牌选手，稳但重

架构是怎么玩的

Flink + Kafka 是实时数仓的"标准答案"。数据从业务系统（MySQL Binlog、App 埋点等）进入 Kafka，Flink 消费 Kafka 消息做实时 ETL、聚合、Join，结果写回 Kafka 或写入 OLAP 引擎（ClickHouse、StarRocks、Doris 等）。

# PyFlink 实时聚合示例：每 5 分钟统计各商品销售额
from pyflink.datastream import StreamExecutionEnvironment
from pyflink.table import StreamTableEnvironment, EnvironmentSettings
from pyflink.table.expressions import col

# 创建流式执行环境
env = StreamExecutionEnvironment.get_execution_environment()
env.set_parallelism(4) # 4 个并行度，根据数据量调

settings = EnvironmentSettings.new_instance() \\
.in_streaming_mode() \\
.build()
t_env = StreamTableEnvironment.create(env, settings)

# === 定义 Kafka 数据源表 ===
t_env.execute_sql("""
CREATE TABLE order_events (
order_id BIGINT,
product_id BIGINT,
user_id BIGINT,
amount DECIMAL(10, 2),
event_time TIMESTAMP(3),
— 用事件时间做 Watermark，解决数据乱序问题
WATERMARK FOR event_time AS event_time – INTERVAL '10' SECOND
) WITH (
'connector' = 'kafka',
'topic' = 'order_events',
'properties.bootstrap.servers' = 'kafka-broker:9092',
'format' = 'json',
— 从最新消息开始消费
'scan.startup.mode' = 'latest-offset'
)
""")

# === 定义输出到 ClickHouse 的结果表 ===
t_env.execute_sql("""
CREATE TABLE product_sales_realtime (
window_start TIMESTAMP(3),
window_end TIMESTAMP(3),
product_id BIGINT,
total_amount DECIMAL(10, 2),
order_count BIGINT,
PRIMARY KEY (window_start, product_id) NOT ENFORCED
) WITH (
'connector' = 'clickhouse',
'url' = 'clickhouse://clickhouse:8123',
'table-name' = 'product_sales_realtime'
)
""")

# === 核心聚合逻辑：5 分钟滚动窗口 ===
t_env.execute_sql("""
INSERT INTO product_sales_realtime
SELECT
TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start, — 窗口开始时间
TUMBLE_END(event_time, INTERVAL '5' MINUTE) AS window_end, — 窗口结束时间
product_id,
SUM(amount) AS total_amount, — 窗口内总销售额
COUNT(*) AS order_count — 窗口内订单数
FROM order_events
GROUP BY
TUMBLE(event_time, INTERVAL '5' MINUTE), — 滚动窗口翻转函数
product_id
""")

# env.execute("实时商品销售额聚合")

优点

• 生态最完善：监控（Prometheus + Grafana）、容错（Checkpoint/Savepoint）、背压处理全部成熟。
• 性能极致：毫秒级延迟，日处理百亿级事件无压力。
• SQL 化程度高：Flink SQL 已经覆盖了 90% 的实时计算场景。

缺点

• 运维成本高：你要管 Kafka 集群、Flink 集群、下游 OLAP 集群，一整套下来至少 2 个专门的人。
• 学习曲线陡峭：Watermark、状态后端、反压调优……概念多到让人头秃。
• 成本不低：计算 + 存储资源吃满，小团队烧不起。

适合场景：日处理量 > 1TB，团队 > 5 人，对延迟要求极其苛刻。

三、RisingWave：云原生"小而美"

它解决了什么问题

RisingWave 是 2023 年开源、2024—2025 年快速崛起的一个流数据库。它的核心卖点非常直白：你只需要一个 RisingWave 集群，不需要 Kafka + Flink + OLAP 这一整套。

它的架构思路是：MySQL/PostgreSQL 的 CDC 数据直接进 RisingWave，RisingWave 内部做流式计算，计算结果直接用 PostgreSQL 协议对外提供查询服务。这意味着你的 BI 工具（Metabase、Superset）可以直连 RisingWave 查实时数据，就像查 PostgreSQL 一样丝滑。

核心优势

• 极简运维：一个二进制搞定所有。没有 ZooKeeper、没有外部依赖。
• PostgreSQL 兼容：直接用 psql 或任何 PG 客户端查询，学习成本接近零。
• 存算分离：计算和存储各自弹性扩缩，比 Flink 的固定资源模式灵活不少。

需要注意的限制

• 对大状态支持还在打磨中：如果你的流 Join 需要维护几十 GB 的状态，RisingWave 目前不如 Flink 稳。
• 生态工具较少：监控、告警、可视化的周边工具还没 Flink 那么丰富。

— RisingWave 创建物化视图（自动实时更新）
— 相比 Flink SQL，语法更简洁
CREATE MATERIALIZED VIEW product_sales_5min AS
SELECT
window_start,
window_end,
product_id,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM TUMBLE(
order_events, — 数据源表
event_time, — 时间列
INTERVAL '5' MINUTE — 窗口大小
)
GROUP BY
window_start,
window_end,
product_id;

— 查询这个视图，拿到的永远是最新结果
— BI 工具直接 SELECT * FROM product_sales_5min 就行
SELECT * FROM product_sales_5min
WHERE window_start >= NOW() – INTERVAL '1' HOUR
ORDER BY total_amount DESC
LIMIT 10;

适合场景：中小数据量、小团队、追求简单、不需要复杂多流 Join 的场景。

四、Materialize：数据库行家的选择

Materialize 比 RisingWave 更早进入市场（2019 年），技术路线也很独特：它是直接与 PostgreSQL 深度绑定的，通过 PG 的 logical replication 获取 CDC 数据。

它的核心哲学是：把"物化视图"做到极致。你定义的每个查询，Materialize 都会维持一个持续更新的增量视图，查询时直接返回快照，快得惊人。

— Materialize 的独特之处：支持标准 PostgreSQL DDL/DML
— 在你的 PG 实例中创建 Source（数据源）
CREATE SOURCE order_source
FROM POSTGRES CONNECTION pg_connection (
PUBLICATION 'order_publication'
) FOR ALL TABLES;

— 创建实时物化视图
CREATE MATERIALIZED VIEW product_dashboard AS
SELECT
p.category,
COUNT(DISTINCT o.user_id) AS unique_buyers,
SUM(o.amount) AS total_revenue,
AVG(o.amount) AS avg_order_value,
— 行数占比，用于饼图展示
SUM(o.amount) / SUM(SUM(o.amount)) OVER () * 100 AS revenue_pct
FROM orders o
JOIN products p ON o.product_id = p.id
— 这里没有窗口限制！Materialize 自动处理任意时序的 Join
GROUP BY p.category;

— 查询：永远是实时的最新数据
SELECT * FROM product_dashboard ORDER BY total_revenue DESC;

Materialize vs RisingWave 怎么选

如果你的主数据库已经是 PostgreSQL，且需要频繁的多表 Join 计算，Materialize 可能是更好的选择。如果你是从零搭建、希望快速上手，RisingWave 的体验更爽。

五、总结

实时数仓选型没有银弹，我按场景给个速查表：

• 大厂/大数据/复杂场景 → Flink + Kafka + ClickHouse/StarRocks，成熟稳定，但请备好人手和预算。
• 中小团队/轻量实时/追求简单 → RisingWave，一个二进制搞定，运维成本极低。
• PG 深度用户/多表 Join 场景 → Materialize，和 PG 的契合度无人能及。

2026 年下半年，我个人的判断：Flink 仍然是王者地位，但 RisingWave 和 Materialize 会吃掉大量中小规模的市场份额。对于大多数中小团队来说，"够用 + 简单"比"极致 + 复杂"更有吸引力。