Hbase读写原理

不同列族分别存在不同的文件夹里。

与MySQL比较

首先Hbase是依赖于HDFS和zookeeper的。

Zookeeper分担了Hmaster的一部分功能，客户端进行DML语句的时候，都是先跟ZK交互。

RegionServer管理了很多的Region（表），RegionServer里面的WAL(HLog)是预写入日志，功能是防止内存中的数据没有来的及落盘时丢失。在Region里面管理的Store管理的是列族，Store里面有Mem Store（内存），Flush之后，删除内存中的数据，同时写入文件StoreFile Hfile,Hfile 其实是在DataNode里面的。

Hbase的读比写慢。

Hbase命名空间下有一张元数据表meta表和namespace表。meta表里面保存了要 *** 作的表所在的位置等元数据。

（1）首先客户端向zk请求元数据表所在的RegionServer，zk返回给客户端meta表所在的regionServer。

（2）然后客户端再去对应的RegionServer查找meta表，找到真正要 *** 作的表所在的regionServer，同时把meta表的信息缓存下来，加快后续的查询。

（3）然后客户端再向目标表所在的RegionServer发送put请求。先把数据写到Hlog里面，再写到内存MemStore,数据会在内存排序，然后向客户端发送ack，到这里对于客户端来说写数据已经结束了。再等到MemStore的刷写时机后，将数据刷写到Hfile

注：meta表所在的位置信息保存在zk的meta-region-server节点上，客户端首先就是在这个节点上差询meta表所在的RegionServer。meta表里面的信息就是表与其对应的RegionServer的信息

这个stu表可能不止一条，因为stu表可能数据量大了之后根据RowKey进行了切分，并且可能会在不同的机器上。

不同的列族是在不同的文件夹。

MemStore刷写时机：

全局的MemStore的容量，默认是堆内存的40%。这个容量值会触发flush *** 作，所有的MemStore都要刷写，flush *** 作会阻塞读写 *** 作。

会刷写并阻塞到到MemStore大小降到它的最大容量的95%

WAL日志的刷写时机：

可以设置日志的大小和数量，当达到一定数量，刷写到HDFS

（1）从zk找meta表所在的RegionServer

（2）从上述RegionServer里的meta表里找目标表所在的RegionServer，同时把meta表缓存，加速后面的查询。

（3）向目标表所在的RegionServer发送get请求。可以从block Cache，MemStore还有StoreFile里面查，具体从哪查根据时间戳，查时间戳大的，具体就都查然后merge取最新。

RegionServer里面有block Cache可以缓存磁盘的数据，加速查询。如果block Cache里面有，就将缓存和MemStore的数据merge然后取最新时间戳，没有就是把磁盘读的和MemStore里面的合并。所以hbase大多数读要走磁盘，所以读很慢。

每次刷写会生成新的Hfile，Hfile很小并且数量多的时候会影响查询的速度。所以要进行合并。合并分为minor Compaction和major Compaction

minor Compaction将临近的若干较小的Hfile合并成一个较大的Hfile，不会清理过期和删除的数据，major Compaction会将一个Store里面的所有Hfile合并成一个大的Hfile，并且会清理掉过期和删除的数据。

数据的读写可以不依赖Hmaster，只需要指定zookeeper，但是Hmaster负责region调度的元数据

但是DDL语言是要有Hmaster的

Flush和major Compact

（1）flush在同一个内存中清除过期或删除（删除标记也是一行数据）的数据，但是如果数据不同的版本分布在不同的memStroe，就不能清除。删除的标记在flush之后不会被删，但在后面的major compaction会把删除标记删除掉。

（2）major compaction 会清除过期或删除的数据。

默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动拆分，两个子Region开始都会在一个Regionserver里面，但是出于负载均衡的考虑，Hmaster有可能会将某个Region传给其他的RegionServer。

Split的时机：

（1）当一个Region中的某个Store下的StoreFile的总大小查过某个值，由参数hbasehregionmaxfilesize设定（默认10g），该Region就会按照RowKey进行拆分。

（2）在新版本中这个值是Min（R^2"hbasehregionmemStoreflushsize（128M）","hbasehregionmaxfilesize"）,R是当前RegionServer中属于该Table的Region个数。分region是按照RowKey切分的。这会导致数据倾斜，就是因为切分的阈值在变化，导致切分之后的region数据量不均匀，导致热点的问题。所以在建表的时候要做预分区，就是用RowKey规划好多少个region，不让hbase自己的切分逻辑切分。

官方建议只用一个列族，防止不同的列族之间数据不均匀，单一列族数据量增多，导致全局的flush，数据量小的列族也要flush，这样会形成很多小的storeFile。

delete *** 作：

（1）设置RowKey：打的删除标记是deleteFamily，删除多个版本

（2）设置RowKey+Family：打的标记是deleteFamily，删除多个版本

（3）设置RowKey+family+column：有addColumn()和addColumns()addColumn是删除最新的版本或者删除指定时间戳的版本，删除标记是delete标记。addColumns是删除所有的版本或者删除指定时间戳或之前的版本，删除标记是deleteColumn

Delete的 *** 作其实也是put *** 作，put的是删除的标记。

在Hbase中HMaster负责监控HRegionServer的生命周期，均衡RegionServer的负载，如果HMaster挂掉了，那个整个Hbase集群将处于不健康的状态，并且此时的工作状态不会维持太久。所以Hbase支持对HMaster的高可用配置。

在Hbase的conf目录下新建backup-masters文件，vim加入备份Master，比如slave01,slave02在把文件分发到各个slave里，然后再启动hbase 就能实现HMaster的高可用了。

