大数据 选型

[timzaak]

File System

HDFS 毋庸置疑的第一位，所有的大数据上层建筑都会适配HDFS， 我本更多想考虑对象存储，但国内云厂家的对象存储针对 HDFS 的兼容性适配并不能都达到可用标准。至于 MinIO，虽然适配HDFS, 但需要自建。 所以， 在云上：HDFS > 对象存储 > MinIO。 自建： MinIO > HDFS， 因为 MinIO 还能做对象存储使用。

运算/数据处理

Spark、Flink 两者我目前拿不到合理的数据去评估两者在特定场景的优劣。毕竟双方都已经从差异化竞争步向同质化竞争，考虑到 Spark 全球范围影响力，还是用 Spark 比较合适。 调度方案不考虑 YARN，只需要 k8s operator，可以和应用服务共享运维能力。 至于实时计算，这个需要更细致的考量应用场景，再定技术栈。很多时候伪实时即可满足需求。

管道/队列

Kafka 是在大数据中队列组件的王者，但考虑到 RocketMQ 在 Java 业务中的广泛使用，用它未尝不可，毕竟很少业务能达到 RocketMQ 的上限，目前还无法确认上层大数据应用对于 RocketMQ 的支持程度。至于 Pulsar，虽然很喜欢 Topic 可随意搞，但 Push 消息而非 Pull，以及复杂的组件构成所带来的维护成本，还是放弃掉。

OLAP、OLTP

TiDB 目前是我的第一优先级，但国内云厂商支持度不够，真要选型，可能是 Apache Doris、 Pheonix over HBase、Clickhouse、Hive、Presto 等可开箱即用。

KV

TiKV、Aerospike，两者都可，Aerospike 性能会更强。

时序

InfluxDB 目前云厂商支持最多，但都是1.7x 版本，之后 InfluxDB 更换了协议，云厂商不再跟进。时序DB具体应用场景主要是 insert is most important， merge is second 的场景，我对此的认知，就是 IOT 计费、统计、监控场景可用，其余就算了。

数据湖

全中国也没几家公司能达到这个级别，先不考量。

总的选型思路

1. 尽量用云厂商的套件，尤其涉及存储。
2. 尽量用可泛化，运维简单的套件，性能指标并不重要，尤其是实际场景连一半性能上限都达不到的情况下。
3. 尽量不上大数据。很多实际场景只是个 ETL + Cache 而已。

[timzaak]

尽量不上大数据的解释

PG、MySQL 对于单表只查找数据而非二次计算的需求，在这个星球上很少满足不了。唯二的问题是：

1. 磁盘空间不足，需要 2T 以上空间
2. 负载过高，64C、128C 都扛不住并发

针对于此，也只需要针研究好索引构成策略，进行分库分表即可，因此造成的事务问题现在已经到处有成熟方案解决。 （如何一致性备份尚未研究）

当遇到以下两个以上的情况，才需考量大数据架构：

1. 原始数据，非结构化，无法建立有效索引
2. 需要经常性扫所有数据进行计算，才能获取查询结果，例如：sum/count/max/min/average group by having
3. 数据量已经在10TB级别以上

低于上面需求的的可考虑以下解决方案： 用 128C、512G内存机器（计算机器） + Scala parallel lib 做演算 用 async logback + 对象存储 Appender + lb 做数据落库（二进制数据目前还没找到合适的方案） 用 RocketMQ 做消息通知，进行实时处理 用 常规 job dispatcher + 命令行 做离线演算任务调度 PS：没有考虑 checkpoint、异常恢复、计算倾斜等问题，对于复杂运算，还是会考验编程者技术。

上述计算完毕的结果，可直接落库到 MySQL、PG，进行结果缓存

[timzaak]

Ray 分布式计算模型，主要面向机器学习、AI。 虽然缺乏大数据 Table 等SQL API，但考虑到AI热火的今天，以后还是有可能要用到的。