hive—1.1、执行优化

文档目录

问题1：hive的MapReduce相比于传统关系型数据库为什么慢？
问题2：MapReduce过程中如何确定进行了什么执行计划？
问题3：MapReduce中map和reduce任务数量由什么决定？
- map任务数量

问题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、谓词下推

bash 复制代码

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：关联方式

关联策略	Map阶段是否有独立任务	关键特征	适用场景
Common Join	是	有Reduce阶段，涉及Shuffle	两个大表关联
Map Join	否 (只有大表有)	无Reduce阶段，小表被广播	一大一小表关联
SMB Join (Sort Merge Bucket Join)	否	基于分桶表的优化，Map端直接关联	两个分桶且桶数成倍数的表

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 ==========================================