基于Hadoop平台的电信大数据入库及查询性能优化研究

陈娜+张金娟+刘智琼+徐歆壹

【摘要】随着移动互联网的快速发展，电信运营商内部各种IT系统中的数据出现了“大数据”的特征，既有的技术架构和路线已无法高效处理如此海量的数据。针对流量经营大数据管理和大数据服务中海量DPI数据的数据入库和数据查询场景，提出了一种基于Hadoop的分布式数据服务架构，并设计出在该架构下的数据入库和查询性能的优化算法，通过模拟数据的实验对性能优化算法进行了验证。

【关键词】大数据HadoopHBase性能优化

中图分类号：TP39文献标识码：A文章编号：1006-1010(2014)-07-0058-06

1 引言

随着3G网络的成熟和智能终端的普及，移动互联网上的数据呈现爆炸式的增长，电信运营商为适应移动互联网时代激烈的竞争，也提出了角色转型的战略，不断推出各种新业务和新应用，引导用户的行为模式从传统的“语音+短信+增值业务”的模式转变为“语音+应用+流量”的模式。各种新业务和新应用层出不穷，趋向多元化，这使得电信运营商内部各种IT系统中的数据也出现了大数据的特征，一是数据类型繁多；二是数据价值分散；三是处理速度快，时效性要求高。既有的技术架构和路线，已经无法高效处理如此海量的数据，例如DPI数据。

近年来，大数据处理的技术架构涌现出了众多新技术，其中由Apache基金会开发的Hadoop开源架构应用最广泛，在电信企业内部也已有部分IT系统在尝试使用Hadoop架构。本文针对海量DPI数据的数据入库和数据查询场景，提出一种基于Hadoop的分布式数据服务架构，同时，设计出在该架构下的数据入库和查询性能的优化算法，并通过模拟数据的实验对性能优化算法进行了验证。

2 系统功能架构设计

在功能架构上，本系统采用“三层结构”的设计思想，应用系统在逻辑上按“数据服务层、业务处理层和接入层”三层结构设计。将接入层独立出来使得系统的访问和使用更灵活方便，易于实现个性化和客户化；将业务处理层和数据服务层分开可以屏蔽业务数据的存储、组织和访问的细节，实现业务数据的充分共享，从而实现横向组合。系统功能架构如图1所示。

（1）数据服务层

数据服务层为整个系统提供分布式的数据服务，其中包括分布式文件系统HDFS、分布式数据库HBase、分布式协调器Zookeeper和业务实例化部分。

（2）业务处理层

业务处理层构建于数据服务层之上，封装了整个系统的核心业务处理逻辑。其中包括接口服务与查询管理、数据ETL、索引定制、数据服务、系统管理功能。

（3）接入层

接入层实现本系统和外部系统的接口，其中包括输入接口和输出接口。本系统输入接口采用文件接口，输出接口采用Web Service消息接口。

3 验证数据和实验环境描述

实验选择的验证数据是流量经营DPI数据，DPI数据是基于DPI技术获取的TCP/IP应用层数据，基于此能够对数据内容进行分析，因此DPI数据在流量经营业务背景下具有很重要的意义。

（1）数据特性

实验选择流量经营DPI数据的数据特性如表1所示：

表1DPI数据的数据特性

业务类型 文件编码方式 原始记录字段数 需入库的记录字段数 需入库记录数/亿

HTTP业务 ASCII 65 14 25

WAP业务 ASCII 40 14 25

（2）验证方法和评估指标

实验主要验证50亿DPI数据的入库、查询性能和整个系统的高可用性，具体的验证方法和评估指标如表2所示：

表2评估指标

评估点 评估指标

50亿数据的入库性能 入库总耗时（LTC）、每秒入库记录数（RNPS）

50亿数据的查询性能 平均查询响应时长（ATRT）、平均事务处理能力（TPS）

（3）硬件配置

实验的主机环境为6台DL380 Gen8，CPU为E5-2630*1（12核），内存16G，联机磁盘各300GB，构建分布式文件系统的存储各2T；实验网络带宽采用千兆以太网络。

