一、下载地址（永久有效）
百度云盘下载（公开永久）：HBase权威指南【中文版】.pdf
二、HBase产生的背景
2003年，Google发表了一篇论文，叫"The Google File System"。这个分布式文件系统简称GFS，它使商用硬件集群存储海量数据。文件系统将数据在节点之间进行冗余复制，这样的话，即使一台存储服务器发生故障，也不会影响数据的可用性。它对数据的流式读取也做了优化，可以边处理边读取。
（Hadoop的HDFS 参考 Google的 GFS）
不久，Google又发表了另一篇论文，叫"MapReduce: Simpliied Data Processing on Large Clusters"。MapReduce是GFS架构的一个补充，因为它能够充分利用GFS集群中的每个商用服务器提供的大量CPU。MapReduce加上GFS形成了处理海量数据的核心力量，包括构建Google的搜索索引。
（Hadoop的MapReduce参考 Google的MapReduce）
不过以上描述的两个系统都缺乏实时随机存储数据的能力（意味着尚不足以处理Web服务）。GFS的另一个缺陷就是，它适合存储少许非常非常大的文件，而不适合存储成千上千万的小文件，因为文件的元数据信息最终要存储在主节点（NameNode）的内存中，文件越多主节点的压力越大。
因此，Google尝试去找到一个能够驱动交互应用的解决方案，例如，Google邮件或者Google分析，能够同时利用这种基础结构、依靠GFS存储的数据冗余和数据可用性较强的特点。存储的数据应该拆分成特别小的条目，然后由系统将这些小记录聚合到非常大的存储文件中，并提供一些索引排序，让用户可以查找最少的磁盘（磁盘寻址）就能够获取数据。最终，它应该能够及时存储爬虫的结果，并跟MapReduce协作构建搜索索引。
意识到RDBMS（关系型数据库）在大规模处理中的缺点，工程师们开始考虑问题的其他切入点：摒弃关系型的特点，采用简单的API来进行增、查、改、删（CRUD == Create、Read、Update and Delete）操作，再加一个扫描函数（scan），在较大的键范围或全表上进行迭代扫描。这些努力的成果最终在2006年的论文"BigTable： A Distributed Storeage System for Structured Data" 中发表了。
"BigTable" 是一个管理结构化数据的分布式存储系统，它可以扩展到非常大：如在成千上万的商用服务器上存储PB级的数据。......一个稀疏的、分布式的、持久化的多维排序映射"。
（Hadoop的HBase参考 Google的BigTable）
三、HBase的主要主件
HBase中有三个主要组件：客户端库、一台主服务器、多台region服务器。可以动态地增加和移动region服务器，以适应不断变化的负载。主服务器主要负责利用Apache Zookeeper为region服务器分配region，Apache Zookeeper是一个高可靠的、高可用的持久化的分布式协调系统。
Zookeeper是Apache 软件基金会旗下的一个独立的开源系统，它是Google公司为解决BigTable中问题而提出的Chubby算法的一种开源实现。它提供了类似文件系统一样的访问目录和文件（称为znode）的功能，通常分布式系统利用它协调所有权、注册服务、监听更新。
每台region服务器在Zookeeper中注册一个自己的临时节点（客户端开启一个Session，一旦客户端关闭，节点将会在ZK服务端被删除），主服务器会利用这些临时节点来发现可用的服务器，还可以利用临时节点来跟踪机器故障和网络分区。
在Zookeeper服务器中，每个临时节点都属于某一个会话，这个会话是客户端连接上Zookeeper服务器之后自动生成的。每个会话在服务器中有一个唯一的id，并且客户端会以此id不断地向Zookeeper服务器发生"心跳"，一旦发生故障Zookeeper客户端进程死掉，Zookeeper服务器会判定该会话超时，并自动删除属于它的临时节点（节点类似于文件系统中的文件夹）。
（1）zkServer.sh start 开启ZK服务（ZK集群中的每台ZK服务都要开启）
（2）zkCli.sh -server localhost:2181 ZK服务端开启后，启动ZK客户端进行连接
最后定格在
（3）create -e /app1/ data-0 客户端连接ZK服务后，在根目录下创建一个临时Znode节点叫"app1",其value值我们设置为"data-0"
创建之后，我们会发现集群中其余ZK服务会同步更新这个Znode节点（app1文件夹）
比如，我们在144的Zookeeper服务器上进行"ls /" （列出ZK根目录下面的文件）如下
146的亦如此：
除了我们刚才创建的app1节点外，ZK集群中还有Zk自己的节点zookeeper和kafka的brokers节点以及hbase节点（永久）等
我们可以利用get命令，来查看节点（文件夹）app1的信息如下（在144服务器上进程操作）：
由于我们创建的znode是临时节点，因此，当我们退出（quit）当前客户端连接会话时，节点app1会被删除，退出后，我们再次连接ZK服务进行查询，发现已经没有该节点了，效果如下：
HBase还可以利用Zookeeper确保只有一个主服务在运行（HBaseMaster），存储用于发现region的引导位置，作为一个region服务器的注册表，以及实现其他目的。Zookeeper是一个关键组成部分，没有它HBase就无法运作。Zookeeper使用分布式的一系列服务器和Zap协议（确保其状态保存一致）减轻了应用上的负担。
master服务器负责跨region服务器的全局region的负载均衡，将繁忙的服务器中的region移动到负载较轻的服务器中。主服务器（HBaseMaster）不是实际数据存储或者检索路径的组成部分，它仅提供了负载均衡和集群管理，不为region服务器或者客户端提供任何的数据服务，因此是轻量级服务器。此外，主服务器还提供了元数据的管理操作，例如，建表和创建列族（column family）。
region服务器负责为它们的服务的region提供读和写请求，也提供了拆分超过配置大小的region的接口。客户端则直接与region服务器通信，处理所有数据相关的操作。
"数十亿行 X 数百万列 X 数千个版本 = TB级 或 PB级的存储"
其余内容，请自行学习，学习使人快乐！