基于HBase的健康大数据平台性能优化及应用

王勇++尹鹏飞++李娟

摘要：健康大数据已被纳入国家大数据战略布局，如何能够收集有效的健康数据，构建高性能、高可靠性、低成本和具有良好可扩展性的健康大数据平台至关重要。传统的单纯利用Hadoop、HBase无法满足复杂的业务需求和实时查询的要求，同时性能方面也存在一些问题。分析了HBase的底层原理，对HBase的读写性能进行优化。借助Phoenix提供的SQL接口来操控HBase，可方便对集群和数据进行管理。Phoenix针对HBase也提出了一系列优化方案。利用HBase和Phoenix的特性构建高性能的健康大数据平台。实验结果表明，优化后的健康大数据系统具有更好的读写性能，能够更好地满足大数据发展需求。

关键词：健康大数据；HBase；分布式数据库；负载预测

DOIDOI：10.11907/rjdk.171146

中图分类号：TP319文献标识码：文章编号：16727800（2017）010014604

0引言

通过移动互联网、智能设备和物联网技术，人们能够随时追踪记录自己当前的生理健康指标、运动状况、饮食情况和其它生活习惯，这些数据的收集能够帮助挖掘出更有价值的医疗信息。然而，技术的发展仍无法跟上数据增长的速度。对于大规模数据的存储、管理和实时查询仍然面临很多问题，同时健康监测数据也缺乏统一标准，使大量数据无法共享利用，这无疑会影响健康监测大数据的发展进程。

本文对健康监测数据的存储与管理进行研究，根据健康监测数据的数据表示模型和数据形态，采用HBase大数据平台研究健康监测数据的存储与组織形式，实现了健康大数据的存储和管理，并提供高并发的读写性能与可扩展性。

HBase是参照Google Bigtable实现的NoSQL数据库，有着天然的大数据存储优势[1]。它具有强一致性、随机读写、面向列，以及可动态修改、可水平伸缩的特性[2]。HBase支持范围查询以及行事务，可在廉价PC Server上搭建大规模的结构化存储集群。HBase非常适合于构建高性能的健康大数据平台。然而，HBase还处在高速发展时期，仍有一些问题需要解决。Apache的Phoenix为人们操作HBase提供了更加便捷的沟通方式，其提供了标准的SQL和JDBC API的力量与完整的ACID事务的能力和后期绑定的灵活性。目前，关于HBase性能的优化和研究还存在着诸多现实问题，缺乏关键技术支持。本文重点研究了基于健康数据存储的HBase集群的性能优化与应用，并采用HBase1.0.2版本、phoenix4.8版本进行分析实验，旨在提供一个高性能、高可用的健康大数据存储和管理平台。

1健康大数据平台分析与优化

1.1健康数据模型设计

中华人民共和国国家卫生和计划生育委员会于2011年8月发布了《城乡居民健康档案基本数据集》，规定了城乡居民健康档案基本数据集的元数据属性和数据元目录。通过研究与分析该数据集，构建了统一的健康档案存储模型，并转化成HBase的数据模型，进行数据库的设计与实现。

选取《高血压患者随访数据元专用属性》作为案例进行研究分析。表1是分析得到的高血压关系模型。其中行键采用身份证号码、医院编号、医疗项目和时间戳的组合键。

其中，NumRegionServer可以采用集群中的RegionServer数目，有利于分担数据读写压力，但也不宜过多，否则会造成集群性能下降。

1.3HBase数据查询优化

HBase在0.92之后引入了协处理器（Coprocessors），能够更好地建立二级索引、复杂过滤器、访问控制等更为复杂的操作[5]。Phoenix则在此基础上提供了更加方便的操作。Phoenix能够用SQL的方式建立二级索引。Phoenix支持4种类型的索引技术：Covered Indexes、Functional Indexes、Global Indexing和Local Indexing，这些索引技术分别适用于不同的业务场景，主要是偏重于读或写。

可以通过如下方式直接为HBase创建索引：

CREATE INDEX BLOOD_PRESSURE_INDEX ON BLOOD_PRESSURE （detail.id_number） INCLUDE（detail.user_name，detail.follow_date）

创建了一个名为BLOOD_PRESSURE_INDEX的索引，查询id_number、user_name、follow_date字段可加快查询速度，同时也可根据这些字段查询所需的rowkey。如果查询字段中包含了不在索引的字段且不是rowkey，索引则不会被触发到，查询仍会进行全表扫描。

1.4数据统计与分页查询

HBase本身不提供分页查询功能，但在实际的应用需求中，难免会用到分页功能，尤其对于数据量异常庞大的海量数据系统。对于UPDATE STATISTICS BLOOD_PRESSURE，执行命令能加快对BLOOD_PRESSURE表数据统计的查询速度。关于Phoenix提供的HBase分页查询，可以通过以下查询方式进行：

SELECT *

FROM BLOOD_PRESSURE

WHERE IdNumner = ？ AND Name=？

ORDER BY

PK

LIMIT STARTROW OFFSET ENDROW

