前言   

   在《数据库系统中的Code Generation技术介绍》中，我们简单介绍了一下Code Generation技术及其在大规模OLAP系统，特别是大规模分布式OLAP系统中的重要性。MaxCompute采用了Code Generation技术来提高计算效率。在MaxCompute2.0中，我们又引入了基于LLVM的JIT(Just In Time) Code Generation技术。结合向量化的执行引擎，基于SIMD技术的执行效率优化等方式，较之MaxCompute 1.0，MaxCompute 2.0在性能方便有了较大的提升，具体可以参照《MaxCompute2.0性能评测：更强大、更高效之上的更快速》。

MaxCompute 1.0中的Code Generation

   如上图，MaxCompute 1.0采用了静态的Code Generation技术，工作主要在MaxCompute控制集群中名为“Executor”的角色上完成。其流程如下：

1. 用户的SQL语句在Executor上经过Parsing和Optimization之后，生成对应的查询计划。
2. Executor上的Code Generation模块将查询计划翻译成一个名为“mapred.cpp”的C++源文件。如上图所示，查询计划中的每一个Task（就是MaxCompute作业中的一个Stage）会被翻译成C++中的一个Class, 而所有的处理逻辑被生成到该Class的Process()方法当中。
3. Executor调用g++将“mapred.cpp”编译成一个动态库，并将其下发到计算集群中的每一个Worker上。
4. 被调度起来的Worker会Load该动态库，调用相应的Process()方法以完成计算逻辑。

   可以看到，利用Code Generation技术，对于每一个SQL来说执行时代码都是经过定制的，因此执行效率较传统的Volcano Model更好。但是，其中也有一些问题。

1. g++ 编译还是比较消耗CPU/内存的，特别是当优化选项开到O2以上的时候。特别是用户SQL比较复杂的情况下（有些SQL在SELECT语句中有多达上千个表达式，或者表达式的嵌套计算特别深入），生成的C++源文件也比较大，编译更加耗时。在实际生产中，我们见过编译耗时数十秒，消耗上G内存的情况。
2. 生成的动态库在控制集群和计算集群之间传输也会有带来一定的网络开销。因为这个动态库的与SQL逻辑紧密相关的，因此无法复用，因此每个SQL都会经历编译，下发的过程，在任务提交比较频繁的情况下，控制集群的稳定性会收到一定挑战。
3. 因为较高的编译时开销，这种Code Generation的方式在处理复杂的语句加中小数据规模查询的场景，比如service mode下，overhead太大。

MaxCompute 2.0中的Code Generation

 MaxCompute 2.0采用了基于LLVM的JIT Code Generation技术。所谓JIT，就是程序在运行期间根据需要动态生成相应的机器指令。这样，整个Code Generation的工作由控制集群移交到了真正执行计算逻辑的计算集群各个Worker上。其流程如下：

1. 和MaxCompute 1.0中一样，用户的SQL语句在Executor上经过Parsing和Optimization之后，生成对应的查询计划。
2. 查询计划直接被发送到计算集群各个Worker上。
3. MaxCompute 2.0执行引擎的Code Generation模块Load查询计划，并利用LLVM C++ API生成相应的机器码。Code Generation模块返回一个函数指针作为调用的入口。
4. Worker通过调用Code Generation模块返回的函数指针以完成计算逻辑。

   与MaxCompute 1.0相比，MaxCompute 2.0中Code Generation速度有明显提升。在1.0中，一个SQL的平均Code Generation耗时大概在2-3s左右，这个时间在2.0中被缩短到100 - 200ms。因为在2.0中Code Generation都在计算集群的Worker上完成，因此相对来说减轻了控制集群的压力，有助于MaxCompute控制集群的稳定性。此外，因为MaxCompute 2.0的执行引擎是复用的（不因为SQL不同而不一样），因此无需像1.0中一样，在控制集群与计算集群之间传输动态库，降低了控制集群与计算机群之间的网络负载。

后续工作