大数据与HBase

(一)数据库的发展

数据库诞生于二十世纪的50年代，当时的应用场景仅限于国防、科研等大型应用场景。70年代小型机开始出现，随之出现的是我们所熟悉的关系型数据库，如IBM的DB 2、Oracle、INGRES等。90年代PC机开始普及，一些企业开始做信息化转型，ERP/CRM/财务软件开始涌现，这些软件都是运行在廉价的X86服务器和PC机上，所用的数据库是开源或商业的MySQL、SQL Server、PostgreSQL 等。2000年后进入互联网大数据时代，数据急剧膨胀，传统的单机关系数据库已经无法满足时代处理数据的需求，因此开始涌现一些像HBase，Redis、MongoDB的NoSQL数据库。

2015年之后，我们进入了云时代，涌现一批云原生数据库，如阿里云的Lindorm、AnalyticDB及PolarDB等，本文聚焦大数据时代，下面来看一下大数据发展的趋势。

(二)数据趋势

如上图所示，大数据发展的显著特征是数据量呈几何基数爆炸增长。

经统计，2005年刚进入互联网时，全网的数据为0.1个ZB(1ZB=100万PB)左右。到了2020年，数据量急剧增长到了47 个ZB。随着 IoT万物互联的兴起，预计到2025年的时候，数据量会达到163个ZB。

除了数据量越来越多，数据种类也是日益丰富。如聊天记录，网购订单记录以及物流的详情，包括风控、机器学习、视频、音频、图像等。要从这些海量的数据中去挖掘出有价值的信息，是一件非常困难的事情。

(三)大数据的特点

大数据具有如下四个特点:

• 大容量

1)体量大，增长快

2)水平扩展成为基本需求 

• 半结构化 

1)丰富的数据类型

2)列具有发散性

• 高速度

1)高速读写
2)往往会遇到IO瓶颈

• 真实性

1)脏数据成为常态
2)数据质量挑战大 从上面四个特点可以看出，传统RDBMS已经无法满足大数据需求。

(四)Google的三驾马车

面对上述问题，Google率先提出处理大数据的三驾马车:GFS、BigTable和MapReduce。

它们的设计哲学很简单，就是把单机变成分布式的处理架构，同时这个软件能够运行在比较廉价的商业X86服务器上。

GFS(Google File System)

1. 分布式文件系统
2. Master+ChunkServer
3. 追加模型

MapReduce

1. 分布式计算系统
2. 离线批处理
3. Map-Reduce模型

BigTable

1. 分布式表格系统
2. Master+多TableServer
3. Schema Free

Google File System(GFS)是一个分布式文件系统，当遇到一台机器存不下一个文件，就把它切片然后分到多个机器上存储。

BigTable是一个分布式表格系统，当遇到一台机器存不下一个表格，就把它的数据进行分片，然后分布到各个机器上。

MapReduce是一个分布式计算系统，当遇到一台机器的算力不够，就把这些计算任务分到各个机器上，然后做Reduce把结果做汇总。

(五）BigTable和HBase

后来有人根据Google的三驾马车研发了一个开源系统叫做Hadoop，HBase基于BigTable论文在Hadoop生态中的开源实现。

(六)HBase的历史

2006年，HBase诞生于Powerset，一家从事于自然语言处理和搜索的创业公司，该公司之后被微软收购。 HBase基于BigTable论文实现，最初用途是为了解决Hadoop中随机读效率低下的问题。

2007年4月，HBase作为一个模块提交到Hadoop的代码库中，代码量为8000行。HBase最初的开发人员是Michael Stack和Jim Kellerman。

2010年5月，HBase成为Apache的*项目。同年，Facebook把HBase使用在其消息平台中，这是HBase大规模商业 化使用的开始。

(七)Apache HBase项目现状

• HBase仍然是Apache社区最活跃的项目之一。 
• 有众多来自中国的Committer/PMC。 
• 张铎目前为Apache HBase社区主席。

HBase的架构与原理

​

(一)HBase基本概念

HBase(Hadoop Database)是一个基于Google BigTable论文设计的高可靠性、高性能、可伸缩的分布式存储系统。 HBase有以下四个特点:

·数据模型
1)Schema Free

2)无数据类型

3)大宽表

4)行存储，列模型 

·系统架构 

1)原生分布式架构

2)自动分区

3)专为海量数据设计

·读写能力

1)高吞吐，低延迟

2)支持随机/范围查询

3)适用在线/离线场景

·特色功能

1)TTL

2)多版本

3)离线导入

4)Coprocessor

5)......

(二)HBase数据模型

上方为数据模型，HBase所有数据都存储在一个表格里，表格下面有不同的列簇，每一个列簇里有非常多的行，每一行里 有非常多的列。因为HBase是一个松散Schema架构，不同行的列可以是不一样的，比如row1这行没有ColumnB，那么 这一列不会占用存储空间。同时，每一列可以有不同的值，这些值可以用timestamp作为版本号来区分。

