基于HBase整合Hive的查询性能研究

李雅楠 庞 慧，2，*

(1.河北建筑工程学院,河北 张家口 075300；2.张家口市大数据技术创新中心，河北 张家口 075000)

0 引 言

HBase是面向列的非关系型数据库，外加其具有高可靠、高性能、高可用以及可伸缩的特点，被广泛应用.HBase的文件存储系统是HDFS，利用Hadoop MapReduce来处理HBase中的海量数据[1].HBase面向列的特点也使其具有先天的劣势.HBase在查询的时候只能够以rowkey为主键来进行，每次查询都需要扫描全表，这样的方式浪费资源且查询效率比较低.

Hive是比较典型的数据仓库工具，可以被用来进行ETL，其进行查询时也需要借助Hadoop MapReduce.现将HBase与Hive进行整合，实现“HBase存储+Hive查询”的整合方案.HiveQL语句与最基础的sql语句十分相似，且Hive Shell的操作相较于HBase Shell简单易上手.因此，该整合方案也可以省略操作上的繁琐步骤.

1 HBase与Hive相关理论

1.1 HBase

HBase的表数据存放在Region中.每个表一开始只有一个Region，随着数据量不断增加，Region增大，当达到一个阈值时，Region就会被RegionServer水平切分成两个新的Region[2].以此类推，随着数据越来越多，对应的Region也越来越多.Region由RegionServer进行管理，通常情况下，一个RegionServer可以管理多个Region.

HBase的功能组件包含以下三个：(1)可以链接到每个客户端的库函数；(2)Region：HBase中包含多个Region服务器；(3)Master主服务器，仅有一个.若客户端发送请求，由Region服务器来处理.除此之外，Region服务器被用来维护并存储系统分配的Region.HBase中表的分区信息，由Master来负责，主要担任管理和维护的工作.

HBase保存Region位置信息的方式和B+树的三层结构十分类似.第一层是Zookeeper文件，它主要是用来记录-ROOT-表的位置信息；-ROOT-表就是第二层，这层也叫根数据表，-ROOT-表中记录的是.META.表的Region的位置信息[3].另外，根数据表只有一个Region，并且通过它就可以访问元数据表中的数据；第三层是.META.表，即元数据表，用来记录数据表的Region位置信息，且可以包含多个Region.

1.2 Hive

传统数据仓库大都是基于Oracle、MySQL这样的关系型数据库，扩展成本高，面对PB级别的数据量以及各种关系数据库、NoSQL数据库、XML文件等数据源，其处理速度和处理效率不能够满足数据存储、查询以及融合多维度数据进行分析的需要[4].

Hive相当于作业提交层，将HiveQL语句发送给中间层MapReduce来进行计算，使用HDFS进行存储.Hive查询过程中，可以通过设置合理的MapReduce的task数、小文件合并等方式来提高查询效率[5].

Hive的工作流程，与大众所熟悉的关系数据库非常相似.区别就是Hive使用的是分布式计算框架.Hive元数据存储是需要通过Thrift来提供的.简单的讲，就是用户要是想要修改元数据，要是直接调用元数据存储方法是行不通的，只能够通过HiveQL来执行，HiveQL语句和大众熟悉的sql语句十分相似，操作比较简单.此外，如果用户要获取元数据，只能够通过只读的方式来进行，不能够修改.

1.3 HBase整合Hive

HBase与Hive都有其对外的API接口，两者可以通过API进行整合.Hive可以通过HBaseStorageHandler来访问HBase中的表数据，并且可以进行创建、查询等操作.

Hive访问HBase中表数据，实质上是通过MapReduce读取HBase表数据[6].实现的第一步就是Hive通过HiveHBaseTableInputFormat在MapReduce中对HBase的数据表进行切分，一个Region对应一个Split，即MapReduce的Map的数量与表中Regions的数量相同.之后利用RecordReader对数据进行读取.Sca-nner可以被用来对全表进行扫描，从而读取HBase中表数据，其可以调用Region-Server的next()函数来获取表数据.Filter可以实现过滤条件的转化.

以上操作全部完成之后，如果HBase和Hive中的表数据一致，且在HBase或者Hive任意平台进行增删改查等操作，另一平台的数据都可以同步，说明HBase存储+Hive查询框架已经整合成功.比如：首先在Hive中查询前十行表数据，之后在HBase中查询，所得出的结果是否一致，若结果一致，则证明HBase与Hive整合成功.

