阿狗工具

产生背景

自 1970 年以来，关系数据库用于数据存储和维护有关问题的解决方案。大数据的出现后， 好多公司实现处理大数据并从中受益，并开始选择像 Hadoop 的解决方案。Hadoop 使用分 布式文件系统，用于存储大数据，并使用 MapReduce 来处理。Hadoop 擅长于存储各种格式 的庞大的数据，任意的格式甚至非结构化的处理。

Hadoop 的限制
Hadoop 只能执行批量处理，并且只以顺序方式访问数据。这意味着必须搜索整个数据集， 即使是最简单的搜索工作。 当处理结果在另一个庞大的数据集，也是按顺序处理一个巨大的数据集。在这一点上，一个 新的解决方案，需要访问数据中的任何点（随机访问）单元。

Hadoop 随机存取数据库
应用程序，如 HBase，Cassandra，CouchDB，Dynamo 和 MongoDB 都是一些存储大量数据和 以随机方式访问数据的数据库。

总结：

• 1、海量数据量存储成为瓶颈，单台机器无法负载大量数据
• 2、单台机器 IO 读写请求成为海量数据存储时候高并发大规模请求的瓶颈
• 3、随着数据规模越来越大，大量业务场景开始考虑数据存储横向水平扩展，使得存储服 务可以增加/删除，而目前的关系型数据库更专注于一台机器

一、Hbase的概念

Hbase 官网：hbase.apache.org

HBase是Hadoop的生态系统，是建立在Hadoop文件系统（HDFS）之上的分布式、面向列的数据库，通过利用Hadoop的文件系统提供容错能力。如果你需要进行实时读写或者随机访问大规模的数据集的时候，请考虑使用HBase！

HBase作为Google Bigtable的开源实现，Google Bigtable利用GFS作为其文件存储系统类似，则HBase利用Hadoop HDFS作为其文件存储系统；Google通过运行MapReduce来处理Bigtable中的海量数据，同样，HBase利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。

HBase 是一个高可靠、高性能、面向列、可伸缩的分布式数据库，主要用来存储非结构化和半结构化的松散数据，设计它的目的就是用于处理非常庞大的表——通过水平扩展的方式，用计算机集群就可以处理由超过 10 亿行数据和数百万列元素所组成的数据表。

HBase 数据库的要点

• 它介于 NoSQL 和 RDBMS 之间，仅能通过主键(rowkey)和主键的 range 来检索数据

• HBase 查询数据功能很简单，不支持 join 等复杂操作

• 不支持复杂的事务，只支持行级事务(可通过 hive 支持来实现多表 join 等复杂操作)。

• HBase 中支持的数据类型：byte[]（底层所有数据的存储都是字节数组）

• 主要用来存储结构化和半结构化的松散数据。

结构化、半结构化和非结构化

• 结构化：数据结构字段含义确定，清晰，典型的如数据库中的表结构

• 半结构化：具有一定结构，但语义不够确定，典型的如 HTML 网页，有些字段是确定的(title)， 有些不确定(table)

• 非结构化：杂乱无章的数据，很难按照一个概念去进行抽取，无规律性。

与 Hadoop 一样，HBase 目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加 计算和存储能力。

HBase 中的表特点

• 1、大：一个表可以有上十亿行，上百万列

• 2、面向列：面向列(族)的存储和权限控制，列(簇)独立检索。

• 3、稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。

• 4、无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一 张表中不同的行可以有截然不同的列。

HBase 与关系型数据库的简要比较

二、HBase 特点

1、海量存储

• HBase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。
• Hbase单表可以有百亿行、百万列，数据矩阵横向和纵向两个维度所支持的数量级都非常具有弹性。

2、列式存储
HBase是根据列族来存储数据的。这里的列式存储其实说的是列族存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。

3、多版本
Hbase每一列的数据存储有多个Version。

4、面向列
Hbase是面向列的存储和权限控制，并支持独立检索。列式存储，其数据在表中按照某列存储的，这样在查询只需要少数几个字段时，能大大减少读取的数据量。（实时动态增加列；单独对某一列做一些操作）

5、高并发
由于目前大部分使用HBase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。

6、稀疏性
稀疏主要是针对HBase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。

7、极易扩展
HBase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。
基于存储的扩展（HDFS），如果磁盘空间不够时，增加datanode节点或增加datanode节点的存储即可。

备注：RegionServer的作用是管理region、承接业务的访问，这个后面会详细的介绍通过横向添加Datanode的机器，进行存储层扩容，提升Hbase的数据存储能力和提升后端存储的读写能力。

