分布式数据库HBase

1. 概述

1.1 从BigTable说起

BigTable是一个分布式存储系统
BigTable 起初用于解决典型的互联网搜索问题

• 建立互联网索引
• 爬虫持续不断的抓取新页面，这些页面每页一行的存储到BigTable里。
• MapReduce计算作业运行在整张表上，生成索引，为网络搜索应用做准备。
• 搜索互联网
• 用户发起网络搜索请求。
• 网络搜索应用查询建立好的索引，从BigTable得到网页。
• 将结果提交给用户。

BigTable 利用谷歌提出的MapReduce 分布式并行计算模型处理海量数据，使用谷歌分布式文件系统GFS作为底层数据存储，采用Chubby提供协同服务管理。
BigTable可扩展到PB级别的数据和上千台机器，具备广泛应用性，可扩展性，高性能等特点。

1.2 Hbase 简介

Hbase 是一个高可靠，高性能，面向列，可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。，Hbase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理超过10亿行数据和数百万列元素组成的数据表。

Hbase和BigTable的第层技术对应关系：

关系数据库已经流行多年，且Hadoop已经有了HDFS和MapReduce，为什么需要Hbase？

• Hadoop可以很好的解决大规模数据的离线批量处理问题，但是受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用得需求。
• HDFS面向批处理访问模式，不是随机访问模式。
• 传统关系数据库无法应对在数据规模剧增时导致得系统扩展和性能问题（分库分表也不能很好解决）。
• 传统关系数据库在数据结构变化时一般需要停机维护，且空列浪费存储空间。
• 因此，出现了一类面向半结构化数据存储和处理得高可扩展，低写入/查询延迟得系统，如键值数据库，文档数据库和列族数据库。

1.3 Hbase与传统关系数据库的对比分析

• 数据类型： 关系数据库采用关系模型，具有丰富的数据类型和存储方式，Hbase则采用更加简单的数据模型，把数据存储为未经解释的字符串。
• 数据操作：关系数据库会涉及到多表连接，Hbase则不存在表与表之间的关系，自由简单的插入，查询，删除，清空等。
• 存储模式： 关系数据库是基于行模式存储的。Hbase是基于列存储的，每个列族都有几个文件保存，不同列族的文件是分离的。
• 数据索引： 关系数据库有多个索引，以提高访问性能；Hbase只有一个索引–行键。
• 数据维护： 在关系数据库中更新操作会用最新的值去替换旧值，而在Hbase中执行更新操作时，并不会删除数据旧的版本，而是根据时间戳的不同生成一个新的版本，旧的仍然保留。
• 可伸缩性： 关系数据库很难实现横向扩展，纵向扩展的空间也比较有限，相反，Hbase等这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易的通过在集群中增加或者减少硬件数量来实现性能的伸缩。

2. Hbase访问接口

3. Hbase数据模型

3.1 数据模型概述

• Hbase是一个稀疏，多维度，排序的映射表，这张表的索引是行键，列族，列限定符和时间戳。
• 每个值都是一个未经解释的字符串，而没有数据类型。
• 用户在表中存储数据，每一行都有一个可排序的行键和任意多的列。
• 表在水平方向由一个或者多个列族组成，一个列祖中可以包含任意多个列，同一个列族里面的数据存储在一起。
• 列族支持动态扩展，可以很轻松的添加一个列族或列，无需预先定义列的数量以及类型。

3.2 数据模型相关概念

• 表： Hbase采用表来组织数据，表由行和列组成，列划分为若干列族。
• 列： 每个Hbase都由若干行组成，每个行由行键来标识。
• 列族： 一个Hbase表被分组成是许多列族的集合，它是基本的访问控制单元。
• 列限定符： 列族里面的数据通过列限定符来定位。
• 单元格： 在Hbase表中，通过行，列族和列限定符来确定一个单元格。
• 表：Hbase采用表来组织数据，表由行和列组成，列划分为若干列族。
• 时间戳： 每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。

