HIVE-初识（hive入门）

什么是HiveHive是建立在Hadoop上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载，可以简称为ETL。Hive 定义了简单的类SQL查询语言，称为HQL，它允许熟悉SQL的用户直接查询Hadoop中的数据，同时，这个语言也允许熟悉MapReduce的开发者开发自定义的mapreduce任务来处理内建的SQL函数无法完成的复杂的分析任务。Hive中包含的有SQL解析引擎，它会将SQL语句转译成M/R Job,然后在Hadoop中执行。通过这里的分析我们可以了解到Hive可以通过sql查询Hadoop中的数据，并且sql底层也会转化成mapreduce任务，所以hive是基于hadoop的。

Hive的数据存储

Hive的数据存储基于Hadoop的 HDFSHive没有专门的数据存储格式Hive默认可以直接加载文本文件（TextFile），还支持SequenceFile、RCFile等文件格式针对普通文本数据，我们在创建表时，只需要指定数据的列分隔符与行分隔符，Hive即可解析里面的数据Hive的系统架构下面我们来分析一下Hive的系统架构看这个图

下面表示是Hadoop集群，上面是Hive，从这也可以看出来Hive是基于Hadoop的。看右边的几个概念的解释用户接口，包括 CLI、JDBC/ODBC、WebGUICLI，即Shell命令行，表示我们可以通过shell命令行操作HiveJDBC/ODBC 是 Hive 的Java操作方式，与使用传统数据库JDBC的方式类似

元数据存储(Metastore)

注意：这里的存储是名词，Metastore表示是一个存储系统Hive中的元数据包括表的相关信息，Hive会将这些元数据存储在Metastore中，目前Metastore只支持 mysql、derby。Driver：包含：编译器、优化器、执行器编译器、优化器、执行器可以完成 Hive的查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划最终存储在 HDFS 中，并在随后由 MapReduce 调用执行Hadoop：Hive会使用 HDFS 进行存储，利用 MapReduce 进行计算Hive 的数据存储在 HDFS 中，大部分的查询由 MapReduce 完成（特例 select * from table 不会生成 MapRedcue 任务，如果在SQL语句后面再增加where过滤条件就会生成MapReduce任务了。）在这有一点需要注意的，就是从Hive2开始，其实官方就不建议默认使用MapReduce引擎了，而是建议使用Tez引擎或者是Spark引擎，不过目前一直到最新的3.x版本中mapreduce还是默认的执行引擎其实大数据计算引擎是有几个发展阶段的

首先是第一代大数据计算引擎：MapReduce

第二代大数据计算引擎：Tez，Tez的存在感比较低，它是源于MapReduce，主要和Hive结合在一起使用，它的核心思想是将Map和Reduce两个操作进一步拆分，这些分解后的元操作可以灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可以形成一个大的作业，这样可以提高计算效率，我们在实际工作中Hive使用的就是 Tez引擎，替换Hive的执行引擎也很简单，只需要把Tez安装好（Tez也是支持在YARN上执行的），然后到Hive中配置一下就可以了，不管使用什么引擎，不会对我们使用hive造成什么影响，也就说对上层的使用没有影响接着是第三代大数据计算引擎：

Spark，Spark在当时属于一个划时代的产品，改变了之前基于磁盘的计算思路，而是采用内存计算，就是说Spark把数据读取过来以后，中间的计算结果是不会进磁盘的，一直到出来最终结果，才会写磁盘，这样就大大提高了计算效率，而MapReduce的中间结果是会写磁盘的，所以效率没有Spark高。Spark的执行效率号称比MapReduce 快100倍，当然这需要在一定数据规模下才会差这么多，如果我们就计算几十兆或者几百兆的文件，你去对比发现其实也不会差多少，后面我们也会学到Spark这个基于内存的大数据计算引擎注意：spark也是支持在YARN上执行的其实目前还有第四代大数据计算引擎，

Flink，Flink是一个可以支持纯实时数据计算的计算引擎，在实时计算领域要优于Saprk，Flink和Spark其实是有很多相似之处，在某些方面他们两个属于互相参考，互相借鉴，互相成长，Flink后面我们也会学到，等后面我们讲到这个计算引擎的时候再详细分析。注意：Flink也是支持在YARN上执行的。所以发现没有，MapReduce、Tez、Spark、Flink这些计算引擎都是支持在yarn上执行的，所以说Hdoop2中对架构的拆分是非常明智的。解释完这些名词之后其实我们就对这个架构有了一个基本理解，再看来这个图用户通过接口传递Hive SQL，然后经过Driver对SQL进行分析、编译，生成查询计划，查询计划会存储在HDFS中，然后再通过MapReduce进行计算出结果，这就是整个大的流程。其实在这里我们可以发现，Hive这个哥们是既不存储数据，也不计算数据，这些活都给了Hadoop来干，Hive底层最核心的东西其实就是Driver这一块，将SQL语句解析为最终的查询计划。Metastore接着来看一下Hive中的元数据存储，MetastoreMetastore是Hive元数据的集中存放地。Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在的hdfs目录等Metastore默认使用内嵌的derby数据库Derby数据库的缺点：在同一个目录下一次只能打开一个会话使用derby存储方式时，Hive会在当前目录生成一个derby.log文件和一个metastore_db目录，metastore_db里面会存储具体的元数据信息如果下次切换到一个另一个新目录访问Hive，则会重新生成derby.log文件和metastore_db目录

没有办法使用之前的元数据信息了。推荐使用MySQL作为外置存储引擎，可以支持多用户同时访问以及元数据共享