本篇内容介绍了“HBase架构设计是怎样的”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

创新互联公司是专业的襄城网站建设公司，襄城接单;提供成都网站设计、网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行襄城网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

Hadoop生态的分布式数据库

1、什么是分布式数据库？

从狭义的理解就是分布式关系型数据库，主要特指目前热门的NewSQL。

从广义的理解，分库分表的传统关系型数据库，传统关系型数据库集群，关系型数据库的主从架构，分布式KV数据库（例如：HBase），分布式文档数据库（例如：MongoDB），分布式关系数据库(例如：TiDB)等，统称为分布式数据库。

本文主要讲Google一脉相承的Hadoop生态下的分布式数据库架构设计，以及传统RDBMS与NOSQL的分布式环境下的一致性对比。

2、Hadoop HDFS的数据存储模型

最早Google发明了GFS分布式文件系统，之后对应的开源项目就是鼎鼎大名的Hadoop HDFS。

GFS/HDFS的特点表现在顺序的、成块的、无索引的向文件块中写入数据，并在集群环境中按块(block)均匀分布存储，使用时再根据MapReduce、Spark的并行任务，按块批次的读取分析。这样就把写入和并行读取的性能发挥到了极致，具备了任何建立索引的数据库都无法比拟的读写速度。

HDFS的数据写入结构示意图

上图是一个写入HDFS数据的例子，我们需要知道HDFS这些事情：

• 需要写入HDFS的文件会被分成数据块，一个数据块通常是64M或者128M。

• 数据块在HDFS集群中默认有三个副本，平均分配在不同的DataNode数据节点上。

• 由于HDFS的分布式架构是中心化管理，因此并没有数据节点主副的概念，只有顺序的概念，所有数据节点都是存储数据块副本的，全部通过namenode节点安排数据节点的写入顺序。

• 数据节点的写入过程就像一个数据管道，根据客户端就近原则，形成数据节点的排队，当第一个节点写入数据包后，然后再向数据管道的下一个数据节点复制，以此类推，并得到完成确认。

3、HBase的架构设计

为了更好的理解HBase/Bigtable，一定需要先铺陈一下它们所依赖的分布式文件系统基础环境，然后再看看这些巧夺天工的分布式数据库设计如何形成的。

由于GFS/HDFS集群的高性能设计是建立在放弃随机查找的基础之上。那么如何既能拥有随机查找的特性，又能充分利用好HDFS/GFS的集群优势，而且还能在分布式环境下，具备数据写入的强一致性呢？这才涌现出了HBase/Bigtable这类基于分布式文件系统的分布式数据库。

但大家要注意了，实际上HBase/Bigtable的随机查找设计目标并不是解决复杂的join关联查找或二次索引范围查找，而是实现简单的一个K-V查询模型，满足海量数据的存放条件下，通过主键查找结果，能达到毫秒级响应的数据库。

HBase的数据写入结构示意图

上图就是HBase的写入过程以及HDFS作为物理层支撑的架构示意图。

HBase按照LSM-Tree索引加上SSTable数据结构建立了NoSQL常用的数据存储模型。写入过程分成了下面几个部分：

• 客户端向HBase的Region Server写入数据，会首先进入到WAL（Write-Ahead-Log）预写日志中，然后再进入到选择的Region的MemStore中，那这个WAL的目的是什么呢？保命用的！因为一旦Region Server断电或异常崩溃，MemStore的数据是在内存里，肯定就丢了，MemStore恢复的时候就靠WAL存的日志数据了。MemStore真正同步数据后，WAL才会从本地写入HDFS，否则回滚。

• Region的MemStore是一个放在内存里的高速操作区，MVCC事务操作，最近写入记录读取都可以在此处快速完成，当数据在MemStore写满后，就会刷入到Store File磁盘存储区。

• Store File存储区就是不断通过memstore刷盘而形成的HFile，每个HFile默认分配128M，大小正好与HDFS的一个数据块（block）一致，HFile的物理位置就是存储在HDFS的每个数据块中，HFile就是不可更改的了，并通过HDFS的副本机制，形成三副本保证数据的可靠性。

3、HDFS与HBase的协作配合

从上述的HDFS和HBase系统的配合中（GFS与BigTable同理）我们可以看到Hadoop生态体系设计的巧妙结构：

• HDFS对于大文件块的顺序写入，批量分析，HDFS的无索引、顺序写入、管道复制机制充分体现了Google的暴力美学～解决问题的方式务实、简单、直接、高效。

• HBase作为列簇设计的K-V数据库，又实现了细腻入微的设计思想，通过LSM-Tree索引和SSTable数据结构建立起原生数据库存储层。

• HBase机制上WAL、MemStore、StoreFile形成数据操作的多元素协作。

• HBase架构上HRegion Server、HRegion、HLog、HStore层层嵌套，形成分布式数据库的集群化能力。