2 实验与分析

2.1 实验环境

实验的的硬件采用的是Lenovo ThinkPad L440.

软件采用的是：CentOS 6.4，Hadoop 2.7.1，HBase 1.1.2，Hive 1.2.0.

实验使用的数据集为美国新冠肺炎按州县进行统计的数据，时间为2020.1.21-2020.5.19.其中date表示日期，county表示县，state表示州，cases表示截止到该日期为止该县的的累计确诊病例，deaths表示截止到该日期为止该县的死亡人数.该文件为csv文件，大约共15万行数据.

2.2 实验过程

2.2.1 配置环境

(1)拷贝lib下的jar文件：将HBase中的jar文件全部copy到Hive中.(2)拷贝HBase与Hive的通信包：Hive中包含通信包hive-hbase-handler-1.2.0.jar，将其复制到HBase目录的lib下；(3)修改Hive的配置文件：修改conf目录下的hive-site.xml配置文件，需要把下面的配置语句加入到该配置文件中，其中*.*.*.*是本机ip.

2.2.2 上传csv文件

首先要将该csv文件上传至HBase，具体步骤为：(1)在HBase中创建新表；(2)将csv文件上传至HDFS；(3)将HDFS中的csv文件导入到HBase的表中，命令为：hbase org.apache.hadoop.hbase.mapreduce.ImportTsv-Dimporttsv.separator=","-Dimporttsv.columns=HBASE_ROW_KEY,info:date,info:county,info:state,info:cases,info:deaths hbase_to_hive_us1/user/us.csv.

2.2.3 在Hive中创建关联HBase的外部表

在Hive Shell中执行：CREATE EXTERNAL TABLE hive_to_hbase_us1(key string,date string,county string,state string,cases int,deaths int)STORED BY'org.apache.hadoop.hive.hbase.HBaseStorageHandler'WITH SERDEPROPERTIES("hbase.columns.mapping"=":key,info:date,info:county,info:state,info:cases,info:deaths")TBLPROPERTIES("hbase.table.name"="hbase_to_hive_us1").执行成功即外部表创建成功.

2.2.4 在Hive中查询数据

在Hive Shell中执行：select * from hive_to_hbase_us1 limit 10;如图1所示，查询结果与存储在HBase中的前十行数据吻合，说明已经整合成功.

图1 hbase整合hive成功图

2.3 实验结果

根据该数据集的特点，本文设计如下查询方式来验证查询速率：由于新冠肺炎的确诊人数是逐步增多的，时间越靠后，确诊或者死亡涉及到的县也越来越多，所以时间越靠后所涉及到的数据量是越来越大的.而对于疫情严重的州，累计确诊病例必然也是越来越大.在这里随机取三个州来进行验证：New York，Calif-ornia，Florida，这里分别使用HBase和HBase整合Hive两种方式来统计以上三个州截止5月19日的总确诊量.经过查询统计，以上三个州截止5月19日的确诊量如表1所示.

表1 美国三个州截止5.19的累计确诊人数

查询New York，California，Florida三个州所用的时间如图2所示.

图2 查询效率对比图

通过对查询Florida，California，New York三个州截止5月19日的确诊量所用的时间进行记录，可看出使用HBase存储+Hive查询的整合框架的查询性能优于使用HBase原生访问.并且随着数据量的增大，两种方案查询性能的差距越来越明显，用户体验感也更好.不过由于硬件条件有限，所选取的数据量仅能显示出实验效果，并不能看到极大的差距，还有待提高.

3 结 语

本文设计了HBase整合Hive的框架，并且结合美国新冠肺炎的部分数据，对该数据分别使用HBase原生访问以及HBase存储+Hive查询两种方案进行数据分析.实验证明，HBase整合Hive可以在提高HBase的查询性能.因Hive对事务弱支持,且事务执行速度很慢,存在诸多限制和不便,不适合高并发的场景[7].本文的整合方案也可以使得Hive适用于更多应用场景.但是由于硬件条件有限，只分析了该离线数据，并且实验数据量也不是很大，在大量的实时数据分析中，是否可以得出同样的结论，或者说该整合方案是否稳定，是否需要进一步的查询性能的优化，依旧值得做更深层次的研究.