HBase数据库行键设计及验证

李兴菊 赵建军 聂红梅 王迎

摘要：HBase列式非关系型数据库行键设计决定了海量数据存储与查询效率。针对目前存在的数据存储问题及检索效率问题，对现有5种主流方法进行数据测试后，选择了相对较优的哈希前缀法，井在原有基础上根据智慧水务系统中的数据结构特性，使用重要字段提升法结合逆序行键方法进行设计.验证结果显示，该行键组合法针对智慧水务中的时序性数据，在存储方面解决了写入热点与存储分散相矛盾的问题，检索效率在原有哈希前缀法基础上也有了一定提升。

关键词：HBase;数据库;行键;数据模型;智慧水务

DOI：10.11907/ejdk.191271开放科学（资源服务）标识码（OSID）：

中图分类号：TP391文献标识码：A 文章编号：1672-7800（2019）010-0178-04

0引言

非关系型数据库系统（Not only SQL，NoSQL）的诞生解决了互联网Web2.0时代带来的数据存储处理瓶颈问题，非关系型数据库由于具有高并发性以及强大的扩展性等优点，弥补了关系型数据库的不足。非关系型数据库中的列式存储系统HBase的出现更是在很大程度上解决了数据存储问题，并一度使HBase成为当前的热门存储技术之一。虽然目前已有很多针对HBase存储与查询的相关研究，但由于应用场景及存储数据结构的不同，使设计的HBase存储模式无法解决数据在存储与查询过程中面临的效率问题。根据大量针对HBase的相关研究，选择对HBase数据存储与查询影响相对较大的部分——行键设计进行讨论。例如在文献中对HBase数据库模式设计进行讨论，并采用组合方法设计了行键，但其仅注重模式选择，而对行键具体设计并未作过多讨论及验证;圣文顺、徐爱萍在数据检索方面分别使用基于行键前缀匹配及关键字匹配的方式提高数据检索效率，但该实现方式需要牺牲数据写入能力。通过总结以上行键设计方法，针对居民用水数据设计了一种相对合理的行键，最后对设计结果进行实验验证。结果证明该行键方法在处理此类数据时，相比其它行键方法在解决存储与检索热点问题方面具有一定优势。

1HBase数据库

HBase（Hadoop Database）数据库是非关系型数据库（NoSQL）的一种，其参考了Google的Bigtable开源分布式系统，使用Hadoop中的分布式文件系统HDFS作为数据底层存储系统，具有高可靠性、面向列与可伸缩等特性，因其自身的独特特性，常被用来存储海量非結构化和半结构化的松散数据。HBase主要具有以下特点：①海量性：可存储百万亿数量级的数据;②列式存储特性：不存在数据稀疏性问题，大大节省了存储开销;③可扩展性：以HDFS作为底层文件存储方式，继承了其可扩展性;④高可靠性：HDFS的冗余备份机制减少了数据丢失情况;⑤高性能：检索效率可达到毫秒级别。

以上特点一方面体现出其与传统关系型数据库的不同，另一方面也体现了HBase在数据管理性能方面的优越性。图1为HBase系统框架，其不仅展示了HBase的核心组件，还展示了与Hadoop在数据存储工作中的关系。图1中HBase的4个核心组件分别是客户端（Client）、主服务器（Master）、Region服务器以及协调服务器（Zookeeper）。客户端是人们与HBase通话的人口，Zookeeper用来从众多Master中选出一个集群总管，以保证在任何时刻都有唯一一个Master节点在工作，避免出现“单点失效”问题;Mas-ter服务器负责对每个Region服务器进行协调，将集中在某个Region服务器的操作均衡分配到负载较轻的服务器中，准确地说是对整个集群进行管理;Region服务器负责对其下面的Region提供读写操作，当Region超过分配值大小时对其进行拆分，并对单个小文件进行合并。

2HBase数据模型

HBase是一个稀疏、多维度、排序的映射表，该表的索引是行键、列族、列限定符与时间戳。图2为HBase数据模型。

HBase与普通数据库都采用表组织数据，整张表由行和列组成，可以有若干行，其使用行键进行标识，是HBase中的唯一索引。由多个列构成的列族也是表的组成部分之一，每个单元格通过行、列族与列限定符确定，单元格中的数据还未定义数据类型，通常情况下默认为字节数组。单元格中使用时间戳区分不同时刻的数据版本，时间戳通常也参与单元格定位，故行键、列族、列限定符与时间戳用来确定一个唯一单元格。

3行键设计

