本文是对《【硬刚大数据之学习路线篇】2021年从零到大数据专家的学习指南(全面升级版)》的面试部分补充。
前言
hive从2008年始于facebook工程师之手，经过10几年的发展至今保持强大的生命力。截止目前hive已经更新至3.1.x版本，hive从最开始的为人诟病的速度慢迅速发展，开始支持更多的计算引擎，计算速度大大提升。
本文我们将从原理、应用、调优分别讲解hive所支持的mapreduce、tez、spark引擎。
我们在之前的文章中：
《硬刚hive|4万字基础调优面试小总结》
《当我们在学习hive的时候在学习什么？「硬刚hive续集」》
对hive的mapreduce引擎已经做过非常详细的讲解了。
本文首发自公众号：《import_bigdata》，大数据技术与架构。
在hive2.x版本中，hivesql会被转化为mr任务，这也是我们经常说的hivesql的执行原理。
我们先来看下 hive 的底层执行架构图， hive 的主要组件与 hadoop 交互的过程：
hive底层执行架构
在 hive 这一侧，总共有五个组件：
ui：用户界面。可看作我们提交sql语句的命令行界面。
driver：驱动程序。接收查询的组件。该组件实现了会话句柄的概念。
compiler：编译器。负责将 sql 转化为平台可执行的执行计划。对不同的查询块和查询表达式进行语义分析，并最终借助表和从 metastore 查找的分区元数据来生成执行计划。
metastore：元数据库。存储 hive 中各种表和分区的所有结构信息。
execution engine：执行引擎。负责提交 compiler 阶段编译好的执行计划到不同的平台上。
上图的基本流程是：
步骤1：ui 调用 driver 的接口；
步骤2：driver 为查询创建会话句柄，并将查询发送到 compiler(编译器)生成执行计划；
步骤3和4：编译器从元数据存储中获取本次查询所需要的元数据，该元数据用于对查询树中的表达式进行类型检查，以及基于查询谓词修建分区；
步骤5：编译器生成的计划是分阶段的dag，每个阶段要么是 map/reduce 作业，要么是一个元数据或者hdfs上的操作。将生成的计划发给 driver。
如果是 map/reduce 作业，该计划包括 map operator trees 和一个 reduce operator tree，执行引擎将会把这些作业发送给 mapreduce ：
步骤6、6.1、6.2和6.3：执行引擎将这些阶段提交给适当的组件。在每个 task(mapper/reducer) 中，从hdfs文件中读取与表或中间输出相关联的数据，并通过相关算子树传递这些数据。最终这些数据通过序列化器写入到一个临时hdfs文件中（如果不需要 reduce 阶段，则在 map 中操作）。临时文件用于向计划中后面的 map/reduce 阶段提供数据。
步骤7、8和9：最终的临时文件将移动到表的位置，确保不读取脏数据(文件重命名在hdfs中是原子操作)。对于用户的查询，临时文件的内容由执行引擎直接从hdfs读取，然后通过driver发送到ui。
hive sql 编译成 mapreduce 过程
美团博客中有一篇非常详细的博客讲解《hive sql的编译过程》。
你可以参考： https://tech.meituan.com/2014/02/12/hive-sql-to-mapreduce.html
编译 sql 的任务是在上节中介绍的 compiler（编译器组件）中完成的。hive将sql转化为mapreduce任务，整个编译过程分为六个阶段：
hive sql编译过程
<code>词法、语法解析</code>: antlr 定义 sql 的语法规则，完成 sql 词法，语法解析，将 sql 转化为抽象语法树 ast tree；
antlr是一种语言识别的工具，可以用来构造领域语言。使用antlr构造特定的语言只需要编写一个语法文件，定义词法和语法替换规则即可，antlr完成了词法分析、语法分析、语义分析、中间代码生成的过程。
语义解析: 遍历 ast tree，抽象出查询的基本组成单元 queryblock；
生成逻辑执行计划: 遍历 queryblock，翻译为执行操作树 operatortree；
优化逻辑执行计划: 逻辑层优化器进行 operatortree 变换，合并 operator，达到减少 mapreduce job，减少数据传输及 shuffle 数据量；
生成物理执行计划: 遍历 operatortree，翻译为 mapreduce 任务；
优化物理执行计划: 物理层优化器进行 mapreduce 任务的变换，生成最终的执行计划。
下面对这六个阶段详细解析：
为便于理解，我们拿一个简单的查询语句进行展示，对5月23号的地区维表进行查询：
阶段一：词法、语法解析
根据antlr定义的sql语法规则，将相关sql进行词法、语法解析，转化为抽象语法树ast tree：
阶段二：语义解析
遍历ast tree，抽象出查询的基本组成单元queryblock：
ast tree生成后由于其复杂度依旧较高，不便于翻译为mapreduce程序，需要进行进一步抽象和结构化，形成queryblock。
queryblock是一条sql最基本的组成单元，包括三个部分：输入源，计算过程，输出。简单来讲一个queryblock就是一个子查询。
queryblock的生成过程为一个递归过程，先序遍历 ast tree ，遇到不同的 token 节点(理解为特殊标记)，保存到相应的属性中。
阶段三：生成逻辑执行计划
遍历queryblock，翻译为执行操作树operatortree：
hive最终生成的mapreduce任务，map阶段和reduce阶段均由operatortree组成。
基本的操作符包括：
operator在map reduce阶段之间的数据传递都是一个流式的过程。每一个operator对一行数据完成操作后之后将数据传递给childoperator计算。
由于join/groupby/orderby均需要在reduce阶段完成，所以在生成相应操作的operator之前都会先生成一个reducesinkoperator，将字段组合并序列化为reduce key/value, partition key。
阶段四：优化逻辑执行计划
hive中的逻辑查询优化可以大致分为以下几类：
投影修剪
推导传递谓词
谓词下推
将select-select，filter-filter合并为单个操作
多路 join
查询重写以适应某些列值的join倾斜
阶段五：生成物理执行计划
生成物理执行计划即是将逻辑执行计划生成的operatortree转化为mapreduce job的过程，主要分为下面几个阶段：
对输出表生成movetask
从operatortree的其中一个根节点向下深度优先遍历
reducesinkoperator标示map/reduce的界限，多个job间的界限
遍历其他根节点，遇过碰到joinoperator合并mapreducetask
生成stattask更新元数据
剪断map与reduce间的operator的关系
阶段六：优化物理执行计划
hive中的物理优化可以大致分为以下几类：
分区修剪(partition pruning)
基于分区和桶的扫描修剪(scan pruning)
如果查询基于抽样，则扫描修剪
在某些情况下，在 map 端应用 group by
在 mapper 上执行 join
优化 union，使union只在 map 端执行
在多路 join 中，根据用户提示决定最后流哪个表
删除不必要的 reducesinkoperators
对于带有limit子句的查询，减少需要为该表扫描的文件数
对于带有limit子句的查询，通过限制 reducesinkoperator 生成的内容来限制来自 mapper 的输出
减少用户提交的sql查询所需的tez作业数量
如果是简单的提取查询，避免使用mapreduce作业
对于带有聚合的简单获取查询，执行不带 mapreduce 任务的聚合
重写 group by 查询使用索引表代替原来的表
当表扫描之上的谓词是相等谓词且谓词中的列具有索引时，使用索引扫描
经过以上六个阶段，sql 就被解析映射成了集群上的 mapreduce 任务。
hive explain 语句类似mysql 的explain 语句，提供了对应查询的执行计划，对于我们在理解hive底层逻辑、hive调优、hive sql书写等方面提供了一个参照，在我们的生产工作了是一个很有意义的工具。
hive explain语法
explain [extended|cbo|ast|dependency|authorization|locks|vectorization|analyze] query
hive explain的语法规则如上，后面将按照对应的子句进行探讨。
extended 语句会在执行计划中产生关于算子（operator）的额外信息，这些信息都是典型的物理信息，如文件名称等。
在执行explain query 之后，一个查询会被转化为包含多个stage的语句（看起来更像一个dag）。这些stages要么是map/reduce stage，要么是做些元数据或文件系统操作的stage （如 move 、rename等）。explain的输出包含2个部分：
执行计划不同stage之间的以来关系（dependency）
每个stage的执行描述信息（description）
以下将通过一个简单的例子进行解释。
执行explain 语句
explain输出结果解析
依赖图
一个hive查询被转换为一个由一个或多个stage组成的序列（有向无环图dag）。这些stage可以是mapreduce stage，也可以是负责元数据存储的stage，也可以是负责文件系统的操作（比如移动和重命名）的stage。
我们将上述结果拆分看，先从最外层开始，包含两个大的部分:
stage dependencies：各个stage之间的依赖性
stage plan：各个stage的执行计划
先看第一部分 stage dependencies ，包含两个 stage，stage-1 是根stage，说明这是开始的stage，stage-0 依赖 stage-1，stage-1执行完成后执行stage-0。
再看第二部分 stage plan，里面有一个 map reduce，一个mr的执行计划分为两个部分
map operator tree：map端的执行计划树
reduce operator tree：reduce端的执行计划树
这两个执行计划树里面包含这条sql语句的 operator
tablescan：表扫描操作，map端第一个操作肯定是加载表，所以就是表扫描操作，常见的属性：
select operator：选取操作，常见的属性 ：
group by operator：分组聚合操作，常见的属性：
reduce output operator：输出到reduce操作，常见属性：
filter operator：过滤操作，常见的属性：
map join operator：join 操作，常见的属性：
file output operator：文件输出操作，常见的属性:
fetch operator 客户端获取数据操作，常见的属性：
explain使用场景
那么explain能够为我们在生产实践中带来哪些便利及解决我们哪些迷惑呢？
join 语句会过滤 null 的值吗？
现在，我们在hive cli 输入以下查询计划语句
然后执行：
我们来看结果:
从上述结果可以看到 predicate: id is not null 这样一行，说明 join 时会自动过滤掉关联字段为 null 值的情况，但 left join 或 full join 是不会自动过滤null值的，大家可以自行尝试下。
group by 分组语句会进行排序吗？
直接来看 explain 之后结果:
我们看 group by operator，里面有 keys: id (type: int) 说明按照 id 进行分组的，再往下看还有 sort order: + ，说明是按照 id 字段进行正序排序的。
哪条sql执行效率高
观察如下两条sql：
这两条sql语句输出的结果是一样的，但是哪条sql执行效率高呢？
有人说第一条sql执行效率高，因为第二条sql有子查询，子查询会影响性能； 有人说第二条sql执行效率高，因为先过滤之后，在进行join时的条数减少了，所以执行效率就高了。 到底哪条sql效率高呢，我们直接在sql语句前面加上 explain，看下执行计划不就知道了嘛！
在第一条sql语句前加上 explain，得到如下结果:
在第二条sql语句前加上 explain，得到如下结果:
大家有什么发现，除了表别名不一样，其他的执行计划完全一样，都是先进行 where 条件过滤，在进行 join 条件关联。说明 hive 底层会自动帮我们进行优化，所以这两条sql语句执行效率是一样的。
以上仅列举了3个我们生产中既熟悉又有点迷糊的例子，explain 还有很多其他的用途，如查看stage的依赖情况、排查数据倾斜、hive 调优等，小伙伴们可以自行尝试。
explain dependency的用法
explain dependency用于描述一段sql需要的数据来源，输出是一个json格式的数据，里面包含以下两个部分的内容：
input_partitions：描述一段sql依赖的数据来源表分区，里面存储的是分区名的列表，如果整段sql包含的所有表都是非分区表，则显示为空。
input_tables：描述一段sql依赖的数据来源表，里面存储的是hive表名的列表。
使用explain dependency查看sql查询非分区普通表，在 hive cli 中输入以下命令：
得到如下结果：
使用explain dependency查看sql查询分区表，在 hive cli 中输入以下命令：
得到结果：
explain dependency的使用场景有两个：
场景一：快速排除。快速排除因为读取不到相应分区的数据而导致任务数据输出异常。例如，在一个以天分区的任务中，上游任务因为生产过程不可控因素出现异常或者空跑，导致下游任务引发异常。通过这种方式，可以快速查看sql读取的分区是否出现异常。
场景二：理清表的输入，帮助理解程序的运行，特别是有助于理解有多重子查询，多表连接的依赖输入。
下面通过两个案例来看explain dependency的实际运用：
识别看似等价的代码
有如下两条看似相等的sql：
代码一：
代码二：
我们看下上述两段代码explain dependency的输出结果：
代码1的explain dependency结果：
代码2的explain dependency结果：
通过上面的输出结果可以看到，其实上述的两个sql并不等价，代码1在内连接（inner join）中的连接条件（on）中加入非等值的过滤条件后，并没有将内连接的左右两个表按照过滤条件进行过滤，内连接在执行时会多读取part=0的分区数据。而在代码2中，会过滤掉不符合条件的分区。
识别sql读取数据范围的差别
有如下两段代码：
以上两个代码的数据读取范围是一样的吗？答案是不一样，我们通过explain dependency来看下：
可以看到，对左外连接在连接条件中加入非等值过滤的条件，如果过滤条件是作用于右表（b表）有起到过滤的效果，则右表只要扫描两个分区即可，但是左表（a表）会进行全表扫描。如果过滤条件是针对左表，则完全没有起到过滤的作用，那么两个表将进行全表扫描。这时的情况就如同全外连接一样都需要对两个数据进行全表扫描。
在使用过程中，容易认为代码片段2可以像代码片段1一样进行数据过滤，通过查看explain dependency的输出结果，可以知道不是如此。
explain authorization 的用法
通过explain authorization可以知道当前sql访问的数据来源（inputs） 和数据输出（outputs），以及当前hive的访问用户 （current_user）和操作（operation）。
在 hive cli 中输入以下命令：
结果如下：
从上面的信息可知：
上面案例的数据来源是defalut数据库中的 student_tb_orc表;
数据的输出路径是hdfs://node01:8020/tmp/hive/hdfs/cbf182a5-8258-4157-9194-90f1475a3ed5/-mr-10000;
当前的操作用户是hdfs，操作是查询;
观察上面的信息我们还会看到authorization_failures信息，提示对当前的输入没有查询权限，但如果运行上面的sql的话也能够正常运行。为什么会出现这种情况？hive在默认不配置权限管理的情况下不进行权限验证，所有的用户在hive里面都是超级管理员，即使不对特定的用户进行赋权，也能够正常查询。
tez是apache开源的支持dag作业的计算框架，是支持hadoop2.x的重要引擎。它源于mapreduce框架，核心思想是将map和reduce两个操作进一步拆分，分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的dag作业。
tez将map task和reduce task进一步拆分为如下图所示：
tez的task由input、processor、output阶段组成，可以表达所有复杂的map、reduce操作，如下图:
tez的实现
tez对外提供了6种可编程组件，分别是：
1）input：对输入数据源的抽象，它解析输入数据格式，并吐出一个个key/value
2）output：对输出数据源的抽象，它将用户程序产生的key/value写入文件系统
3）paritioner：对数据进行分片，类似于mr中的partitioner
4）processor：对计算的抽象，它从一个input中获取数据，经处理后，通过output输出
5）task：对任务的抽象，每个task由一个input、ouput和processor组成
6）maser：管理各个task的依赖关系，并按顺依赖关系执行他们
除了以上6种组件，tez还提供了两种算子，分别是sort（排序）和shuffle（混洗），为了用户使用方便，它还提供了多种input、output、task和sort的实现，具体如下：
1）input实现：localmergedinput（文件本地合并后作为输入），shuffledmergedinput（远程拷贝数据且合并后作为输入）
2）output实现：inmemorysortedoutput（内存排序后输出），localonfilesorteroutput（本地磁盘排序后输出），onfilesortedoutput（磁盘排序后输出）
3）task实现：runtimetask（非常简单的task，基本没做什么事）
4）sort实现：defaultsorter（本地数据排序），inmemoryshufflesorter（远程拷贝数据并排序）
为了展示tez的使用方法和验证tez框架的可用性，apache在yarn mrappmaster基础上使用tez编程接口重新设计了mapreduce框架，使之可运行在yarn中。为此，tez提供了以下几个组件：
1）input：simpleinput（直接使用mr inputformat获取数据）
2）output：simpleoutput（直接使用mr outputformat获取数据）
3）partition：mrpartitioner（直接使用mr partitioner获取数据）
4）processor：mapprocessor（执行map task），reduceprocessor（执行reduce task）
5）task：finaltask，initialtask，initialtaskwithinmemsort，initialtaskwithlocalsort ，intermediatetask，localfinaltask，maponlytask。
对于mapreduce作业而言，如果只有map task，则使用maponlytask，否则，map task使用initialtaskwithinmemsort而reduce task用finaltask。当然，如果你想编写其他类型的作业，可使用以上任何几种task进行组合，比如”initialtaskwithinmemsort –> finaltask”是mapreduce作业。
为了减少tez开发工作量，并让tez能够运行在yarn之上，tez重用了大部分yarn中mrappmater的代码，包括客户端、资源申请、任务推测执行、任务启动等。
tez和mapreduce作业的比较：
tez绕过了mapreduce很多不必要的中间的数据存储和读取的过程，直接在一个作业中表达了mapreduce需要多个作业共同协作才能完成的事情。
tez和mapreduce一样都运行使用yarn作为资源调度和管理。但与mapreduce on yarn不同，tez on yarn并不是将作业提交到resourcemanager，而是提交到ampoolserver的服务上，ampoolserver存放着若干已经预先启动applicationmaster的服务。
当用户提交一个作业上来后，ampoolserver从中选择一个applicationmaster用于管理用户提交上来的作业，这样既可以节省resourcemanager创建applicationmaster的时间，而又能够重用每个applicationmaster的资源，节省了资源释放和创建时间。
tez相比于mapreduce有几点重大改进：
当查询需要有多个reduce逻辑时，hive的mapreduce引擎会将计划分解，每个redcue提交一个mr作业。这个链中的所有mr作业都需要逐个调度，每个作业都必须从hdfs中重新读取上一个作业的输出并重新洗牌。而在tez中，几个reduce接收器可以直接连接，数据可以流水线传输，而不需要临时hdfs文件，这种模式称为mrr（map-reduce-reduce*）。
tez还允许一次发送整个查询计划，实现应用程序动态规划，从而使框架能够更智能地分配资源，并通过各个阶段流水线传输数据。对于更复杂的查询来说，这是一个巨大的改进，因为它消除了io/sync障碍和各个阶段之间的调度开销。
在mapreduce计算引擎中，无论数据大小，在shuffle阶段都以相同的方式执行，将数据序列化到磁盘，再由下游的程序去拉取，并反序列化。tez可以允许小数据集完全在内存中处理，而mapreduce中没有这样的优化。仓库查询经常需要在处理完大量的数据后对小型数据集进行排序或聚合，tez的优化也能极大地提升效率。
给 hive 换上 tez 非常简单，只需给 hive-site.xml 中设置：
设置hive.execution.engine为 tez 后进入到 hive 执行 sql：
可以看到，我的 userinfo 中有 100w 条记录，执行一遍 count 需要 6.19s。 现在把 engine 换为 mr
再次执行 count userinfo:
可以看到，使用 tez 效率比 mapreduce 有近3倍的提升。而且，hive 在使用 tez 引擎执行时，有 ==>> 动态的进度指示。而在使用 mr 时，只有日志输出 map and reduce 的进度百分比。使用 tez，输出的日志也清爽很多。
在我测试的很多复杂的 sql，tez 的都比 mapreduce 快很多，快慢取决于 sql 的复杂度。执行简单的 select 等并不能体现 tez 的优势。tez 内部翻译 sql 能任意的 map，reduce，reduce 组合，而 mr 只能 map->reduce->map->reduce，因此在执行复杂 sql 时， tez 的优势明显。
tez 参数优化
优化参参数（在同样条件下，使用了tez从300s+降到200s+）
tez内存优化
1. am、container大小设置
参数说明：set tez.am.resource.memory.mb tobe the same as yarn.scheduler.minimum-allocation-mb the yarnminimum container size.
参数说明：set hive.tez.container.size to be the same as or a small multiple(1 or 2 times that) of yarn container size yarn.scheduler.minimum-allocation-mb but never more than yarn.scheduler.maximum-allocation-mb.
2. am、container jvm参数设置
默认值：80% * tez.am.resource.memory.mb,一般不需要调整
默认值：80% * hive.tez.container.size 参数说明：hortonworks建议"–server –djava.net.preferipv4stack=true–xx:newratio=8 –xx:+usenuma –xx:useg1g"
默认值：0.8,参数说明：task/am占用jvm xmx的比例，该参数建议调整，需根据具体业务情况修改；
3. hive内存map join参数设置
默认值：100,参数说明：输出排序需要的内存大小。建议值：40% * hive.tez.container.size，一般不超过2g.
默认值：true,参数说明：是否将多个mapjoin合并为一个，使用默认值
默认值为10mb,参数说明：多个mapjoin转换为1个时，所有小表的文件大小总和的最大值，这个值只是限制输入的表文件的大小，并不代表实际mapjoin时hashtable的大小。 建议值：1/3 * hive.tez.container.size
默认值：100,参数说明：size of the buffer to use if not writing directly to disk。建议值: 10% * hive.tez.container.size.
4. container重用设置
默认值：true,参数说明：container重用开关
hive社区于2014年推出了hive on spark项目（hive-7292），将spark作为继mapreduce和tez之后hive的第三个计算引擎。该项目由cloudera、intel和mapr等几家公司共同开发，并受到了来自hive和spark两个社区的共同关注。通过该项目，可以提高hive查询的性能，同时为已经部署了hive或者spark的用户提供了更加灵活的选择，从而进一步提高hive和spark的普及率。
总体设计
hive on spark总体的设计思路是，尽可能重用hive逻辑层面的功能；从生成物理计划开始，提供一整套针对spark的实现，比如 sparkcompiler、sparktask等，这样hive的查询就可以作为spark的任务来执行了。以下是几点主要的设计原则。
尽可能减少对hive原有代码的修改。这是和之前的shark设计思路最大的不同。shark对hive的改动太大以至于无法被hive社区接受，hive on spark尽可能少改动hive的代码，从而不影响hive目前对mapreduce和tez的支持。同时，hive on spark保证对现有的mapreduce和tez模式在功能和性能方面不会有任何影响。
对于选择spark的用户，应使其能够自动的获取hive现有的和未来新增的功能。
尽可能降低维护成本，保持对spark依赖的松耦合。
基于以上思路和原则，具体的一些设计架构如下。
hive 的用户可以通过hive.execution.engine来设置计算引擎，目前该参数可选的值为mr和tez。为了实现hive on spark，我们将spark作为该参数的第三个选项。要开启hive on spark模式，用户仅需将这个参数设置为spark即可。
在hive中使用以下语句开启:
spark 以分布式可靠数据集（resilient distributed dataset，rdd）作为其数据抽象，因此我们需要将hive的表转化为rdd以便spark处理。本质上，hive的表和spark的 hadooprdd都是hdfs上的一组文件，通过inputformat和recordreader读取其中的数据，因此这个转化是自然而然的。
spark为rdd提供了一系列的转换（transformation），其中有些转换也是面向sql 的，如groupbykey、join等。但如果使用这些转换（就如shark所做的那样），就意味着我们要重新实现一些hive已有的功能；而且当 hive增加新的功能时，我们需要相应地修改hive on spark模式。有鉴于此，我们选择将hive的操作符包装为function，然后应用到rdd上。这样，我们只需要依赖较少的几种rdd的转换，而主要的计算逻辑仍由hive提供。
由于使用了hive的原语，因此我们需要显式地调用一些transformation来实现shuffle的功能。下表中列举了hive on spark使用的所有转换。
hive on spark
对repartitionandsortwithinpartitions 简单说明一下，这个功能由spark-2978引入，目的是提供一种mapreduce风格的shuffle。虽然sortbykey也提供了排序的功 能，但某些情况下我们并不需要全局有序，另外其使用的range partitioner对于某些hive的查询并不适用。
物理执行计划
通过sparkcompiler将operator tree转换为task tree，其中需要提交给spark执行的任务即为sparktask。不同于mapreduce中map+reduce的两阶段执行模式，spark采用dag执行模式，因此一个sparktask包含了一个表示rdd转换的dag，我们将这个dag包装为sparkwork。执行sparktask 时，就根据sparkwork所表示的dag计算出最终的rdd，然后通过rdd的foreachasync来触发运算。使用foreachasync是因为我们使用了hive原语，因此不需要rdd返回结果;此外foreachasync异步提交任务便于我们对任务进行监控。
sparkcontext生命周期
sparkcontext 是用户与spark集群进行交互的接口，hive on spark应该为每个用户的会话创建一个sparkcontext。但是spark目前的使用方式假设sparkcontext的生命周期是spark应 用级别的，而且目前在同一个jvm中不能创建多个sparkcontext。这明显无法满足hiveserver2的应用场景，因为多个客户端需要通过同一个hiveserver2来提供服务。鉴于此，我们需要在单独的jvm中启动sparkcontext，并通过rpc与远程的sparkcontext进行通信。
任务监控与统计信息收集
spark提供了sparklistener接口来监听任务执行期间的各种事件，因此我们可以实现一个listener来监控任务执行进度以及收集任务级别的统计信 息（目前任务级别的统计由sparklistener采集，任务进度则由spark提供的专门的api来监控）。另外hive还提供了operator级 别的统计数据信息，比如读取的行数等。在mapreduce模式下，这些信息通过hadoop counter收集。我们可以使用spark提供的accumulator来实现该功能。
细节实现
hive on spark解析sql的过程
sql语句在分析执行过程中会经历下图所示的几个步骤
语法解析
操作绑定
优化执行策略
交付执行
语法解析之后，会形成一棵语法树，如下图所示。树中的每个节点是执行的rule,整棵树称之为执行策略。
策略优化
形成上述的执行策略树还只是第一步，因为这个执行策略可以进行优化，所谓的优化就是对树中节点进行合并或是进行顺序上的调整。
以大家熟悉的join操作为例，下图给出一个join优化的示例。a join b等同于b join a，但是顺序的调整可能给执行的性能带来极大的影响，下图就是调整前后的对比图。
在hash join中，首先被访问的表称之为“内部构建表”，第二个表为“探针输入”。创建内部表时，会将数据移动到数据仓库指向的路径；创建外部表，仅记录数据所在的路径。
再举一例，一般来说尽可能的先实施聚合操作(aggregate)然后再join
这种优化自动完成，在调优时不需要考虑。
sql到spark作业的转换过程
native command的执行流程
由于native command是一些非耗时的操作，直接使用hive中原有的exeucte engine来执行即可。这些command的执行示意图如下:
sparktask的生成和执行
我们通过一个例子来看一下一个简单的两表join查询如何被转换为sparktask并被执行。下图左半部分展示了这个查询的operator tree，以及该operator tree如何被转化成sparktask；右半部分展示了该sparktask执行时如何得到最终的rdd并通过foreachasync提交spark任务。
sparkcompiler遍历operator tree，将其划分为不同的mapwork和reducework。
mapwork为根节点，总是由tablescanoperator（hive中对表进行扫描的操作符）开始；后续的work均为reducework。reducesinkoperator（hive中进行shuffle输出的操作符）用来标记两个work之间的界线，出现reducesinkoperator表示当前work到下一个work之间的数据需要进行shuffle。因此，当我们发现reducesinkoperator时，就会创建一个新的reducework并作为当前work的子节点。包含了filesinkoperator（hive中将结果输出到文件的操作符）的work为叶子节点。
与mapreduce最大的不同在于，我们并不要求reducework一定是叶子节点，即reducework之后可以链接更多的reducework，并在同一个sparktask中执行。
从该图可以看出，这个查询的operator tree被转化成了两个mapwork和一个reducework。
执行sparktask步骤：
根据mapwork来生成最底层的hadooprdd，
将各个mapwork和reducework包装成function应用到rdd上。
在有依赖的work之间，需要显式地调用shuffle转换，具体选用哪种shuffle则要根据查询的类型来确定。另外，由于这个例子涉及多表查询，因此在shuffle之前还要对rdd进行union。
经过这一系列转换后，得到最终的rdd，并通过foreachasync提交到spark集群上进行计算。
在logicalplan到physicalplan的转换过程中，tordd最关键的元素
我们通过一个例子来看一下一个简单的两表join查询如何被转换为sparktask并被执行。下图左半部分展示了这个查询的operator tree，以及该operator tree如何被转化成sparktask;右半部分展示了该sparktask执行时如何得到最终的rdd并通过foreachasync提交spark任务。
sparkcompiler遍历operator tree，将其划分为不同的mapwork和reducework。mapwork为根节点，总是由tablescanoperator（hive中对表 进行扫描的操作符）开始；后续的work均为reducework。reducesinkoperator（hive中进行shuffle输出的操作符） 用来标记两个work之间的界线，出现reducesinkoperator表示当前work到下一个work之间的数据需要进行shuffle。因此， 当我们发现reducesinkoperator时，就会创建一个新的reducework并作为当前work的子节点。包含了 filesinkoperator（hive中将结果输出到文件的操作符）的work为叶子节点。与mapreduce最大的不同在于，我们并不要求 reducework一定是叶子节点，即reducework之后可以链接更多的reducework，并在同一个sparktask中执行。
从该图可以看出，这个查询的operator tree被转化成了两个mapwork和一个reducework。在执行sparktask时，首先根据mapwork来生成最底层的 hadooprdd，然后将各个mapwork和reducework包装成function应用到rdd上。在有依赖的work之间，需要显式地调用 shuffle转换，具体选用哪种shuffle则要根据查询的类型来确定。另外，由于这个例子涉及多表查询，因此在shuffle之前还要对rdd进行 union。经过这一系列转换后，得到最终的rdd，并通过foreachasync提交到spark集群上进行计算。
运行模式
hive on spark支持两种运行模式：本地和远程。当用户把spark master url设置为local时，采用本地模式；其余情况则采用远程模式。本地模式下，sparkcontext与客户端运行在同一个jvm中；远程模式 下，sparkcontext运行在一个独立的jvm中。提供本地模式主要是为了方便调试，一般用户不应选择该模式。因此我们这里也主要介绍远程模式 （remote sparkcontext，rsc）。下图展示了rsc的工作原理。
用户的每个session会创建一个sparkclient，sparkclient会启动remotedriver进程，并由remotedriver创 建sparkcontext。sparktask执行时，通过session提交任务，任务的主体就是对应的sparkwork。sparkclient 将任务提交给remotedriver，并返回一个sparkjobref，通过该sparkjobref，客户端可以监控任务执行进度，进行错误处理， 以及采集统计信息等。由于最终的rdd计算没有返回结果，因此客户端只需要监控执行进度而不需要处理返回值。remotedriver通过 sparklistener收集任务级别的统计数据，通过accumulator收集operator级别的统计数据（accumulator被包装为 sparkcounter），并在任务结束时返回给sparkclient。
sparkclient 与remotedriver之间通过基于netty的rpc进行通信。除了提交任务，sparkclient还提供了诸如添加jar包、获取集群信息等接 口。如果客户端需要使用更一般的sparkcontext的功能，可以自定义一个任务并通过sparkclient发送到remotedriver上执 行。
理论上来说，hive on spark对于spark集群的部署方式没有特别的要求，除了local以外，remotedriver可以连接到任意的spark集群来执行任务。在我 们的测试中，hive on spark在standalone和spark on yarn的集群上都能正常工作（需要动态添加jar包的查询在yarn-cluster模式下还不能运行，请参考hive-9425）。
优化
yarn的配置
<code>yarn.nodemanager.resource.cpu-vcores</code>和<code>yarn.nodemanager.resource.memory-mb</code>,这两个参数决定这集群资源管理器能够有多少资源用于运行yarn上的任务。 这两个参数的值是由机器的配置及同时在机器上运行的其它进程共同决定。本文假设仅有hdfs的datanode和yarn的nodemanager运行于该节点。
配置cores
基本配置是datanode和nodemanager各一个核，操作系统两个核，然后剩下28核配置作为yarn资源。也即是yarn.nodemanager.resource.cpu-vcores=28
配置内存
对于内存，预留20gb给操作系统，datanode，nodemanager，剩余100gb作为yarn资源。也即是 yarn.nodemanager.resource.memory-mb=100*1024
spark配置
假设yarn节点机器配置，假设有32核，120gb内存。
给yarn分配资源以后，那就要想着spark如何使用这些资源了，主要配置对象：
execurtor 和driver内存，executro配额，并行度。
executor内存
设置executor内存需要考虑如下因素:
executor内存越多，越能为更多的查询提供map join的优化。由于垃圾回收的压力会导致开销增加。
某些情况下hdfs的客户端不能很好的处理并发写入，所以过多的核心可能会导致竞争。
为了最大化使用core，建议将core设置为4，5，6（多核心会导致并发问题，所以写代码的时候尤其是静态的链接等要考虑并发问题）具体分配核心数要结合yarn所提供的核心数。 由于本文中涉及到的node节点是28核，那么很明显分配为4的化可以被整除，spark.executor.cores设置为4 不会有多余的核剩下,设置为5，6都会有core剩余。 spark.executor.cores=4，由于总共有28个核，那么最大可以申请的executor数是7。总内存处以7，也即是 100/7，可以得到每个executor约14gb内存。
要知道 <code>spark.executor.memory</code> 和<code>spark.executor.memoryoverhead</code>共同决定着executor内存。建议<code>spark.executor.memoryoverhead</code>站总内存的 15%-20%。 那么最终<code>spark.executor.memoryoverhead=2g</code>和<code>spark.executor.memory=12g</code>.
根据上面的配置的化，每个主机就可以申请7个executor，每个executor可以运行4个任务，每个core一个task。那么每个task的平均内存是 14/4 = 3.5gb。在executor运行的task共享内存。 其实，executor内部是用newcachedthreadpool运行task的。
确保<code>spark.executor.memoryoverhead</code>和<code>spark.executor.memory</code>的和不超过<code>yarn.scheduler.maximum-allocation-mb</code>。
driver内存
对于drvier的内存配置，当然也包括两个参数。
spark.driver.memoryoverhead 每个driver能从yarn申请的堆外内存的大小。
spark.driver.memory 当运行hive on spark的时候，每个spark driver能申请的最大jvm 堆内存。该参数结合 spark.driver.memoryoverhead共同决定着driver的内存大小。
driver的内存大小并不直接影响性能，但是也不要job的运行受限于driver的内存. 这里给出spark driver内存申请的方案，假设yarn.nodemanager.resource.memory-mb是 x。
driver内存申请12gb，假设 x > 50gb
driver内存申请 4gb，假设 12gb < x <50gb
driver内存申请1gb,假设 1gb < x < 12 gb
driver内存申请256mb，假设 x < 1gb
这些数值是<code>spark.driver.memory</code>和 <code>spark.driver.memoryoverhead</code>内存的总和。对外内存站总内存的10%-15%。 假设 <code>yarn.nodemanager.resource.memory-mb=100*1024mb</code>,那么driver内存设置为12gb，此时 <code>spark.driver.memory=10.5gb</code>和<code>spark.driver.memoryoverhead=1.5gb</code>
注意，资源多少直接对应的是数据量的大小。所以要结合资源和数据量进行适当缩减和增加。
executor数
executor的数目是由每个节点运行的executor数目和集群的节点数共同决定。如果你有四十个节点，那么hive可以使用的最大executor数就是 280(40*7). 最大数目可能比这个小点，因为driver也会消耗1core和12gb。
当前假设是没有yarn应用在跑。
hive性能与用于运行查询的executor数量直接相关。 但是，不通查询还是不通。 通常，性能与executor的数量成比例。 例如，查询使用四个executor大约需要使用两个executor的一半时间。 但是，性能在一定数量的executor中达到峰值，高于此值时，增加数量不会改善性能并且可能产生不利影响。
在大多数情况下，使用一半的集群容量（executor数量的一半）可以提供良好的性能。 为了获得最佳性能，最好使用所有可用的executor。 例如，设置spark.executor.instances = 280。 对于基准测试和性能测量，强烈建议这样做。
动态executor申请
虽然将spark.executor.instances设置为最大值通常可以最大限度地提高性能，但不建议在多个用户运行hive查询的生产环境中这样做。 避免为用户会话分配固定数量的executor，因为如果executor空闲，executor不能被其他用户查询使用。 在生产环境中，应该好好计划executor分配，以允许更多的资源共享。
spark允许您根据工作负载动态扩展分配给spark应用程序的集群资源集。 要启用动态分配，请按照动态分配中的步骤进行操作。 除了在某些情况下，强烈建议启用动态分配。
并行度
要使可用的executor得到充分利用，必须同时运行足够的任务（并行）。在大多数情况下，hive会自动确定并行度，但也可以在调优并发度方面有一些控制权。 在输入端，map任务的数量等于输入格式生成的split数。对于hive on spark，输入格式为combinehiveinputformat，它可以根据需要对基础输入格式生成的split进行分组。 可以更好地控制stage边界的并行度。调整hive.exec.reducers.bytes.per.reducer以控制每个reducer处理的数据量，hive根据可用的executor，执行程序内存，以及其他因素来确定最佳分区数。 实验表明，只要生成足够的任务来保持所有可用的executor繁忙，spark就比mapreduce对hive.exec.reducers.bytes.per.reducer指定的值敏感度低。 为获得最佳性能，请为该属性选择一个值，以便hive生成足够的任务以完全使用所有可用的executor。
hive配置
hive on spark 共享了很多hive性能相关的配置。可以像调优hive on mapreduce一样调优hive on spark。 然而，hive.auto.convert.join.noconditionaltask.size是基于统计信息将基础join转化为map join的阈值，可能会对性能产生重大影响。 尽管该配置可以用hive on mr和hive on spark，但是两者的解释不同。
数据的大小有两个统计指标:
totalsize- 数据在磁盘上的近似大小
rawdatasize- 数据在内存中的近似大小
hive on mr用的是totalsize。hive on spark使用的是rawdatasize。由于可能存在压缩和序列化，这两个值会有较大的差别。 对于hive on spark 需要将 <code>hive.auto.convert.join.noconditionaltask.size</code>指定为更大的值，才能将与hive on mr相同的join转化为map join。
可以增加此参数的值，以使地图连接转换更具凶猛。 将common join 转换为 map join 可以提高性能。 如果此值设置得太大，则来自小表的数据将使用过多内存，任务可能会因内存不足而失败。 根据群集环境调整此值。
通过参数 <code>hive.stats.collect.rawdatasize</code> 可以控制是否收集 rawdatasize 统计信息。
对于hiveserver2，建议再配置两个额外的参数: <code>hive.stats.fetch.column.stats=true</code> 和 <code>hive.optimize.index.filter=true</code>.
hive性能调优通常建议使用以下属性:
预启动yarn容器
在开始新会话后提交第一个查询时，在查看查询开始之前可能会遇到稍长的延迟。还会注意到，如果再次运行相同的查询，它的完成速度比第一个快得多。
spark执行程序需要额外的时间来启动和初始化yarn上的spark，这会导致较长的延迟。此外，spark不会等待所有executor在启动作业之前全部启动完成，因此在将作业提交到群集后，某些executor可能仍在启动。 但是，对于在spark上运行的作业，作业提交时可用executor的数量部分决定了reducer的数量。当就绪executor的数量未达到最大值时，作业可能没有最大并行度。这可能会进一步影响第一个查询的性能。
在用户较长期会话中，这个额外时间不会导致任何问题，因为它只在第一次查询执行时发生。然而，诸如oozie发起的hive工作之类的短期绘画可能无法实现最佳性能。
为减少启动时间，可以在作业开始前启用容器预热。只有在请求的executor准备就绪时，作业才会开始运行。这样，在reduce那一侧不会减少短会话的并行性。
要启用预热功能，请在发出查询之前将hive.prewarm.enabled设置为true。还可以通过设置hive.prewarm.numcontainers来设置容器数量。默认值为10。
预热的executor的实际数量受spark.executor.instances（静态分配）或spark.dynamicallocation.maxexecutors（动态分配）的值限制。 hive.prewarm.numcontainers的值不应超过分配给用户会话的值。
注意：预热需要几秒钟，对于短会话来说是一个很好的做法，特别是如果查询涉及reduce阶段。 但是，如果hive.prewarm.numcontainers的值高于群集中可用的值，则该过程最多可能需要30秒。请谨慎使用预热。