Hive介绍

1.Hadoop开发存在的问题

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

2.Hive概述

Hive是基于Hadoop的一个数据仓库工具。可以将结构化的数据文件映射为一张’数据库表’，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取、转化、加载（ETL Extract-Transform-Load ），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HiveQL，它允许熟悉 SQL 的用户查询数据。

3.Hive的Hql

HQL - Hive通过类SQL的语法，来进行分布式的计算。HQL用起来和SQL非常的类似，Hive在执行的过程中会将HQL转换为MapReduce去执行，所以Hive其实是基于Hadoop的一种分布式计算框架，底层仍然是MapReduce，所以它本质上还是一种离线大数据分析工具。

4.数据库和数据仓库的对比

1.数据库面向事务处理，数据仓库是面向主题设计的。
数据仓库里存储的数据都是对决策或数据分析（挖掘）有用的数据。客户数据、利润数据等
2.数据库存储的日常操作数据或者实时的在线数据，数据仓库存储的一般是历史数据。
3.数据仓库的数据一般都隐式或显式的包含时间维度。
4.数据仓库是弱事务的（或根本就没有事务），大多数业务都是读，分析等业务。
5.数据仓库里的数据一般是来自于多个异构数据源，比如有数据库的数据，文件数据，网络数据，空间数据，媒体数据等，然后通过一定的技术进行ETL。
6.数据库存储数据量较小，数据仓库较大
7.数据库存储格式化数据，数据仓库存各种格式

5.适用场景

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

6.Hive的优化

6.1.map side join

1.mapJoin的主要意思就是，当连接的两个表是一个比较小的表和一个特别大的表的时候，可以把比较小的table直接放到内存中去，然后再对比较大的表格进行map操作，此时join就发生在map操作的时候，每当扫描一个大的table中的数据，就要去去查看小表的数据，哪条与之相符，继而进行连接。这里的join并不会涉及reduce操作。map端join的优势就是在于没有shuffle，在实际的应用中，设置方式：set hive.auto.convert.join=true;
2.hive有一个参数：hive.mapjoin.smalltable.filesize，默认值是25mb（其中一个表大小小于25mb时，自动启用mapjoin）
3.要求：在hive做join时，要求小表在前(左）

6.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
减少笛卡尔积的数量

6.3.group by 优化

调优参数:set hive.groupby.skewindata=true;
任务分为两次MR任务，第一次对key标记，第二次回归正常
数据倾斜时负载均衡，当选项设定为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已经有了很大的改善，因此基本解决数据倾斜

6.4.count distinct 优化

优化前：select count(distinct id )from tablename
优化后：select count(*) from (select distinct id from tablename)tmp;
分析：

优化前
1.由于对id引入了distinct操作，所以在Map阶段无法利用combine对输出结果去消重，必须将id作为key输出
2.在reduce阶段再对来自于不同的MapTask的结果进行消重，计入最终统计值
3.由于ReduceTask的数量默认为1，所以导致MapTask的所有结果都只能由这一个ReduceTask处理，这就使得ReduceTask的执行效率成为整个任务的瓶颈
4.虽然在使用hive的时候可以通过set mapred.reduce.tasks设置ReduceTask的数量，但是Hive在处理COUNT这种“全聚合(full aggregates)”计算时，它会忽略用户指定的Reduce Task数，而强制使用1

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

6.5.调整切片数（map任务数）

1.Hive底层自动对小文件做了优化，用了CombineTextInputFormat，将多个小文件切片合成一个切片。如果合成完之后的切片大小>mapred.max.split.size 的大小，就会生成一个新的切片
2.mapred.max.split.size 默认是128MB，设置方式为：set mapred.max.split.size=134217728（128MB)
3.对于切片数（MapTask）数量的调整，要根据实际业务来定，比如一个100MB的文件包含了有1千万条数据，此时可以调成10个MapTask，则每个MapTask处理1百万条数据。

6.6.JVM重利用

1.设置方式：set mapred.job.reuse.jvm.num.tasks=20(默认是1个）
2.JVM重用是hadoop调优参数的内容，对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成千上万个task任务的情况
3.JVM重用可以使得一个JVM进程在同一个JOB中重新使用N次后才会销毁。

6.7.启用严格模式

1.用户可以通过 set hive.mapred.mode=strict 来设置严格模式，改成unstrict则为非严格模式
2.在严格模式下，用户在运行query的时候：
（1）分区表的查询必须使用分区字段来限制
（2）使用了order by 必须使用limit语句（如果不使用limit，会对查询结果进行全局排序，消耗时间长）
（3）不能产生了笛卡尔积

6.8.关闭推测执行机制

通常在测试环境下数据量较大，如果还加上推测执行，那么在数据分片本来就会发生数据倾斜，执行时间就是比其他的时间长，那么hive就会把这个执行时间长的job当作运行失败，继而又产生一个相同的job去运行，造成资源的浪费。可通过如下设置关闭推测执行：
set mapreduce.map.speculative=false
set mapreduce.reduce.speculative=false
set hive.mapred.reduce.tasks.speculative.execution=false

7.Hive特点

针对海量数据的高性能查询和分析系统
由于 Hive 的查询是通过 MapReduce 框架实现的，而 MapReduce 本身就是为实现针对海量数据的高性能处理而设计的。所以 Hive 天然就能高效的处理海量数据。
与此同时，Hive 针对 HiveQL 到 MapReduce的翻译进行了大量的优化，从而保证了生成的MapReduce 任务是高效的。在实际应用中，Hive 可以高效的对 TB 甚至 PB级的数据进行处理。

类SQL的查询语言
HiveQL 和 SQL 非常类似，所以一个熟悉SQL 的用户基本不需要培训就可以非常容易的使用 Hive 进行很复杂的查询。

HiveQL 灵活的可扩展性(Extendibility)
除了 HiveQL 自身提供的能力，用户还可以自定义其使用的数据类型、也可以用任何语言自定义 mapper 和 reducer 脚本，还可以自定义函数(普通函数、聚集函数)等。这就赋予了 HiveQL 极大的可扩展性。用户可以利用这种可扩展性实现非常复杂的查询。

高扩展性(Scalability)和容错性
Hive本身并没有执行机制，用户查询的执行是通过 MapReduce 框架实现的。由于MapReduce 框架本身具有高度可扩展(计算能力随 Hadoop 机群中机器的数量增加而线性增加)和高容错的特点，所以 Hive也相应具有这些特点。

与 Hadoop 其他产品完全兼容
Hive 自身并不存储用户数据，而是通过接口访问用户数据。这就使得 Hive支持各种数据源和数据格式。例如，它支持处理 HDFS 上的多种文件格式(TextFile、SequenceFile 等)，还支持处理 HBase 数据库。用户也完全可以实现自己的驱动来增加新的数据源和数据格式。一种理想的应用模型是将数据存储在 HBase 中实现实时访问，而用Hive对HBase 中的数据进行批量分析。