HBase基本知识介绍及典型案例分析

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
云数据库 Tair(兼容Redis),内存型 2GB
简介: 本文来自于2018年10月20日由中国 HBase 技术社区在武汉举办的中国 HBase Meetup 第六次线下交流会。 HBase基本知识介绍及典型案例分析 PPT 下载:http://hbase.group/slides/162 本次分享的内容主要分为以下五点: HBase基本知识; HBase读写流程; RowKey设计要点; HBase生态介绍; HBase典型案例分析。

本文来自于2018年10月20日由中国 HBase 技术社区在武汉举办的中国 HBase Meetup 第六次线下交流会。

HBase基本知识介绍及典型案例分析 PPT 下载:https://yq.aliyun.com/download/3259 


d4f6f4f645cce58f58e5686061300e9759d1444e


本次分享的内容主要分为以下五点:

  • HBase基本知识;

  • HBase读写流程;

  • RowKey设计要点;

  • HBase生态介绍;

  • HBase典型案例分析。

首先我们简单介绍一下 HBase 是什么。


6521f2acef4cd23eeced0514945a547ab2829f10


HBase 最开始是受 Google 的 BigTable 启发而开发的分布式、多版本、面向列的开源数据库。其主要特点是支持上亿行、百万列,支持强一致性、并且具有高扩展、高可用等特点。

既然 HBase 是一种分布式的数据库,那么其和传统的 RMDB 有什么区别的呢?我们先来看看HBase表核心概念,理解这些基本的核心概念对后面我理解 HBase 的读写以及如何设计 HBase 表有着重要的联系。


7e301eb3d0c9b799e66c80d0ce50b8b313911ee1


HBase 表主要由以下几个元素组成:

  • RowKey:表中每条记录的主键;

  • Column Family:列族,将表进行横向切割,后面简称CF;

  • Column:属于某一个列族,可动态添加列;

  • Version Number:类型为Long,默认值是系统时间戳,可由用户自定义;

  • Value:真实的数据。

大家可以从上面的图看出:一行(Row)数据是可以包含一个或多个 Column Family,但是我们并不推荐一张 HBase 表的 Column Family 超过三个。Column 是属于 Column Family 的,一个 Column Family 包含一个或多个 Column。

在物理层面上,所有的数据其实是存放在 Region 里面的,而 Region 又由 RegionServer 管理,其对于的关系如下:


68f2b7fd34ebda5bdf2032291c9c9cc48f6a0d3e


  • Region:一段数据的集合;

  • RegionServer:用于存放Region的服务。

从上面的图也可以清晰看到,一个 RegionServer 管理多个 Region;而一个 Region 管理一个或多个 Column Family。
到这里我们已经了解了 HBase 表的组成,但是 HBase 表里面的数据到底是怎么存储的呢?


d31b9bd2f34e579ea0b3549b31b75f809602269e


上面是一张从逻辑上看 HBase 表形式,这个和关系型数据库很类似。那么如果我们再深入看,可以看出,这张表的划分可以如下图表示。


4116d1f59767be6d613c9785c687581a1ab7c29e


从上图大家可以明显看出,这张表有两个 Column Family ,分别为 personal 和 office。而 personal 又有三列name、city 以及 phone;office 有两列 tel 以及 address。由于存储在 HBase 里面的表一般有上亿行,所以 HBase 表会对整个数据按照 RowKey 进行字典排序,然后再对这张表进行横向切割。切割出来的数据是存储在 Region 里面,而不同的 Column Family 虽然属于一行,但是其在底层存储是放在不同的 Region 里。所以这张表我用了六种颜色表示,也就是说,这张表的数据会被放在六个 Region 里面的,这就可以把数据尽可能的分散到整个集群。

在前面我们介绍了 HBase 其实是面向列的数据库,所以说一行 HBase 的数据其实是分了好几行存储,一个列对应一行,HBase 的 KV 结构如下:


62f80f1af8d8ad001f9e4a6b01d511672407de1c


为了简便期间,在后面的表示我们删除了类似于 Key Length 的属性,只保留 Row Key、Column Family、Column Qualifier等信息。所以 RowKey 为 Row1 的数据第一列表示为上图最后一行的形式。以此类推,整个表的存储就可以如下表示:


78a5433280c94ac5c322184faa3a96fb4563b668


大家可以从上面的 kv 表现形式看出,Row11 的 phone 这列其实是没有数据的,在 HBase 的底层存储里面也就没有存储这列了,这点和我们传统的关系型数据库有很大的区别,有了这个特点, HBase 特别适合存储稀疏表。

我们前面也将了 HBase 其实是多版本的,那如果我们修改了 HBase 表的一列,HBase 又是如何存储的呢?


17fc37d041442dd63a86a217f4fe06268b18c163


比如上如中我们将 Row1 的 city 列从北京修改为上海了,如果使用 KV 表示的话,我们可以看出其实底层存储了两条数据,这两条数据的版本是不一样的,最新的一条数据版本比之前的新。总结起来就是:

  • HBase支持数据多版本特性,通过带有不同时间戳的多个KeyValue版本来实现的;

  • 每次put,delete都会产生一个新的Cell,都拥有一个版本;

  • 默认只存放数据的三个版本,可以配置;

  • 查询默认返回最新版本的数据,可以通过制定版本号或版本数获取旧数据。

到这里我们已经了解了 HBase 表及其底层的 KV 存储了,现在让我们来了解一下 HBase 是如何读写数据的。首先我们来看看 HBase 的架构设计,这种图来自于社区:


34d4213300521eef7e7a13b3de1870e7dea0b9e1


HBase 的写过程如下:

  • 先将数据写到WAL中;

  • WAL 存放在HDFS之上;

  • 每次Put、Delete操作的数据均追加到WAL末端;

  • 持久化到WAL之后,再写到MemStore中;

  • 两者写完返回ACK到客户端。


bd5dce78403993e64b09a0cdcc1bb21e55b20375

MemStore 其实是一种内存结构,一个Column Family 对应一个MemStore,MemStore 里面的数据也是对 Rowkey 进行字典排序的,如下:

6805093263a79a813377ef8c34d549c4187f13bb

既然我们写数都是先写 WAL,再写 MemStore ,而 MemStore 是内存结构,所以 MemStore 总会写满的,将 MemStore 的数据从内存刷写到磁盘的操作成为 flush:

b5741a5d97bb783dc98ea9ffd5f3adb1d4b3ce3d

以下几种行为会导致 flush 操作

  • 全局内存控制;

  • MemStore使用达到上限;

  • RegionServer的Hlog数量达到上限;

  • 手动触发;

  • 关闭RegionServer触发。

每次 flush 操作都是将一个 MemStore 的数据写到一个 HFile 里面的,所以上图中 HDFS 上有许多个 HFile 文件。文件多了会对后面的读操作有影响,所以 HBase 会隔一定的时间将 HFile 进行合并。根据合并的范围不同分为 Minor Compaction 和 Major Compaction:


517aa43d7afd11cb495f1b667026af874208461a


Minor Compaction: 指选取一些小的、相邻的HFile将他们合并成一个更大的Hfile。
Major Compaction:

  • 将一个column family下所有的 Hfiles 合并成更大的;

  • 删除那些被标记为删除的数据、超过TTL(time-to-live)时限的数据,以及超过了版本数量限制的数据。

HBase 读操作相对于写操作更为复杂,其需要读取 BlockCache、MemStore 以及 HFile。


bfa0d81d9d0e6274203e372ad7ef0dd403573206


上图只是简单的表示 HBase 读的操作,实际上读的操作比这个还要复杂,我这里就不深入介绍了。

到这里,有些人可能就想到了,前面我们说 HBase 表按照 Rowkey 分布到集群的不同机器上,那么我们如何去确定我们该读写哪些 RegionServer 呢?这就是 HBase Region 查找的问题,


