分布式数据库HBase

分布式数据库Hbase

4.1 概述

4.1.1从BigTable说起

 1.BigTable是一个分布式存储系统，利用谷歌提出的MapReduce分布式并行计算模型来处理海量数据，用谷歌分布式文件系统GFS作为底层数据存储，采用Chubby提供协同服务管理（谷歌的协调服务，Chubby类似Zookeeper）

 2.BigTable的特性

  *支持大规模海量数据

  *分布式并发数据处理效率极高

  *易扩展且可动态伸缩

  *适用于廉价设备

  *适合读操作不适合写操作

4.1.2Hbase简介

 1.Hbase是一个高效，高可靠，高性能，面向列，可伸缩的分布式数据库，是BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据

 2.Hbase利用MapReduce来处理Hbase中的数据，实现高性能计算，利用Zookeeper作为协同服务，实现稳定服务和失败恢复，使用HDFS作为底层存储，当然也可以使用本地文件系统，Sqoop为Hbase提供了高效，便捷的RDBMS数据导入功能，Pig和Hive为Hbase提供了高层语言支持

4.1.3Hbase与传统关系数据库的对比

 1.关系数据库：面向磁盘的存储和索引结构，多线程访问，基于锁的同步访问机制，基于日志的恢复机制和事务机制，关系数据库的关键特性----完善的事务机制和高效的查询机制

 2.Web2.0 关系数据库不在满足需求

Hbase与传统数据库的主要区别

 *数据类型，Hbase采用了更加简单的数据模型，他把数据存储为未经解释的字符串，用户可以把不同的结构化和非结构化数据都序列化成字符串，保存到Hbase，用户只需要编写不同的程序把字符串解析成不同的数据类型

 *数据操作，关系数据库中包含CRUD等和表连接，利用主外键实现， Hbase只有简单的插入，查询，删除，清空等，只采用单表主键查询，无法实现表连接

 *存储模式，关系数据库基于行存储，连续存储，读取时，按顺序扫描元组筛选出自己想要的，如果只有几个属性是需要的，那么就浪费了许多磁盘空间和内存带宽，Hbase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的，优点：降低IO开销，支持大量用户高并发，同一列族中的数据会一起被压缩，具有较高的压缩比

 *数据索引，关系数据库可以针对不同列构建复杂索引，Hbase只有一个索引，行键

 *数据维护，关系数据库可以更改，Hbase则不会删除旧的数据，而是新增加一个数据

 

*可伸缩性，关系数据库很难实现横向扩展，纵向扩展很有限，Hbase可以

**Hbase的局限性：不支持事务，无法实现跨行的原子性

4.2 Hbase访问接口

     类型          特点                  场合

Native Java API  最常规高效  适合Hadoop MapReduce作业和批处理Hbase表

Hbase Shell     Hbase命令工具  适合于Hbase管理

Thrift Gateway 利用Thrift序列化技术支持多语言 适合其他异构系统访问Hbase

REST Gateway 解除了语言限制 支持REST风格的Http API访问Hbase

Pig         使用Pig Latin流式编程语言  适合做数据统计

Hive        简单           用Sql方式访问Hbase

 

4.3 Hbase 数据模型

4.3.1数据模型概述

 1.Hbase是一个稀疏，多维度，排序的映射表，这张表的索引是行键，列族，列限定符，时间戳。每一个值是未经解释的字符串，没有数据类型，

 2.Hbase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧版依然保留，Hbase可以设置版本保留数量，客户端可以选择获取最近的版本或者所有版本，如果不提供时间戳，那么就返回最新的版本，因为数据在存储时，按照时间戳排序，Hbase提供两种版本回收方式，一种是保存数据的最后n个版本，二是保存最近一段时间的版本，例如7天

4.3.2数据模型相关概念

 1.表

  *由行和列组成，列划分为若干个列族

 2.行 （Row Key）

  *由行键来标识（row key）

  访问表中的行只有三种方式：