根据以上查询语句，可以根据姓名、身份证号查询最新的从STARTROW到ENDROW之间的数据内容。

1.5HBase负载预测

虽然Phoenix提供了salted table 功能，可以将写入的数据随机分配到不同的RegionServer中，但是随着集群规模的变化，也许会增加集群节点，也许会有宕机的节点。SALT_BUCKETS是固定的，无法修改。采用负载预测算法，预测HBase节点的负载情况，建立预测模型，提前将过大的region进行split，然后分配到最佳的RegionServer当中，以缓解节点负载。endprint

1.5.1负载均衡定义

令HBase集群系统由m台服务器组成，根据能力与负载相匹配原则，设集群服务器系统的节点负载能力为Capacity-i（i=1，2，3，4，…，m ）。如果当前的总集群负载为Lsum，每个节点当前的负载量化指标为LRS-i（i=1，2，3，4，…，m ），每个节点应承担的负载量化指标为LRSAVG-i（i=1，2，3，4，…，m ），则可以得出如下公式：

Capacity-1：Capacity-2：Capacity-3：…：

Capacity-i=a：b：c：…：i（1）

LRSAVG-i=Lsum*i/（a+b+c+…+i）

（i=1，2，3，4，…，m）（2）

如果LRSAVG-i与LRS-i相当，则表示当前节点负载良好，达到了较佳的读写性能；反之，说明当前节点的负载偏小或偏大，需根据具体大小进行调整。

1.5.2负载能力定义

为了能够更好地对比计算机之间的性能，需要将计算机的性能指标进行量化分析。根据集群的性能匹配条件，将网络流量Lnet、写请求次数Lwrite、读请求次数Lread、CPU利用率Lcpu、内存利用率Lmem作为集群监测的主要指标。

图1为单台节点的HBase，不断发送写数据请求，得到的响应时间折线如图1所示。

图1展示了在一定的数据写入请求下，HBase提供的响应时间的对应关系。通过写入数据来测试HBase性能，实验发现，隨着数据量不断增大，HBase的响应时间也在不断延长，折线斜率也在上升，直到某个位置出现无法响应的状况。本次实验在数据批量写入70 000条数据时，发现集群无法作出响应。定义一次批量最多写入的数据条数Lwrite-i（i=1，2，3，4，…，m ）作为集群的负载能力量化指标，同时得出如下公式：

Capacity-i=Lwrite-i（i=1，2，3，4，…，m ）（3）

1.5.3负载预测方法

指数平滑法是一种常用的预测算法，对本期观测值赋予不同权重来体现下一期的预测值。一次指数平滑法具有严重滞后性，不能很好地预测变化趋势较明显的场景。为了避免数据的滞后，对数据模型进行了改进，公式如下：

Dt+1=（Yt-Yt-1）+（1-）Dt（t>0）（4）

Ft+1=Yt+（1-）Ft+Dt+1（5）

其中，为平滑系数，取值为0.8。Dt+1为t+1时刻预测模型的差值平滑值，增加Dt+1可以预防指数平滑法引起的滞后性。Ft+1为t+1时刻的负载预测值，Yt为t时刻的实际观测值，当t为0时，选取F0为Y1。将LRS-i作为上述公式中的Yt进行t时刻的负载预测，判断节点的负载情况。LRS-i作为节点的总负载情况，每个节点包含多个表的多个region，LRS-i的总负载可以计为i节点中所有region的负载总和。对于region是否拆分，进行如下分析：统计当前table的所有region个数TRCount，如果region的负载大于当前表平均region负载的两倍，则将此region进行拆分；否则，判断region的文件大小决定是否拆分。计LTB-RG-i为某个表具体region的负载，LTB-AVGRG为某个表的平均region负载。当LTB-RG-i大于2倍的LTB-AVGRG时，将此region进行拆分。

LTB-RG-i>2*LTB-AVGRG？split：0（6）

Li=LRS-i+12LTB-RG-mLRSAVG-i（i=1，2，3，4，…，m ）（7）

Region拆分后的移动方案，需要综合考虑节点的Capacity-i和LRSAVG-i，将拆分后的region移动到Li最小的节点中。其中Li代表编号为m的region占用的节点负载容量比值。

1.5.4算法流程

算法详细描述如下：①建立定时任务，定期执行此算法；②构建监控系统，实时监控系统当前的负载情况、网络流量、读写次数、CPU利用率、内存利用率。一方面可以实时发出报警提醒，另一方面可对将来的集群负载状态预测提供有利的数据支撑；③预测数据模型，利用HBase的监控性能指标，对HBase的regionserver、region负载进行预测，并制定region的拆分与迁移策略，可以参照公式（5）、（6）；④获取当前region的负载情况，建立队列，将region的负载从大到小进行排列，计算所有region均衡负载的量化指标，比较LTB-RG-i和LTB-AVGRG之间的大小关系；如果region的预测负载大于region平均负载的两倍，则将其进行拆分，拆分后的每个子region分别承担一半父region的负载。然后，重新排列队列，直到集群中所有的region都满足为止；⑤如果当前的region负载实现了平衡，则判断region文件大小，对于过大的文件同样采用步骤④的拆分移动策略。算法流程如图2所示。