最关键的就是HBase与HDFS的分工思想，HBase解决业务数据记录写入，K-V随机查找（毫秒级），由Region Server控制的行级事务等一些列分布式数据库特征；而HDFS解决小文件汇聚成大文件的高性能处理，分布式文件系统的海量存储，数据多副本的可靠性，以及成为Mapreduce、Spark、Hive等其他框架与HBase之间协作的基础平台。

最后再说说有些NoSQL的弱一致性为什么就可以被接受? 

回顾一下最开始的MySQL的异步模式复制，它为什么是MySQL的默认复制模式? 

若满足最终一致性，那么这类分布式系统选择了CAP定理中的AP，就是说为了保证系统内部无论是否出错，都会给客户响应。代价就是分布式各节点的数据副本有可能不一致，但这个问题不是此类系统业务最在乎的事情，往往系统的高性能，并能为客户端提供快速响应力才是关键目标，MySQL的默认主从复制如此，有些NoSQL亦如此。

传世的关系模型

首先从数据库的表达力来讲，并不是NoSQL要强于关系模型，事实上SQL的表达力是无出其右的，否则就不会兴盛四十年而不衰，就不会有Hive SQL、Spark SQL、Presto、Impala这些以支持SQL交互为起点的NoSQL上层框架存在的必须性。

看吧，还没到NewSQL这一代的时候，返祖的现象就已经出现了！

1、我们再温故知新一下什么是关系模型：

关系型模型之父Edgar F. Codd，在1970年Communications of ACM 上发表了《大型共享数据库数据的关系模型》这就是永恒的经典，关系模型的语义设计达到了40年来普世的易于理解，语法的嵌套，闭环，完整。

关系型模型之父Edgar F. Codd

原始的关系模型：

• 结构（structure）结构的主要特征就是关系（relation），表格就是实现形式关系定义在类型（type or domain）的基础上，属性（attribute）就是类型的实际值，N个属性就是描述了N元关系每个关系都至少有一个候选键（唯一标识符），它是属性的组合，通常只有一个属性。元组（tuple）就是属性的集合

• 完整性（integrity）实体完整性规则：主键属性不允许null，不能存在任何不匹配的外键取值。

• 操作（manipulation）关系的运算符集合（限制、投影、积、交、并、差、连接），关系表达式赋值关系（例如：关系1 并 关系2赋值给关系3），操作的输入关系和输出关系，形成了闭包（closure）性质，就可以写出嵌套表达式

原始理论具体到实现再翻译成我们好理解的描述：结构、完整性、操作就构成了现在传统数据库的关系模型。

结构：就是我们经常要先对数据库预先定义的表名和字段（名称、类型）

完整性：就是表的主键不能为空，表与表之间的主外键关联必须保证是完整的，外键一定是能找到主键的。

操作：那就是SQL表达式啦，SQL的子查询就是典型的闭包（Closure），可以形成嵌套表达式。

2、虽然NoSQL很火，但我们这个世界没法 NO SQL

HBase/Bigtable可以认为是NoSQL的典型代表

恰恰NoSQL发展至今，出现了Hive SQL，Spark SQL，Presto，Impala，直到基于Google Spanner论文的TIDB，CockroachDB等NewSQL的不断涌现，才让我们用实践证明，无论是NoSQL也好，NewSQL也罢，它们的查询语言客户端又回到了SQL。

我们只是在大数据领域需要替换关系型数据库的存储逻辑，使得数据库更分布式化，更容易实现扩展。这是符合单机性能到了天花板后，必须横向扩展的硬需求，但这也并不是说关系模型就过时了！

像HBase/Bigtable这样的NoSQL，大多数采用了LSM-Tree的索引机制，来替换RDBMS的B-Tree机制，这么做都是为了能实现内存与磁盘，写入与查找的更平衡利用。

它们又用数据分片的水平切分替换RDBMS的分库分表的垂直切分，让节点与集群的水平伸缩性更为自动化，而不是像分库分表那样进行人工复杂的介入。

TiDB这些NewSQL的出现恰恰是在缝合关系模型和分布式存储之间的裂缝，面向客户端依然是关系模型，强化分布式业务更新的强一致性(分布式事务，这是最难的最复杂的地方)，面向存储则坚定的选择K-V模型。

例如TIDB的TIKV集群采用的就是rocksdb，rocksdb的底层索引机制又和HBase/Bigtable采用相同设计机制的又一个nosql成员。

因此并不是Google的Spanner论文以及F1,TiDB这些实现技术开了历史的倒车，恰恰是对狂热的nosql运动的一种反思，对成为经典的SQL关系模型理论的一种认真思考和融合。

任何新技术都是站在前辈的基础上开启的，我们总要回头望望，反思新技术的运用到底我们得到了什么，又失去了什么！

“HBase架构设计是怎样的”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！

本文标题：HBase架构设计是怎样的
本文路径：http://myzitong.com/article/pdhjeo.html