Spark-SQL性能极致优化： Native Codegen Framework

EMR团队探索并开发了SparkSQL Native Codegen框架，为SparkSQL换了引擎，新引擎带来最高4倍性能提升，为EMR再次获取世界第一立下汗马功劳。来自阿里云EMR团队的周克勇将详细介绍Native Codegen框架。本文整理自视频 https://developer.aliyun.com/live/43579

---

本次分享主要分为三部分，第一做这件事情的动机和背景，第二做的过程中解决的核心问题，最后是总结。

有些同学可能了解到，EMR团队今年4月份打破了大数据领域Benchmark TBCDS的世界纪录。在硬件完全相同的情况下，性能提升了一倍，从520万分提高到1100多万分。这个成绩的背后主要依赖两条技术，增强了Optimizer和Native Runtime。Optimizer层面，我们在之前工作的基础上，又做了诸如 CTE 、动态分区裁剪、小表广播、PK/FK、Fast Decimal等优化。

大家如果关注刚结束的SparkSummit，会发现一些类似的技术，如动态分区裁剪已经进了最新的Spark3.0，EMR版本的Spark在几个月之前就支持了。另一条技术是Native Runtime，也是今天分享的主题，涵盖的主要工作，包括 Native Codegen、统一内存布局、Batch化执行框架，后续会详细介绍。

大家都知道 Optimizer的目的是获取最好的执行计划，主要技术包括states收集和Cost Model，难点是静态states不够准确，无法在Plan阶段准确预知Filter或join之后的数据量，因此对后续Plan的代价评估不够准确。

今年SparkSummit发布的adaptive Execution，就把动态stats收集和plan优化结合在一起来解决这个问题。相对应的 Runtime的目的是针对选定的plan，如何使它跑得更快，长期以来 Runtime的主要工作基本上都聚焦在解决当下的新硬件瓶颈。如MapReduce刚出来时，网络带宽是瓶颈，所以Google做了很多locality方面的优化。Spark刚出来时解决的硬件瓶颈是磁盘I/O，它通过内存缓存来提升性能。

再后来 CPU成了新的瓶颈，我们可以看到从10年到20年，磁盘I/O和网络带宽都有了每年数量级的提升，但是CPU的主频基本上保持不变，因此CPU成了新的硬硬件瓶颈，提升CPU性能，成为近年来 Runtime领域重要的优化方向。优化CPU主要有两条技术路线，向量化和Codegen。我们先看一下传统的 SQL执行所应用的火山模型的问题所在，这是一个简单的Select加Filter加Project加Agg的例子。

在执行的过程中，在火山模型中，每个算子都是一个迭代器，下游的算子，调上游算子的next方法，next返回当前算子处理之后的中间结果。这个模型最大的问题是每条record在经过每一个算子的时候，都要经过一次虚函数调用，而虚函数调用的开销是非常大的。

第二个问题就是在每个算子之间需要把中间的结果物化到内存。针对这个问题，向量化技术给出的解，是通过批量执行加列式存储，加小循环，来更好的利用 SIMD的指令和CPU的乱序执行，从而最大化数据并行度和指令并行度，从而分摊掉虚函数调用的开销，并提升执行性能。

例如上面例子里Agg 算子计算过程，他把输入 column1，column2以及 Agg的输出结果sum都存在数组里，然后通过一个很紧凑的for循环进行计算。由于循环足够简单，编译器会做循环展开和SIMD的优化。从截图中我们可以看到，编译器生成了很多向量化的指令，此外，由于for循环足够简单，然后for循环内部基本上都是访存指令，如访问colum1的第i个数据，colum2的第i个数据，所以每次放循环最主要的时间都是在进行访存，而因为 for循环足够的短，所以CPU的乱序执行的窗口里，可以同时发射多条漏斗指令，从而解决了 Memory Wall的问题。

这个技术的代表是MonetDB/X100(2005)，以及今年Spa