Spark Tungsten 为什么能提升执行效率？
面试怎么回答
Tungsten 的目标是让 Spark 更贴近内存和 CPU 工作。它用紧凑的二进制格式替代大量 Java 对象，减少对象头、装箱、序列化和 GC；通过显式执行内存管理支持 Spill；再配合面向缓存的哈希、排序实现和代码生成，减少虚函数调用。但 Python UDF、对象式 RDD、Shuffle 或数据倾斜仍可能成为瓶颈。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
同样的聚合逻辑，从对象式处理换成 Spark SQL 后，CPU 和 GC 压力往往会明显下降。
背后不只是优化器改写计划，还有 Tungsten 对内存布局和 CPU 执行方式的重做。
Tungsten 通过紧凑二进制内存格式、显式内存管理和面向 CPU 的代码执行，减少对象分配、GC、序列化与虚函数调用。
Java 对象模型的成本很高
一行数据拆成多个 Java 对象，会带来对象头、指针、装箱和内存碎片。大规模聚合和排序时，堆上对象数量暴涨，GC 不仅扫描耗时，还会打断计算。对象之间分散存放，也不利于 CPU Cache 连续读取。
二进制行让数据更紧凑
Spark SQL 使用内部二进制表示保存行、数组和 Map，字段按固定区域和可变区域组织。算子可以直接在这块内存上读取和比较，减少对象反序列化与复制。紧凑布局提高缓存命中，也让排序、哈希和聚合更容易做专用实现。
显式管理执行内存
Tungsten 让 Spark 更主动地管理执行内存，在内存不足时可以把排序、聚合等数据结构溢写到磁盘，而不是只依赖 JVM 抛出 OOM。堆外内存能减少 GC 管理对象的数量，但并不等于没有内存上限，仍要监控峰值和 Spill。
面向硬件优化算子
哈希表、排序器和编码路径会围绕顺序访问、低分支和紧凑数据结构实现，尽量利用现代 CPU 的 Cache 和流水线。Whole-Stage CodeGen 则进一步把多个算子融合成生成代码，这通常被视为 Tungsten 执行优化的一部分。
它不是所有任务的万能加速器
RDD 中的任意对象、Python UDF、无法生成代码的表达式或大量外部库调用，会打断这条优化路径。数据倾斜、Shuffle 网络、文件小且多等瓶颈，也不能靠二进制内存格式自动解决。判断效果仍要看执行计划、GC、Spill 与 CPU 指标。
面试时要讲出因果链
不要只背“堆外内存、Cache、CodeGen”三个词。应说明对象模型为什么导致空间和 GC 成本，二进制布局如何减少对象与复制，专用算子和代码生成又如何减少解释与函数调用，最后补充边界条件。
参考资料
- Spark Tuning Guide：https://spark.apache.org/docs/latest/tuning.html