实时宽表技术选型：Flink vs Spark Streaming、消息队列选型、OLAP存储选型
做实时宽表，技术选型是第一步，也是最容易踩坑的一步。我见过不少团队，一上来就追新，结果上线后各种水土不服。说白了，选型没有银弹，只有最适合你业务场景的组合。
这一章，我把选型拆成三个层面来讲：计算引擎、消息队列、OLAP存储。每个层面我都会结合自己的实战经验，给你一些判断依据。
计算引擎：Flink vs Spark Streaming
先聊计算引擎。现在市面上主流的实时计算引擎，基本就是 Flink 和 Spark Streaming 二选一。很多人问我：「到底选哪个？」我的回答是：看你的实时性要求有多「实时」。
Flink：真正的流式计算
Flink 的设计哲学是「一切皆流」。每条数据过来，它都立即处理，延迟通常在毫秒级。我在做金融风控项目时，要求交易事件发生后 500 毫秒内完成规则匹配，Flink 是唯一的选择。
Flink 的核心优势：
- 真正的逐条处理：数据来一条处理一条，延迟极低
- 精确一次语义：通过 checkpoint + 两阶段提交，保证数据不丢不重
- 事件时间语义：支持乱序事件处理，这在 IoT 场景中特别重要
- 状态管理强大：内置 RocksDB 状态后端，可以处理 GB 级别的状态
Spark Streaming：微批处理的坚守者
Spark Streaming 本质上是微批处理，把流数据切成一个个小批次（比如每 2 秒一批），然后批量处理。延迟通常在秒级到十秒级。
Spark Streaming 的适用场景：
- 延迟容忍度较高：比如分钟级的报表聚合
- 与 Spark 生态深度绑定：如果团队已经重度使用 Spark 做离线处理，复用 Spark Streaming 可以降低运维成本
- 批流一体需求：Spark 3.0 之后的 Structured Streaming 在批流统一上做得不错
对比总结
| 维度 | Flink | Spark Streaming |
|---|---|---|
| 处理模式 | 逐条流式 | 微批处理 |
| 延迟 | 毫秒级 | 秒级 |
| 精确一次 | 原生支持 | 需配置 |
| 状态管理 | 强（RocksDB） | 弱（依赖外部存储） |
| 学习曲线 | 较陡 | 较平缓 |
| 生态整合 | 独立生态 | 与 Spark 生态紧密 |
消息队列选型：Kafka vs Pulsar
消息队列是实时宽表的「血管」，数据从源头到计算引擎，全靠它来承载。选错了，后面全是坑。
Kafka：成熟稳定的老大哥
Kafka 是目前最成熟的消息队列，社区活跃，生态完善。我做过的大多数实时项目，消息层都用的 Kafka。
Kafka 的优势：
- 吞吐量极高：单机可以支撑百万条/秒的消息写入
- 持久化可靠：基于磁盘的顺序读写，数据不丢
- 生态丰富：与 Flink、Spark、ClickHouse 等都有成熟的连接器
- 运维经验多：网上踩坑案例多，遇到问题容易找到解决方案
Pulsar：云原生新贵
Pulsar 是后起之秀，设计上更云原生。它把存储和计算分离，支持存算分离架构。
Pulsar 的亮点：
- 存算分离：Broker 无状态，存储层使用 BookKeeper，扩缩容更灵活
- 多租户原生支持：内置租户、命名空间、权限管理
- 延迟更低：相比 Kafka，Pulsar 的端到端延迟更低
- 队列模型更丰富：支持独占、共享、灾备等多种订阅模式
选型建议
| 场景 | 推荐 | 原因 |
|---|---|---|
| 常规实时数仓 | Kafka | 成熟稳定，生态完善 |
| 多租户 SaaS | Pulsar | 原生多租户支持 |
| 云原生环境 | Pulsar | 存算分离，弹性更好 |
| 团队经验有限 | Kafka | 踩坑案例多，容易排查 |
OLAP存储选型：ClickHouse vs Doris vs StarRocks
OLAP 存储是实时宽表的最后一环，数据最终要在这里被查询和分析。选型不对，查询慢、并发低、运维难，前面做的所有努力都白费。
ClickHouse：列式存储的标杆
ClickHouse 是单表查询的王者。它的列式存储和向量化执行引擎，让它在聚合查询上快得离谱。
ClickHouse 的优势：
- 单表查询极快：十亿级数据秒级响应
- 压缩比高：列式存储 + 多种压缩算法，存储成本低
- SQL 支持好：兼容大部分标准 SQL
- 运维相对简单：单机部署就能跑
Doris：MPP 架构的均衡之选
Doris 是百度开源的 MPP 数据库，在查询性能和并发能力之间取得了不错的平衡。
Doris 的特点：
- 查询性能均衡：单表和多表 Join 都有不错的表现
- 高并发支持：通过分区分桶 + 物化视图，可以支撑数千 QPS
- 实时导入：支持 Stream Load，秒级可见
- 运维友好：Web UI 管理，扩缩容方便
StarRocks：Doris 的进化版
StarRocks 是从 Doris 分叉出来的，在查询优化器和向量化执行上做了大量改进。
StarRocks 的亮点：
- 查询性能更强：CBO 优化器 + 向量化执行，复杂查询比 Doris 快 2-3 倍
- 物化视图更智能：支持自动刷新和透明改写
- 主键模型：支持 Upsert 和 Delete，适合实时更新场景
- 生态兼容：兼容 MySQL 协议，迁移成本低
选型对比
| 维度 | ClickHouse | Doris | StarRocks |
|---|---|---|---|
| 单表查询 | ★★★★★ | ★★★★ | ★★★★★ |
| 多表 Join | ★★ | ★★★★ | ★★★★★ |
| 高并发 | ★★★ | ★★★★ | ★★★★ |
| 实时导入 | ★★★★ | ★★★★★ | ★★★★★ |
| 运维复杂度 | ★★ | ★★★ | ★★★ |
| 社区活跃度 | ★★★★★ | ★★★★ | ★★★★ |
整体技术栈选型框架
下面这张图，是我个人总结的实时宽表技术栈选型框架。你可以根据业务场景，沿着这个路径做决策。
嗯，这张图基本概括了实时宽表的完整链路。从数据源到消息队列，再到计算引擎，最后落地到 OLAP 存储。每一层的选型都直接影响整个链路的性能和稳定性。