odps（hive）上进行join操作的三种方式

 

最近项目上用到了阿里云大数据平台的数据仓库，很多离线计算和挖掘工作都是基于odps来实现，这其中必不可少的工作就是表与表之间的碰撞。 

         由于一开始集群资源比较充裕，一个sql任务不会运行的太久，所以没有对join做单独的关注和优化，最近由于资源紧张并且涉及到大表join，发现性能下降到令人发指的程度（千万级别的表a与百亿级别的表b进行最简单的join操作耗时5个小时以上），另外就是涉及到odps不等值join的用法，使我最近结合hive研究了odps上的join操作以及优化。 

         在这里提一下个人对阿里云大数据平台的理解，阿里云的odps、流计算、盘古、伏羲等等其实在底层或多或少都是以开源的hadoop、hive、storm等技术为基础，只是阿里这之上做了很多的封装、优化、以及虚拟化等工作，本质上其实在技术架构和技术特点上与开源组件和类似的，但是由于阿里云大部分是闭源，所以这里也只是个人在使用了阿里云产品之后的臆测。 

         odps （hive）上的join大致可分为三类：

 1、普通join

         不做任何优化，直接使用join，由mapreduce计算得出结果，涉及到shuffle，性能差，不支持不等值和条件join。

 

 2、广播小表、map join

         适用于与小表join，与spark的broadcast变量类似，将小表存储至内存，通过map来来遍历实现join操作，省去了shuffle，大幅提升了性能，前提是各个节点的内存能够放下广播的表，另外对广播表的行数、大小也有限制，该方式在 odps上可实现不等值join。

 

3、Sort-­Merge-­Bucket Join

         hive上除了分区以外还有更细粒度的物理划分--分桶bucket，分区可以理解为按照分区列的值将数据存储在不同的目录下，分桶是按照分桶列的值存在不同的文件之中，具体细节包括按照列值hash、对bucket数量取模、桶中值按照某些列排序等等。采用分桶会带来很多好处，例如取样、join等。

大表与大表join，第2种方法显然不可行，可采用分而治之的方法，将两张表格提前按照相同的规则进行分区、分桶（要求两张表分桶数必须成倍数、按照某些列进行排序），这样大表之间的join，就变成了各个桶之间的map join操作；最终结果是各个桶的结果链接，由于桶里的内容可以排序，所以在map join和结果合并时性能都比较好。 

该方法适用于提升大表之间的join操作的性能，前提是要对join的两张表做额外的分桶排序配置。该方法支持不等值join。

 

--------------------------------------------------------------------------------------------------------------------------------

 

总结，若不做任何优化，那就是直接mapreduce进行join运算，性能低；若是与小表的join可采用广播小表进行map join的方式，省去了shuffle操作，性能较好；若是大表与大表join，可采用smb join方式，原理与第二种类似，但需要提前做额外的表格配置。