HBase列簇的数据是存储在一起的，从这个角度上来说，HB是一个列储。但是，每个列簇里不同行，是按行的格式去存 储的，从这个角度上来说，可以认为HBase是一个行储。

然后，可以通过HBase的Rowkey和ColumnFamily加上Column的名字，再加上timestamp，作为key可以唯一确定一个 value，所以从这个角度，HBase也是一个KV存储。

(三)HBase架构

上图为HBase架构，它有三个非常明显的特征。

首先，它是一个原生分布式架构。在这个系统中，HMaster只是做一些分布式的协调工作，真正服务用户请求的是 HRegionServer，它是一个可以无限水平扩展的架构，用户数据会通过切片的方式负载均衡到每个HRegionServer上。

第三个主要特征是存储计算分离，HBase本身不存储任何数据，所有的数据都是存储在底层的HData上。

1.分布式设计

Zookeeper

1)存储Master、RegionServer、Meta表的服务器地址;

2)存储Table的状态;
3)存储Region分配时的状态。

HMaster

1)主备模式，利用Zookeeper协调;

2)负责Region分配，负载均衡;

3)负责Region管理，灾难恢复。 

HRegionServer 

1)维护Region状态;

2)负责处理put/get/scan等IO请求;

3)向Master汇报监控状态。

Client

1)数据增删改查操作;

2)负责数据的路由信息;

3)通过Cache Region位置加速访问。 

2.数据分片

上方为HBase的数据分片。它是一个范围分片，把数据按照范围分布在各个Region里。这样的好处是可以根据范围从头 查到尾，而不是像哈希分区一样，分区之间都是无序。范围分片可以有序地把这一个表从头遍历到尾，当数据写到一个 Region中，这个Region会变大，当它变大到一定的阈值之后，HBase会自动把它分裂成两个Region，然后通过负载均 衡的算法，把这些Region平均分配到不同的Region Servers上。

当运行的时间较长，Region可能数据会空掉，此时可以在线发起一个Merge，把两个Region Merge在一起，从而减少内 存占用。因此，HBase在分片这一方面是非常方便的。

3.存储计算分离

HBase本身不会存储任何数据，它本身一些读的Cache和写的MemStore，主要是做读写缓冲，主要的持久化都会发生在 HDFS上，这样做有什么好处呢?

首先，它可以做快速的负载均衡，比如RegionServerA负载比较高了，要把RegionServerA迁移到RegionServerB上 去，那么它只需要在RegionServerA上发起一个关闭命令，然后在RegionServerB上打开Region所在的HDFS文件，就 可以开始服务，完全不用搬迁数据，这个速度也是非常快，基本在百毫秒级别。

有了存储计算分离之后，还可以独立扩缩计算节点和存储节点，当计算不够用的时候，可以单独去扩RegionServer。当 存储不够用的时候，可以单独扩大存储节点。

同时，使用HBase开源软件之后，还可以做成本优化，利用HDFS的异构介质引入像OSS、S3这样的低成本存储来降低 成本。也可以利用开源技术，比如Erasuer coding来降低我们的存储大小，也是为了降低成本。

(四)HBase读写原理

1.请求路由

首先，我们来看一下客户端的路由请求。

客户端如果要发送一个请求到服务器，比如要读写某一行数据，首先会去跟Zookeeper要meta region所在的RegionServer 地址，之后就会往meta region所在的Server发请求，问所要的数据在哪个位置。之后直接往RegionServer发信息读写 数据，Client也会把这次成功请求的信息缓存在本地，当下一次要访问这个范围数据的时候，就不需要去跟Zookeeper和 RegionServer做交互，可以直接访问这个服务器。

当然，如果发生了负载均衡，Region已经不在这个服务器上，HBase再往这个服务器发信息的时候，它会收到一个报错，之后它又会重新开启这样的路由操作，直到找到这一个Region新的位置。

2.LSM-Tree

说到HBase的读写，不得不提LSM-Tree架构。HBase使用LSM-Tree(Log-Structured Merge-Trees)作为存储模型。

使用LSM-Tree的好处是可以把随机写变成顺序写，因此它的读写吞吐比使用B+树的引擎数据库要高出非常多。在写入的时候，首先HBase把数据缓存在MemStore里，然后顺序地写一个Log来做灾难恢复，然后内存中的数据也会定期地flush在磁盘上，flush出来数据是不能更改的，它相当于一棵不能更改的B树，当我们在读的时候，会把多个这样的文件 Merge起来做数据的读取。

3.读流程

上图为HBase的读流程。

在读的时候，首先会根据查询的条件选择到对应的Region和Store，这个Store就是前文所说的列簇，然后会根据条件去 过滤掉这些数据不可能存在的文件，把过滤出来的文件形成一个KeyValue Heap，然后再根据从小到大的顺序把这些数据 返回给客户端。