4 入库性能优化

入库性能相关的因素主要包括Region分裂率、CPU使用率、磁盘I/O使用率、网络I/O使用率、HBase内核参数优化度和入库应用程序优化度。通过深入研究，本文提出入库的极限性能测评算法如下：

（1）

其中，WIO是单台机器的I/O带宽，单位为kB/s；Scdr是要入库的单条话单的大小，单位是kB；C1是HDFS文件系统保留的副本系数；C2是整个集群的机器数。R2和R1代表性能测试结束和开始时的Htable Region个数，当R2大于R1时说明有Region分裂产生，最理想的性能值是R2=R1，表示没有Region发生过分裂。指的是集群所有服务器的平均CPU使用率，这里取分段值：

当CPU使用率平均值≥80%时，=1；当60%≤CPU使用率平均值＜80%时，=0.7；当CPU使用率平均值＜60%时，=0；指集群所有服务器的平均I/O使用率，取值规则和相同；指集群所有服务器的平均网络带宽使用率，取值规则和相同；λ1表示HBase内核参数优化度和入库应用程序优化度，此值越小说明平台和应用程序越优化，取值范围为[0,1]。当其为0时则达到理论的最优程度。

根据实验环境，对K系列参数做如下设置：k1为Region分裂系数，在DL380 Gen8集群环境下为常数130；k2为CPU影响系数，在DL380 Gen8集群环境下为常数50 000；k3为磁盘I/O影响系数，在DL380 Gen8集群环境下为常数60 000；k4为网络影响系数，在千兆以太网环境下为常数60 000；k5为软系数，表示软件层面的优化系数，该值为常数120 000。当HBase的内核参数未做任何优化时λ1的经验值为0.85左右，当HBase内核参数和应用做下文的10项优化后，λ1的经验值为0.1。

4.1HBase内核参数优化

HBase内核参数的优化是对入库极限性能测评算法中因子λ1的优化，主要包括以下5个方面：

（1）hbase.hregion.max.filesize的设置

HBase中hfile的默认最大值（hbase.hregion.max.filesize）是256MB，hbase.hregion.max.filesize不宜过大或过小[1]。对于流量经营DPI离线应用，调整为128MB会更加合适一些。

（2）hbase.regionserver.handler.count的设置

RegionServer端开启的RPC监听器实例个数，也即RegionServer能够处理的I/O请求线程数，默认是10。因流量经营DPI数据为多线程并发入库，故调整该值到50。

（3）hbase.hregion.memstore.block.multiplier设置

这个参数的作用是当memstore的大小增至超过hbase.hregion.memstore.flush.size的2倍时，block所有请求，遏制风险进一步扩大，该参数的默认值是2。因流量经营DPI数据写操作的量非常大，故调整该值为3。

（4）hbase.hstore.blockingStoreFiles设置

block写请求会严重影响当前RegionServer的响应时间，但过多的storefile也会影响读性能[2]。为了获取较平滑的响应时间，流量经营DPI数据入库设置该值为无限大。

endprint

（5）hfile.block.cache.size设置

storefile的读缓存占用Heap的大小百分比为20%，该值直接影响数据读的性能。流量经营DPI数据主要是提供数据的查询服务，为提高读数据的性能，设置该值为0.4。

4.2预分Region数量

预分Region数量是对入库极限性能测评算法中因子（R2-R1）部分的优化。为规避Hregion分裂导致的额外资源耗费对系统性能的影响，根据需要入库的数据量大小提前预分好所有的Region，可以提高系统的总体性能。

4.3使用Snappy压缩算法

使用Snappy压缩算法对DPI的入库数据进行压缩是对入库极限性能测评算法中因子、和的优化。入库前文件总大小为509GB，入库后数据保留3份，HDFS文件系统共使用269.79G，相对压缩比为0.53。若按照单条DPI数据的绝对压缩率计算，压缩率可以达到15%左右。使用Snappy压缩算法后，大幅降低了系统总体的I/O吞吐量，进而也大幅提高了入库的性能。

4.4写表操作的性能优化

