互联网大数据框架介绍（二）Hive，HBase

继续上一节的hadoop，HDFS，yarn，MapReduce。这节继续想下讲，将数据仓库Hive，和大数据的数据库HBase

Hive

首先，我们要明确什么是Hive，Hive是构建于Hadoop的HDFS和MapReduce上，的用于管理和查询结构化/非结构化数据的数据仓库。

Hive分别有三个部分组成：

1）使用HQL作为查询接口

2）使用HDFS作为底层存储

3）使用MapReduce作为执行层

现在，通俗一些说，Hive之所以产生。是因为使用MapReduce做过数据分析的人都知道，很多分析程序除业务逻辑不同外，程序流程基本一样。在这种情况下，就需要hive这样的用戶编程接口。所以Hive的意义其实是为了简化编写MapReduce程序而生的。

而且，需要注意的是，hive中的所有查询除了”select * from table;”其他语句都是需要通过Map\Reduce的方式来执行的。由于要走Map\Reduce的过程，即使一个只有1行1列的表，如果不是通过select * from table;方式来查询的，可能也需要8、9秒。但hive比较擅长处理大量数据。当要处理的数据很多，并且Hadoop集群有足够的规模，这时就能体现出它的优势。所以Hive与正常SQL的区别就如下图：

【转】：那么，hive是什么？

白话一点再加不严格一点，hive可以认为是map-reduce的一个包装。hive的意义就是把好写的hive的sql转换为复杂难写的map-reduce程序。

所以说Hive和SQL除了写入的语句像之外，其他的都一点儿相同点的没有。

具体的Hive实现如上图所示：

Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑，就是些表的定义等，也就是表的元数据（metastore中存储）。使用SQL实现Hive是因为SQL大家都熟悉，转换成本低，类似作用的Pig就不是SQL。hive支持mysql、oracle等任何支持JDBC（Java DataBase Connecter）连接方式的数据库来存储元数据，需要修改相应的配置项。使用JDBC连接数据库做Metastore，并通过JDBC来访问Hive，所以说现在也就明白了为什么要用SQL语言了。当然了，在Hive中不叫SQL语言，叫做HQL(Hive Query Language)，毕竟不是完全的结构化数据，Hive还要处理非结构化数据，说以叫做HQL，HQL支持select、union all、join（left、right、mapjoin）like、where、各种聚合函数、支持json解析，并不能完全支持SQL。

Hive的基本架构

上图可以很好的解释Hive的整个结构，这里的ETL（ Extract-Transform-Load ）过程，通俗些，就是将数据库寻出成map/reduce可操作的格式，如TEXT或CSV，再put到HDFS中，也就是将好写的hive的sql转换为复杂难写的map-reduce程序的核心部分。

介绍完Hive下边将Hive进行以下简单的总结：

1、hive是sql语言，通过数据库的方式来操作hdfs文件系统，为了简化编程，底层计算方式为mapreduce。

2、hive是面向行存储的数据库。 hive其实就是一个分布式的关系型数据库，因为底层是基于MapReduce的，所以更有利于分析数据，因此将其称为一个数据仓库。

3、Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。

4、Hive的用途主要是利用在报表方面。

附：下面大括号里的一段是用来讲解数据库与数据仓库的区别，如果懂就可以略过：

【

数据仓库又是什么，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。举个简单的例子：数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。官方一些的解释他们的却别： 
数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。
数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。
（1） 面向主题：指数据仓库中的数据是按照一定的主题域进行组织。
（2）集成：指对原有分散的数据库数据经过系统加工, 整理得到的消除源数据中的不一致性。
（3）相对稳定：指一旦某个数据进入数据仓库以后只需要定期的加载、刷新。
（4）反映历史变化：指通过这些信息，对企业的发展历程和未来趋势做出定量分析预测。
主要区别在于：
（1）数据库是面向事务的设计，数据仓库是面向主题设计的。
（2）数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
（3）数据库设计是尽量避免冗余，数据仓库在设计是有意引入冗余。
（4）数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
           

】

Hbase（Hadoop DataBase）

介绍完Hive， 如果简单的说Hive是将MapReduce进行了一层封装，那么Hbase就是将HDFS进行了一层封装。他的本质是数据存储，是个NoSql（Not Only SQL非关系型数据库）数据库；hbase部署于hdfs之上，并且克服了hdfs在随机读写方面的缺点。 从他的命名也可以看出，他是Hadoop的一个数据库。

所以，Hbase的定义为一个分布式的基于列存储的非关系型数据库，HBase是为查询而生的，它通过组织起节点內所有机器的內存，提供一個超大的內存Hash表 。并且因为他是部署于hdfs之上，所以区别于Hive，HBase的本质是数据存储。

上图就是整个大数据处理的过程，即可以看出Hbase和Hive之间的关系，当然Hive也可以直接作用于HDFS上。

HBase的基本架构

Hbase的基本架构如下图，他主要由Zookeeper 、HMaster、HRegionServer这三部分构成，使用Zookeeper管理集群，使用HDFS作为底层存储。在架构层面上由HMaster（Zookeeper选举产生的Leader）和多个HRegionServer组成，下面详细介绍各个部分的作用，已经HBase的运作流程。

以下内容转自http://www.linuxidc.com/Linux/2016-08/134185.htm：

【Client：使用HBase的RPC机制与HMaster和HRegionServer进行通信，提交请求和获取结果。对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC。

Zookeeper：通过将集群各节点状态信息注册到Zookeeper中，使得HMaster可随时感知各个HRegionServer的健康状态，而且也能避免HMaster的单点问题。