8、高可靠性：WAL机制保证了数据写入时不会因集群异常而导致写入数据丢失：Replication机制保证了在集群出现严重问题时，数据不会发生丢失或损坏。而且Hbase底层使用hdfs，hdfs本身也有备份机制。

9、高性能：
底层的LSM数据结构和RowKey有序排列等架构上的独特设计，使得Hbase写入性能非常高。
Region切分、主键索引、缓存机制使得Hbase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能够到达毫秒级别。

LSM树，树形结构，最末端的子节点是以内存的方式进行存储的，内存中的小树会flush到磁盘中（当子节点达到一定阈值以后，会放到磁盘中，且存入的过程会进行实时merge成一个主节点，然后磁盘中的树定期会做merge操作，合并成一棵大树，以优化读性能。）

支持过期：HBase支持TTL（ Time To Live）过期特性，用户只需要设置过期时间，超过TTL的数据就会被自动清理，不需要用户写程序手动删除。

三、HBase 数据模型

逻辑上，HBase的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。但从HBase的底层物理存储结构（K-V）来看，HBase更像是一个多维度map（multi-dimensional map）

3.1 逻辑结构

Row_Key是必需有的，而且是唯一的，personal_info、office_info是列族，不同的列族是分开存储的。列族下面才是存储数据的列，而列是可以随便增加的。

上图是HBase表的逻辑结构，实际存储中，一个表可能是放在不同的服务器节点上面。另外存储是基于HDFS集群的，所以要先了解HDFS。

3.2、HBase的物理存储结构

以上只是一个基本的逻辑结构，底层的物理存储结构才是重中之重的内容，看下图

对于 HBASE 时间戳 用于标记 数据有效，默认情况下，每次查询数据只返回最新的时间戳标记的数据；

3.3、数据模型

NameSpace

• 命名空间，类似关系型数据库 DatabBase 概念，每个命名空间下有多个表。HBase有两个自带的命名空间，分别是hbase和default，hbase 中存放的是 HBase 内置的表，default 表是用户默认使用的命名空间。

• 命名空间的结构

• Table：表，所有的表都是命名空间的成员，即表必属于某个命名空间，如果没有指定，则在 default 默认的命名空间中。

• RegionServer group：一个命名空间包含了默认的 RegionServer Group。

• Permission：权限，命名空间能够让我们来定义访问控制列表 ACL（Access Control List）。例如，创建表，读取表，删除，更新等等操作。

• Quota：限额，可以强制一个命名空间可包含的 region 的数量。

Table(表)

• 表由一个或者多个列族构成。数据的属性如name、age、TTL(超时时间)等都在列族里边定义。定义完列族的表是个空表，只有添加了数据行以后，表才有数据。

Region(区域)

• Region 就是若干行数据的集合。HBase 中的 Region 会根据数据量的大小动态分裂，Region是基于HDFS实现的，关于Region的存取操作都是调用HDFS客户端完成的。同一个行键的 Region 不会被拆分到多个 Region 服务器上。

• Region 有一点像关系型数据的分区，数据存放在Region中，当然Region下面还有很多结构，确切来说数据存放在MemStore和HFile中。访问HBase 时先去HBase 系统表查找定位这条记录属于哪个Region ，然后定位到这个Region 属于哪个服务器，然后就到哪个服务器里面查找对应Region 中的数据。

RegionServer

• RegionServer 就是存放Region的容器，直观上说就是服务器上的一个服务。负责管理维护 Region。

Row(行)

• 一行包含多个列，这些列通过列族来分类。行中的数据所属的列族从该表所定义的列族中选取。由于HBase是一个面向列存储的数据库，所以一个行中的数据可以分布在不同的服务器上。

RowKey(行键)

• RowKey 类似 MySQL 中的主键，在 HBase 中 RowKey 必须有且 RowKey 是按照字典排序的，如果用户不指定 RowKey 系统会自动生成不重复字符串。查询数据时只能根据 RowKey 进行检索，所以 Table 的 RowKey 设计十分重要。

Column Family(列族)

• 多个列组合成一个列族。建表时不用创建列，在 HBase 中列是可增减变化的！唯一要确定的是列族，表有几个列族在开始创建时就定好的。表的很多属性，比如数据过期时间、数据块缓存以及是否使用压缩等都是定义在列族上的。
• HBase 会把相同列族的几个列数据尽量放在同一台机器上。

Column (列)

• HBase 中的每个列都由 Column Family(列族) 和 Column Qualifier(列限定符)进行限定，例如 info：name、info：age。建表时只需指明列族，而列限定符无需预先定义。

Cell

• 单元格，由 {rowkey, column Family：column Qualifier, time Stamp} 唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存储。

TimeStamp

