hive—1.1、执行优化

问题1：hive的MapReduce相比于传统关系型数据库为什么慢？

解答：该问题和多个多个层面相关，具体如下：

A：设计目的

B：硬件性能，一般传统关系型数据库考虑到延迟问题，基本会选择高配的 SSD盘来提升查询效率；而Hadoop因为存储海量数据考虑到成本问题，磁盘类型会选择机械盘；在硬件IO读写上会有一定的差异；

C：计算模型
传统关系型数据库为管道式，一个阶段的输出结果会立刻作为下一个阶段的输入继续迭代计算，计算的过程主要依赖内存进行；
hive为阶段式+中间落盘：
致命点：每一个MapReduce任务的输出结果都必须写入磁盘，作为下一个Stage的输入。这意味着大量的、昂贵的磁盘I/O操作。

D：启动开销
传统关系型数据库，都有常驻进程，执行查询时，客户端发送SQL过来，服务端直接使用已经分配好的内存和线程资源开始计算，启动开销忽略不计。
hive启动：用户提交一个Hive查询，系统需要先将其翻译成多个MR任务。
每个MR任务都需要向资源管理器（如Yarn）申请资源，启动Application Master，然后拉起多个Container（JVM进程）来运行Map Task和Reduce Task，这个过程本身就需要几秒甚至十几秒的时间。

E：数据本地性与网络开销
关系型：一般架构设计为存算一体
hive中：在shuffle（混洗）阶段，会存在数据跨节点移动的问题；

F：数据索引与精确裁剪 vs. 全量扫描
传统关系型数据库可以依赖完善的索引功能，直接过滤和定位数据；
hive中即使按照谓词下推来实现了map阶段的数据过滤，因为没有索引也是全表扫描；

Hive 中一张表的数据是按行分散到不同节点的，但每一行自身是完整存储在一个节点上的。

问题2：MapReduce过程中如何确定进行了什么执行计划？

解答：
通过explain sql定位，分别如下：

A、谓词下推

TableScan └── Filter Operator └── predicate:(sbuuid='asdfasdfasd')└── Select Operator └── ListSink

说明：
1）过滤操作紧跟在TableScan之后

Filter Operator直接作为TableScan的子节点，这意味着在读取数据后，立即执行了过滤条件(sbuuid = ‘asdfasdfasd’)

2）没有额外的Stage
整个查询只有一个Stage（Stage-0），说明没有复杂的中间过程，过滤在Map阶段就完成；

3）过滤条件predicate: (sbuuid = ‘asdfasdfasd’)出现在数据扫描阶段
这正是谓词下推的核心特征：在数据读取时就进行过滤；

B：关联方式

C：预先聚合

hive的预先聚合官方术语叫 Map端聚合 或 局部聚合，是指 在 Map 阶段先做一次部分聚合，减少发往 Reduce 的数据量。

涉及的参数：SET hive.map.aggr=false;

如何判断有预先聚合操作？
有预先聚合的标志？两个 Group By，Map端 mode=hash，Reduce端 mode=mergepartial

问题3：MapReduce中map和reduce任务数量由什么决定？

解答：
1）由配置参数
2）资源情况
3）输入数据量
多个因素共同决定；

map任务数量

有如下确定规则：
1）一个数据文件确定对应一个map任务；当数据表有很多小文件时，就需要启动很多map任务；
2）按照数据量存储大小/数据块 = map 任务数量

========================================= over ==========================================