内含面试|一文搞懂HBase的基本原理

本文会对HBase的基本原理进行剖析，通过本文你可以了解到：

• CAP理论

• NoSQL出现的原因

• HBase的特点及使用场景

• HBase的数据模型和基本原理

• 客户端API的基本使用

• 易混淆知识点面试总结

温馨提示 :本文内容较长，如果觉得有用，建议收藏。

从BigTable说起

HBase是在谷歌BigTable的基础之上进行开源实现的，是一个高可靠、高性能、面向列、可伸缩的分布式数据库，可以用来存储非结构化和半结构化的稀疏数据。HBase支持超大规模数据存储，可以通过水平扩展的方式处理超过10亿行数据和百万列元素组成的数据表。

BigTable是一个分布式存储系统，利用谷歌提出的MapReduce分布式并行计算模型来处理海量数据，使用谷歌分布式文件系统GFS作为底层的数据存储，并采用Chubby提供协同服务管理，具备广泛的应用型、可扩展性、高可用性及高性能性等特点。关于BigTable与HBase的对比，见下表：

依赖	BigTbale	HBase
数据存储	GFS	HDFS
数据处理	MapReduce	Hadoop的MapReduce
协同服务	Chubby	Zookeeper

CAP理论

2000年，Berkerly大学有位Eric Brewer教授提出了一个CAP理论，在2002年，麻省理工学院的 Seth Gilbert(赛斯·吉尔伯特) 和 Nancy Lynch(南希·林奇) 发表了布鲁尔猜想的证明，证明了CAP理论的正确性。所谓CAP理论，是指对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（ C onsistency）

  等同于所有节点访问同一份最新的数据副本。即任何一个读操作总是能够读到之前完成的写操作的结果，也就是说，在分布式环境中，不同节点访问的数据是一致的。

• 可用性（ A vailability）

  每次请求都能获取到非错的响应—— 但是不保证获取的数据为最新数据 。即快速获取数据，可以在确定的时间内返回操作结果。

• 分区容错性（ P artition tolerance）

  以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。即指当出现网络分区时(系统中的一部分节点无法与其他的节点进行通信)，分离的系统也能够正常运行，即可靠性。

如上图所示：一个分布式的系统不可能同时满足一致性、可用性和分区容错性，最多同时满足两个。当处理CAP的问题时，可以有一下几个选择：

• 满足CA，不满足P。将所有与事务相关的内容都放在同一个机器上，这样会影响系统的可扩展性。传统的关系型数据库。如MySQL、SQL Server 、PostgresSQL等都采用了此种设计原则。

• 满足AP，不满足C。不满足一致性(C)，即允许系统返回不一致的数据。其实，对于WEB2.0的网站而言，更加关注的是服务是否可用，而不是一致性。比如你发了一篇博客或者写一篇微博，你的一部分朋友立马看到了这篇文章或者微博，另一部分朋友却要等一段时间之后才能刷出这篇文章或者微博。虽然有延时，但是对于一个娱乐性质的Web 2.0网站而言，这几分钟的延时并不重要，不会影响用户体验。相反，当发布一篇文章或微博时，不能够立即发布(不满足可用性)，用户对此肯定不爽。所以呢，对于WEB2.0的网站而言，可用性和分区容错性的优先级要高于数据一致性，当然，并没有完全放弃一致性，而是最终的一致性(有延时)。如Dynamo、Cassandra、CouchDB等NoSQL数据库采用了此原则。

• 满足CP，不满足A。强调一致性性(C)和分区容错性(P)，放弃可用性性(A)。当出现网络分区时，受影响的服务需要等待数据一致，在等待期间无法对外提供服务。如Neo4J、HBase 、MongoDB、Redis等采用了此种设计原则。

为什么出现NoSQL

所谓 NoSQL ，即 Not Only SQL 的缩写，意思是不只是SQL。上面提到的CAP理论正是NoSQL的设计原则。那么，为什么会兴起NoSQL数据库呢?因为WEB2.0以及大数据时代的到来，关系型数据库越来越不能满足需求。大数据、物联网、移动互联网和云计算的发展，使得非结构化的数据比例高达90%以上，关系型数据库由于模型不灵活以及扩展水平较差，在面对大数据时，暴露出了越来越多的缺陷。由此NoSQL数据库应运而生，更好地满足了大数据时代及WEB2.0的需求。

面对WEB2.0以及大数据的挑战，关系型数据库在以下几个方面表现欠佳：

• 对于海量数据的处理性能较差

  WEB2.0时代，尤其是移动互联网的发展，UGC(用户生成内容，User Generated Content)以及PGC(公众生成内容，Public Generated Content)占据了我们的日常。现如今，自媒体发展遍地开花，几乎每个人都成了内容的创造者，比如博文、评论、意见、新闻消息、视频等等，不一而足。可见，这些数据产生的速度之快，数据量之大。比如微博、公众号、抑或是淘宝，在一分钟内产生的数据可能就会非常的惊人，面对这些千万级、亿级的数据记录，关系型数据库的查询效率显然是不能接受的。

• 无法满足高并发需求

  WEB1.0时代，大部分是静态网页(即提供什么就看什么)，从而在大规模用户访问时，可以实现较好的响应能力。但是，在WEB2.0时代，强调的是用户的交互性(用户创造内容)，所有信息都需要事实动态生成，会造成高并发的数据库访问，可能每秒上万次的读写请求，对于很多关系型数据库而言，这显示是难以承受的。

• 无法满足扩展性和高可用性的需求

  在当今 娱乐至死 的时代，热点问题(吸引人眼球，满足猎奇心理)会引来一窝蜂的流量，比如微博曝出某明星出轨，热搜榜会迅速引来大批用户围观(俗称吃瓜群众)，从而产生大量的互动交流(蹭热点)，这些都会造成数据库的读写负荷急剧增加，从而需要数据库能够在短时间内迅速提升性能以应对突发需求(毕竟宕机会非常影响户体验)。但是关系型数据库通常难以水平扩展，不能够像网页服务器和应用服务器那样简单地通过增加更多的硬件和服务节点来扩展性能和负载能力。

综上，NoSQL数据库应运而生，是IT发展的必然。

HBase的特点及使用场景

特点

• 强一致性读写

HBase 不是 最终一致性(eventually consistent) 数据存储. 这让它很适合高速计数聚合类任务

• 自动分片(Automatic sharding)

HBase 表通过region分布在集群中。数据增长时，region会自动分割并重新分布

• <