hbase_architecture.md

HBase Architecture

Overview

HBase 有如下特性：

• 强一致性
• 自动分片
• RegionServer 自动故障转移
• 整合 Hadoop/HDFS
• 支持 MapReduce
• 提供 Java Client API
• 提供 Thrift/REST API
• Block Cache 和 Bloom Filter
• 便于管理

HBase 的一致性

CAP定理指出对于一个分布式系统而言，不可能同时满足以下三点：

• 一致性（Consistence）
• 可用性（Availability）
• 网络分区容忍性（Partition tolerance）

对于分布式系统而言，分区容忍性是基本要求，所以在设计分布式数据系统时，需要在一致性和可用性中做权衡，但无论如何做权衡，都无法完全放弃一致性，如果真的放弃一致性，那么这个系统中的数据就变得不可信了。一般而言，分布式数据系统会牺牲部分一致性，使用最终一致性。

常见的一致性类型有：

• 强一致性：当更新操作完成后，之后任意进程任何时间的请求的返回值都是一致的。
• 弱一致性：更新完成后，系统并不保证后续请求的返回值是一致的（更新前和更新后的值都可能被返回），也不保证过多久返回的值一致。
• 最终一致性：更新完成后，在“不一致窗口”后的请求的返回值都是一致。最终一致性是弱一致性的特例。

HBase 有哪几种一致性？

• 强一致性（Strong Consistency） 强一致性是 HBase 的默认一致性模型。
• 时间轴一致性（Timeline Consistency）
  时间轴一致性的读请求的返回结果可能不包括最近更新的数据，即 get 和 scan 可能包括过期数据。为保证写事务的顺序，HBase 中的写事务都是强一致性模型。 若需要使用时间轴一致性的读请求，可执行命令：get 't1','r6', {CONSISTENCY => "TIMELINE"}。

HBase 是怎样保证强一致性的呢？

• 每个值只出现在一个 region。
• 同一时间每个 region 只被分配给一个 region server。
• 所有行内的 mutation 操作都是原子操作。
• 通过任何 API 返回的行的内容总是一个完整的行。

Architecture

引用的一张图：

每个 HRegionServer 共享一个WAL，HRegionServer 有一个或多个 Region 构成，每个 Region 下又有一个或多个 Store，每个表的列族对应一个 Store 实例，每个 Store 包括一个或多个 StoreFile 实例，StoreFile 为 HBase 实际存储文件 HFile 的封装，每个 Store 对应一个 MemStore。HFile 由多个 Block 组成。

Table       (HBase table)
    Region       (Regions for the table)
         Store          (Store per ColumnFamily for each Region for the table)
              MemStore           (MemStore for each Store for each Region for the table)
              StoreFile          (StoreFiles for each Store for each Region for the table)
                    Block             (Blocks within a StoreFile within a Store for each Region for the table)

LSM树 & B+树 --> TODO

Reference

• Apache HBase ™ Reference Guide
• Consistency
• HBase: How does replication work
• HBase Read Replicas
• HBase Read High Availability Using Timeline Consistent Region Replicas
• What are HBase znodes