2. 技术选型框架：选型评估维度与组织匹配

选型这件事，说白了就是做权衡。没有银弹，只有最适合你当前场景的方案。我这些年看过太多团队，一上来就追最火的技术，结果落地时发现跟自己的业务场景完全不搭。嗯，今天我们就来聊聊，到底该怎么系统地评估一个流批一体引擎。

2.1 四个核心评估维度

我个人习惯把选型拆成四个维度：延迟、吞吐、一致性、生态。这四个点基本能覆盖90%的选型场景。我们一个一个来看。

2.1.1 延迟（Latency）

延迟指的是从数据产生到被处理完成的时间。流计算里，延迟通常用端到端延迟来衡量。

• 毫秒级：适合实时风控、交易监控。比如 Flink 在纯流模式下能做到毫秒级。
• 秒级：适合实时大屏、监控告警。Spark Streaming 的微批次模式通常在秒级。
• 分钟级：适合离线报表、批量 ETL。传统 MapReduce 或 Hive 就是这个级别。

2.1.2 吞吐（Throughput）

吞吐就是单位时间内能处理多少数据。通常用每秒处理记录数（RPS）或每秒处理字节数（BPS）来衡量。

这里有个坑：延迟和吞吐往往是矛盾的。你追求极低延迟，吞吐就会受限；你追求高吞吐，延迟就会上升。选型时得先搞清楚，你的业务更在意哪个。

2.1.3 一致性（Consistency）

一致性是流批一体最核心的难点。说白了就是：数据会不会丢？会不会重复？

• 至少一次（At-Least-Once）：数据不会丢，但可能重复。适合日志采集、监控。
• 精确一次（Exactly-Once）：数据既不丢也不重复。适合金融交易、计费系统。
• 最多一次（At-Most-Once）：数据可能丢，但不会重复。适合实时大屏，丢了就丢了。

2.1.4 生态（Ecosystem）

生态决定了你落地时有多痛苦。我一般看这几个方面：

• 连接器丰富度：Kafka、HDFS、Hive、HBase、Elasticsearch……这些常用的有没有现成的 Connector？
• SQL 支持度：团队里不是所有人都能写 Java/Scala 代码。SQL 支持得好，业务同学也能上手。
• 监控与运维：有没有 Prometheus 指标？有没有 Web UI？出问题了怎么排查？
• 社区活跃度：遇到 Bug 多久能修？有没有商业公司支持？

2.2 技术成熟度曲线

技术选型不能只看功能，还得看这个技术处在什么阶段。我经常用 Gartner 的技术成熟度曲线来辅助判断。

你看这张图，Flink 已经进入了稳步复苏期，甚至接近生产成熟期。而一些新兴的流引擎还在技术触发期。我的建议是：

• 核心业务：选成熟期或复苏期的技术。比如 Flink、Spark。
• 创新业务：可以试试膨胀期的技术，但要做好踩坑的准备。
• 千万别选：泡沫幻灭期的技术。这个阶段社区动荡，文档不全，Bug 一堆。

2.3 组织能力匹配度

技术选型不只是技术问题，更是组织问题。你想想看，一个全是 Java 工程师的团队，你非要选 Scala 写的 Spark，这不是给自己找麻烦吗？

2.3.1 团队技术栈

2.3.2 运维能力

流计算引擎的运维比批处理复杂得多。你得考虑：

• 集群管理：你们有专门的运维团队吗？还是开发兼着做？
• 监控告警：有没有 Prometheus + Grafana？出问题了能第一时间发现吗？
• 故障恢复：任务挂了，是自动重启还是手动恢复？Checkpoint 怎么配？

2.3.3 学习成本

每个引擎都有自己的概念体系。Flink 有 DataStream、KeyedStream、Window；Spark 有 DStream、DataFrame、Structured Streaming。团队学习一个新引擎，通常需要 2-4 周才能上手。

我一般会这样评估：

1. 先做 POC（概念验证）：选一个核心场景，让团队用目标引擎实现一遍。
2. 看学习曲线：Flink 的 SQL 模式学习成本低，但 DataStream API 学习成本高。
3. 考虑长期维护：这个引擎的文档全不全？社区活跃吗？招人容易吗？

2.4 选型决策矩阵

最后，我分享一个我自己常用的选型决策矩阵。把四个维度打分，然后加权求和。

当然，这个权重不是固定的。如果你的业务对延迟极度敏感，可以把延迟的权重提到 50%。关键是要量化，别凭感觉拍脑袋。