写表操作的性能优化是对入库极限性能测评算法中因子λ1的优化，主要包括以下5个方面：

（1）Auto Flush设置

通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求[3]。默认情况下auto flush是开启的。

（2）Write Buffer设置

通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte，可以根据实际写入数据量的多少来设置该值[3]。

（3）WAL Flag设置

在HBase中，客户端向集群中的RegionServer提交数据时，首先会先写WAL日志，只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功；如果写WAL日志失败，客户端则被通知提交失败。这样可以做到RegionServer宕机后的数据恢复。因此，对于相对不太重要的数据，可以在Put/Delete操作时，通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数，放弃写WAL日志，从而提高数据写入的性能[4]。

（4）批量写

通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase，同样HBase提供了另一个方法：通过调用HTable.put(List)方法可以将指定的row key列表，批量写入多行记录。这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高、网络传输RTT高的情景，可带来明显的性能提升[5]。

（5）多线程并发写

在客户端开启多个HTable写线程，每个写线程负责一个HTable对象的flush操作，这样结合定时flush和写buffer（writeBufferSize），既能保证在数据量小的时候，数据可以在较短时间内被flush（如1s内），同时又能保证在数据量大的时候，写buffer一满就及时进行flush[6]。

4.5入库性能结果对比分析

通过以上优化，入库50亿数据优化前后最终测试结果对比如表3所示：

表3数据优化前后入库性能结果对比

记录数/亿 优化前LTC 优化前RNPS/（万条·s-1） 优化后LTC 优化后RNPS/（万条·s-1）

50 11小时46分 11.8 5小时20秒 28.1

根据表3数据可得优化前的集群入库效率为11.8万条/s，优化后的集群入库效率为28.1万条/s。再结合入库的极限性能测评算法对以上结果进行分析：

（1）优化前结果分析

结论一：优化前实际入库速率11.8万条/s远小于极限性能=29.2万条/s，优化前的入库性能只达到极限性能的40.4%，总体上还有很大的优化空间；

结论二：Region数量分裂了244次，磁盘I/O出现瓶颈，需控制Region的分裂，降低磁盘的总体I/O。

结论三：根据以上性能测评算法计算出的优化前入库速率为11.6万条/s，与实际测试结果11.8万条/s近似。

（2）优化后结果分析

结论一：优化后实际入库速率28.1万条/s接近极限性能29.2万条/s，优化后的入库性能达到极限入库性能的96.2%；

结论二：优化后的Region未发生分裂，磁盘I/O、网络I/O、CPU使用率均未出现瓶颈；

结论三：根据以上性能测评算法计算出的优化后入库速率为28万条/s，与实际测试结果28.1万条/s近似。

5 查询性能优化

查询性能相关的因素包括：查询服务中间件吞吐量、查询寻址次数、查询集群规模、查询应用优化程度。实验选择的查询中间件为tomcat。通过验证，单台DL380 Gen8机器读取内存的查询性能为300；用户并发查询ATRT为0.18s，TPS为1 429TPS，以上两值不同的硬件平台取值不一样。通过深入研究，本文提出查询的极限性能测评算法如下：

（2）

（3）

其中，表示查询的平均事务响应时间，R1表示做一次查询HBase的路由寻址次数，该值与应用设计有关，不同的设计最终路由寻址次数可能不一样；λ1表示查询应用的优化度，取值范围为[0,1]，当该值为0时说明查询应用已经达到最优程度，根据经验当应用未做任何优化时λ1的经验值为0.9，当应用做了下文中的6项优化后，λ1的经验值为0.1。

表示查询的平均事务处理能力，R1、λ1、C1的含义与计算公式中的因子含义相同。k1表示路由系数，在DL380 Gen8集群环境下为常数65；k2表示应用优化系数，在DL380 Gen8集群环境下为常数600。

5.1RowKey的设计

RowKey的设计是对查询性能评估算法中R1因子的优化。HTable的RowKey是用来检索记录的主键，访问HBase Table的方式只有三种，分别是通过单个RowKey访问、通过RowKey的range访问、全表扫描。因而RowKey的设计就与查询条件紧密相关，RowKey的设计好坏也直接影响到查询的性能和查询条件的灵活性。

