📚 课程目录第4章选型方法论

4. 选型方法论：选型维度、场景匹配与成本评估

选型这件事，说白了就是做权衡。没有完美的引擎，只有最适合你场景的引擎。我见过太多团队一上来就追新，结果踩了一堆坑。今天我把这套方法论拆开揉碎了讲给你听。

我个人习惯把选型维度归纳为四个：延迟、吞吐、状态大小、生态。这四个维度基本能覆盖 90% 的选型场景。

很多引擎宣传自己「毫秒级延迟」。嗯，这里要注意——那通常是理想情况。我在项目中遇到过，某引擎在 demo 环境确实能跑到 10ms，但一上生产，数据量大了，状态多了，延迟直接飙到 5 秒。

为什么会这样？因为延迟受三个因素影响：

我的建议：选型时不要只看引擎的「理论延迟」，要看「端到端延迟」。从数据进入 Kafka 到结果写入目标表，这个链路里的每个环节都要测一遍。

吞吐这个维度，我习惯用「单核吞吐」来评估。你想想看，集群规模可以扩，但单核性能决定了你的成本天花板。

举个例子：Flink 的单核吞吐通常在 10-50 万条/秒，Spark Streaming 在 5-20 万条/秒。但这不是的——

避坑指南：我曾经遇到一个项目，团队选了吞吐最高的引擎，结果因为状态太大，频繁 GC，实际吞吐反而比另一个引擎低了 30%。选型不能只看峰值，要看「稳定吞吐」。

状态大小这个维度，说实话，很多人在选型时根本不看。但恰恰是它，决定了你的集群能不能跑得稳。

我总结了一个经验公式：

状态大小 = 键数量 × 每个键的状态大小 × 并行度系数

举个例子：一个用户行为分析任务，每天 1 亿用户，每个用户维护 10 个指标，每个指标 8 字节——

如果选了内存状态后端，这个量级基本扛不住。我建议状态超过 10GB 就优先考虑 RocksDB 或增量 checkpoint。

生态这个东西，平时感觉不到，一旦需要对接新系统就头疼了。我个人习惯用「连接器覆盖率」来评估：

  核心观点：生态好的引擎，开发效率能提升 2-3 倍。反之，你可能要花大量时间写自定义连接器。

有了四个维度，接下来就是匹配场景了。我整理了一个矩阵，帮你快速定位：

这个矩阵不是的。我记得有一次，一个做 IoT 的团队非要选 Flink，但他们的数据量只有每秒 1000 条，延迟要求 10 秒。其实 Kafka Streams 完全够用，还省运维成本。选型要「量体裁衣」。

成本评估，很多人只算机器钱。其实还有三个隐性成本：

我见过一个案例：某公司选了 Flink，但团队之前全是 Spark 背景。结果前三个月基本在「交学费」，线上故障频发。如果当时选 Spark Structured Streaming，虽然性能差一点，但整体交付时间能缩短 40%。

我的建议：做成本评估时，把「团队现有技能」也算进去。如果团队对某个引擎有 6 个月以上的实战经验，那这个引擎的「隐性成本」会低很多。

技术债务这个词，听起来有点虚。但说白了，就是你现在做的选择，未来要还的「利息」。

我总结了几种常见的技术债务：

避坑指南：我曾经接手过一个项目，前任团队为了性能，改了 Flink 的序列化层。结果 Flink 升级到 1.14 时，他们的代码完全不能用，花了两个月重构。能不改源码，就别改。

如何评估技术债务？我习惯用「债务系数」：

债务系数 = (定制代码行数 / 总代码行数) × 100%

如果这个系数超过 20%，就要警惕了。说明你的系统已经和社区版本「脱钩」了。

最后，我把整个选型流程串起来。这是我个人习惯用的五步法：

这五步走下来，基本不会出大问题。嗯，我这些年做过的选型，90% 都是按这个流程来的。

  核心总结：选型不是「选最好的」，而是「选最合适的」。延迟、吞吐、状态、生态，四个维度缺一不可。加上成本评估和技术债务分析，你就能做出一个「未来不后悔」的决定。