技术选型：实时计算引擎、消息队列与存储系统
这一章，我们来聊聊技术选型。说白了，就是决定用哪些工具来搭实时指标层。我见过不少团队，一上来就追新，结果踩了一堆坑。选型没有银弹，关键看场景。
核心原则：选型不是选最强的，而是选最适合你团队和业务的。稳定性、社区活跃度、学习曲线，往往比纸面性能更重要。
实时计算引擎：Flink vs Spark Streaming
这两个是当前最主流的实时计算引擎。我两个都用过，先说说我的感受。
Apache Flink
Flink 是真正的流式计算引擎。它把一切当作流来处理，包括批处理。这带来了几个关键优势：
- 真正的流处理架构：每条数据到达时立即处理，延迟极低（毫秒级）。
- 精确一次语义：通过分布式快照（Checkpoint）机制，保证数据不丢不重。我在做金融风控项目时，这个特性救过我的命。
- 事件时间处理：天然支持基于事件发生时间的处理，能处理乱序数据。比如用户下单时间比到达时间晚了几秒，Flink 能正确处理。
- 状态管理：内置强大的状态后端，支持大规模状态存储和容错。
Apache Spark Streaming
Spark Streaming 本质上是微批处理。它把流数据切成小批次，然后用 Spark 引擎处理。嗯，这里要注意：
- 微批架构：延迟通常在秒级，不适合对延迟要求极高的场景。
- 生态丰富：与 Spark SQL、MLlib 无缝集成，适合需要同时做流处理和批处理的场景。
- Structured Streaming：后来推出的流式 API，简化了开发，但底层仍是微批。
- 社区成熟：Spark 生态非常庞大，人才储备多。
| 对比维度 | Flink | Spark Streaming |
|---|---|---|
| 架构 | 真正的流处理 | 微批处理 |
| 延迟 | 毫秒级 | 秒级 |
| 精确一次 | 原生支持 | 需配置 |
| 状态管理 | 强大 | 较弱 |
| 事件时间 | 原生支持 | 支持 |
| 学习曲线 | 较陡 | 较平缓 |
| 适用场景 | 低延迟、复杂事件处理 | 准实时、批流一体 |
我的建议：如果你做的是实时指标层，需要秒级甚至毫秒级响应，选 Flink。如果团队 Spark 经验丰富，且延迟要求不高（比如分钟级），Spark Streaming 也是不错的选择。我曾经在一个项目中，因为团队熟悉 Spark，硬是用 Spark Streaming 做了实时大屏，虽然延迟高了点，但开发效率确实高。
消息队列选型：Kafka vs Pulsar
消息队列是实时指标层的“血管”。数据从源头到计算引擎，全靠它。
Apache Kafka
Kafka 是消息队列的老大哥。它设计简洁，性能强悍。
- 高吞吐：顺序读写磁盘，单机吞吐量极高。
- 持久化：消息持久化到磁盘，可回溯消费。
- 分区机制：通过分区实现水平扩展和并行消费。
- 生态成熟：几乎所有大数据组件都支持 Kafka。
Apache Pulsar
Pulsar 是后起之秀，设计上解决了一些 Kafka 的痛点。
- 存算分离：计算层（Broker）和存储层（BookKeeper）分离，扩缩容更灵活。
- 多租户：原生支持多租户，资源隔离更好。
- 低延迟：采用分段存储，读写延迟更低。
- 队列模型：支持多种消费模式，包括独占、共享、灾备。
| 对比维度 | Kafka | Pulsar |
|---|---|---|
| 架构 | 存算一体 | 存算分离 |
| 多租户 | 较弱 | 原生支持 |
| 延迟 | 较低 | 更低 |
| 运维复杂度 | 中等 | 较高 |
| 社区生态 | 非常成熟 | 快速发展 |
| 适用场景 | 日志收集、数据管道 | 多租户、云原生 |
避坑指南：我曾经在一个项目中，为了追求“新技术”，选了 Pulsar。结果团队没人熟悉，运维踩了不少坑。后来换回 Kafka，虽然性能差一点，但稳定多了。选型时，一定要考虑团队的技术储备。
存储选型：ClickHouse vs Druid
存储是实时指标层的“终点”。数据经过计算后，要存起来供查询。
ClickHouse
ClickHouse 是列式存储数据库，以极致的查询速度著称。
- 列式存储：只读取需要的列，IO 开销小。
- 向量化执行：利用 CPU 的 SIMD 指令集，加速计算。
- 实时写入：支持每秒百万级的写入。
- SQL 兼容：支持标准 SQL，学习成本低。
Apache Druid
Druid 是专为 OLAP 场景设计的实时分析数据库。
- 预聚合：支持时间维度的预聚合，查询更快。
- 实时摄入：原生支持流式数据摄入。
- 高可用：分布式架构，节点故障自动恢复。
- 时序优化：对时间序列查询做了深度优化。
| 对比维度 | ClickHouse | Druid |
|---|---|---|
| 存储模型 | 列式存储 | 列式存储 + 预聚合 |
| 查询速度 | 极快 | 快 |
| 写入性能 | 高 | 高 |
| SQL 支持 | 强 | 较弱 |
| 运维复杂度 | 中等 | 较高 |
| 适用场景 | 即席查询、报表 | 实时 OLAP、时序分析 |
我的习惯：如果查询场景复杂，需要灵活的多维分析，我倾向 ClickHouse。如果场景固定，主要是时间序列的聚合查询，Druid 更合适。记得有一次，我用 ClickHouse 做用户行为分析，SQL 写起来非常顺手，查询速度也快。
整体技术栈选型框架
下面这张图，是我总结的实时指标层技术栈选型框架。你可以根据业务场景，快速定位合适的组合。
选型没有标准答案。我建议你根据业务场景、团队能力、运维成本，综合评估。记住，稳定压倒一切。一个跑得稳的系统，比一个跑得快但总出问题的系统，有价值得多。