流量经营DPI数据的查询条件是根据用户号码和时间范围来检索该号码在该时间范围内的所有记录，那么流量经营DPI数据的Htable RowKey设计为：手机号码MDN（15位）+开始时间Start Time（14位）+协议类型ProtocolID（2位）+时长DURATION（9位）。因以上字段的数据在检索和排序时都是按数字序来排序的，因而所有字段都按固定长度拼接，长度不足则左补0。按照以上设计，当按照手机号码和开始时间查询记录时，可以直接通过-ROOT-表寻址、.META.表寻址两次即可找到本次查询所对应的Region。

5.2负载均衡设计

负载均衡设计是对查询性能评估算法中C1因子的优化。查询服务的吞吐量易受限于单台PCServer的处理能力，经过试验，DL380 Gen8的查询平均时延不超过0.05s的情况下，最大允许的并发查询用户数为120个。那么在PCServer集群环境下查询服务也须使用分布式结构，且各主机对查询请求负载均衡[7]。按照以上依据，采用Nginx+Tomcat的负载均衡架构，将查询消息通过Nginx负载均衡分发到4台主机上。按照该负载均衡的设计，经过试验，4台主机在查询时延不超过0.05s的情况下，最大允许的并发用户数达到450个。

5.3查询应用的优化

读表操作是对查询性能评估算法中因子λ1的优化，具体优化点包括以下6点：

（1）多HTable并发读

创建多个HTable客户端用于读操作，提高读数据的吞吐量。

（2）Scanner Caching

通过调用HTable.setScannerCaching(int scannerCaching)可以设置HBase scanner一次从服务端抓取的数据条数，默认情况下一次一条。通过将此值设置成一个合理的值，可以减少scan过程中next()的时间开销[7]。

（3）Scan Attribute Selection

scan时指定需要的Column Family，可以减少网络传输数据量，否则默认scan操作会返回整行所有Column Family的数据[8]。

（4）Close ResultScanner

通过scan取完数据后，关闭ResultScanner，否则RegionServer可能会出现资源争用的问题。

（5）批量读

通过调用HTable.get(Get)方法可以根据一个指定的RowKey获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List)方法可以根据一个指定的RowKey列表，批量获取多行记录，只需要一次网络I/O开销，对于对数据实时性要求高而且网络传输RTT高的情景，可带来明显的性能提升[9]。

（6）缓存查询结果

对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑LRU等常用的策略[9]。

5.4查询性能结果对比分析

通过以上优化，查询50亿数据优化前后最终测试结果如表4所示：

表4数据优化前后查询性能结果对比

查询

方法 虚拟用户数/个 优化前ATRT/s 优化前TPS 优化后ATRT/s 优化后TPS

查50亿 300 0.785 219 0.039 4 626

结合查询的极限性能测评算法对以上结果进行分析：

（1）优化前

结论一：每次查询的寻址次数为4次，比理论最小寻址次数多了2次，可优化HTable表设计和RowKey设计，减少查询的寻址次数；

结论二：查询的应用只部署在1台机器上，需使用负载均衡的分布式查询，发挥所有机器的作用；

结论三：根据以上性能测评算法计算出的和为0.785与224，与实际测试结果0.785和219近似。

（2）优化后

结论一：每次查询的寻址次数为2次，已经达到最优的查询寻址路径；

结论二：查询的应用使用是分布在6台机器上的，充分发挥了每台机器的作用；

结论三：根据以上性能测评算法计算出的和为0.04和4 614，与实际测试结果0.039与4 626近似。

6 结论

本文论述了电信企业在流量经营背景下，基于Hadoop平台的一种新的数据服务架构。基于Hadoop平台搭建的分布式数据服务系统可以提供海量数据的高速入库与查询性能。同时本文通过真实实验数据，总结了在该架构下性能优化的一般方案和性能计算模型，通过这些性能优化方案可以将数据服务的质量提升到新的高度。

参考文献：

