摘要： 回顾大数据技术领域大事件，最早可追溯到06年Hadoop的正式启动，而环顾四下，围绕着数据库及数据处理引擎，业内充斥着各种各样的大数据技术。在云栖社区2017在线技术峰会大数据技术峰会上，阿里云大数据计算平台架构师林伟做了题为《MaxCompute的大脑：基于代价的优化器》的分享，为大家分享阿里巴巴大数据计算服务的大脑——基于代价的优化器的设计和架构。
更多精彩内容参见云栖社区大数据频道https://yq.aliyun.com/big-data；此外，通过Maxcompute及其配套产品，低廉的大数据分析仅需几步，详情访问https://www.aliyun.com/product/odps。
摘要：回顾大数据技术领域大事件，最早可追溯到06年Hadoop的正式启动，而环顾四下，围绕着数据库及数据处理引擎，业内充斥着各种各样的大数据技术。这是个技术人的好时代，仅数据库领域热门DB就有300+，围绕着Hadoop生态圈的大数据处理技术更是繁花似锦。在云栖社区2017在线技术峰会大数据技术峰会上，阿里云大数据计算平台架构师林伟做了题为《MaxCompute的大脑：基于代价的优化器》的分享，为大家分享阿里巴巴大数据计算服务的大脑——基于代价的优化器的设计和架构。
MaxCompute简介
大数据计算服务(MaxCompute)是一种快速、完全托管的PB/EB级数据仓库解决方案，MaxCompute具备万台服务器扩展能力和跨地域容灾能力，是阿里巴巴内部核心大数据平台，承担了集团内部绝大多数的计算任务，支撑每日百万级作业规模。MaxCompute向用户提供了完善的数据导入方案以及多种经典的分布式计算模型，能够更快速的解决用户海量数据计算问题，有效降低企业成本，并保障数据安全。
MaxCompute架构
MaxCompute基本的体系结构如上图所示，最底层就是在物理机器之上打造的提供统一存储的盘古分布式文件存储系统；在盘古之上一层就是伏羲分布式调度系统，这一层将包括CPU、内存、网络以及磁盘等在内的所有计算资源管理起来；再上一层就是统一的执行引擎也就是MaxCompute执行引擎；而在执行引擎之上会打造各种各样的运算模式，比如流计算、图计算、离线处理、内存计算以及机器学习等等；在这之上还会有一层相关的编程语言，也就是MaxCompute语言；在语言上面希望为各应用方能够提供一个很好的平台，让数据工程师能够通过平台开发相关的应用，并使得应用能够快速地在分布式场景里面得到部署运行。
MaxCompute的研发思路
MaxCompute的研发思路主要分为以下四个方面：
高性能、低成本和大规模。希望打造的MaxCompute平台能够提运算的高性能，尽可能降低用户的使用成本，并且在规模上面能够达到万台机器以及多集群的规模。
稳定性，服务化。希望MaxCompute平台能够提供稳定性和服务化的方式，使得用户不用过多地考虑分布式应用的难度，而只需要注重于用户需要进行什么样的计算，让系统本身服务于用户，并能够提供稳定性，服务化的接口。
易用性，服务于数据开发者。希望MaxCompute平台是易用的，并且能够很方便地服务于数据开发工程师，不需要数据工程师对于分布式的场景进行很深的理解，而只要关注于需要用这些数据进行什么样的运算就可以，接下来就是由MaxCompute平台帮助数据开发工程师高效并且低成本地执行自己的想法。
多功能。希望MaxCompute能够具有更多的功能，不仅仅是支持流计算、图计算、批处理和机器学习等，而希望更多种类的计算能够在MaxCompute平台上得到更好的支持。
MaxCompute的大脑——优化器
基于以上的研发思路，MaxCompute平台需要拥有一个更加强大的大脑，这个大脑需要更加理解用户的数据，更加理解用户的计算，并且更加理解用户本身，MaxCompute的大脑需要能够帮助用户更加高效地优化运算，通过系统层面去理解用户到底需要进行什么样的运算，从而达到之前提到的各种目的，使得用户能够从分布式场景中脱离出来，不必去考虑如何才能使得运算高效地执行，而将这部分工作交给MaxCompute的大脑，让它来为用户提供更智能的平台，这也就是MaxCompute所能够为用户带来的价值。
那么MaxCompute的大脑究竟是什么呢？其实就是优化器。优化器能够将所有信息串联在一起，通过理解系统中数据的相关性以及用户的企图，并通过机器的能力去充分地分析各种各样的环境，在分布式场景中以最高效的方式实现对于用户运算的执行。在本次分享中以离线计算作为主要例子来对于MaxCompute的大脑——优化器进行介绍。
首先对于离线计算的概念进行简单介绍，MaxCompute离线计算架构设计如上图所示。在计算层面往往会存在一个类似高级语言的脚本语言，MaxCompute提供的是类SQL的脚本语言，将脚本语言通过FrontEnd提交进来，之后经过处理转化成为逻辑执行计划，逻辑执行计划在Optimizer（优化器）的指导下翻译成更加高效的物理执行计划，并通过与Runtime的连接之后由伏羲分布式调度系统将物理执行计划分解到运算节点上进行运算。
上述过程的核心就在于如何充分地理解用户的核心计划并通过优化得到高效的物理执行计划，这样的过程就叫做优化器Optimizer。目前开源社区内的Hive以及Spark的一些优化器基本上都是基于规则的优化器，其实对于优化器而言，单机系统上就存在这样的分类，分成了基于规则的优化器和基于代价的优化器。
在单机场景里面，Oracle 6-9i中使用的是基于规则的优化器，在Oracle 8开始有了基于代价的优化器，而Oracle 10g则完全取代了之前基于规则的优化器；而在大数据场景里面，像Hive最开始只有基于规则的优化器，而新版的Hive也开始引入了基于代价的优化器，但是Hive中还并不是正真意义上的代价优化器。而MaxCompute则使用了完全的基于代价的优化器。那么这两种优化器有什么区别呢？其实基于规则的优化器理论上会根据逻辑模式的识别进行规则的转换，也就是识别出一个模式就可能触发一个规则将执行计划从A改成B，但是这种方式对数据不敏感，并且优化是局部贪婪的，就像爬山的人只看眼前10米的范围内哪里是向上的，而不考虑应该先向下走才能走到更高的山顶，所以基于规则的优化器容易陷入局部优但是全局差的场景，容易受应用规则的顺序而生产迥异的执行计划，所以往往结果并不是最优的。而基于代价的优化器是通过Volcano火山模型，尝试各种可能等价的执行计划，然后根据数据的统计信息，计算这些等价执行计划的“代价”，最后从中选用代价Cost最低的执行计划，这样可以达到全局的最优性。
这里分享一个具体的例子帮助大家理解为什么基于规则的优化器无法实现全局的最优化。上图中的这段脚本的意思就是先在A、B和C上面做完join，join出来的结果在某一列上面进行group by操作并计算出平均值。可以将上述的查询过程画成树形的逻辑执行计划，在数据库领域往往是bottom-up的，也就是对于逻辑计划树而言，叶子节点是输入，最终的目标输出则是根节点，所以最终的数据流向是从下向上的。可以看到在这个逻辑计划里面，首先是对于A、B、C三个表进行join，假设Size(B)