HBase中不管是表列族存储还是Region划分都是基于行键进行的，因此HBase的存储结构很大一部分都与行键设计有关，对HBase数据库以及数据模型的基本认识有利于针对不同数据管理进行行键设计。由于HBase在存储时使用列族而非列进行数据分割，底层存储使用列族将数据线性存人单元格中，每个列族则按照行键使用其字典顺序进行数据存储。行键设计决定了每个Region中数据将如何存储，由于行键一旦被创建则无法更改，所以行键设计中不仅要考虑在同一时间段读写操作都集中在某一个Region上而出现的负载不均衡问题，还要考虑针对特定应用场景如何提高数据检索效率，达到对海量异构数据的高效读写。针对负载均衡及查询效率问题，对行键设计进行讨论是至关重要的，而其设计必须以预期的访问模式进行。

3.1以检索为主的行键方法设计

行键作为HBase中的唯一索引，只能在行键上建立索引，在对数据库进行访问时最主要的方法是通过行键进行访问，也即是说HBase在数据读取时是按照RowKey进行快速检索的，如果设置的行键无法满足检索条件，或用户使用的检索条件不匹配时，则只能采用全表扫描方法，在数据量相对较少的情况下，该方式对HBase的性能不会产生太大影响，但一旦存储的数据规模增大后，这种全表扫描方法则会使得查询效率大大降低。

在HBase数据模型中，整张表包括了行、列族、列限定符与时间戳等几个重要部分，考虑是否可以将其中每一部分作为行键进行设计，然后对每一部分作为行键结果进行讨论。

方法一：将时间戳单独作为行键。时间戳代表同一份数据的多个版本，其作为用户数据检索时的一个重要部分，当前很多传感器、监控仪器等智能设备产生的数据都以时间作为存储标志，或用户在不同时刻对表中数据进行修改更新时，相应单元格会对该时间戳进行保存。目前也有很多行键设计方法使用时间戳对查询方法进行优化。在文献中将时间戳作为行键的一部分，使用Long.MAX_value对产生的数据时间戳进行逆序存储，以保证用户始终能最先查询到更新后的数据。该方法针对时序性强的数据范围查询具有一定优势，具体实现方法为：Long.MAX value-timestamp。

方法二：使用列限定符作为行键。用户在查询数据时可以将列限定符作为行键，以检索或排除用户需要查询的数据，也能在特定条件下实现查询优化。但当一个表中包含很多列时，如果将列直接作为行键进行数据检索依然会出现查询条件不匹配的问题，因而必须进行全表扫描操作。对行、列族、列限定符与时间戳作为行键时的查询性能进行测试，测试结果如图3所示。

使用单独时间戳或列限定符等很难达到提高检索效率的目的，当用户无法使用行键中的字段或使用其它数据进行查询时，即对不匹配的数据查询起不到作用或作用很小，考虑将其进行组合进行行键设计以提高检索效率。

方法三：组合方法。采用组合方法是可行的，但为了提高数据查询性能，将行键索引放在内存中进行缓存，如果使用组合方法将表中全部数据放人行键中会使其长度过长，将不得不占用更大内存，从而导致内存利用率降低。所以在进行组合时一方面要考虑行键长度，尽可能使行键长度较短，另一方面，针对处理的数据特点及用户检索习惯，将常用字段作为行键的一部分进行组合。结合以上两个原则设计行键则能在一定程度上提高数据查询效率。

通过以上分析发现：行键设计无法达到尽善尽美，只能根据具体情况，在设计时根据权重进行取舍，从表中找出针对该场景最关键的查询条件进行设计，使检索效率相对较高。

3.2以写为主的行键设计方法

行键是一串二进制码流，使用字典顺序由低到高地存储在表中。在进行Region划分吋必须基于行键进行，通常情况下行键生成是采用ID自增的方式，或默认采用时间戳作为行键起始值。目前针对时间序列数据的行键设计方法有很多，随着各种传感器、监控系统等智能设备的逐渐普及，由它们产生数据最为突出的特点是时间序列性很明确，针对这类数据最棘手的问题则是如何避免系统在写入过程中因操作过分集中于某个Region而产生读写热点，从而使系统整体性能下降。思考如何将这类数据分散存储到每个Region服务器上是解决问题的出发点。有很多方法都能达到目的，当前最主要的几种行键设计方法有：

（1）随机生成行键法。通过散列函数（如：MD5）在原来生成的相邻键前加上随机生成的一个前缀，通过该方法生成的行键可以解决原本行键造成的负载不均衡问题，将写负载相对均匀地分布到Region上，但缺点是：每次只能检索一行数据，无法再按时间范围扫描数据。如：

Byte[]row key=MD5（timestamp）

（2）哈希前缀法。使用哈希函数将原本行键中选定的一部分进行哈希运算后作为行键前缀，从而避免将时间序列作为行键造成的寫入热点问题，同样也能达到负载均衡。如：