• 时间戳，用于标识数据的不同版本（version），每条数据写入时如果不指定时间戳，系统会自动添加为其写入 HBase 的时间。并且读取数据的时候一般只拿出数据的Type符合，时间戳最新的数据。之所以按照Type取数据是因为HBase的底层HDFS支持增删查，但不支持改。

四、系统架构

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组件组成，HBase依赖于ZooKeeper和HDFS。

HBase客户端

• HBase客户端（Client）提供了Shell命令行接口、原生Java API编程接口、Thrift/REST API编程接口以及MapReduce编程接口。HBase客户端支持所有常见的DML操作以及DDL操作，即数据的增删改查和表的日常维护等。其中Thrift/REST API主要用于支持非Java的上层业务需求，MapReduce接口主要用于批量数据导入以及批量数据读取。

ZooKeeper

• HBase 通过 Zookeeper 来做 master 的高可用（通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行，如果 master 异常，会通过竞争机制产生新的 master 提供服务。）、RegionServer 的监控（通过 Zoopkeeper 来监控 RegionServer 的状态，当 RegionSevrer 有异常的时候，通过回调的形式通知 Master RegionServer 上下线的信息）、元数据的入口以及集群配置的维护等工作。

Hmaster

• 监控 RegionServer，为 RegionServer 分配 Region（维护整个集群的负载均衡，在空闲时间进行数据的负载均衡 ） ，维护集群的元数据信息，处理 region 的分配或转移（发现失效的 Region，并将失效的 Region 分配到正常的 RegionServer 上 ；当 RegionSever 失效的时候，协调对应 Hlog 的拆分）

HregionServer

• HregionServer 直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如下： 管理 master 为其分配的 Region，处理来自客户端的读写请求 ，负责和底层 HDFS 的交互（存储数据到 HDFS），负责 Region 变大以后的拆分，负责 Storefile 的合并工作 ，刷新缓存到HDFS，维护Hlog。

HDFS

• 为 Hbase 提供最终的底层数据存储服务，同时为HBase 提供高可用（Hlog 存储在HDFS）的支持，具体功能概括如下：提供元数据和表数据的底层分布式存储服务，保证的高可靠和高可用性 （数据多副本）

MemStore

• 内存缓存，达到一定缓存大小或者时间节点触发一次 flush，文件系统中生成新的 HFile，每次 Flush 的最小单位是 Region。每个 Column family 维护一个 MemStore。

Write-Ahead logs（WAL，Hlog）

• 用来容灾。当对 HBase 写数据的时候，数据会在内存MemStore中保留一段时间，MemStore达到一定的数据量（时间以及数据量阈值可以设定），数据再写进磁盘。但把数据保存在内存中可能有更高的概率引起数据丢失，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile 的文件中，然后再写入内存中，所以在系统出现故障的时候，数据可以通过这个日志文件重建。

Region

• Hbase表的分片，HBase 表会根据 RowKey 值被切分成不同的 region 存储在 RegionServer中，在一个 RegionServer 中可以有多个不同的 region。同一个行键的 Region 不会被拆分到多个 Region 服务器上。 一个HBase表被划分成多个Region，开始只有一个Region，后台不断分裂。

  
  
  
  
  

  一个表中包含多个列族，一个列族一个文件存储，region的切分是横向切分的，那么包含了多个列族。

Meta表

• 描述HBase表的表，元数据表。有了 Region 标识符，就可以唯一标识每个 Region。为了定位每个 Region 所在的位置，可以构建一张映射表。映射表的每个条目包含两项内容，一项是 Region 标识符，另一项是 Region 服务器标识。这个条目就表示 Region 和 Region 服务器之间的对应关系，从而就可以使用户知道某个 Region 存储在哪个 Region 服务器中。这个映射表包含了关于 Region 的元数据，因此也被称为“元数据表”，又名“Meta表”。使用 scan 命令可查看 Meta 表的结构，如图所示

  
  
  

• Meta 表中的每一行记录了一个 Region 的信息。RowKey 包含表名、起始行键和时间戳信息，中间用逗号隔开，第一个 Region 的起始行键为空。时间戳之后用.隔开的为分区名称的编码字符串，该信息是由前面的表名、起始行键和时间戳进行字符串编码后形成的。

• Meta 表里有一个列族 info。info 包含了三个列，分别为 Regioninfo、Server 和 Serverstartcode。Regionlnfo中记录了 Region 的详细信息，包括行键范围 StartKey 和 EndKey、列族列表和属性。

• Server 记录了管理该 Region 的 Region 服务器的地址，如 localhost:16201。Serverstartcode 记录了 Region 服务器开始托管该 Region 的时间。

