大数据技术原理与应用 第4章 分布式数据库HBase

4.1 HBase简介

4.1.1 分布式存储系统BigTable

HBase是BigTable的开源实现。

为什么会有BigTable这个分布式存储系统呢？
BigTable最初是为了解决谷歌公司内部大规模网页搜索问题的，谷歌公司一直用BigTable存储大量的网页。
对于网页搜索，可以分为两个阶段：

1. 建立整个网页的索引，大概分为两个步骤：
   （1）设计一个网页爬虫，不断爬取各个网页内容，爬到的每个网页的内容再单独存在bigtable里
   （2）在bigtable上运行mapreduce，会生成相关的索引，才能保证我们能够快速地搜索相关网页
2. 搜索引擎接受用户的请求，然后到相关的索引搜索相关的网页，从Bigtable中提取相关的网页内容给用户。

HBase也不仅仅用于网页搜索


分布式存储系统Bigtable不是用底层磁盘来存储的，Bigtable是架构在GFS之上的。GFS中还会涉及到协同管理服务，是用Chubby来实现的。

那么BigTable为什么会受到广泛的关注呢？

4.1.2 HBase简介

HBase是一个
高可靠、高性能、面向列、可伸缩
的分布式数据库。特长是可以用来存储非结构化和半结构化的松散数据。

底层分布式文件系统 是 存储完全非结构化的数据，HBase的目标：通过水平扩展的方式，允许几千台服务器去存储海量文件。数据库一般都拥有10亿行以上的记录，它的列可以达到几百万列，规模非常大，HBase在水平扩展性上，相对于传统数据库具有很大的优势。

4.1.3 HBase和BigTable对比

HBase是BigTable的开源实现。

4.1.4 为什么要设计HBase这么一个数据库产品

虽然已经有了HDFS和mapreduce，但是hadoop主要解决大规模数据离线批量处理问题，没办法满足大数据实时处理需求。

对于传统的关系型数据库，它不能解决大规模数据的存储问题，传统型数据库的扩展能力非常有限。而且现在数据的结构经常发生变化，关系型数据的模式确定以后，就很难修改了，要对整个数据库进行停机操作、维护好以后再上线，效率很低。这就是关系型数据库现在落后的原因。

HBase具有很好的水平可扩展性，就能很好地满足海量数据的存储。

4.1.5 HBase和传统关系型数据的联系与区别

1. 关系数据库有很规范的数据模型（比较复杂），HBase则是采用很简单的数据模型，它就是把所有数据都存储为未经解读的字符串，后期用的是，再靠开发人员来解读数据。
2. 关系数据库中有非常多的数据操作（增删改查），HBase则没有。尤其是关系型数据库中常用的多表连接操作（join），HBase中就完全避免了。关系型数据库中，在面临大数据操作时有个非常低效的操作就是连接操作，因为连接操作涉及到两表或多表之间大量的数据传输，数据量大的时候，效率是非常低的。
3. 关系数据库是行模式存储，HBase是列模式存储，之后详谈。
4. 关系数据库会构建 主索引，多个二级索引来满足查询。
   
5. 对于HBase来讲，它不具备替换操作，旧的版本会继续保留。只有过了一定期限后，才会被后台清理掉。
6. 关系数据库很难实现水平扩展，纵向扩展也会受到天花板的制约。HBase不是采用单台机器，而是采用集群，所以有很好的水平扩展性。
   

4.1.6 HBase访问接口

Hive里就可以用Hive QL类似于SQL的命令去操作。

4.2 HBase数据模型

HBase是一个稀疏的多维度的排序的映射表，通过4个元素：
行键、列族、列限定符、时间戳
来定位具体的数据。

4.2.1 列族

HBase可以对列族进行动态扩展（增加/减少都可以），HBase执行数据更新时，会保留旧的版本。
HBase大多时候是借助底层的HDFS文件系统进行存放数据的，那HDFS采用的是非常简单的数据模型（只允许写入追加，不允许修改），所以HBase是在HDFS基础之上的，这就决定了HBase在往里修改数据的时候，做不到对数据直接修改，只能升到新的版本用个时间戳标记。

HBase组织数据的时候，也是采用的表的形式。与关系型数据库的区别在于：关系型数据库会对数据进行解析，降低数据的冗余存储，因此之后需要多表连接；而HBase不考虑冗余（计算机的快速发展，可以存放大量数据），更多是追求分析效率，HBase的一个表由行和列组成，列由多个列族组成。

列限定符

一个列族包含多个列限定符name major email，而且在实际应用中可以灵活地增加或减少列。
通过 行键、列族、列限定符 就能确定 一个单元格 的位置。

单元格里存储的数据都是未经解析的字符串。具体解析由程序员完成。

时间戳确定版本。


由4个键确定一个值，所以可以认为是键值数据库。

从这里也可以看出，HBase就是一个稀疏表，很多格是空的。
但是底层存储的时候，并不是这么存储的。

它单独抽出 行键、时间戳、列族 出来存储。

4.2.2 列式存储结构

以前的关系型数据库采用 行式存储方式。HBase采用的是列式存储模式。
列式：就是一个记录的所有属性数据按列的方式存放。

为什么要这么做呢？

1. 面向行的存储有什么优势和缺点？
   OLTP事务性操作
   
   为了分析年龄这个数据，必须要把所有数据都一行行扫描，取出年龄。
2. 面向列的存储有什么优势和缺点？
   

4.3 HBase的实现原理

4.3.1 HBase的功能组件

1. Master
   
