引擎选型怎么定
引擎选型没有单一最优解，按场景分工才实际：T+1 的批量加工用 Hive 或 Spark，实时链路用 Flink，面向人的交互分析用 Doris、ClickHouse 这类 MPP 或列存 OLAP。判断维度是延迟要求、数据规模、并发量与团队已有的运维能力。真正容易出问题的往往不是单引擎性能，而是多个引擎同时加工同一份数据时的口径与流向。
基本信息
| 离线批处理 | Hive、Spark |
|---|---|
| 实时计算 | Flink |
| 交互分析 | Doris、ClickHouse、Trino |
| 选型维度 | 延迟要求、数据量、并发量、运维成本 |
典型使用场景
- T+1 报表：大体量扫描与聚合，Hive 或 Spark 批量加工最稳
- 实时大屏与告警：延迟要求秒级，走 Flink 实时链路
- BI 自助分析：并发高、结果集小，放 Doris 或 ClickHouse 更稳
- 联邦查询：不搬数据直接查湖表，用 Trino 这类引擎
- 历史回补：同一逻辑用批模式重跑，避免维护第二套实时代码
引擎分工对照
| 引擎 | 定位 | 典型场景 |
|---|---|---|
| Hive | 离线 SQL 批处理 | T+1 ETL 与历史回溯 |
| Spark | 内存计算统一引擎 | 复杂 ETL、迭代计算、批流 API 统一 |
| Flink | 流批一体的有状态引擎 | CDC 入湖、实时指标与告警 |
| Doris / ClickHouse | MPP 与列存 OLAP | 看板、即席查询、高并发点查 |
分工示意
分工示意
# 典型链路：同一份数据只在一个引擎里定口径
CDC -> Flink -> 湖表（明细）
湖表 -> Spark/Hive -> DWS 汇总
DWS 汇总 -> Doris/ClickHouse -> 看板
# 反例：同一天的数据既用 Spark 算一遍又用 Flink 算一遍，数字必然对不上每引入一个引擎都要配套权限、监控、备份与值班方案，否则会形成运维孤岛。小团队更实用的做法是先固定一条主链路（例如 Hive 或 Spark 加一个 OLAP），确认瓶颈之后再引入新引擎。
同一份明细在两套引擎里各算一遍是口径分裂的常见来源：两边调度节奏或过滤条件一旦不同，同一指标就会出现两个数字，排查成本远高于省下的那点计算时间。