*通过单个行键访问

      *通过一个行键的区间来访问

      *全表扫描

  *行键可以是任意字符串，长度为64KB，在Hbase内部，行键保存为任意字节数组

  *行键按照字典顺序存储

3.列族  （Column Family）

 *表由列族的集合组成，是基本的访问控制单元

 *列族需要在表创建时就定义好，数量不能太多，不能超过几十个，不要频繁修改

 *存储在列族中的数据，通常属于同一数据类型，有更好的压缩率 course：math

 *Hbase中，访问控制，磁盘和内存的使用统计都是在列族层面进行

 *Hbase可以对应用设置访问权限，有些只能读，有些可以写

 *Hbase列族可以配置成不同的访问模式，可以放入内存中，换取更好的相应

 

 4.列限定符  （Column Qualifier）

  *列族里的数据通过列或者列限定符来访问

  *列限定符没有数据类型，一般视为字节数组

 5.单元格

  *在Hbase中，通过行键，列族，列限定符确定一个单元格（cell）

  *单元格里的数据有没有数据类型，一般视为字节数组

  *单元格里可以有多个版本，每个版本都有一个不同的时间戳

 6.时间戳

  *单元格里的版本，都由时间戳进行索引

  *每次对单元格执行操作（新建，修改，删除）时会隐式的生成并存储一个时间戳

  *时间戳一般是64位整型，也可以自定义

  *单元格里的版本是由时间戳的降序排序的

4.3.3数据坐标

 1.Hbase使用坐标来定位表中的数据

 2.相当于四维坐标【行键，列族，列限定符，时间戳】

4.3.4概念视图

4.3.5物理视图

4.3.6面向列的存储

 1.传统的关系数据库是面向行存储，Hbase是面向列存储

 2.行式数据库使用NSM存储模型，一个元组会被连续的储存在磁盘中，读数据时需要扫描元组的完整内容，然后从元组中筛选出需要的属性，如果只有少量属性是需要的，你们NSM就浪费了许多磁盘空间和内存带宽

 3.列式数据库采用DSM存储模型，是为了最小化无用IO，DSM会对关系进行垂直分解，并为每个属性匹配一个子关系，每个子关系单独存储，只有子关系和属性匹配时才会被访问

 4.DSM是以关系数据库中的属性或列进行存储的，关系中多个元组的同一属性值会被存储在一起，而不同的属性值会被放在不同的磁盘页中

 5.行式数据库主要适合于小批量的数据处理，如联机事务方面的处理 Oracle Mysql

 6.列式数据库主要适合于批量数据处理和即席查询

优点：*降低IO开销

      *支持大量用户并发查询

      *处理速度快100倍

      *具有较高的数据压缩比

DSM存储模式缺陷：

*执行连接操作时需要昂贵的元组重构代价

      *联机事务时，需要频繁对元组进行修改，会有高昂的开销

 

 

4.4 Hbase的实现原理

4.4.1Hbase的功能组件

 1.主要包括三个功能组件：

*库函数

      *一个Master主服务器

      *许多个Region服务器

 2.Region服务器负责存储和维护分配给自己的Region,处理来自客户端的请求

 3.Master服务器负责管理和维护Hbase表的分区信息，比如一个表被分到哪些Region，每个Region被放到哪个Region服务器上，同时也负责维护Region服务器列表，如果Master死机，整个服务器都无效

 4.Master会实时监测集群中的Region服务器，把特定的Region分配到可用的Region服务器上，确保整个集群中Region服务器的负载均衡，当某个Region服务器失效时，Master会把这个服务器上的Region分配到其他服务器

 5.Master还处理模式变化，如表和列组的创建

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

 7.需要指出的时，Hbase客户端并不依赖于Master，而是借助于Zookeeper来获取Region的位置信息

4.4.2表和Region

 1.根据行键进行分区，每个行区间构成一个分区，被称为Region，包含了位于某个区域的全部数据，它是负载均衡和数据分发的基本单位

 2.初始时，一个表只包含一个Region，随着表越来越大，行数达到一个阈值时，就会被等分成两个新的Region,逐渐增大

 3.每个Region的默认大小是100MB-200MB，同一个Region是不会被拆分到不同服务器的，每个Region服务器大约有10-1000个Region

