实时ETL vs 离线ETL架构对比
请从数据处理延迟、架构复杂度、成本、数据一致性、适用场景等维度，详细对比实时ETL和离线ETL（Lambda架构中批处理层 vs 速度层）的优缺点。在什么场景下应该选择实时ETL？什么场景下离线ETL仍是更好的选择？
回答
屠龙少年
1. 核心差异
| 维度 | 离线ETL | 实时ETL |
|---|---|---|
| 延迟 | T+1，小时级 | 秒级/分钟级 |
| 计算引擎 | Hive/Spark/HDFS | Flink/Kafka Streams |
| 存储 | HDFS/ORC/Parquet | Kafka/RocksDB/内存 |
| 数据量 | TB-PB级批处理 | MB-GB级微批处理 |
| 容错 | 易（重跑即可） | 难（Checkpoint复杂） |
| 开发成本 | 低（SQL为主） | 高（需处理状态/乱序） |
| 硬件成本 | 较低（离线集群） | 较高（内存+SSD） |
2. 实时ETL适用场景
✅ 必须实时：
- 风控/反欺诈（毫秒级响应）
- 实时监控告警（秒级延迟）
- 推荐系统特征实时计算
- 实时大屏（Dashboard秒级刷新）
✅ 实时能带来业务价值：
- 实时BI报表（每小时/每分钟的销售趋势）
- 实时个性化推荐
- 实时运营策略调整
3. 离线ETL适用场景
✅ 仍推荐离线：
- 月度/季度报表（T+1足够）
- 全量数据统计（需要精确结果）
- 复杂ETL（多表Join+多层嵌套）
- 历史数据回刷/重跑
- 数据备份和归档
✅ 实时成本过高时：
- 数据量极大但延迟不敏感
- 复杂业务逻辑维护成本大于收益
- 下游系统不支持高频写入
4. 实时ETL技术挑战
- 乱序数据处理（Watermark/Allowed Lateness）
- 状态管理（大状态Checkpoint）
- Exactly-Once语义
- 数据回溯困难
- 运维复杂度高
5. 混合方案（Lambda）
批路径（离线ETL）：精确的全量报表
流路径（实时ETL）：近似的实时指标
合并层：实时结果基础上，离线结果到达后校正
现代趋势：Kappa架构（统一用流处理），适用于实时需求占主导的场景。