Hive的概述、流程和优化

Hive简介

一、Hadoop开发存在的问题

1. 只能用java语言开发，如果是c语言或其他语言的程序员用Hadoop，存在语言门槛
2. 需要对Hadoop底层原理，api比较了解才能做开发
3. 开发调试比较麻烦

二、Hive概述

1. Hive是基于Hadoop的一个数据仓库工具。可以将结构化的数据文件映射为一张表，并提供完整的sql查询功能
2. 底层是将sql语句转换为MapReduce任务进行运行
3. Hive提供了一系列的工具，可以用来进行数据提取、转化、加载（ETL Extract-Transform-Load ），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制
4. 本质上是一种大数据离线分析工具

三、Hive的HQL

1. HQL - Hive通过类SQL的语法，来进行分布式的计算
2. HQL用起来和SQL非常的类似，Hive在执行的过程中会将HQL转换为MapReduce去执行，所以Hive其实是基于Hadoop的一种分布式计算框架，底层仍然是MapReduce

四、特点

1. 优点：
   a. 学习成本低，只要会sql就能用hive
   b. 开发效率高，不需要编程，只需要写sql
   c. 模型简单，易于理解
   d. 针对海量数据的高性能查询和分析
   e. HiveQL 灵活的可扩展性(Extendibility)
   f. 高扩展性(Scalability)和容错性
   g. 与 Hadoop 其他产品完全兼容
2. 缺点：
   a. 不支持行级别的增删改
   b. 不支持完整的在线事务处理
   c. 本质上仍然是MR的执行，效率不算高

五、适用场景

1. Hive 构建在基于静态（离线）批处理的Hadoop 之上，Hadoop 通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。因此，Hive 并不能够在大规模数据集上实现低延迟快速的查询因此，Hive 并不适合那些需要低延迟的应用
2. Hive 并不提供实时的查询和基于行级的数据更新操作。Hive 的最佳使用场合是大数据集的离线批处理作业，例如，网络日志分析。

数据库和数据仓库
一、数据仓库和数据库对比
二、OLTP和OLAP对比

1. 数据库属于OLTP系统（Online Transaction Processing）联机事务处理系统。涵盖了企业大部分的日常操作，如购物、库存、制造、银行、工资、注册、记账等。比如Mysql，oracle等关系型数据库；数据仓库属于OLAP系统。（Online Analytical Processing）联机分析处理系统。Hive，Hbase等
2. OLTP是面向用户的、用于程序员的事务处理以及客户的查询处理；OLAP是面向市场的，用于知识工人（经理、主管和数据分析人员）的数据分析
3. OLAP通常会集成多个异构数据源的数据，数量巨大；OLTP系统的访问由于要保证原子性，所以有事务机制和恢复机制
4. OLAP系统一般存储的是历史数据，所以大部分都是只读操作，不需要事务；OLTP系统具有较强的事务
   
   
   体系结构
   1. 用户接口主要有三个：CLI，JDBC 和 WUI
   a. CLI，最常用的模式。实际上在>hive 命令行下操作时，就是利用CLI用户接口
   b. JDBC，通过java代码操作，需要启动hiveserver，然后连接操作
5. Metastore
   Hive将元数据存储在数据库中，如mysql、derby。Hive中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等
6. 解释器（complier)、优化器(optimizer)、执行器(executor)组件
   这三个组件用于：HQL语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在HDFS中，并在随后有MapReduce调用执行
7. Hadoop
   Hive的数据存储在HDFS中，大部分的查询、计算由MapReduce完成

流程
1. 通过客户端提交一条Hql语句
2. 通过complier（编译组件）对Hql进行词法分析、语法分析。在这一步，编译器要知道此hql语句到底要操作哪张表
3. 去元数据库找表信息
4. 得到信息
5. complier编译器提交Hql语句分析方案
6. 执行流程
a. executor 执行器收到方案后，执行方案（DDL过程）。在这里注意，执行器在执行方案时，会进行判断：如果当前方案不涉及到MR组件，比如为表添加分区信息、比如字符串操作等，比如简单的查询操作等，此时就会直接和元数据库交互，然后去HDFS上去找具体数据；如果方案需要转换成MR job，则会将job 提交给Hadoop的JobTracker
b. MR job完成，并且将运行结果写入到HDFS上
c. 执行器和HDFS交互，获取结果文件信息
7. 如果客户端提交Hql语句是带有查询结果性的，则会发生：7-8-9步，完成结果的查询。

优化