4.4.3Region的定位

 1.每个Region都有一个RegionID来标识他的唯一性，这样一个Region标识符就由【表名+开始主键+RegionID】构成

 2.可以构建一个映射表，映射表的每个条目包含两项内容，一个是Region标识符，另一个是Region服务器标识符，这个条目就表示Region和Region服务器的映射关系，这个表包含了关于Region元数据（Region和Region服务器的映射关系），因此被称为，元数据表或者.META.表

 3.当一个Hbase表中的Region数量非常庞大时，元数据表中的条目会越来越多，一个服务器保存不下，也需要分区存储到不同的服务器上，因此.META.表也会被分成多个Region，这时，为了定位这些Region，就需要再构建一个新表，记录元数据的具体位置，这个映射表就是根数据表，-ROOT-表，这个表是不能被分割的，永远只存在一个Region来存放这些-ROOT-表，因此这个Region是被写死的，Master永远知道他的位置

 

 

 

 

 

4.Hbase表使用类似B+树的三层结构来保存Region的位置信息

  层次     名称          作用

第一层   Zookeeper文件  记录了-ROOT-表的位置

第二层  -ROOT-表       记录了.META.表的Region位置信息，-ROOT-表只能有一个Region，通过-ROOT-表就能访问.META.表中信息

第三层   .META.表      记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了Hbase表中所有用户数据表的Region位置信息

 5.为了加快访问速度，.META.表中的数据会被保存到内存中

 

 

 6.客户端访问用户数据之前，需要首先访问Zookeeper，获取-ROOT-表的位置

信息，然后访问-ROOT-表获取.META.表的位置信息，接着访问。MATA.表获

取位置信息

4.5 Hbase运行机制

4.5.1Hbase系统架构

 1.Hbase系统架构包括：

   *客户端

   *Zookeeper服务器

   *Master服务器

   *Region服务器

 2.Hbase一般采用HDFS作为底层数据存储

 3.客户端

 1.客户端包含Hbase访问接口，同时在缓存中维护着已经访问过的Region的位

置信息，Hbase的客户端使用Hbase的RPC机制与Master和Region服务器

进行通信，管理类和Master进行RPC，数据读写类和Region进行RPC

 

4.Zookeeper服务器

 1.Zookeeper服务器并不是一台服务器，可能由多台机器构成的集群来提供稳定可靠的协同服务，必须有一个‘总管（Master）’，知道所有机器的运行状态。

 2.在Hbase集群中，包含一个Master和多个Region服务器，Zookeeper可以让Master很轻松的知道每一个Region服务器的状态

 3.每个Region服务器都需要到Zookeeper中进行注册，Zookeeper会实时监控每一台Region服务器的状态并汇报给Master，这样Master就可以通过Zookeeper知道每一台Region服务器的状态

 4.Zookeeper不仅可以维护当前集群中机器的服务状态，而且能帮助选出一个Master，Hbase可以启动多-Master，但是Zookeeper可以帮助选出一个Master作为最高总管，并且保证任何时刻存在唯一一个Master在运行，避免了单点失效的问题

 

 

 5.Zookeeper中保存了-ROOT-表的地址和Master的地址，客户端可以通过访问Zookeeper获得-ROOT-表的地址，并通过三级寻址找到所需要的数据，Zookeeper中还存储了Hbase的模式，包括有哪些表，每个表有哪些列族

5.Master

1.Master主要负责表和Region的管理工作

 *管理用户对表的CRUD

 *实现不同Region服务器之间的负载均衡

 *在Region合并分裂后，重新调整Region的分布

 *对发生故障的Region服务器上的Region进行迁移

2.客户端可以访问Zookeeper获取-ROOT-表的信息，最终到达自己想要读写的地方，Master仅仅维护者表和Region的元数据信息，负载很低

