Co2y's Blog

HBase应用场景

发表于 | 分类于 |

HBase特点

  1. HBase的数据文件HFile放在HDFS上，由HDFS提供数据冗余，保证可靠性。

  2. HDFS本身是一个append的文件系统，不适合随机读取和更新删除操作，HBase的一个功能就是利用LSM架构配合compaction提供随机访问和删除修改功能。

  3. HBase只提供唯一的行级索引rowkey，rowkey是按字典序排好的，由一段rowkey组成的region会split分布到集群的各个RegionServer上，每个RegionServer以region为单位管理若干个region，因此具有很好的水平扩展性。rowkey这种按key值范围sharding的方法，可以实现负载均衡，很好的支持大规模集群，且适合范围查询。

  4. HBase的前身是BigTable，支持很大的数据量，这种设计方式可以支持百亿行×百万列×上万个版本。

  5. HBase采用LSM架构，数据写内存记录log即返回，因此put效率很高，delete也是一种特殊的put。当内存满时才flush到磁盘上，继而可能触发compaction等后续操作。一般来说，这种结构的scan效率要比put低，因为scan的时候既需要考虑内存中的memstore，也要考虑HDFS上的各个HFile，当HFile较多时，需要多次磁盘IO导致效率不高。compaction的作用就是通过短时间的IO操作减少后续scan的延迟。

  6. 在CAP理论中，HBase选择了CP。HBase保证了行级OLTP，这点应用在一些线上的实时系统中来保证数据的一致性。

  7. HBase按列族存储，HBase在HDFS上的存储目录结构为 表名/region名/列族名/HFiles。通常HBase支持很多列存储，把这些列合理放到不同的列族中（例如经常一起访问的放在同一个列族）可以极大的提高查询效率。

  8. HBase的表有宽表和高表之分，通常的建议是用高表，主要的好处是宽表太宽不利于找到split的点，且高表把一个维度放到rowkey中更加利于查询。但是宽表也有好处，例如宽表可以保证行级的一致性，在某些情况下宽表更节省空间。

  9. HBase更像是一个存储系统，通常不适合在上面直接做分析。HBase的交互方式除了put，get等API，还可以用HBase提供的coprocessor把一些计算放在服务器端执行。此外就是把HBase和其它系统集成使用，比如Hive、Storm、Spark等。

典型应用

应用一 地理信息系统

应用介绍

地理信息系统（GIS）的一个用途是提供基于位置的服务（LBS），例如给出附近服务的一些信息，或者提供最近的服务位置。

HBase表设计

GIS通常是一个多维数据集，至少需要存储经度和纬度两个维度信息，因此主要考虑如何将这两个维度信息存储到HBase的表中。考虑到rowkey的唯一性，一种简单的存储方式是把经度和维度拼接成rowkey，但是由于rowkey的字典序只能保证相近经度（或纬度）的点存储在一起，而另一个维度的特征则不能体现出来，在范围查询（例如附近有哪些餐馆？）时效率较低。

利用GeoHash可以将经纬度两个维度的信息编码成一个rowkey，并且相近的点他们的字典序也是相近的。这样在范围查询的时候返回的点的数目将大大降低，提高查询效率。GeoHash的原理这里不介绍，它的表现形式大致如下：

GEOHASH X Y ID NAME
dr5rugb9rwjj -73.96993203 40.75815170 442 Fedex Kinko’s
dr5rugbge05m -73.96978387 40.75850573 388 Barnes & Noble
dr5rugbvggqe -73.96974759 40.75890919 441 Fedex Kinko’s
dr5rugckg406 -73.96910155 40.75873061 564 Public Telephone
dr5ruu1x1ct8 -73.96880474 40.76048717 472 Juan Valdez NYC
dr5ruu29vytq -73.97000655 40.76098703 593 Starbucks
dr5ruu2y5vkb -73.96974993 40.76170883 219 Startegy Atrium and Cafe
dr5ruu3d7x0b -73.96873588 40.76107453 463 Smilers 707
dr5ruu693jhm -73.96746533 40.76089302 525 McDonalds

可以看到GeoHash将两个维度信息编码成了一个string，且地理位置上更近的点，他们的字典序也更加接近。

HBase功能

利用GeoHash将经纬度编码到rowkey，主要用到了HBase的rowkey索引特点，rowkey按字典序排序，在空间上相近的点在磁盘上存储的点也是接近的。rowkey可以高效的进行range scan，这在地图上正好对应于一个范围扫描，可以很好的满足查询需求。

应用二 时间序列OpenTSDB

应用介绍

OpenTSDB是一个基于HBase的分布式的可伸缩的时间序列数据库，它的主要作用是做监控系统，例如收集大规模集群的监控数据（包括网络设备，操作系统、应用程序等）并进行存储和分析查询。通常数据是不断插入的，支持永久存储，每个metric的数据存储支持到秒级。可以看出OpenTSDB的监控项是非常多的，例如每台服务器每秒都要监控CPU、内存、磁盘等情况。

