大数据学习：Hive on Spark优化设计
作者：张老师 浏览次数： 2021-01-25 16:46
前面我们对Hive on Spark设计原则及架构做了基本的讲解，可以看出，Hive on Spark的实质，其实是把Hive 查询转换为Spark任务来执行，这其中所涉及到的很多转换，可能会影响到整体的运行效率。自然，这其中也针对性地采用了优化的思路。今天的大数据学习分享，我们就来讲讲Hive on Spark当中的优化设计。
1、Map Join
Map Join是Hive中一个很重要的优化，其原理是，如果参与Join的较小的表可以放入内存，就为这些小表在内存中生成Hash Table，这样较大的表只需要通过一个MapWork被扫描一次，然后与内存中的Hash Table进行Join就可以了，省去了Shuffle和ReduceWork的开销。
在MapReduce模式下，通过一个在客户端本地执行的任务来为小表生成Hash Table，并保存在本地文件系统上。后续的MapWork首先将Hash Table上传至HDFS的Distributed Cache中，然后只要读取大表和Distributed Cache中的数据进行Join就可以了。
Hive on Spark对于Map Join的实现与MapReduce不同。最初考虑使用Spark提供的广播功能来把小表的Hash Table分发到各个计算节点上。使用广播的优点是Spark采用了高效的广播算法，其性能应该优于使用Distributed Cache。而使用广播的缺点是会为Driver和计算节点带来很大的内存开销。
为了使用广播，Hash Table的数据需要先被传送到Driver端，然后由Driver进行广播；而且即使在广播之后，Driver仍需要保留这部分数据，以便应对计算节点的错误。虽然支持Spill，但广播数据仍会加剧Driver的内存压力。此外，使用广播相对的开发成本也较高，不利于对已有代码的复用。
因此，Hive on Spark选择了类似于Distributed Cache的方式来实现Map Join，而且为小表生成Hash Table的任务可以分布式的执行，进一步减轻客户端的压力。
不同于MapReduce，对于Hive on Spark而言，LocalWork只是为了提供一些优化时的必要信息，并不会真正被执行。对于小表的扫描以独立的SparkTask分布式地执行，为此，我们也实现了能够分布式运行的HashTableSinkOperator（Hive中输出小表Hash Table的操作符），其主要原理是通过提高HDFS Replication Factor的方式，使得生成的HashTable能够被每个节点在本地访问。
虽然目前采取了类似Distributed Cache的这种实现方式，但如果在后期的测试中发现广播的方式确实能够带来较大的性能提升，而且其引入的内存开销可以被接受，我们也会考虑改用广播来实现Map Join。
2、Table Cache
Spark的一个优势就是可以充分利用内存，允许用户显式地把一个RDD保存到内存或者磁盘上，以便于在多次访问时提高性能。另外，在目前的RDD转换模式中，一个RDD的数据是无法同时被多个下游使用的，当一个RDD需要通过不同的转换得到不同的子节点时，就要被计算多次。这时，我们也应该使用Cache来避免重复计算。
在SparkSQL中，允许用户显式地把一张表Cache来提高对该表的查询性能；对于Hive on Spark，我们也应该充分利用这一特性。
一个应用场景是Multi Insert查询，即同一个数据源经过运算后需要被插入到多个表中的情况。
在这种情况下，对应的SparkWork中，一个MapWork/ReduceWork会有多个下游的Work，如果不进行Cache，那么共享的数据源就会被计算多次。为了避免这种情况，我们会将这些MapWork/ReduceWork复制成多个，每个对应一个下游的Work，并对其共享的数据源进行Cache。
更为一般的应用场景是一张表在查询中被使用了多次的情况，Hive on Spark目前还不会针对这种查询进行Cache，不过在后续的工作中会考虑采用自动的或者用户指定的方式来优化这种查询。
关于大数据学习，Hive on Spark优化设计，以上就为大家做了简单的介绍了。Hive on Spark当中的优化设计，本质上来说是围绕提升运行效率去做的，这也是Hive on Spark方案需要去尽可能实现的目标。成都加米谷大数据，专业大数据培训机构，大数据开发，数据分析与挖掘，零基础班本月正在招生中，课程大纲及学习视频可联系客服获取！
1、Map Join
Map Join是Hive中一个很重要的优化，其原理是，如果参与Join的较小的表可以放入内存，就为这些小表在内存中生成Hash Table，这样较大的表只需要通过一个MapWork被扫描一次，然后与内存中的Hash Table进行Join就可以了，省去了Shuffle和ReduceWork的开销。
在MapReduce模式下，通过一个在客户端本地执行的任务来为小表生成Hash Table，并保存在本地文件系统上。后续的MapWork首先将Hash Table上传至HDFS的Distributed Cache中，然后只要读取大表和Distributed Cache中的数据进行Join就可以了。
Hive on Spark对于Map Join的实现与MapReduce不同。最初考虑使用Spark提供的广播功能来把小表的Hash Table分发到各个计算节点上。使用广播的优点是Spark采用了高效的广播算法，其性能应该优于使用Distributed Cache。而使用广播的缺点是会为Driver和计算节点带来很大的内存开销。
为了使用广播，Hash Table的数据需要先被传送到Driver端，然后由Driver进行广播；而且即使在广播之后，Driver仍需要保留这部分数据，以便应对计算节点的错误。虽然支持Spill，但广播数据仍会加剧Driver的内存压力。此外，使用广播相对的开发成本也较高，不利于对已有代码的复用。
因此，Hive on Spark选择了类似于Distributed Cache的方式来实现Map Join，而且为小表生成Hash Table的任务可以分布式的执行，进一步减轻客户端的压力。
不同于MapReduce，对于Hive on Spark而言，LocalWork只是为了提供一些优化时的必要信息，并不会真正被执行。对于小表的扫描以独立的SparkTask分布式地执行，为此，我们也实现了能够分布式运行的HashTableSinkOperator（Hive中输出小表Hash Table的操作符），其主要原理是通过提高HDFS Replication Factor的方式，使得生成的HashTable能够被每个节点在本地访问。
虽然目前采取了类似Distributed Cache的这种实现方式，但如果在后期的测试中发现广播的方式确实能够带来较大的性能提升，而且其引入的内存开销可以被接受，我们也会考虑改用广播来实现Map Join。
2、Table Cache
Spark的一个优势就是可以充分利用内存，允许用户显式地把一个RDD保存到内存或者磁盘上，以便于在多次访问时提高性能。另外，在目前的RDD转换模式中，一个RDD的数据是无法同时被多个下游使用的，当一个RDD需要通过不同的转换得到不同的子节点时，就要被计算多次。这时，我们也应该使用Cache来避免重复计算。
在SparkSQL中，允许用户显式地把一张表Cache来提高对该表的查询性能；对于Hive on Spark，我们也应该充分利用这一特性。
一个应用场景是Multi Insert查询，即同一个数据源经过运算后需要被插入到多个表中的情况。
在这种情况下，对应的SparkWork中，一个MapWork/ReduceWork会有多个下游的Work，如果不进行Cache，那么共享的数据源就会被计算多次。为了避免这种情况，我们会将这些MapWork/ReduceWork复制成多个，每个对应一个下游的Work，并对其共享的数据源进行Cache。
更为一般的应用场景是一张表在查询中被使用了多次的情况，Hive on Spark目前还不会针对这种查询进行Cache，不过在后续的工作中会考虑采用自动的或者用户指定的方式来优化这种查询。
关于大数据学习，Hive on Spark优化设计，以上就为大家做了简单的介绍了。Hive on Spark当中的优化设计，本质上来说是围绕提升运行效率去做的，这也是Hive on Spark方案需要去尽可能实现的目标。成都加米谷大数据，专业大数据培训机构，大数据开发，数据分析与挖掘，零基础班本月正在招生中，课程大纲及学习视频可联系客服获取！
