引子
最近阿里云 E-MapReduce 团队在 TPCDS-Perf 榜单中提交了最新成绩，相比第二名(其实也是 EMR 团队于 2019 年提交的记录)，无论从性能还有性价比都取得了 2 倍+的优秀成绩！详细看 TPCDS Perf
阿里云 E-MapReduce 团队，除了在产品、易用性、安全性等维度上投入了大量的研发资源和精力，打造了 EMR 这样一个广受好评的大数据产品；在引擎层面上也长期投入，持续深耕，目的就是要在保持开源软件的 100% 兼容性的同时，要利用团队的技术深度去打造产品的技术壁垒，让客户在使用开源软件栈的时候，能够获得更多的性价比，真真切切的把云上成本降低到极致，让客户能够在上云的过程中没有疑虑和后顾之忧。
阿里云 E-MapReduce 团队在 TPCDS Perf 中取得的成绩也足以验证，团队在 SPARK 引擎的技术深度以及技术实力，接下来会有一个系列的文章，去介绍我们 2020 年度打榜过程的一些优化点还有思考，欢迎社区里的 spark 引擎开发者或者 spark 应用开发者可以关注我们的系列文章，也欢迎来和我们交流，最关键的是，欢迎多投简历，加入阿里云 E-MapReduce 团队，我们求贤若渴！！！
第三次刷榜的 Flag
从上述的 TPCDS Perf 链接中，我们可以看到，其实 EMR 团队在 10TB 规模总共提交了三次成绩。第三次也就是这一次打榜，背后还有一个小故事。因为在 Perf 页面中，最终 TPCDS 关注的指标有两个，一个是性能指标一个是性价比指标。这次项目立项的时候，我们就给自己立下了一个艰难的 Flag ，我们要在物理硬件保持不变的条件下，纯靠软件优化提升 2 倍+，这样子性能指标和性价比指标就都能翻倍了。
与开源 Spark 版本的一些对比数据
在提交完成绩后，我们用开源 Spark V2.4.3 版本进行了 TPCDS 99 Query 测试，以下是性能数据对比
Load 阶段性能提升约 3 X
PT 阶段性能提升约 6 X
PS. 其中社区 Spark V2.4.3 版本中 Query 14 以及 Query 95 因为 OOM 的原因没法跑出来，不纳入计算
社区 Spark 版本运行时间大于 200S 的 Query 单独拿出来对比
PS. 这几个 Query 最低的 Query 78 有 3X 性能提升，Query 57有接近 100 倍的性能提升。
优化点概述
优化器
基于 InMemoryTable Cache 的 CTE 物化
简单来说，就是尽量更合理的利用 InMemoryTable Cache 去减少不必要的重复计算，比如说 Query 23A/B 中的标量计算，本身是非常重的操作，并且又必须重复的计算，通过 CTE 优化的模式匹配，识别出需要重复计算且比较耗时的操作，并利用 InMemoryTable 缓存，整体减少 E2E 时间
-
更加有效的 Filter 相关优化-
Dynamic Partition Pruning这个在社区最新的3.0版本才有这个功能 -
小表广播复用一个具有过滤性的小表，如果可以过滤 2 个或以上的打表数据时，可以复用该小表的过滤效果 Query 64 就是一个好例子 -
BloomFilter before SMJ在 SMJ 真正实施之前，通过前置 BloomFilter ，Join 过程的数据进一步减少，最大限度的消除 SpillDisk 的问题
-
-
PK/FK Constraint 优化通过主键外键信息，对优化器提供更多的优化建议-
RI-Join去除 事实表与维表于主键外键上做 Join ，但是维表的列并没有被 Project 的情况下，这次 Join 其实完全没有必要执行 -
GroupBy Keys 去除非主键列当GroupBy Keys 中同时包括主键列以及非主键列，其实非主键列对 GroupBy 结果已经没有影响了，因为主键列已经隐含了 Unique 的信息 GroupBy Push Down before Join
-
Fast Decimal
基于 Table Analyze 以及运行时中的 Stat 信息，优化器可以决定把某些 Decimal 优化为 Long 或者 Int 的计算，这会有极大的提升，而 TPCDS 99 Query 里有大量的 Decimal 计算
运行时
这次的优化里面，还有一个很好玩的优化，就是我们引入的 Native Runtime，如果说上述的优化器优化都是一些特殊 Case 的杀手锏，Native Runtime 就是一个广谱大杀器，根据我们后期统计，引入 Native Runtime，可以普适性的提高 SQL Query 15～20%的 E2E 耗时，这个在TPCDS Perf 里面也是一个很大的性能提升点。
大致的介绍一下 Native Runtime
基于开源版本的 WholeStageCodeGeneration 的框架，在原有的生成的 Java 代码，替换成 Weld IR 来真实运行。Weld详细参考 http://weld.stanford.edu/。在整个项目里，Weld IR 的替换其实是非常小的一部分工作，为了Weld IR 能够运行起来，我们还需要做以下的工作
- Expression Weld IR CodeGen ( TPCDS 范围内全支持)
- Operators Weld IR CodeGen (除了 SortMergeJoin 用 C++ 实现，其他均可以用 Weld IR 代替)
- 统一内存布局 (OffHeap UnsafeRow => C++ & Weld Runtime)
- Batch 化执行框架 (因为如果按照 Java 运行时，每次都是一条记录的在生成代码里流转，在 NativeRuntime 的时间里代价太高， JNI 以及WeldRuntime 明显不能这么玩)
- 其他高性能Native算子 SortMergeJoin、PartitionBy、CSV Parsing，这几个算子目前用 Weld IR 提供的接口无法直接实现，我们通过 C++来实现这些算子的 Native 执行
结语
这个文章只是大概的介绍了这次性能优化的一些优化点，在接下来的系列文章里，我们会针对每一个优化点细致的展开、分析，希望对 Spark-SQL 有兴趣的同学们可以多多关注，多多捧场。同时，我们也希望对 EMR 团队有兴趣的同学，积极联系我们，我们真的求贤若渴，海量 HC ，请有兴趣者联系 林学维(峰七) 18518298234，也可邮箱 xuewei.linxuewei@alibaba-inc.com !!!
