技术选型指南
选型核心维度
在选择大数据技术栈时，需要从以下维度综合评估：
- 数据规模：TB / PB / EB 级别需求不同
- 实时性要求：离线（小时级）/ 近实时（分钟级）/ 实时（秒/毫秒级）
- 查询模式：批量扫描 / 点查 / 聚合分析 / 联邦查询
- 团队技术栈：Java / Python / SQL 能力
- 运维成本：自建集群 vs 云服务
- 生态集成：与现有系统的兼容性
存储选型
什么时候用 HDFS？
- 需要存储海量非结构化/半结构化数据
- 作为 Hive、Spark 的底层存储
- 数据以追加写为主，很少随机更新
什么时候用 HBase？
- 需要随机读写，毫秒级点查
- 数据模型是宽表（列族设计）
- 时序数据、用户画像、消息存储
什么时候用 Hive？
- 团队 SQL 能力强，不想写代码
- 离线数仓建设（ODS/DWD/DWS/ADS 分层）
- 数据量大但查询不频繁
什么时候用 Delta Lake / Iceberg？
- 需要 ACID 事务（数据更新/删除）
- 需要 Schema 演进
- 流批一体的数据湖场景
- 需要时间旅行（Time Travel）查询历史数据
计算引擎选型
需求分析
│
├── 离线批处理？
│ ├── 数据量超大（PB+）且逻辑简单 → MapReduce
│ ├── 需要 SQL → Hive on Spark / Spark SQL
│ └── 需要机器学习 → Spark MLlib
│
├── 实时流处理？
│ ├── 毫秒级延迟 + 精确一次 → Flink
│ ├── 秒级延迟 + 与 Spark 生态集成 → Spark Streaming
│ └── 轻量级，无需独立集群 → Kafka Streams
│
└── 流批一体？
└── Flink（首选）Spark vs Flink 选型
| 维度 | Spark | Flink |
|---|---|---|
| 处理模型 | 微批（Micro-batch） | 真流处理 |
| 延迟 | 秒级 | 毫秒级 |
| 吞吐 | 极高 | 高 |
| 状态管理 | 有限 | 强大（RocksDB） |
| SQL 支持 | 成熟（Spark SQL） | 成熟（Flink SQL） |
| ML 支持 | 强（MLlib） | 弱 |
| 生态 | 更丰富 | 流处理更专业 |
| 学习曲线 | 中等 | 较陡 |
结论：
- 以批处理为主，偶尔需要流处理 → Spark
- 以流处理为主，需要低延迟 → Flink
- 新项目流批一体 → Flink（Flink 批处理能力已很成熟）
OLAP 引擎选型
查询场景
│
├── 单表大数据量聚合分析（日志分析、用户行为）
│ └── ClickHouse（极致性能）
│
├── 实时导入 + 实时查询（T+0 报表）
│ └── Apache Doris（实时性好，MySQL 协议）
│
├── 跨数据源联邦查询（查 Hive + MySQL + S3）
│ └── Presto / Trino
│
└── 离线数仓 SQL 查询（T+1 报表）
└── Hive / Spark SQLClickHouse vs Doris
| 维度 | ClickHouse | Apache Doris |
|---|---|---|
| 查询性能 | 极强（单表） | 强（多表 Join 更好） |
| 实时导入 | 弱（批量导入为主） | 强（秒级） |
| Join 性能 | 弱 | 强 |
| 运维复杂度 | 中等 | 低 |
| MySQL 兼容 | 部分 | 高度兼容 |
| 适用场景 | 日志分析、监控 | 实时报表、数仓 |
消息队列选型
大数据场景下消息队列几乎是 Kafka 一统天下：
- 吞吐量：百万级 TPS
- 持久化：消息持久化到磁盘，可重放
- 生态：与 Flink、Spark、Hadoop 深度集成
- 流处理：Kafka Streams 可直接做轻量流处理
什么时候考虑其他方案：
- RabbitMQ：需要复杂路由规则、消息优先级
- RocketMQ：金融场景，需要事务消息
- Pulsar：需要多租户、地理复制
云原生 vs 自建集群
| 维度 | 自建集群 | 云服务（EMR/HDInsight） |
|---|---|---|
| 成本 | 硬件成本高，运维成本高 | 按需付费，弹性扩缩容 |
| 控制权 | 完全控制 | 受云厂商限制 |
| 运维 | 需要专业运维团队 | 云厂商托管 |
| 适用 | 数据安全要求高、规模稳定 | 快速上线、规模波动大 |
建议
中小团队优先考虑云服务（阿里云 EMR、AWS EMR），节省运维成本。大厂或数据安全要求高的场景才考虑自建。