hive—1.1、执行优化

文档目录问题1hive的MapReduce相比于传统关系型数据库为什么慢问题2MapReduce过程中如何确定进行了什么执行计划A、谓词下推B关联方式C预先聚合问题3MapReduce中map和reduce任务数量由什么决定map任务数量问题1hive的MapReduce相比于传统关系型数据库为什么慢解答该问题和多个多个层面相关具体如下A设计目的B硬件性能一般传统关系型数据库考虑到延迟问题基本会选择高配的 SSD盘来提升查询效率而Hadoop因为存储海量数据考虑到成本问题磁盘类型会选择机械盘在硬件IO读写上会有一定的差异C计算模型传统关系型数据库为管道式一个阶段的输出结果会立刻作为下一个阶段的输入继续迭代计算计算的过程主要依赖内存进行hive为阶段式中间落盘致命点每一个MapReduce任务的输出结果都必须写入磁盘作为下一个Stage的输入。这意味着大量的、昂贵的磁盘I/O操作。D启动开销传统关系型数据库都有常驻进程执行查询时客户端发送SQL过来服务端直接使用已经分配好的内存和线程资源开始计算启动开销忽略不计。hive启动用户提交一个Hive查询系统需要先将其翻译成多个MR任务。每个MR任务都需要向资源管理器如Yarn申请资源启动Application Master然后拉起多个ContainerJVM进程来运行Map Task和Reduce Task这个过程本身就需要几秒甚至十几秒的时间。E数据本地性与网络开销关系型一般架构设计为存算一体hive中在shuffle混洗阶段会存在数据跨节点移动的问题F数据索引与精确裁剪 vs. 全量扫描传统关系型数据库可以依赖完善的索引功能直接过滤和定位数据hive中即使按照谓词下推来实现了map阶段的数据过滤因为没有索引也是全表扫描Hive 中一张表的数据是按行分散到不同节点的但每一行自身是完整存储在一个节点上的。问题2MapReduce过程中如何确定进行了什么执行计划解答通过explain sql定位分别如下A、谓词下推TableScan └── Filter Operator └── predicate:(sbuuidasdfasdfasd)└── Select Operator └── ListSink说明1过滤操作紧跟在TableScan之后Filter Operator直接作为TableScan的子节点这意味着在读取数据后立即执行了过滤条件(sbuuid ‘asdfasdfasd’)2没有额外的Stage整个查询只有一个StageStage-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.aggrfalse;如何判断有预先聚合操作有预先聚合的标志两个 Group ByMap端 modehashReduce端 modemergepartial问题3MapReduce中map和reduce任务数量由什么决定解答1由配置参数2资源情况3输入数据量多个因素共同决定map任务数量有如下确定规则1一个数据文件确定对应一个map任务当数据表有很多小文件时就需要启动很多map任务2按照数据量存储大小/数据块 map 任务数量 over