58a076e378e568e8c2b5e829bddbd20aba552ff4


客户端按照上面的流程查找需要读写的 RegionServer 。这个过程一般是第一次读写的时候进行的,在第一次读取到元数据之后客户端一般会把这些信息缓存到自己内存中,后面操作直接从内存拿就行。当然,后面元数据信息可能还会变动,这时候客户端会再次按照上面流程获取元数据。

到这里整个读写流程得基本知识就讲完了。现在我们来看看 HBase RowKey 的设计要点。我们一般都会说,看 HBase 设计的好不好,就看其 RowKey 设计的好不好,所以RowKey 的设计在后面的写操作至关重要。我们先来看看 Rowkey 的作用


d45ed6a42c0689d16d1355b0452463904621e9c7


HBase 中的 Rowkey 主要有以下的作用:

  • 读写数据时通过Row Key找到对应的Region

  • MemStore 中的数据按RowKey字典顺序排序

  • HFile中的数据按RowKey字典顺序排序

从下图可以看到,底层的 HFile 最终是按照 Rowkey 进行切分的,所以我们的设计原则是结合业务的特点,并考虑高频查询,尽可能的将数据打散到整个集群。


86580d7030646261b49a52d1e1a46e343a184f07


一定要充分分析清楚后面我们的表需要怎么查询。下面我们来看看三种比较场景的 Rowkey 设计方案。


23a2a09a789dd9c9038c5869f0163370c9e030e7

dec20cd7af3c69d55dd8447da4551ebec9e6fe0c

14cc0fe9f8fa039f2b31853f92b0c571243dfd75


这三种 Rowkey 的设计非常常见,具体的内容图片上也有了,我就不打文字了。

数据如果只是存储在哪里其实并没有什么用,我们还需要有办法能够使用到里面的数据。幸好的是,当前 HBase 有许多的组件可以满足我们各种需求。如下图是 HBase 比较常用的组件:


61f0f8fe2a4e4813d8535e6e70f3f6b7d4fcf3a8


HBase 的生态主要有:

  • Phoenix:主要提供使用 SQL 的方式来查询 HBase 里面的数据。一般能够在毫秒级别返回,比较适合 OLTP 场景。

  • Spark:我们可以使用 Spark 进行 OLAP 分析;也可以使用 Spark SQL 来满足比较复杂的 SQL 查询场景;使用 Spark Streaming 来进行实时流分析。

  • Solr:原生的 HBase 只提供了 Rowkey 单主键,如果我们需要对 Rowkey 之外的列进行查找,这时候就会有问题。幸好我们可以使用 Solr 来建立二级索引/全文索引充分满足我们的查询需求。

  • HGraphDB:HGraphDB是分布式图数据库。依托图关联技术,帮助金融机构有效识别隐藏在网络中的黑色信息,在团伙欺诈、黑中介识别等。

  • GeoMesa:目前基于NoSQL数据库的时空数据引擎中功能最丰富、社区贡献人数最多的开源系统。

  • OpenTSDB:基于HBase的分布式的,可伸缩的时间序列数据库。适合做监控系统;譬如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储,查询。

下面简单介绍一下这些组件。


b7a861547bdcf9ff813b73d16f6511ecf6c184ab

4d1da656000887ecc7083f1a2068778ffb014caa

43f7a8dc396d76a97774bb02db8aac5c9cd4bb7b

1a92e2b571a6ef43631a7084d250c450ffdbc85d

a65082695d6aac2d233cd8e97800df42fafccbda

5df40f7685b2a12129555874caf11cc9e5f1d91a


有了这么多组件,我们都可以干什么呢?来看看 HBase 的典型案例。


b02811af386ada8d63f68f3e950aa6249e09918e


HBase 在风控场景、车联网/物联网、广告推荐、电子商务等行业有这广泛的使用。下面是四个典型案例的架构,由于图片里有详细的文字,我就不再打出来了。