HMaster：管理所有的HRegionServer，告诉其需要维护哪些HRegion，并监控所有HRegionServer的运行状态。当一个新的HRegionServer登录到HMaster时，HMaster会告诉它等待分配数据；而当某个HRegion死机时，HMaster会把它负责的所有HRegion标记为未分配，然后再把它们分配到其他HRegionServer中。HMaster没有单点问题，HBase可以启动多个HMaster，通过Zookeeper的选举机制保证集群中总有一个HMaster运行，从而提高了集群的可用性。

HRegion：当表的大小超过预设值的时候，HBase会自动将表划分为不同的区域，每个区域包含表中所有行的一个子集。对用户来说，每个表是一堆数据的集合，靠主键（RowKey）来区分。从物理上来说，一张表被拆分成了多块，每一块就是一个HRegion。我们用表名+开始/结束主键，来区分每一个HRegion，一个HRegion会保存一个表中某段连续的数据，一张完整的表数据是保存在多个HRegion中的。

HRegionServer：HBase中的所有数据从底层来说一般都是保存在HDFS中的，用户通过一系列HRegionServer获取这些数据。集群一个节点上一般只运行一个HRegionServer，且每一个区段的HRegion只会被一个HRegionServer维护。HRegionServer主要负责响应用户I/O请求，向HDFS文件系统读写数据，是HBase中最核心的模块。HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了逻辑表中的一个连续数据段。HRegion由多个HStore组成，每个HStore对应了逻辑表中的一个列族的存储，可以看出每个列族其实就是一个集中的存储单元。因此，为了提高操作效率，最好将具备共同I/O特性的列放在一个列族中。

HStore：它是HBase存储的核心，由MemStore和StoreFiles两部分组成。MemStore是内存缓冲区，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile的文件数量增长到一定阈值后，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除操作。因此，可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这样使得用户的写操作只要进入内存就可以立即返回，保证了HBaseI/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前的HRegion Split成2个HRegion，父HRegion会下线，新分出的2个子HRegion会被HMaster分配到相应的HRegionServer，使得原先1个HRegion的负载压力分流到2个HRegion上。

HLog：每个HRegionServer中都有一个HLog对象，它是一个实现了Write Ahead Log的预写日志类。在每次用户操作将数据写入MemStore的时候，也会写一份数据到HLog文件中，HLog文件会定期滚动刷新，并删除旧的文件（已持久化到StoreFile中的数据）。当HMaster通过Zookeeper感知到某个HRegionServer意外终止时，HMaster首先会处理遗留的 HLog文件，将其中不同HRegion的HLog数据进行拆分，分别放到相应HRegion的目录下，然后再将失效的HRegion重新分配，领取到这些HRegion的HRegionServer在加载 HRegion的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后Flush到StoreFiles，完成数据恢复。

ROOT表和META表

HBase的所有HRegion元数据被存储在.META.表中，随着HRegion的增多，.META.表中的数据也会增大，并分裂成多个新的HRegion。为了定位.META.表中各个HRegion的位置，把.META.表中所有HRegion的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示。

-ROOT-表永远不会被分割，它只有一个HRegion，这样可以保证最多只需要三次跳转就可以定位任意一个HRegion。为了加快访问速度，.META.表的所有HRegion全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位HRegion的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的HRegion。

读写操作流程

写操作

步骤1：Client通过Zookeeper的调度，向HRegionServer发出写数据请求，首先写一份数据到HLog文件中，HLog文件会定期滚动刷新，并删除旧的文件，接着在HRegion中写数据。

步骤2：数据被写入HRegion的MemStore，直到MemStore达到预设阈值。

步骤3：MemStore中的数据被Flush成一个StoreFile。

步骤4：随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。

步骤5：StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。

步骤6：单个StoreFile大小超过一定阈值后，触发Split操作，把当前HRegion Split成2个新的HRegion。父HRegion会下线，新Split出的2个子HRegion会被HMaster分配到相应的HRegionServer 上，使得原先1个HRegion的压力得以分流到2个HRegion上。

读操作

步骤1：client访问Zookeeper，查找-ROOT-表，获取.META.表信息。

步骤2：从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer。

步骤3：通过HRegionServer获取需要查找的数据。

步骤4：HRegionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

HBase数据模型

HBase是一个类似于BigTable的分布式数据库，它是一个稀疏的长期存储的（存在HDFS上）、多维度的、排序的映射表。这张表的索引是行关键字、列关键字和时间戳。HBase的数据都是字符串，没有类型。

可以将一个表想象成一个大的映射关系，通过行键、行键+时间戳或行键+列（列族：列修饰符），就可以定位特定数据。由于HBase是稀疏存储数据的，所以某些列可以是空白的。上表给出了com.cnn.www网站的数据存放逻辑视图，表中仅有一行数据，行的唯一标识为“com.cnn.www”，对这行数据的每一次逻辑修改都有一个时间戳关联对应。表中共有四列：contents:html、anchor:cnnsi.com、anchor:my.look.ca、mime:type，每一列以前缀的方式给出其所属的列族。

行键（RowKey）是数据行在表中的唯一标识，并作为检索记录的主键。在HBase中访问表中的行只有三种方式：通过某个行键访问、给定行键的范围访问、全表扫描。行键可以是任意字符串（最大长度64KB）并按照字典序进行存储。对于那些经常一起读取的行，需要对键值精心设计，以便它们能放在一起存储。

】

在下一节，将继续介绍spark、sqoop的相关内容。。。