概述

一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的

开源实现，主要用来存储非结构化和半结构化的松散数据。

hbase伪分布式集群配置 hbase分布式数据库_服务器

为什么需要HBase?

  • Hadoop无法满足大规模数据实时处理应用的需求
  • HDFS面向批量访问模式，不是随机访问模式
  • 传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题

HBase与传统的关系数据库的区别:

1.数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式。HBase采用更加简单的数据模型，把数据存储为字符串

2.数据操作：HBase操作不存在复杂的表和表之间的关系。只有简单的插入，查询，删除，清空等

3.存储模式：关系数据库基于行模式存储。HBase基于列存储，每个列族由几个文件保存

4.数据索引：关系数据库可构建复杂的多个索引提高数据访问性能。HBase只有一个索引-行健，不会降低系统查找速度

5.数据维护：更新后保留旧版本

6.可伸缩性：可轻易通过再及群众增加或者减少硬件数量来实现性能伸缩性

HBase访问接口

hbase伪分布式集群配置 hbase分布式数据库_hbase伪分布式集群配置_02

HBase数据模型

数据模型概述

HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限
定符和时间戳

数据模型相关概念

  • 表：由列、行组成，列划分为若干个列族
  • 行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。
  • 列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元
  • 列限定符：列族里的数据通过列限定符（或列）来定位
  • 单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]
  • 时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引

数据坐标

四维坐标，行键、列族、列限定符和时间戳来确定一个单元格

概念视图

hbase伪分布式集群配置 hbase分布式数据库_hbase伪分布式集群配置_03

物理视图

hbase伪分布式集群配置 hbase分布式数据库_hbase伪分布式集群配置_04

面向列的存储

hbase伪分布式集群配置 hbase分布式数据库_数据_05

HBase的实现原理

HBase功能组件

库函数(链接到每个客户端）,一个主master服务器,许多从region服务器

  • 主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分
    配Region，负载均衡
  • Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求
  • 客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信
    息后，直接从Region服务器上读取数据
  • 客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户
    端甚至从来不和Master通信，这种设计方式使得Master负载很小

表和Region

hbase伪分布式集群配置 hbase分布式数据库_数据_06

  • 每个Region默认大小是100MB到200MB
  • 每个Region的最佳大小取决于单台服务器的有效处理能力
  • 目前每个Region最佳大小建议1GB-2GB
  • 同一个Region不会被分拆到多个Region服务器
  • 每个Region服务器存储10-1000个Region

Region的定位

  • 元数据表，又名.META.表，存储了Region和Region服务器的映射关系
  • 当HBase表很大时 .META.表也会被分裂成多个Region
  • 根数据表，又名-ROOT-表，记录所有元数据的具体位置
  • -ROOT-表只有唯一一个Region，名字是在程序中被写死的
  • Zookeeper文件记录了-ROOT-表的位置
  • 为了加快访问速度， .META.表的全部Region都会被保存在内存中
  • 假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目的计算方法是：
  • （-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）
  • 一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算， 128MB空间可以容纳128MB/1KB=217行，也就是说，一个-ROOT-表可以寻址217个.META.表的Region。
  • 同理，每个.META.表的 Region可以寻址的用户数据表的Region个数是128MB/1KB=217。
  • 最终，三层结构可以保存的Region数目是(128MB/1KB) × (128MB/1KB) = 234个Region

客户端访问数据时的“三级寻址”

  • 为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题
  • 寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器

HBase运行机制

HBase系统架构

hbase伪分布式集群配置 hbase分布式数据库_数据_07

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

Region服务器工作原理

1.用户读取数据过程

  • 用户写入数据时，被分配到相应Region服务器去执行
    -用户数据首先被写入到MemStore和Hlog中
    -只有当操作写入Hlog之后， commit()调用才会将其返回给客户端
    -当用户读取数据时， Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找

2.缓存的刷新

  • 系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
  • 每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件
  • 每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务

3.storeFile合并

  • 每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
  • 调用Store.compact()把多个合并成一个合并操作比较耗费资源，只有数量达到一个阈值才启动合并

Store工作原理

Store是Region服务器的核心

  • 多个StoreFile合并成一个
  • 单个StoreFile过大时，又触发分裂操作， 1个父Region被分裂成两个子
    Region

HLog工作原理

  • 分布式环境必须要考虑系统出错。 HBase采用HLog保证系统恢复
  • HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）
  • 用户更新数据必须首先写入日志后，才能写入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文件中，完成数据恢复
  • 共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志

HBase应用方案

HBase实际应用中的性能优化方法

行键：行健按照字典序存储，将进场一起读取的数据存储一块
inmemory 将表放在regon服务器的缓存汇总，保证读取时候被cache命中
max version 值保留最新版本数据
timeToLive 删除过期数据

HBase性能监视

  • Master-status(自带)
    HBase Master默认基于Web的UI服务端口为60010， HBase region服务器默
    认基于Web的UI服务端口为60030
  • Ganglia
  • OpenTSDB
  • Ambari

在HBase之上构建SQL引擎

为什么在HBASE上提供SQL接口？
易使用 减少编码

方案：
1.Hive整合HBase
整合功能从Hive0.6.0版本已经开始出现，利用两者对外的API接口互相通信，通信主要依靠hive_hbase-handler.jar工具包

2.Phoenix
Phoenix由Salesforce.com开源，是构建在Apache HBase之上的个SQL中间层，可以让开发者在HBase上执行SQL查询。

构建HBase二级索引

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

  • 通过单个行健访问
  • 通过一个行健的区间来访问
  • 全表扫描

使用其他产品为HBase行健提供索引功能：

  • Hindex二级索引
  • HBase+Redis
  • HBase+solr

HBase编程实践

HBase的安装与配置

安装+配置
单机模式、伪分布式模式、分布式模式
启动关闭Hadoop和HBase的顺序一定是：
启动Hadoop—>启动HBase—>关闭HBase—>关闭Hadoop

cd /usr/local/hadoop
./sbin/start-all.sh

jps命令查看是否启动成功
启动hbase

cd /usr/local/hbase
./bin/start-hbase.sh //启动HBase
./bin/hbase shell  //启动hbase shell

HBase常用Shell命令

  • list：列出HBase中所有的表信息
  • put：向表、行、列指定的单元格添加数据一次只能为一个表的一行数据的一个列添加一个数据
  • scan：浏览表的相关信息
  • get：通过表名、行、列、时间戳、时间范围和版本号来获得相应单元格的值
  • enable/disable：使表有效或无效
  • drop：删除表

HBase常用Java API及应用实例