https://www.cnblogs.com/xinfang520/p/7717399.html

仅能通过主键(row key)和主键的 range 来检索数据，仅支持单行事务(可通过 hive 支持来实现多表 join 等复杂操作)。

HBase 中的表一般有这样的特点：

• 大：一个表可以有上十亿行，上百万列
• 面向列:面向列(族)的存储和权限控制，列(族)独立检索。
• 稀疏:对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。

结构：

• 数据库以 region 的形式存在
• 支持 HDFS 文件系统
• 使用 WAL（Write-Ahead Logs）存储日志
• 参考系统是 Zookeeper
• 使用行键（row key）
• 支持分片
• 使用行、列、列族和单元格

？？？高端服务器下如何拆分（docker？？？多个region可靠性？？？）

Hbase 的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。通过横向添加 RegionSever 的机器，进行水平扩展，提升 Hbase 上层的处理能力，提升 Hbsae 服务更多 Region 的能力。备注：RegionServer 的作用是管理 region、承接业务的访问，这个后面会详细的介绍通过横向添加 Datanode 的机器，进行存储层扩容，提升 Hbase 的数据存储能力和提升后端存储的读写能力。

Client

1. 包含访问hbase的接口，Client维护着一些cache来加快对hbase的访问，比如regione的位置信息.

HBase Master用于协调多个Region Server，侦测各个RegionServer之间的状态，并平衡RegionServer之间的负载。HBaseMaster还有一个职责就是负责分配Region给RegionServer。HBase允许多个Master节点共存，但是这需要Zookeeper的帮助。不过当多个Master节点共存时，只有一个Master是提供服务的，其他的Master节点处于待命的状态。当正在工作的Master节点宕机时，其他的Master则会接管HBase的集群。
功能：

1. 监控 RegionServer
2. 处理 RegionServer 故障转移
3. 处理元数据的变更 处理schema更新请求

HDFS上的垃圾文件回收

1. 处理 region 的分配或移除
2. 在空闲时间进行数据的负载均衡
3. 通过 Zookeeper 发布自己的位置给客户端
4. HMaster仅仅维护者table和HRegion的元数据信息，负载很低。

对于一个RegionServer而言，其包括了多个Region。RegionServer的作用只是管理表格，以及实现读写操作。Client直接连接RegionServer，并通信获取HBase中的数据。对于Region而言，则是真实存放HBase数据的地方，也就说Region是HBase可用性和分布式的基本单位。如果当一个表格很大，并由多个CF组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储的单元（Store）。
（？？？mongo是基于tag或zone的范围分片，hbase基于collumn family）

1. 负责存储 HBase 的实际数据
2. 处理分配给它的 Region
3. 刷新缓存到 HDFS
4. 维护 HLog
5. 执行压缩
6. 负责处理 Region 分片

对于 HBase 而言，Zookeeper的作用是至关重要的。首先Zookeeper是作为HBase Master的HA解决方案。也就是说，是Zookeeper保证了至少有一个HBase Master 处于运行状态。并且Zookeeper负责Region和Region Server的注册。其实Zookeeper发展到目前为止，已经成为了分布式大数据框架中容错性的标准框架。不光是HBase，几乎所有的分布式大数据相关的开源框架，都依赖于Zookeeper实现HA。

• 每个column family存储在HDFS上的一个单独文件中，空值不会被保存。
• Key 和 Version number在每个column family中均有一份；
• HBase为每个值维护了多级索引，即：；
• 表在行的方向上分割为多个Region；
• Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
• Region按大小分割的，随着数据增多，Region不断增大，当增大到一个阀值的时候，Region就会分成两个新的Region；
• Region虽然是分布式存储的最小单元，但并不是存储的最小单元。每个Region包含着多个Store对象。每个Store包含一个MemStore或若干StoreFile，StoreFile包含一个或多个HFile。MemStore存放在内存中，StoreFile存储在HDFS上。（？？？比较mongo等几层分类）

HFile 存储在 Store 中，一个 Store 对应 HBase 表中的一个列族。
Hbase 表的分片，HBase 表会根据 RowKey 值被切分成不同的 region 存储在 RegionServer 中，在一个 RegionServer 中可以有多个不同的 region。

HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示。
寻址过程：client—>Zookeeper—>-ROOT-表—>.META.表—>RegionServer—>Region—>client

WAL（一般翻译为预写日志）是事务机制中常见的一致性的实现方式。每个RegionServer中都会有一个HLog的实例，RegionServer会将更新操作（如 Put，Delete）先记录到 WAL（也就是HLo）中，然后将其写入到Store的MemStore，最终MemStore会将数据写入到持久化的HFile中（MemStore 到达配置的内存阀值）。失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer；

HFile由很多个数据块（Block）组成，并且有一个固定的结尾块。其中的数据块是由一个Header和多个Key-Value的键值对组成。在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到HFile中的数据。

上图是RegionServer数据存储关系图。上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。 不直接写，用WAL不是为了事务，为了可靠性，但是写HLOG的稳定性如何保证：写错log，就基于checkpoint点后的操作反向操作

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。

• (1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。
• (2) 数据被写入Region的MemStore，直到MemStore达到预设阈值。
• (3) MemStore中的数据被Flush成一个StoreFile。
• (4) 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
• (5) StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
• (6) 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。

可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高机能。

读操作流程

• (1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
• (2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
• (3) 通过RegionServer获取需要查找的数据。
• (4) Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

https://www.yuque.com/wangzhiwuimportbigdata/ihf2lk/dl4fns

https://blog.csdn.net/newchitu/article/details/87101125

当table中的行不断增多，就会有越来越多的region。这样一张完整的表被保存在多个Regionserver 上。

每个Store又由一个memStore和0至多个StoreFile组成。如图：StoreFile以HFile格式保存在HDFS上。
HFile存储到HDFS上，按照默认128MB一块进行存储，默认保存3份，提高容错能力。

访问hbase table中的行，只有三种方式：

1. 通过单个row key访问
2. 通过row key的range
3. 全表扫描
   Row Key 行键可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。

Hbase会对表中的数据按照rowkey排序(字典顺序)
存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。
字典序对int排序的结果是 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21 … 。要保持整形的自然序，行键必须用0作左填充。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。列族越多，在取一行数据时所要参与IO、搜寻的文件就越多，所以，如果没有必要，不要设置太多的列族。

• HBase为每个值维护了多级索引，即：；

HBase中通过row和columns确定的为一个存贮单元称为cell。每个 cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由hbase(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，hbase提供了两种数据版本回收方式：

1. 保存数据的最后n个版本
2. 保存最近一段时间内的版本（设置数据的生命周期TTL）。
   用户可以针对每个列族进行设置。

由{row key, column( = + ), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

多级索引

mongo代替es？？？

es
https://blog.csdn.net/weixin_44769733/article/details/100839675

华为
cnblogs.com/njuzhoubing/p/4549523.html