df6d1a0569583bc760f4eef597f1656a6a761a48

24f00b435679daf126ee3970c72ebd32ac068d04

eb7540e7c3f2ca62cdf7bb1e7eb668096ebc9eff

67c83cdf5232ae245e38e271dd8985e0cb40016c


另外,11月03日我们将在成都举办中国 HBase 第七届 HBase Meetup 会议。如果想参与分享可以直接来联系过往记忆(微信:iteblog),接下来社区的计划安排如下,如想来分享可以联系我。


e92fdade734287e0e144c0132b94071e34036bff



d3f2f0da5b6761a64c7049db7719525a2c492a0c


大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。


096973d69f34b1380151180fd0a8ff2cade5bced


HBase技术交流社区 - 阿里官方“HBase生态+Spark社区大群”点击加入:https://dwz.cn/Fvqv066s

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
  相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情: https://cn.aliyun.com/product/hbase   ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
3月前
|
分布式计算 大数据 分布式数据库
"揭秘HBase MapReduce高效数据处理秘诀:四步实战攻略,让你轻松玩转大数据分析!"
【8月更文挑战第17天】大数据时代,HBase以高性能、可扩展性成为关键的数据存储解决方案。结合MapReduce分布式计算框架,能高效处理HBase中的大规模数据。本文通过实例展示如何配置HBase集群、编写Map和Reduce函数,以及运行MapReduce作业来计算HBase某列的平均值。此过程不仅限于简单的统计分析,还可扩展至更复杂的数据处理任务,为企业提供强有力的大数据技术支持。
50 1
|
6月前
|
SQL 关系型数据库 MySQL
Sqoop【付诸实践 01】Sqoop1最新版 MySQL与HDFS\Hive\HBase 核心导入导出案例分享+多个WRAN及Exception问题处理(一篇即可学会在日常工作中使用Sqoop)
【2月更文挑战第9天】Sqoop【付诸实践 01】Sqoop1最新版 MySQL与HDFS\Hive\HBase 核心导入导出案例分享+多个WRAN及Exception问题处理(一篇即可学会在日常工作中使用Sqoop)
243 7
|
6月前
|
分布式计算 Hadoop 关系型数据库
Hadoop任务scan Hbase 导出数据量变小分析
Hadoop任务scan Hbase 导出数据量变小分析
95 0
|
6月前
|
数据可视化 JavaScript 关系型数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(五)FineBI可视化
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(五)FineBI可视化
121 0
|
6月前
|
SQL 消息中间件 关系型数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(四)实时计算需求及技术方案
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(四)实时计算需求及技术方案
176 0
|
6月前
|
SQL 消息中间件 分布式数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(三)离线分析
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(三)离线分析
122 0
|
6月前
|
消息中间件 存储 数据采集
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(二)数据源
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(二)数据源
104 0
|
6月前
|
存储 消息中间件 分布式数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(一)案例需求
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(一)案例需求
100 0
|
11月前
|
存储 SQL 分布式数据库
分布式数据恢复-hbase+hive分布式存储数据恢复案例
hbase+hive分布式存储数据恢复环境: 16台某品牌R730XD服务器节点,每台物理服务器节点上有数台虚拟机,虚拟机上配置的分布式,上层部署hbase数据库+hive数据仓库。 hbase+hive分布式存储故障&初检: 数据库文件被误删除,数据库无法使用。 通过现场对该分布式环境的初步检测,发现虚拟机还可以正常启动,虚拟机里面的数据库块文件丢失。好在块文件丢失之后没有对集群环境写入数据,底层数据损坏可能性比较小。
|
存储 SQL 分布式数据库
记录一次 Hbase 线上问题的分析和解决,并分析总结下背后的知识点 - KeyValue size too large
记录一次 Hbase 线上问题的分析和解决,并分析总结下背后的知识点 - KeyValue size too large