[1] 蔡斌,陈湘萍. Hadoop技术内幕：深入解析Hadoop Common和HDFS架构设计与实现原理[M]. 北京: 机械工业出版社, 2013.

[2] 董西成. Hadoop技术内幕：深入解析MapReduce架构设计与实现原理[M]. 北京: 机械工业出版社, 2013.

[3] Lars George. HBase: The Definitive Guide[M]. O'Reilly, 2012.

[4] 陈能技,郭柏雅. 性能测试诊断分析与优化[M]. 北京: 电子工业出版社, 2012.

[5] Apache. HUG8: January HBase User Group at StumbleUpon[EB/OL]. (2010-07-27). http://www.meetup.com/hbaseusergroup/events/12241393/.

[6] Apache. The Apache HBaseTM Reference Guide[EB/OL]. (2013-06-11). http://hbase.apache.org/book.html#configuration.

[7] 林伟伟. 一种改进的Hadoop数据放置策略[J]. 华南理工大学学报：自然科学版, 2012(1): 36-39.

[8] 张榆,马友忠,孟小峰. 一种基于HBase的高效空间关键字查询策略[J]. 小型微型计算机系统, 2012(10): 72-74.

[9] European Conference, ServiceWave 2011 4th. Enhancing Query Support in HBase via an Extended Coprocessors Framework[C]. 2011.★

作者简介

陈娜：高级工程师，硕士毕业于华中科技大学，现任职于中国电信股份有限公司广州研究院，主要从事电信IT支撑系统的相关研究工作。

张金娟：工程师，硕士毕业于华南理工大学通信与信息系统专业，现任职于中国电信股份有限公司广州研究院，主要从事IT系统性能评测及调优方面的工作和研究。

刘智琼：高级工程师，硕士毕业于湖南大学，现任职于中国电信股份有限公司广州研究院，研究方向为电信运营商支撑系统。

endprint

5.2负载均衡设计

负载均衡设计是对查询性能评估算法中C1因子的优化。查询服务的吞吐量易受限于单台PCServer的处理能力，经过试验，DL380 Gen8的查询平均时延不超过0.05s的情况下，最大允许的并发查询用户数为120个。那么在PCServer集群环境下查询服务也须使用分布式结构，且各主机对查询请求负载均衡[7]。按照以上依据，采用Nginx+Tomcat的负载均衡架构，将查询消息通过Nginx负载均衡分发到4台主机上。按照该负载均衡的设计，经过试验，4台主机在查询时延不超过0.05s的情况下，最大允许的并发用户数达到450个。

5.3查询应用的优化

读表操作是对查询性能评估算法中因子λ1的优化，具体优化点包括以下6点：

（1）多HTable并发读

创建多个HTable客户端用于读操作，提高读数据的吞吐量。

（2）Scanner Caching

通过调用HTable.setScannerCaching(int scannerCaching)可以设置HBase scanner一次从服务端抓取的数据条数，默认情况下一次一条。通过将此值设置成一个合理的值，可以减少scan过程中next()的时间开销[7]。

（3）Scan Attribute Selection

scan时指定需要的Column Family，可以减少网络传输数据量，否则默认scan操作会返回整行所有Column Family的数据[8]。

（4）Close ResultScanner

通过scan取完数据后，关闭ResultScanner，否则RegionServer可能会出现资源争用的问题。

（5）批量读

通过调用HTable.get(Get)方法可以根据一个指定的RowKey获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List)方法可以根据一个指定的RowKey列表，批量获取多行记录，只需要一次网络I/O开销，对于对数据实时性要求高而且网络传输RTT高的情景，可带来明显的性能提升[9]。

（6）缓存查询结果

对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑LRU等常用的策略[9]。

5.4查询性能结果对比分析

通过以上优化，查询50亿数据优化前后最终测试结果如表4所示：

表4数据优化前后查询性能结果对比

查询

方法 虚拟用户数/个 优化前ATRT/s 优化前TPS 优化后ATRT/s 优化后TPS

查50亿 300 0.785 219 0.039 4 626

结合查询的极限性能测评算法对以上结果进行分析：

（1）优化前