1. map side join
   a. mapJoin的主要意思就是，当连接的两个表是一个比较小的表和一个特别大的表的时候，可以把比较小的table直接放到内存中去，然后再对比较大的表格进行map操作，此时join就发生在map操作的时候，每当扫描一个大的table中的数据，就要去去查看小表的数据，哪条与之相符，继而进行连接。这里的join并不会涉及reduce操作。map端join的优势就是在于没有shuffle，在实际的应用中，设置方式：set hive.auto.convert.join=true;
   b. hive有一个参数：hive.mapjoin.smalltable.filesize，默认值是25mb（其中一个表大小小于25mb时，自动启用mapjoin）
   c. 要求：在hive做join时，要求小表在前(左）
2. join语句优化
   优化前：select m.cid,u.id from order m join customer u on m.cid=u.id where m.dt=’20160801’;
   优化后：select m.cid,u.id from (select cid from order where dt=’20160801’)m join customer u on m.cid = u.id
3. group by 优化
   调优参数:set hive.groupby.skewindata=true;
   数据倾斜时负载均衡，当选项设定为true，生成的查询计划会有两个MRJob。第一个MRJob 中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中（这个过程可以保证相同的GroupBy Key被分布到同一个Reduce中），最后完成最终的聚合操作
   由上面可以看出起到至关重要的作用的其实是第二个参数的设置，它使计算变成了两个mapreduce，先在第一个中在 shuffle 过程 partition 时随机给 key 打标记，使每个key 随机均匀分布到各个 reduce 上计算，但是这样只能完成部分计算，因为相同key没有分配到相同reduce上，所以需要第二次的mapreduce,这次就回归正常 shuffle,但是数据分布不均匀的问题在第一次mapreduce已经有了很大的改善，因此基本解决数据倾斜
4. count distinct 优化
   优化前：select count(distinct id )from tablename
   优化后：select count(*) from (select distinct id from tablename)tmp;
   分析：
   a. 优化前
   i. 由于对id=引入了distinct操作，所以在Map阶段无法利用combine对输出结果去消重，必须将id作为key输出
   ii. 在reduce阶段再对来自于不同的MapTask的结果进行消重，计入最终统计值
   iii. 由于ReduceTask的数量默认为1，所以导致MapTask的所有结果都只能由这一个ReduceTask处理，这就使得ReduceTask的执行效率成为整个任务的瓶颈
   iv. 虽然在使用hive的时候可以通过set mapred.reduce.tasks设置ReduceTask的数量，但是Hive在处理COUNT这种“全聚合(full aggregates)”计算时，它会忽略用户指定的Reduce Task数，而强制使用1
   

b. 优化后：
i. 利用Hive对嵌套语句的支持，将原来一个MapReduce作业转换为两个作业：在第一阶段选出全部的非重复id，在第二阶段再对这些已消重的id进行计数
ii. 在第一阶段我们可以通过增大Reduce的并发数，并发处理Map输出
iii. 在第二阶段，由于id已经消重，因此COUNT(*)操作在Map阶段不需要输出原id数据，只输出一个合并后的计数即可。这样即使第二阶段Hive强制指定一个Reduce Task，极少量的Map输出数据也不会使单一的Reduce Task成为瓶颈
iv. 这一优化使得在同样的运行环境下，优化后的语句执行只需要原语句20%左右的时间

e. 调整切片数（map任务数）
i. Hive底层自动对小文件做了优化，用了CombineTextInputFormat，将做个小文件切片合成一个切片。如果合成完之后的切片大小>mapred.max.split.size 的大小，就会生成一个新的切片
ii. mapred.max.split.size 默认是128MB，设置方式为：set mapred.max.split.size=134217728（128MB)
iii. 对于切片数（MapTask）数量的调整，要根据实际业务来定，比如一个100MB的文件包含了有1千万条数据，此时可以调成10个MapTask，则每个MapTask处理1百万条数据。
f. JVM重利用
i. 设置方式：set mapred.job.reuse.jvm.num.tasks=20(默认是1个）
ii. JVM重用是hadoop调优参数的内容，对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成千上万个task任务的情况
iii. JVM重用可以使得一个JVM进程在同一个JOB中重新使用N次后才会销毁。
g. 启用严格模式
i. 用户可以通过 set hive.mapred.mode=strict 来设置严格模式，改成unstrict则为非严格模式
ii. 在严格模式下，用户在运行如下query的时候会报错：
i. 分区表的查询没有使用分区字段来限制
ii. 使用了order by 但没有使用limit语句（如果不使用limit，会对查询结果进行全局排序，消耗时间长）
iii. 产生了笛卡尔积
h. 关闭推测执行机制
通常在测试环境下机会确定应用程序是否跑通，如果还加上推测执行，那么在数据分片本来就会发生数据倾斜，执行执行时间就是比其他的时间长，那么hive就会把这个执行时间长的job当作运行失败，继而又产生一个相同的job去运行，造成资源的浪费。可通过如下设置关闭推测执行：
set mapreduce.map.speculative=false
set mapreduce.reduce.speculative=false
set hive.mapred.reduce.tasks.speculative.execution=false