HBase表设计

考虑如下的一组数据：

1
2
3
4
metric: proc.loadavg.1m
timestamp: 1234567890
value: 0.42
tags: host=web42，pool=static

一般的设计可能是把metric，timestamp这些组成rowkey，value作为column存储，例如RowKey=metric|timestamp|value|host=web42|pool=static，Column=v，Value=0.42。但这会有一些问题，例如空间占用过大等。

OpenTSDB是用两张表来存储，tsdb和tsdb-uid。

tsdb

在tsdb中，它的rowkey和上面说的rowkey相似，只不过OpenTSDB把每个部分又做了映射来节约存储，例如 metric-->3字节整数。对于column来说，OpenTSDB将一个小时的数据，保存在一行里面。所以上面的timestamp（1234567890），会对小时取模（3600），得到1890，表示的是它是在这个小时里面的第1890秒。然后将1890作为column name，而0.42即为column value。

tsdb-uid

tsdb-uid用来保存proc.loadavg.1m tags:host tags:pool这些名字的映射关系。格式为：
RowKey( 自增id，3字节数组），name:metrics，name:tagk，name:tagv。同时也对它们之间的反向关联关系也作了展开存储。

HBase功能

  1. 首先OpenTSDB选择HBase是因为监控的数据量很大，超过单机数据库的容量，因此需要能够水平扩展的分布式数据库。可以支持大量metric的存储和灵活地添加metric。

  2. 时序数据容易面临热点问题，OpenTSDB没有把timestamp放在rowkey开始的位置，而是放了metric，这样既可以根据metric快速查询又避免了热点问题。

  3. 为了解决rowkey每个部分不定长和空间占用问题，使用了tsdb-uid这张表来做映射。

  4. 把一个小时内的3600秒作为column来存储，可以进一步减少空间占用。

应用三 音乐站用户属性库

应用介绍

案例来源于HBase企业应用开发实战第7章。音乐站用户属性库包括物料数据、用户属性信息和用户行为信息。

  • 物料数据：包含音乐或MV源文件、描述信息。
  • 用户属性信息：用户注册信息。
  • 用户行为信息：报活记录、播放记录、点击记录、搜索记录、下载记录和用户标记记录。

系统需要利用上述信息来提供业务支持，为此建立了以下三个库：用户行为库，用户属性库和音乐标签库。

  • 用户行为库：用户播放记录，用户点击宏观分类，用户喜欢或不喜欢的点击记录，用户评分，用户搜索记录，用户下载记录，用户购买记录，用户分享记录。
  • 用户属性库：（1）基本维度：性别，年龄，所在地区，职业，月收入，学历，婚姻状况。（2）音乐维度：喜欢的音乐类型、风格、地域，专题等。（3）商业维度：兴趣爱好，广告标签。（4）其它维度：个性标签。
  • 音乐标签库：标签组（地域、语言、流派、曲风等），标签（每个标签组的细化内容，例如地域有内地、欧美、港台、日韩等），数据来源。

对于这些内容有如下使用场景：

  • 查询用户信息。查询喜欢某个音乐标签的所有用户、独立用户数等。查询某个用户的所有相关音乐。
  • 查询音乐信息。查询一个音乐标签对应的所有音乐。查询音乐id对应的音乐信息。
  • 维护标签。标签组和标签的CRUD。
HBase表设计

在该案例中创建了如下5张HBase表：

  • music_user_bhvr_attr，注册用户属性表。rowkey是userid，建立bhvr列族保存用户的行为，建立attr列族保存用户的基本信息。
  • music_user_bhvr_attr_index，索引表，索引音乐地域和userid。
  • music_user_bhvr_attr_nreg，非注册用户属性表，因为注册用户和非注册用户在属性信息和行为信息上有很大的差异，因此区别对待。
  • music_user_bhvr_attr_nreg_index，非注册用户属性表的索引表。
  • music_tags，音乐标签表，存储音乐标签信息。rowkey是音乐id。将各个标签存放在一个列族中。
HBase功能

这个案例用到了许多HBase的基本功能：

  • 首先rowkey是userid或者musicid，可以根据用户和音乐进行快速查询。
  • 对于需要反向查询的情况，需要建立索引表，HBase本身只能支持根据rowkey查询和全表扫描，为了尽量避免全面扫描，需要索引表配合取到数据表中的rowkey。
  • 索引的维护。对于全量数据可以通过离线MapReduce的方式来生成，对于增量数据可以通过HBase提供的coprocessor的hook函数来实时维护。
  • 将读写频率差距比较大的列划分到不同的列族，比如上述music_user_bhvr_attr表中就分别由bhvr、attr等列族存放一个用户的不同信息。
  • 关于版本的定义。HBase支持多version存储，例如查询一个用户3个月内播放过的音乐，可以将这些播放记录以不同的version存放在一行中。这里需要手动设置version为一个较大的值，默认是3。