结论一：每次查询的寻址次数为4次，比理论最小寻址次数多了2次，可优化HTable表设计和RowKey设计，减少查询的寻址次数；

结论二：查询的应用只部署在1台机器上，需使用负载均衡的分布式查询，发挥所有机器的作用；

结论三：根据以上性能测评算法计算出的和为0.785与224，与实际测试结果0.785和219近似。

（2）优化后

结论一：每次查询的寻址次数为2次，已经达到最优的查询寻址路径；

结论二：查询的应用使用是分布在6台机器上的，充分发挥了每台机器的作用；

结论三：根据以上性能测评算法计算出的和为0.04和4 614，与实际测试结果0.039与4 626近似。

6 结论

本文论述了电信企业在流量经营背景下，基于Hadoop平台的一种新的数据服务架构。基于Hadoop平台搭建的分布式数据服务系统可以提供海量数据的高速入库与查询性能。同时本文通过真实实验数据，总结了在该架构下性能优化的一般方案和性能计算模型，通过这些性能优化方案可以将数据服务的质量提升到新的高度。

参考文献：

[1] 蔡斌,陈湘萍. Hadoop技术内幕：深入解析Hadoop Common和HDFS架构设计与实现原理[M]. 北京: 机械工业出版社, 2013.

[2] 董西成. Hadoop技术内幕：深入解析MapReduce架构设计与实现原理[M]. 北京: 机械工业出版社, 2013.

[3] Lars George. HBase: The Definitive Guide[M]. O'Reilly, 2012.

[4] 陈能技,郭柏雅. 性能测试诊断分析与优化[M]. 北京: 电子工业出版社, 2012.

[5] Apache. HUG8: January HBase User Group at StumbleUpon[EB/OL]. (2010-07-27). http://www.meetup.com/hbaseusergroup/events/12241393/.

[6] Apache. The Apache HBaseTM Reference Guide[EB/OL]. (2013-06-11). http://hbase.apache.org/book.html#configuration.

[7] 林伟伟. 一种改进的Hadoop数据放置策略[J]. 华南理工大学学报：自然科学版, 2012(1): 36-39.

[8] 张榆,马友忠,孟小峰. 一种基于HBase的高效空间关键字查询策略[J]. 小型微型计算机系统, 2012(10): 72-74.

[9] European Conference, ServiceWave 2011 4th. Enhancing Query Support in HBase via an Extended Coprocessors Framework[C]. 2011.★

作者简介

陈娜：高级工程师，硕士毕业于华中科技大学，现任职于中国电信股份有限公司广州研究院，主要从事电信IT支撑系统的相关研究工作。

张金娟：工程师，硕士毕业于华南理工大学通信与信息系统专业，现任职于中国电信股份有限公司广州研究院，主要从事IT系统性能评测及调优方面的工作和研究。

刘智琼：高级工程师，硕士毕业于湖南大学，现任职于中国电信股份有限公司广州研究院，研究方向为电信运营商支撑系统。

endprint

5.2负载均衡设计

负载均衡设计是对查询性能评估算法中C1因子的优化。查询服务的吞吐量易受限于单台PCServer的处理能力，经过试验，DL380 Gen8的查询平均时延不超过0.05s的情况下，最大允许的并发查询用户数为120个。那么在PCServer集群环境下查询服务也须使用分布式结构，且各主机对查询请求负载均衡[7]。按照以上依据，采用Nginx+Tomcat的负载均衡架构，将查询消息通过Nginx负载均衡分发到4台主机上。按照该负载均衡的设计，经过试验，4台主机在查询时延不超过0.05s的情况下，最大允许的并发用户数达到450个。

5.3查询应用的优化

读表操作是对查询性能评估算法中因子λ1的优化，具体优化点包括以下6点：

（1）多HTable并发读

创建多个HTable客户端用于读操作，提高读数据的吞吐量。

（2）Scanner Caching

通过调用HTable.setScannerCaching(int scannerCaching)可以设置HBase scanner一次从服务端抓取的数据条数，默认情况下一次一条。通过将此值设置成一个合理的值，可以减少scan过程中next()的时间开销[7]。