3.3 数据坐标

Hbase中需要根据行键，列族，列限定符和时间戳来确定一个单元格，因此可以视为一个四维坐标，即 [ 行键，列族，列限定符，时间戳] 。

4. Hbase的实现原理

4.1 Hbase功能组件

• Hbase的实现包括三个主要的功能组件

  1. 库函数： 链接到每个客户端。
  2. 一个Master主服务器。
  3. 许多个Region服务器。

• 主服务器Master负责管理和维护Hbase表的分区信息，维护Region服务器列表，分配Region，负载均衡。

• Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求。

• 客户端不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据。

• 客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小。

4.2 表和Region

• 开始只有一个Region，后来不断分裂。
• Region拆分操作非常快，接近瞬间，拆分之后的Region读取的仍然是原存储文件，直到合并过程把存储文件写到独立的文件之后，才会读取新文件。
• 同一个Region不会被分拆到多个Region服务器；不同的Region可以分布在不同的Region服务器上。

4.3 Region的定位

• 元数据表，又名**.META.**表，存储了 Region 和 Region服务器的映射关系。
• 当Hbse表很大时，.META.表也会被分割成多个Region。
• 根数据表，又名 -ROOT-表，记录所有元数据的具体位置。
• -ROOT-表只有唯一一个Region，名字是在程序中写死的。
• Zookeeper文件记录了 -RPOOT-表的位置。
  
  Hbase的三层结构中各层次的名称和作用：
  
• 为了加快访问速度，.META.表的全部Region都会被保存在内存中。
• 为了加速寻址，客户端会缓存位置信息。同时，需要解决缓存失败的问题。
• 寻址过程中客户端只需要询问Zookeeper服务器，不需要链接Master服务器。

5. Hbase运行机制

5.1 Hbase系统架构

• 客户端：包含访问Hbase的接口，同时在缓冲中维护着已经访问过的Region位置信息，用来加快后续数据访问过程。
• Zookeeper服务器： Zookeeper可以帮助选举一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的”单点失效“问题。
• Master：主服务器Master主要负责表和Region的管理工作：
• 管理用户对表的增加，删除，修改，查询等操作。
• 实现不同Region服务器之间的负载均衡。
• 在Region分裂或合并后，负责重新调整Region的分布。
• 对发生故障失效的Region服务器上的Region进行迁移。
• Region服务器： Region服务器是Hbase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。

5.2 Region服务器工作原理

• 用户读写数据过程
• 用户写入数据时，被分配到相应Region服务器去执行。
• 用户数据首先被写入到MemStore和Hlog中
• 只有当操作写入Hlog之后，commit（） 调用才会将其返回给客户端。
• 当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找。
• 缓冲的刷新
• 系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记。
• 每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件。
• 每个Region服务器都有一个自己的Hlog文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务。
• StoreFile的合并
• 每次刷写都生成一个新的StoreFile，数量太多，影响查找速度。
• 调用**Store.compact()**把多个合并一个。
• 合并操作比较耗费资源，只有数量达到一个阈值才启动。

5.3 HLog工作原理

• 分布式环境必须要考虑系统出错。Hbase采用Hlog保证系统恢复。
• Hbase系统为每个Region服务器配置了一个Hlog文件，它是一种预写式日志。
• 用户更新数据必须首先写到日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。
• Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。
• Master首先会处理该故障Region服务器上面遗留下的Hlog文件，这个遗留下的Hlog文件包含了来自多个Region对象的日志记录。
• 系统会根据每条日志记录所属的Region对象对Hlog数据进行拆分，分别放到对应的Region对象的目录下，然后，将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的Hlog日志记录也发送给相应的Region服务器。
• Region服务器领取到分配给自己的Region对象以及相关的Hlog日志记录，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile中，完成数据恢复。
• 一个Region服务器内共用日志的优点：提高对表的写操作性能；缺点：恢复时需要拆分日志。

ps:网上更加详细的讲解
大佬的讲解

end.