3.任何时刻，一个Region只能被分配给一个Region服务器，Master维护了当前可用的Region服务器的列表，以及Region的分配信息

6.Region服务器

1.Region服务器是Hbase中最核心的模块，负责维护分配给自己的Region，并且响应用户的读写请求

2.Hbase本身并不具备数据复制和维护数据副本的功能，而HDFS可以帮Hbase提供这些服务，当然，Hbase也可以不适用HDFS作为底层存储，可以用支持Hadoop接口的文件系统作为底层存储，例如本地文件系统或者云计算环境中的Amazon S3

4.5.2Region服务器的工作原理

1.Region服务器内部管理了一系列Region和一个Hlog文件，Hlog是磁盘上的记录文件，记录着所有的更新操作

2.每个Region都是由多个Store组成，每个Store对应了一个列族的存储

3.每个Store又包含一个MemStore和若干个StoreFile，MemStore是内存中的缓存，保存最近更新的数据，StoreFile是磁盘中的文件，这些文件都是B树结构

4.StoreFile在底层的实现方式是HDFS文件系统中的HFile，HFile的数据块通常采用压缩方式存储，可以大大减小IO

5.用户读写过程

 *写数据时，数据首先被写入MemStore和Hlog中，当写入Hlog后，conmit（）才会返回给客户端

 *读数据时，Region服务器先会去找MemStore缓存，如果不在缓存中，才会去StoreFile中去找

6.缓存的刷新

 *MemStore的缓存容量有限，系统会周期性的调用Region.flushcache()把缓存中的数据写到StoreFile中，清空缓存，并在Hlog中写入一个标记，表示缓存已经被写入，每次缓存刷新操作都会在磁盘上生成一个新的StoreFile文件

 *Region服务器都有一个自己的Hlog文件，在启动时，会检查这个文件，确认最后一次缓存写入后是否发生新的写入操作，如果没有，这些数据会被永久的保存在StoreFile中，如果发现更新，先把这些更新写入MemStore，然后再刷新缓存，写入到StoreFile，最后删除旧的Hlog文件

 

 

7.StoreFile文件的合并

 *每次查找都会查找所有的store，非常耗费时间，为了减少时间，系统一般会调用Stroe.compact()把多个StoreFile合并成一个大文件，由于这个操作比较耗费资源，只会在StoreFile文件数量达到一个阈值时才会调用

4.5.3Store工作原理

1.Region服务器是Hbase 的核心，Store是Region服务器的核心，每个Store包含一个MemStroe和多个StroeFile

2.MemStore是排序的内存缓冲区，当用户写入时，先把数据放进MemStore里，当MemStore满了，就会刷新到一个StoreFile文件中，随着StoreFile数量越来越多，会发生合并操作，合并成一个大文件，当这个大文件到达一个阈值（256MB）时就会发生Region分裂操作，一个父Region被分裂成两个子Region

4.5.4Hlog工作原理

1.在分布式环境中，会有系统出错的情况，比如Region服务器发生故障，MemStore中的数据还没有被写入，就会全部丢失，因此，Hbase采用Hlog来保证数据的可恢复性

2.Hbase为每个Region服务器配置了一个Hlog文件，它是一种预写式日志，也就是说用户的数据首先被写入Hlog中后才能写入MemStore缓存，并且，知道缓存对应的日志被写入磁盘是才会刷新

3.Zookeeper会实时监测每个Region服务器的状态，当发生故障时，Zookeeper会先通知Master，Master会首先处理这个服务器上的Hlog文件，由于一个Region服务器上有多个Region,但是他们共用一个Hlog，系统会根据每条记录所属的Region对象对Hlog数据进行拆分，再重新分配给可用的Region服务器中，但是这种方式有优点也有缺点

，优点是：大家公用一个Hlog，只需要写入单个日志文件中，减少磁盘的寻址次数，

缺点是：当Region服务器发生故障，为了恢复其Region对象，需要拆分然后重新分发