实时数仓技术路线对比：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 会吃掉大量中小规模的市场份额。对于大多数中小团队来说，"够用 + 简单"比"极致 + 复杂"更有吸引力。