• 当用户表特别大时，用户表的 Region 也会非常多。Meta 表存储了这些 Region 信息，也变得非常大。Meta 表也需要划分成多个 Region，每个 Meta 分区记录一部分用户表和分区管理的情况。（有了meta表，就可以得到region和HRegionServer的对应关系，可以进行Region定位：客户端通过 ZooKeeper 获取 Meta 表（分区表）存储的地址，首先在对应的 Regionserver上获取 Meta 表的信息（meta表存在Regionserver上），得到所需的Region对应的Regionserver的信息，然后从Region 服务器上找到所需的数据）

Store

• HFile 存储在 Store 中，一个 Store 对应 HBase 表中的一个列族。

HFile

• 这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile 是以 Hfile的形式存储在 HDFS 的。

五、HBase 使用场景

• 1、时空数据：主要是轨迹、气象网格之类，比如滴滴打车的轨迹数据主要存在 HBase 之中，另外大数据量的车联网企业，数据也都是存在 HBase 中。比如互联网出行，智慧物流与外卖递送，传感网与实时 GIS 等场景。

• 2、推荐画像：别是用户的画像，是一个比较大的稀疏矩阵，蚂蚁的风控就是构建在 HBase 上。用户画像有用户数据量大，用户标签多，标签统计维度不确定等特点，适合 HBase 特性的发挥。

• 3、消息/订单：在电信领域、银行领域，不少的订单查询底层的存储，另外不少通信、消息同步的应用构建在 HBase 之上。

另外电商领域的订单数据，订单流程完结数据不在变动，超过一定时间的订单可以存储在HBase中，MySQL只存储最近三个月的订单数据即可，减轻MySQL的压力。

• 4、储存浏览记录：大型的视频网站，电商平台产生的用户点击行为、浏览行为等等存储在 HBase 中为后续的智能推荐做数据支撑。

• 5、对象存储：这里的对象存储实际是中等对象存储，是对 HDFS 存储文件的一个缓冲过度。HBase 提供了中等对现象的存储能力，中等对象的大小范围在 100k 至 10M 之间。

• 6、时序数据：时序数据就是分布在时间上的一系列数值。HBase 之上有 OpenTSDB 模块，可以满足时序类场景的需求。

比如我们有很多的设备、传感器，产生很多数据，如果规模不是特别大的厂家有几千个风机，每个风机有几百个指标，那么就会有一百万左右的时序数据，如果用采样每一秒会产生一百万个时间点，如果用传统数据库，那么每一秒会产生一百万次，持续地往 MQ 做一百万次，它会崩裂。并且查询也是个大问题，除了多维查询以外，我们还会额外地增加时间纬度，查看一段时间的数据。这时候 HBase 很好了满足了时序类场景的需求。

• 7、Cube 分析(KyLin)：通过 KyLin 将 Hive 或 kafka 中的数据，来构建 Cube，这些 Cube 会存储在 HBase 中。

• 8、NewSQL：HBase 上有 Phoenix 的插件，可以满足二级索引、SQL 的需求，对接传统数据需要 SQL 非事务的需求。从 NoSQL 到 NewSQL，Phoenix 或许是新的趋势。

• 9、Feeds 流：Feed 流，是 RSS 中用来接收该信息来源更新的接口，简单的说就是持续更新并呈现给用户的内容。比如微信朋友圈中看到的好友的一条条状态，微博看到的你关注的人更新的内容，App 收到的一篇篇新文章的推送，都算是 feed 流。

更多的场景需要不断挖掘

HBase 可以说是一个数据库，也可以说是一个存储。拥有双重属性的 HBase 天生就具备广阔的应用场景。在最近的一些版本中，引入了 OffHeap 降低 gc 影响，优化链路延迟，提供 Replica 等可以满足在线的需求。引入 MOB，可以存储 10M 左右的对象，完全适应了对象存储。另外由于自身的并发能力、存储能力，可以说是具有最为竞争力的引擎

cassandra-vs-hbase：https://www.scnsoft.com/blog/cassandra-vs-hbase

参考：
https://blog.csdn.net/weixin_42011858/article/details/129299164

https://blog.csdn.net/weixin_44133605/article/details/124635627

https://www.cnblogs.com/qingyunzong/p/8665698.html

https://www.cnblogs.com/wdh01/p/16248799.html

https://blog.csdn.net/qq_33208851/article/details/105223419

https://blog.csdn.net/nmsLLCSDN/article/details/124088245

https://blog.csdn.net/llAl_lAll/article/details/122260638

https://blog.csdn.net/Shyllin/article/details/124386524

https://blog.csdn.net/lilygg/article/details/116790288

https://www.cnblogs.com/kyoner/p/14264470.html

https://zhuanlan.zhihu.com/p/159052841

https://blog.csdn.net/libaowen609/article/details/126674761