每一个region维护着StartRow和EndRow，如果加入的数据符合某个region维护的RowKey范围，则该数据交给这个region维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高Hbase性能。

（1）手动设定预分区

手动设置RowKey分了5个region

（2）生成16进制序列预分区

（3）按照文件中设置的规则预分区

创建splittxt

然后执行

这里如果文件里面给的分区键不是按照顺序的，hbase会先帮我们把键排序，然后按照键来分区。

（4）使用JavaAPI预分区

admin的创建表的方法有多个重载，可以只传表的描述，也可以加入分区的信息。admincreateTable

规划分区要考虑未来数据量和机器的规模。虽然提前做了分区，但是最后如果分区大于了10G,还是会触发split。假设一台机器有100G磁盘，那么预分区尽量大于10个，这样就能避免预分区之后又触发了大于10G的split。

（1）希望数据能够尽量均匀的分配在多个分区里面（散列性）。

（2）唯一性

（3）长度原则（生产环境70到100位）

常见的设计方案：

（1）生产随机数、hash、散列值

（2）字符串反转

（3）字符串拼接

电信项目：

一次通话的记录：13112341233->18998768771 2018-12-12 12:12:21 568

假设分300个区

分区键怎么设计：

（299个键）

000|

001|

298|

RowKey的前面一般会拼上000_,001_,,298_

这样做的好处是，根据前三位就能知道哪个分区。

（1）我们希望手机号尽量分布在不同的分区，但是相同的手机号数据集中在同一个分区，这样方便查询某个用户的通话信息。000_13112341233

（2）因为每个人通话的需求不同，也希望把同一个人的通话记录也分布在不同的分区里面。000_13112341233_2019-12-12

哈希取余：[（13112341234^201912）hash]%299

假设要查询某用户2019年2月的通话记录，可以用13112341234 201902做startRowkey，13112341234 201903做endRowKey

微博。

1、需求

（1）微博内容的浏览

（2）用户社交：关注用户，取关用户

（3）拉取关注人的微博用户

2、设计表

（1）微博内容表Content

行键：用户id+时间戳

（2）用户关系表

因为正常情况一个用户的粉丝和关注都不多，可以用一行存储关注和粉丝的情况。

行键：用户id

（3）初始化页面的表（显示关注的人的最近三条微博）

下面这种方式是全表扫描，Spark如果通过RS来访问Hbase数据进行数据分析，对RS会产生很大的压力。不太建议使用下面的方式

在本地测试时返现运行的很慢，后来看到以下日志

由于Hbase表中只有两个region，所以只启动两个Task，此时并行度为二！

那么也就是说Spark读取Hbase的并行度取决于这个表有多少个region。然后根据region的startkey和endkey来获取数据

数据入hbase不报错,客户端查不到数据

是因为：系统bug，使用软件hbase写代码时，当代码写入成功却查不出来，是系统bug的问题，将代码重新运行即可，HBase是一个分布式的。

Hbase是一种NoSQL数据库，这意味着它不像传统的RDBMS数据库那样支持SQL作为查询语言。Hbase是一种分布式存储的数据库，技术上来讲，它更像是分布式存储而不是分布式数据库，它缺少很多RDBMS系统的特性，比如列类型，辅助索引，触发器，和高级查询语言等待

那Hbase有什么特性呢？如下：

强读写一致，但是不是“最终一致性”的数据存储，这使得它非常适合高速的计算聚合

自动分片，通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配

自动的故障转移

Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接

丰富的“简洁，高效”API，Thrift/REST API，Java API

块缓存，布隆过滤器，可以高效的列查询优化

*** 作管理，Hbase提供了内置的web界面来 *** 作，还可以监控JMX指标

什么时候用Hbase？

Hbase不适合解决所有的问题：

首先数据库量要足够多，如果有十亿及百亿行数据，那么Hbase是一个很好的选项，如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态

其次，如果你不需要辅助索引，静态类型的列，事务等特性，一个已经用RDBMS的系统想要切换到Hbase，则需要重新设计系统。

最后，保证硬件资源足够，每个HDFS集群在少于5个节点的时候，都不能表现的很好。因为HDFS默认的复制数量是3，再加上一个NameNode。

Hbase在单机环境也能运行，但是请在开发环境的时候使用。

内部应用

存储业务数据:车辆GPS信息，司机点位信息，用户 *** 作信息，设备访问信息。。。

存储日志数据:架构监控数据（登录日志，中间件访问日志，推送日志，短信邮件发送记录。。。），业务 *** 作日志信息

存储业务附件：UDFS系统存储图像，视频，文档等附件信息

不过在公司使用的时候，一般不使用原生的Hbase API，使用原生的API会导致访问不可监控，影响系统稳定性，以致于版本升级的不可控。

HFile

HFile是Hbase在HDFS中存储数据的格式，它包含多层的索引，这样在Hbase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，block的大小设置为每个RegionServer 1GB也是常见的。

探讨数据库的数据存储方式，其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的，而不是数据存储本身。

Hfile生成方式

起初，HFile中并没有任何Block，数据还存在于MemStore中。

Flush发生时，创建HFile Writer，第一个空的Data Block出现，初始化后的Data Block中为Header部分预留了空间，Header部分用来存放一个Data Block的元数据信息。

而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中：

注：如果配置了Data Block Encoding，则会在Append KeyValue的时候进行同步编码，编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。

以上就是关于Hbase读写原理全部的内容，包括:Hbase读写原理、Spark 读取 Hbase 数据、数据入hbase不报错,客户端查不到数据等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！