核心选型维度：查询性能、写入吞吐、数据一致性、运维复杂度、生态兼容性、成本
选型这件事，说白了就是做权衡。没有完美的系统，只有最适合你场景的。
我见过太多团队，上来就盯着查询性能猛看，结果上线后发现写入扛不住。或者选了运维最简单的方案，半年后数据对不上了。嗯，这六个维度，一个都不能少。
核心原则：选型不是找「最好的」，而是找「最不痛的」。先明确你的业务场景最在意什么，再拿这六个维度去卡。
1. 查询性能：用户感知的第一道门
查询性能最直观。用户点个报表，3秒出和30秒出，体验天差地别。
我个人习惯，先看两个指标：
- P50 / P99 延迟：平均延迟和长尾延迟。很多系统平均1秒，但P99能到10秒，这在实时场景下是致命的。
- QPS 天花板：并发上来后，性能会不会断崖式下跌。
我在项目中遇到过，某系统单查询很快，但并发一上200，CPU直接打满。后来发现是它的查询模型不支持高并发下的资源隔离。
避坑：测试时别只看单条查询。一定要压测，看并发下的P99。我曾经被一个「单查询10ms」的系统坑过，并发一上来直接飙到5秒。
2. 写入吞吐：数据进不来的话，一切都是空谈
写入吞吐决定了你的实时性天花板。你想想看，业务高峰期每秒几万条数据，系统能接住吗？
这里要区分两个概念：
| 指标 | 含义 | 常见瓶颈 |
|---|---|---|
| 峰值写入速率 | 每秒能处理的最大记录数 | 磁盘IO、网络带宽 |
| 持续写入能力 | 长时间高负载下的稳定性 | 内存GC、合并策略 |
我记得有一次，某系统峰值写入能到50万条/秒，但跑半小时后就开始反压。原因是它的LSM-Tree合并策略在高写入下会触发频繁的compaction，把IO吃光了。
注意：写入吞吐不是越高越好。有些系统为了追求写入性能，牺牲了查询的实时性。比如，写入后要等几秒才能查到，这在某些场景下是不能接受的。
3. 数据一致性：实时系统的「命门」
实时OLAP里，一致性是个容易被忽视的坑。你想想看，用户看到的数据如果前后不一致，信任感瞬间崩塌。
常见的模型有三种：
- 最终一致性：写入后，不同副本可能短暂不一致，但最终会收敛。适合日志分析、监控等场景。
- 强一致性：写入后，所有副本立即一致。适合金融、交易等场景。
- 因果一致性：有因果关系的操作保证顺序。适合社交、协同编辑等场景。
我曾经在选型时，忽略了某系统在节点故障时的一致性保证。结果一次机房断电，数据出现了永久性不一致。嗯，那次教训很深刻。
我的建议：先问清楚业务方，数据不一致的容忍度是多少。如果业务说「不能错」，那就别选最终一致性的系统。
4. 运维复杂度：别让系统成为「黑盒」
运维复杂度，说白了就是「这系统好不好养」。
我见过一些团队，选了功能最强的系统，结果运维团队天天加班。为什么？
- 部署依赖太多（比如要搭ZooKeeper、Kafka、HDFS）
- 扩缩容需要手动迁移数据
- 监控指标不完善，出问题只能看日志
我个人习惯，选型时会问三个问题：
- 部署需要几个组件？
- 扩缩容是自动的还是手动的？
- 有没有现成的Prometheus/Grafana监控模板？
避坑指南：我曾经选过一个系统，文档里说「一键部署」，结果实际要配5个配置文件。嗯，后来我学乖了，选型前一定先搭个Demo跑一遍。
5. 生态兼容性：别让自己「孤岛化」
生态兼容性决定了你的系统能跟上下游「聊得来」。
主要看这几个方面：
| 维度 | 说明 | 常见标准 |
|---|---|---|
| SQL兼容性 | 是否支持标准SQL，还是只能用特定API | MySQL/PostgreSQL协议 |
| 数据源对接 | 能否直接读Kafka、HDFS、S3 | Connector生态 |
| BI工具集成 | 能否被Tableau、Superset等直接查询 | JDBC/ODBC |
你想想看，如果选了个只支持REST API的系统，你的分析师想用SQL查数据，还得写一层中间件。这多麻烦。
我记得有一次，某团队选了一个性能极佳的OLAP引擎，结果发现它不支持JDBC。最后不得不自己写了一个SQL解析层，运维成本直接翻倍。
6. 成本：算清楚「总账」
成本不只是买软件的钱。我习惯算「总拥有成本」：
- 硬件成本：同样的数据量，需要多少台机器？
- 存储成本：数据压缩比如何？冷热数据分层是否支持？
- 人力成本：需要几个人来维护？学习曲线陡不陡？
- 云服务成本：如果用云，读写费用、网络费用怎么算？
一个真实的例子：某系统号称「免费开源」，但为了达到性能要求，需要配NVMe SSD和128GB内存。算下来，单台机器成本比商业版还贵。嗯，选型时别只看软件价格。
六个维度的权衡矩阵
下面这张图，是我自己总结的。每次选型，我都会拿它来对照。
你看，六个维度都指向「业务场景」。没有哪个维度是优先的。比如，金融场景可能把「数据一致性」排第一，而日志分析场景可能更看重「写入吞吐」和「成本」。
嗯，这一章的内容就到这里。记住，选型不是一锤子买卖。随着业务发展，你的权衡点也会变。保持对每个维度的敏感度，比选对一次更重要。