Hadoop和HBase都是基于Linux的操作系统，JVM是运行环境下的系统软件，本实验环境是在ubuntu操作系统下进行的。上述7个主机是由一台大型机划分出的虚拟机得到。

数据的写入方式通常利用HBase的Java API进行数据操作，采用批量提交数据的方式写入。优化后的系统采用Phoenix的Jdbc接口进行数据写入操作，同样采用批量提交的方式。图3为通过原始的未改进的HBase集群进行的写入数据测试和改进方案后的HBase集群写入数据测试对比结果。

通过图3的对比结果，改进后的健康大数据平台在性能上得到了提升，在管理和使用方面也更加便捷。其中，数据的写入响应时间并不是呈直线上升，而是有波动现象，这与HBase的数据写入原理相关。HBase采用LSM的结构进行数据读写，HBase数据写入性能同时还会受到WAL、FLUSH等机制影响。但总体而言，相比于原有的HBase方案，仍得到了一定提升。endprint

上述响应时间测试采用随机查询的方式，在一定规模的数据中，测试系统的随机查询响应时间。通过图4的对比结果可知，改进后的健康大数据平台在查询性能上也得到了提升。通过对比发现，HBase在一定数据范围内，随着数据量增长，数据查询的响应时间并不会随之增加，这是HBase的查询结构LSM的一个特性。此外，也可以借助HBase的MemStore和缓存等方法加快查询速度。

3总结与展望

健康监测大数据平台的关键技术研究对于建设高性能的健康平台具有重要意义。以健康大数据为业务背景，从健康数据格式统一的角度出发，通过研究《城乡居民健康档案基本数据集》，对居民健康档案数据集提出了统一的存储模型和方案。研究了大数据存储和查询的相关技术，提出利用Hash和预分区方法优化HBase的表结构，利用Phoenix建立的二级索引优化HBase的复杂查询速度，并利用Phoenix实现的HBase协处理器优化HBase对聚合操作的执行效率。本文提出的一系列改进方案有效提高了健康大数据平台性能，同时简化了HBase管理操作，对利用HBase构建可进行实时查询、处理复杂查询的应用提供了有价值的参考。

然而，本文没有对健康数据的相关内容进行深入分析，对于健康档案的数据模型建立，在实际应用过程中可能存在偏差。利用Phoenix创建的表只能通过Phoenix写入才能进行查询显示，直接用HBase进行操作反而无法

被查询到，这对数据的写入方式造成了限制。另外HBase仍然存在着诸多问题，由于底层过度依赖于Hadoop的HDFS，使其性能瓶颈也受到影响。此外，HBase的查询和存储性能的提升需要进一步改进自身结构，随着硬件系统的不断发展，HBase可以更多地借助于内存进行存储和查询。

参考文献：

[1]余峰.MYHBASE：一种基于HBASE的NEWSQL数据库的设计与实现[D].杭州：浙江大学，2012.

[2]景晗，郑建生，陈鲤文，等.基于MapReduce 和HBase 的海量网络数据处理[J].科学技术与工程，2015，15（34）：183191.

[3]董新华，李瑞轩，周湾湾，等.Hadoop系统性能优化与功能增强综述[J].计算机研究与发展，2013，50（S2）：115.

[4]卓海艺.基于HBase的海量数据实时查询系统设计与实现[D].北京：北京邮电大学，2013.

[5]丁飞，陈长松，张涛，等.基于协处理器的HBase区域级第二索引研究与实现[J].计算机应用，2014，34（A01）：181185.

[6]连加典，刘宏立，谢海波，等.基于预测机制的分级负载均衡算法[J].计算机工程与应用，2015，51（11）：6773.

[7]郑坤，付艳丽.基于HBase 和GeoTools 的矢量空间数据存储模型研究[J].计算机应用与软件，2015，32（3）：2325.

[8]WHITE T. Hadoop： the definitive guide[M].O′reilly Media Inc GravensteinHighway North，2010，215（11）：14.

[9]HAYT， TANSLEYS， TOLLEK. The fourth paradigm：dataintensive science discovery[M]. Redmond，Washington， USA： Microsoft Research， 2009.

[10]RAMAMRITHAM K. Realtime databases[J]. International Journal of Distributed and Paralled Databases（S09268782），1993（2）：199226.

[11]CHANG F， DEAN J， GHEMAWAT S， et al. Bigtable： adistributed storage system for structured data[J].ACM Transactions on Computer Systems （TOCS）（S07342071）， 2006，26（2）：205218.

[12]陶永才，石磊.异构资源环境下的MapReduce性能優化[J].小型微型计算机系统，2013，34（2）：287292.

[13]傅杰，都志辉.一种周期性MapReduce作业的负载均衡策略[J].计算机科学，2013，40（3）：3840.

[14]张春明，芮建武，何婷婷.一种Hadoop小文件存储和读取的方法[J].计算机应用与软件，2012，29（11）：95100.

责任编辑（责任编辑：黄健）endprint