第3章 技术栈深度考察：Spark/Flink/Hive/OLAP引擎核心原理与优化
本章聚焦面试中对分布式计算引擎与存储引擎的深层次考察，重点在运行时原理、调优策略、故障排查和能力边界判断。建议复习时对照各引擎官方文档的架构图，理解每个组件的作用。
3.1 面试问答卡
问题1：Spark Shuffle 发生 OOM，如何定位和解决？
面试官考察点： 是否理解Shuffle Write/Read的内存分配机制，是否掌握动态调整参数与代码重构的平衡思路。
回答框架： 1. 描述OOM场景（Reduce拉取数据量过大）；2. 检查SparkUI中的Shuffle指标；3. 分析原因（数据倾斜/分区过多/内存比例不合理）；4. 给出对应方案（salting/调整spark.sql.shuffle.partitions/调大off-heap）；5. 说明如何验证。
简短示例回答： “先通过SparkUI观察Shuffle Spill，确认单个task拉取>2GB数据，判断为数据倾斜。采用两阶段聚合：第一阶段添加随机前缀局部聚合，第二阶段去掉前缀全局聚合，同时将spark.sql.adaptive.enabled开启，再设置spark.sql.adaptive.coalescePartitions.minPartitionNum=5，执行时间从40min降至8min。”
可能追问： 为什么两阶段聚合能缓解倾斜？除了salting还有哪些方法？什么时候用Hash Shuffle什么时候用Sort Shuffle？
问题2：Flink 的 Checkpoint 如何保证 exactly-once？如果 checkpoint 频繁失败怎么排查？
面试官考察点： 是否掌握分布式快照（Barrier对齐）原理，是否理解状态存储与故障恢复的关联，以及反压与checkpoint的关系。
回答框架： 1. barrier对齐机制；2. 状态后端配合（RocksDB/FS）；3. 常见失败原因（反压导致超时/State大小暴涨/网络抖动）；4. 定位手段（取消反压/优化算子链/调整minPauseBetweenCheckpoints）；5. 验证恢复逻辑。
简短示例回答： “Checkpoint失败通常由反压引起。我通过Flink UI发现Sink算子反压100%，说明下游写入慢。将checkpoint间隔从10s提到30s，同时为Sink算子启用buffer timeout缓冲，并在RocksDB配置state.backend.incremental=true，最终成功率从30%提升至98%。”
可能追问： barrier不对齐模式与对齐模式的区别？当使用EXACTLY_ONCE时，如果数据源不支持回访如何保序？非对齐checkpoint的原理？
问题3：Hive 查询慢，如何从 SQL 层面和文件层面优化？对比 OLAP 引擎（如 ClickHouse）的差异？
面试官考察点： 基础元数据能力和计算引擎（MR/Tez/Spark）的理解，以及对列式存储/索引/物化视图等优化手段的掌握，并能横向对比OLAP引擎的设计理念。
回答框架： 1. SQL层面（谓词下推/分区裁剪/避免Join倾斜/使用Common Table Expression）；2. 文件层面（ORC/Parquet+Zstd压缩/合理合并小文件）；3. OLAP差异（ClickHouse：列存+向量化执行+稀疏索引，适合大宽表聚合查询，但Join能力弱）。
简短示例回答： “Hive慢先检查数据倾斜：对分组字段加随机前缀。文件层转为ORC格式，设置parquet.block.size=256MB，开启矢量化输入。对比ClickHouse，Hive作为批处理引擎延迟高但扩展性好，ClickHouse适合几十毫秒级分析，但需注意数据更新成本和分布式Join的设计限制。”
可能追问： ORC与Parquet的索引结构区别？你理解的向量化执行具体怎么加速？Hive on Spark与原生Spark SQL的差别？
3.2 引擎优化知识结构表
面试时需快速对比各引擎的典型瓶颈和优化方向，下表列出高频考点：
| 引擎 | 典型瓶颈 | 核心优化策略 | 关键参数/配置 |
|---|---|---|---|
| Spark | Shuffle倾斜 / 内存溢出 | 两阶段聚合、AOE、动态分区裁剪、自适应执行 | spark.sql.adaptive.enabled, spark.sql.shuffle.partitions, spark.memory.offHeap.enabled |
| Flink | 反压 / Checkpoint超时 / 状态膨胀 | 调整buffer timeout、启用增量checkpoint、优化算子链、使用RocksDB | taskmanager.memory.process.size, state.backend.incremental, checkpoint.interval |
| Hive | 小文件过多 / 数据倾斜 / 元数据阻塞 | 合并小文件、ORC + bloom filter、设置合理分区、开启CBO | hive.merge.size.per.task, hive.cbo.enable, mapreduce.input.fileinputformat.split.maxsize |
| ClickHouse | 写入放大 / 多表Join性能差 | 使用物化视图、跳数索引、分区优化、避免分布式Join | merge_tree.max_parts_in_total, index_granularity, max_block_size |
3.3 项目案例模板：基于Spark+Hive的实时离线一体化数仓优化
以下模板可套用在技术深度的项目介绍中，重点突出引擎原理的应用：
- 项目名称： 某电商订单实时-离线一体化数仓
- 业务背景： 业务需同时支持实时BI看板（秒级延迟）和离线报表（T+1），早期两套环境数据口径不一致，维护成本高。
- 规模指标： 日增订单数据 10亿条，日增量20TB，实时峰值QPS 5w，离线调度任务500+。
- 技术栈： Flink（实时清洗+聚合） + Hive（ODS/DWD存储） + Spark（DWS/DM层批量计算） + Druid（OLAP查询）。
- 核心难点： ① 实时层与离线层数据口径对齐（采用Hudi实现增量upsert）；② Flink消费Kafka时反压导致Checkpoint失败；③ Spark Shuffle倾斜导致离线ETL凌晨3点未完成。
- 面试高频追问： 为什么选择Hudi而非Iceberg？如何保证实时聚合的准确度（去重/迟到数据处理）？数据质量如何校验？
- 可迁移话术： “在解决Spark倾斜时，我们先用SparkUI定位到了topN key，采用加盐重组后，将shuffle并行度从200调至800，同时开启了spark.sql.adaptive.enabled和spark.sql.adaptive.coalescePartitions.enabled，最终耗时从2h降至25min。复盘后我们把这个调优步骤沉淀为标准化模板，放在代码仓库中供团队复用。”