（3）Scan Attribute Selection

scan时指定需要的Column Family，可以减少网络传输数据量，否则默认scan操作会返回整行所有Column Family的数据[8]。

（4）Close ResultScanner

通过scan取完数据后，关闭ResultScanner，否则RegionServer可能会出现资源争用的问题。

（5）批量读

通过调用HTable.get(Get)方法可以根据一个指定的RowKey获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List)方法可以根据一个指定的RowKey列表，批量获取多行记录，只需要一次网络I/O开销，对于对数据实时性要求高而且网络传输RTT高的情景，可带来明显的性能提升[9]。

（6）缓存查询结果

对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑LRU等常用的策略[9]。

5.4查询性能结果对比分析

通过以上优化，查询50亿数据优化前后最终测试结果如表4所示：

表4数据优化前后查询性能结果对比

查询

方法 虚拟用户数/个 优化前ATRT/s 优化前TPS 优化后ATRT/s 优化后TPS

查50亿 300 0.785 219 0.039 4 626

结合查询的极限性能测评算法对以上结果进行分析：

（1）优化前

结论一：每次查询的寻址次数为4次，比理论最小寻址次数多了2次，可优化HTable表设计和RowKey设计，减少查询的寻址次数；

结论二：查询的应用只部署在1台机器上，需使用负载均衡的分布式查询，发挥所有机器的作用；

结论三：根据以上性能测评算法计算出的和为0.785与224，与实际测试结果0.785和219近似。

（2）优化后

结论一：每次查询的寻址次数为2次，已经达到最优的查询寻址路径；

结论二：查询的应用使用是分布在6台机器上的，充分发挥了每台机器的作用；

结论三：根据以上性能测评算法计算出的和为0.04和4 614，与实际测试结果0.039与4 626近似。

6 结论

本文论述了电信企业在流量经营背景下，基于Hadoop平台的一种新的数据服务架构。基于Hadoop平台搭建的分布式数据服务系统可以提供海量数据的高速入库与查询性能。同时本文通过真实实验数据，总结了在该架构下性能优化的一般方案和性能计算模型，通过这些性能优化方案可以将数据服务的质量提升到新的高度。

参考文献：

[1] 蔡斌,陈湘萍. Hadoop技术内幕：深入解析Hadoop Common和HDFS架构设计与实现原理[M]. 北京: 机械工业出版社, 2013.

[2] 董西成. Hadoop技术内幕：深入解析MapReduce架构设计与实现原理[M]. 北京: 机械工业出版社, 2013.

[3] Lars George. HBase: The Definitive Guide[M]. O'Reilly, 2012.

[4] 陈能技,郭柏雅. 性能测试诊断分析与优化[M]. 北京: 电子工业出版社, 2012.

[5] Apache. HUG8: January HBase User Group at StumbleUpon[EB/OL]. (2010-07-27). http://www.meetup.com/hbaseusergroup/events/12241393/.

[6] Apache. The Apache HBaseTM Reference Guide[EB/OL]. (2013-06-11). http://hbase.apache.org/book.html#configuration.

[7] 林伟伟. 一种改进的Hadoop数据放置策略[J]. 华南理工大学学报：自然科学版, 2012(1): 36-39.

[8] 张榆,马友忠,孟小峰. 一种基于HBase的高效空间关键字查询策略[J]. 小型微型计算机系统, 2012(10): 72-74.

[9] European Conference, ServiceWave 2011 4th. Enhancing Query Support in HBase via an Extended Coprocessors Framework[C]. 2011.★

作者简介

陈娜：高级工程师，硕士毕业于华中科技大学，现任职于中国电信股份有限公司广州研究院，主要从事电信IT支撑系统的相关研究工作。

张金娟：工程师，硕士毕业于华南理工大学通信与信息系统专业，现任职于中国电信股份有限公司广州研究院，主要从事IT系统性能评测及调优方面的工作和研究。

刘智琼：高级工程师，硕士毕业于湖南大学，现任职于中国电信股份有限公司广州研究院，研究方向为电信运营商支撑系统。

endprint