Hbase-简介-结构（hbase架构介绍）

背景

GFS：分布式文件系统，使用商用硬件集群存储海量数据。文件将数据在节点之间冗余复制（服务器故障，也不会影响数据的可用性）。它对数据的流式读取也做了优化，可边处理边读取。

适合存储少许非常非常大的文件，而不适合存储成千上万的小文件，因为文件的元数据信息最终要存储在主节点的内存中，文件越多压力越大。

MapReduce：GFS架构的一个补充，它能够充分利用GFS集群中的商用服务器提供的大量CPU。MR和GFS形成了处理海量数据的核心力量。

不过两个系统都缺乏实时随机存储数据的能力（意味着尚不足以处理Web服务）。

Google尝试找到一种能驱动交互应用的解决方案。

Hbase 是从摒弃关系型的特点、采用简单的API来进行增删改查、一个扫描函数、较大的键范围或全表范围上迭代出发构建的。

Hbase实现了BigTable的存储架构

表、行、列、单元格

Hbase中最基本单位是列，一列或者多列形成一行，由唯一的行健来确定存储。反过来，一个表中有多行，每列可能有多个版本，在每一个单元格中存储不同值。



在字典序中，是按照二进制逐字节从左到右一次对比每一个主键。

按照行健排序可以得到RDBMS的主键索引一样的特征。（行健是唯一的，只能出现一次），行健可以是任意字节数组，但不一定是人可直接读的。

一行由若干列组成，若干列组成一个列族。（有助于构建语义边界，还有助于设置特性（如压缩，或者指示他们存在内存））

一个列族的所有列存储在同一个底层文件里，这个存储文件HFile

列族需要在表创建时就定义好，不能太频繁修改，数量也不能太多。

列数量没有限制。

列值也没有类型和长度限制。

行和列没有像表格一样排列，而是采用标签描述。（信息都是保存在一个特定的标签下）

NULL值：RDBMS中没有值的地方会添加一个null，但在Hbase的架构中，直接省略了整个列，（即空值不会有任何消耗，不占空间）

列值都具有时间戳，默认系统指定，也可用户显示设置。一般用过时间戳来区分版本数，一个单元格的值按照降序排列在一起，优先读取最新值。

用户可以指定每一个值所能保存的最大版本数。还支持谓词删除

HBase是一个稀疏的、分布式的、持久化的、多维的映射、有行健、列键和时间戳索引。

webtable：Bigtable和Hbase的应用场景，存储从互联网上抓取的网页。

行数据的存取是原子性的，这促成了系统架构具有强一致性。

多版本和时间戳能帮助应用层解决一致性问题。

自动分区

region：HBase中扩展和负载均衡的基本单元，本质是以行健排序的连续存储区间。（如果region太大，系统会动态拆分，相反，就把多个region合并）

一张表初始只有一个region，每次数据插入，系统都会检查是否超过了配置的最大值。超过就用中间键将region拆分为两个相等的子region。

每一个region只能被一台region服务器（region server）加载，每一台region server可以加载多个region

当一个服务器出现故障后，该服务器上的region可以快速恢复，并获得细粒度的负载均衡，因为当服务于某个region的服务器当前负载过大、产生错误或者停止使用或者不可用时，系统会将region移到其它服务器上。

region的拆分非常快。因为拆分之后的region读取的仍然是元存储文件，只到合并或者异步地写为独立文件。