但该方法的缺点是：行键离散化使得之前连续的数据被离散到不同Region中，虽然解决了写入热点问题，却导致检索一个连续范围内的数据时系统性能下降，这是以牺牲查询性能为代价实现的。

（3）提升字段法。行键以时间戳为前缀，提升字段法是指改变生成时间戳的位置，使用其它字段作为前缀，或添加其它字段作为前缀，让连续递增的时间戳在行键中的权重降低，这种组合行键方法也可以解决写入热点问题。

（4）反转行键法。将原本相邻的行键按字节顺序进行反转，使新生产的行键顺序离散化，从而实现热点均衡。

4案列设计

4.1数据源分析

智慧水务系统通过数据采集仪、无线网络、水质水压表等多种在线监测设备实时感知城镇供排水系统运行状态，并在该循环过程中建立水务互联网。通过在此基础上对一些数据进行分析处理，不仅可以减少人力支出，而且可以从各种智能设备上获取有价值的数据，并结合一定分析手段对数据加以利用。智能水务系统的不断完善使供水过程监控更加智能化和协调化，随着经济的发展与城市规模的逐渐扩张，各城市水司供水半径扩大，管网复杂程度提高，人力成本与运营难度也不断提高。由于人们对安全、优质、高效供水服务的需求越来越迫切，以及阶梯水价振幅政策的实施，对水务运营也提出了更高要求。通过物联网、信息化手段改变传统自来水公司的运营模式与经营模式，构建基于物联网、云计算的智慧水务管控一体化平台，已成为水务公司提高运营效率的必然选择。另外，考虑到掌上办公的便捷性，各种结合移动端的APP也相继出现，为打造安全、优质、高效、低碳、环保的供水新模式、建设现代水务企业提供了有效途径，也使现有数据存储方法面临巨大挑战。为使智慧水务系统中从各种传感器与监控仪器等智能设备收集而来的以时间序列为主的数据能为整个决策过程提供更大的价值支持，在分析HBase数据模型、行键设计原则基础上，针对这类数据进行行键设计相关讨论。

4.2综合方案设计

使用以上几种方法并结合城镇居民用水数据信息，对HBase数据库的读写性能进行测试。测试数据约有150万行，得到如表1所示结果。

根据表中的测试结果发现，在4种方法中，字段提升法与哈希前缀法相比其它两种方法的综合性能更好。理想情况下行键设计是在存储时让关联性强的数据存储在同一个Region或相邻Region上，同时在进行大量数据写入操作时能使数据均衡分布在每个Region上，不会造成写入热点问题。智慧水务系统中存储的数据主要包括：社区ID、用水时间、用水量情况等数据。结合以上测试结果与智慧水务系统中要存储的时间序列数据，虽然针对以写为主的智慧水务系统而言，哈希前缀法与提升字段法综合性能相近，但在数据检索时哈希前缀法的查询效率并不高，所以本文采用提升字段法对行键进行设计。

5设计

其中，CuID为居民社区号，使用社区号作为行键起始值，一方面可以让同一社区的居民情况存储在同一个Re-gion上，还可以避免将时间戳作为行键起始值造成的热点问题。Timestamp为用户用水产生的时间，将时间戳放在中间位置是根据用户日常查询习惯，该设计方法解决了用户在查询用水情况时因行键不匹配而导致的检索效率降低问题。将HomeID（住户号）作为行键最后一部分，将3部分按该方式进行组合，从而设计出初步的行键模型。在初步行键设计中利用提升字段法，对最初的时间戳降低权重，从最左边移到了中间。

建表后对该行键方法进行测试后发现，用户在查询数据时通常会查询最近用水情况，所以希望数据存储时能将最新的数据存放在最前面，实现时间降序排列。根据该需求分析，在原行键上进行修改，行键设计方法如下：

row

key=>

最后，本文对两种行键设计方法进行实验测试，测试发现改进后的行键设计方法提高了数据读写性能，也由此说明行键设计既要结合具体应用场景，还要根据数据处理需求，才能最终实现行键设计的相对合理化。

6结语

行键设计一直是HBase数据存储中的研究重点，本文研究发现行键设计依赖于具体应用场景，针对不同的存储管理需求，行键设计方法也有所区别。本文从以检索为主和以写人为主两方面对行键设计进行研究，并对随机生成行键法、哈希前缀法、提升字段法和反转行键法4种方法进行测试，之后根据智慧水务系统数据存储需求选择其中的提升字段法进行行键设计，通过再次测试对初始方法进行改进，最终得到相对合理的行键设计方法，证明了该行键设计方法在时间序列数据处理上的有效性。接下来将对该方法作进一步研究，根据行键设计原则精简行键长度，实现优化目的。