2. Region
   一个大表会被分成很多个Region，客户端获得数据的位置后，直接去对相应的Region服务器进行数据的存取。可以不通过Master。
   
   
   随着数据的增加，会分裂出越来越多的Region，分裂速度很快，并不是物理上的分裂，而是修改一下指向的位置就可以了。
   

4.3.2 怎么实现Region定位

1. 怎么知道Region被存到哪里去了？
   
   当region越来越多的时候，.META.表也要进行分区region存放，那这个元数据表的region又怎么找呢？所有又要建立一级更高的元数据region映射表。
   
   这个就是代表一个个分区region。
   .META.表（也有一个个region）是用户数据的region映射表，-ROOT表是.META.数据的region映射表。
   那数据不断增大，root表是不是也要分区呢？我们说，凡事有个度哈，HBase就不允许root表分裂了。

寻址过程

ROOT表的地址就一个，这个地址在程序中被写死，HBase有个专门的主件ZooKeeper，ROOT表的地址就在ZooKeeper文件里。

三级寻址过程：
所以先去访问ZooKeeper服务器，得到ROOT表的地址，得到META表的地址，得到用户数据表地址，最后得到数据。

HBase三层结构中各层次名称和作用

采用这样的三层架构，能支持多大的数据存储呢？
META表所有的东西都存在内存中，所以肯定要考虑内存大小。


这个空间远超过目前企业的需求了…所以是可行的。

客户端为了更快，会缓存已经查询过的数据的region地址，但是这又带来了新的问题。HBase中数据更新了，数据的位置发生了改变，而客户端里缓存的地址没改，怎么办呢？客户端采用的是惰性机制，当它按缓存中的地址去查询时，发现找不到数据，才会重新三次寻址，更新缓存地址。

4.4 HBase运行机制

全局认识：
HBase并不是直接和底层的磁盘打交道，是借助于HDFS分布式文件系统进行存储的，HDFS建立在底层的Hadoop之上。

4.4.1 客户端

客户端包含了访问HBase的接口，为了加快访问速度，客户端会自己维护已经访问过的region信息。

4.4.2 ZooKeeper服务器

实现协同管理服务，ZooKeeper被大量用于分布式系统，提供配置维护，域名服务，分布式同步服务。提供管家的功能，维护和管理整个HBase集群。


ZooKeeper保证任何时刻只有一个Master在运行（其余都作为备用），管理整个HBase集群。

4.4.3 Master（主服务器）

负责整个HBase中，对region的管理工作。

4.4.4 Region服务器

负责用户数据的存储和管理。客户端读取数据就是和Region服务器打交道。

Region服务器集群由很多Region服务器组成，每一台Region服务器都有几个主件。

每一台Region服务器可以存储10~1000个region，这些region共用一个HLog。每一个region，我们在写数据的时候，会按照列族进行切分（一条用户记录竖着放，一行就是一个列族），每个region中的每个列族就构成一个store。

store的数据也不是直接写到底层去，会先写到MemStore（缓存）中，缓存满了写到StoreFile里去。StoreFile是HBase中的表现形式，StoreFile在底层是借助HDFS来存储的，所以每一个StoreFile都是通过HDFS称为HFile文件存储的。

4.4.5 用户读写数据过程

写入数据：
会写入缓存也就是MemStore中，然后为了保证数据的安全性和可恢复性，还会写日志就是HLog。
先写入HLog，再写入MemStore。

读数据：
先访问MemStore，因为最新的数据在MemStore（缓存）里，缓存找不到，再去磁盘的StoreFile里找。

缓存刷新：

StoreFile的合并：

当StoreFile数量过多时，会影响查找的速度，因此当数量达到一定的阈值，就会合并成一个大的StoreFile。

这又带来新的问题，不断合并后，StoreFile太大了，又会引发分裂操作，这就是region分裂的地方。

HLog工作原理：
HBase是一个集群，底层又是非常廉价的低端机，肯定会有故障，那么怎么保障数据的准确性呢？
就用 日志！


直到日志内容写入磁盘后，缓存内容才会被刷写进磁盘。

谁来监测故障呢？
就是ZooKeeper，监测到某个服务器出问题了，就告诉相关的Master，Master就会去处理故障。Master会拆解故障机上的HLog文件，就把数据部署到新的region上。

为什么不每个region都有一个自己的日志文件，而是一台region服务器上的所有region都共用一个日志文件？
主要就是每次往一个region读写数据，都要打开一次文件，效率太低了。
因为共用，所以故障的时候，就要对log进行拆解，把故障region的部分挑出来恢复。

4.5 HBase应用方案

1. HBase按照行键存储数据，如果我们想要让一些数据集中存储（比如时间靠近的数据，存在一起），要怎么做呢？
   
   时间戳使用 一个 长整型的64位 变量表示的。
   用系统最大的整型减去时间戳作为行键。这样时间靠近的数据，行键值也会接近。
2. 想要把一些数据放入缓存中，提升读写性能，怎么做呢？
   在创建表的时候，可以设置。
   根据需要放，毕竟不能把全部数据都放入缓存中。
   
3. 设置版本数，不用保留太多旧版本
   
4. 时间太久远的数据自动删掉
   
   
5. HBase怎么检测性能？
   可以用一些工具
   
   
   
   
   
6. 能不能用SQL语句查询HBase的数据呢？
   典型的方法有两种：Hive和Phoenix
   
   
7. 怎么在HBase中构建二级索引？
   
   原生的HBase只支持这3种访问方式。
   
   
   
   在插入数据时，触发器启动，同时插入索引表。
   这样就分为了 主表和索引表。