HBase 有 Memstore 和 Block Cache，Memstore 的位置和 HFile 的位置是等价的，会和HFile一起去构建Heap。所谓的 Block Cache，它实际上是文件某一个部分的 Cache。当要读到文件的部分时，发现有 Cache 的时候，可以不用去读这一 个磁盘，而是直接读内存。所以读写架构是先读Cache再做磁盘，把所有的数据都构成一个Heap来做LSM-Tree的架构。

(五)HBase特色功能

1.TTL

大家知道，在MySQL删除过期数据是非常麻烦的，首先要写个脚本，把这些过期数据的具体条件选出来，然后再一一 删。除此之外，还要控制脚本的速度，因为一旦删快，可能会影响到线上系统。

这种场景在HBase中得到妥善解决。

HBase的每一列都会有一个时间戳，如果没有指定时间戳，时间戳默认是这一列数据的写入时间。根据这个时间戳可以设 置一个TTL过期时间，当这一列数据超过了TTL过期时间，HBase会自动删掉过期数据。

特性介绍

1)对于每一行中的每一列数据，系统都保存了其最后更新时间;
2)以秒为单位来设置TTL(Time To Live)长度，每一行中的每一列数据一旦达到了到期时间，系统将自动删除;

3)TTL设置支持表、行、列多个维度。

使用场景
1)适用于无需永久保存的数据;
2)常用语日志、监控、轨迹、浏览记录、费用详单等场景。

2.多版本

特性介绍

1)当数据更新后，之前旧版本仍然可以被访问;

2)旧版本的数量可以设定至多达上百万;

3)系统自动删除多余的旧版本。

使用场景

1)适用于需要维护最近N次变更值的数据，如浏览记录、轨迹记录、登录记录、交易记录等;

2)常用于实时推荐、安全风控、营销圈人等场景。

例如:若保留版本数为100，则系统中会为设备1001的“上次登录时间”、“上次登录城市”字段最多保留100条记录，超出部分自动删除，等价于维护最近100次的登录时间和城市。

3.Bulkload

HBase的另一大特色功能是Bulkload。

HBase是一个LSM-Tree的架构，可以通过一些外部的系统，比如说Spark等，预先把这些数据做好排序，把它写在 HDFS上，然后通过Bulkload瞬间载入到HBase的Region当中，这些数据立马就可以读了。这个过程相比正常的API的少 了一些非常繁杂的计算过程，实现离线生成HFile，秒级加载海量数据。

4.Coprocessor

HBase还有一个特性是Coprocessor，有了Coprocessor之后，用户可以把HBase变成任何业务处理系统。HBase的 Coprocessor分为两类，分别是EndPoint和Observer。

EndPoint

1)分布式计算

2)算子下推

以前实现counter要去数据，必须把这些数据全部拉到客户端一条条地数。有了EndPoint Coprocessor之后，用户可以把 自己的逻辑嵌入到HBase的RegionServer上，通过HBase的分布式实现分布式计算以及计算下推。

像Count这个场景的话，可以先在RegionServer上把这些数据全部Count，然后再在客户端上做一个汇总，这样就少了非 常多的数据传输内容。

Observer

1)Hook HBase内部逻辑
2)实现触发器

通过Observer，用户可以任意用Hook HBase的函数来实现触发器的功能。

HBase使用场景

(一)HBase的生态

HBase的生态是非常丰富的,社区对HBase的定义也是专注做大数据存储，而上层这些场景我们更愿意交给生态产品去实现。

比如说HBase加一个Phoenix来实现SQL访问，也可以通过MR、Spark、Hive分析类组件给HBase做一个分析系统，也可以和Flink结合，成为Flink围表和结构表的存储，实现流式的计算。

(二)HBase的场景

有了这些生态之后，HBase基本上可以满足所有大数据场景的需求。

使用HBase原生API，可以实现一些非常高性能的访问场景，比如推荐画像、订单存储、Feeds流等。也可以在HBase基础上加一些组件来实现其他的场景的使用，比如加上Phoenix之后，我们可以把HBase变成一个NewSQL的数据库。

(三)使用HBase的公司

如此庞大数量的企业在使用HBase，其中一个很大的原因就是HBase背后没有一家商业公司做商业控制，所有用户可以 *下载HBase提供的代码，因此许多大厂都积极地向HBase贡献功能和代码，让HBase的功能变得更加丰富与强大， 性能和稳定性也在逐步提高。

总结

HBase非常好地契合了大数据存储的特性。

首先是HBase具有突出的数据写入能力，在面对大数据的特性时，可以快速地把数据处理消化。

另外HBase具有超强弹性升缩能力，在面对大数据的体量的时候，能够无限水平扩展来存储数据。

同时，HBase具有强大的业务适应能力，适应业务的变化多端，从而能够满足大数据的特点。

最后，HBase具有高效的多维删除能力，来满足大数据真实性、脏数据的特点，能够帮助用户快速处理脏数据和过期 数据。

简而言之，HBase是一个为大数据而生的数据库。