大数据(HBase-应用场景、原理与基本架构)

Hbase概述

     HBase是一个构建在HDFS上的分布式列存储系统;

     HBase是Apache Hadoop生态系统中的重要一员,主要用于海量结构化数据存储

     从逻辑上讲, HBase将数据按照表、行和列进行存储。

Hbase是Hadoop生态系统的一个组成部分

bc82033e38b91c99c6d5e87e58adf17097c.jpg

Hbase与HDFS对比

两者都具有良好的容错性和扩展性,都可以扩展到成百上千个节点;

HDFS适合批处理场景
   不支持数据随机查找
   不适合增量数据处理
   不支持数据更新

Hbase表的特点

     大:一个表可以有数十亿行,上百万列;

     无模式:每行都有一个可排序的主键和任意多的列,列可以根据需要动态的增加,同一张表中不同的行可以有截然不同的列;

     面向列:面向列(族)的存储和权限控制,列(族)独立检索;

     稀疏:对于空( null)的列,并不占用存储空间,表可以设计的非常稀疏;

     数据多版本:每个单元中的数据可以有多个版本,默认情况下版本号自动分配,是单元格插入时的时间戳;

     数据类型单一: Hbase中的数据都是字符串,没有类型

行存储与列存储

3190bfecb5bc6b20c288bed4655a3e70716.jpg

   数据是按行存储的
   没有索引的查询使用大量I/O 
   建立索引需要花费大量时间和资源

3718316b798e99982bf4fe35d26803232d6.jpg

    数据是按列存储-每一列单独存放
    数据即是索引
    指访问查询涉及的列-大量降低系统I/O 
    每一列由一个线索来处理-查询的并发处理
    数据类型一致,数据特征相似-高效压缩

 

Hbase数据模型

     HBase是基于Google BigTable模型开发的, 典型的key/value系统;

a9b27e2951ea97333d8b3d36562723c5de7.jpg

Hbase逻辑视图

5877ef4620028cdfaa80c696b3f94b59da9.jpg

 

Rowkey与Column Family

3a12f3fc91a3fbc1f9a1eac7f2b9aa7ebfa.jpg

 

Hbase基本概念

Row Key
  Byte array
  表中每条记录的“主键”
  方便快速查找

Column Family
  拥有一个名称(string)
  包含一个或者多个相关列

Column
  属于某一个column family
  包含在某一列中
    familyName:columnName

Version Number
默认值系统时间戳

Value(cell)
  Byte array

Hbase数据模型

     HBase schema可以有多个类似Table 
     每个表可由多个Column Family组成
     Hbase可以有Dynamic Column
e4a3eb9d54fa1b61ff63d26ee7d0642d4a7.jpg

version number 可由用户提供
   无需以递增的顺序插入
Table可能非常稀疏
   不同的cell可以拥有不同的列
Row Key是主键
5e48d35e8a99d5c9542be52e46256b3182a.jpg

Hbase与支持的操作

所有操作均是基于rowkey的;
支持CRUD(Create、Read、Update和Delete)和Scan;
单行操作
   put
   get
   scan
多行操作
   Scan
   Multiput
没有内置join操作,可使用MapReduce解决
 

Hbase物理模型

  每个column family存储在HDFS上的一个单独文件中;
  Key 和 Version number在每个 column family中均由一份;
  空值不会被保存。
  Hbase为每个值维护了多级索引

一个实例

68b2f28502ccff03529b1974ce57a5f8f53.jpg

1a4442db05c8e750b09493eec174006aa36.jpg

0dbd8eb1b7a451b62a195ce31d2faac5b1f.jpg

物理存储

1、 Table中的所有行都按照row key的字典序排列;
2、 Table 在行的方向上分割为多个Region;

9cac28c17d999035a8c1f2b7acb3e01a6df.jpg

3、 Region按大小分割的,每个表开始只有一个region,随着数据增多, region不断增大,当增大到一个阀值的时候,region就会等分会两个新的region,之后会有越来越多的region;

71bcd046a9b57f5e713ff87b6cbae2904d2.jpg

4 、 Region是HBase中分布式存储和负载均衡的最小单元。不同Region分布到不同RegionServer上;

4a210b0281c09027bd5c12c530ae8516b47.jpg

5 、 Region虽然是分布式存储的最小单元,但并不是存储的最小单元
   Region由一个或者多个Store组成,每个store保存一个columns family
   每个Store又由一个memStore和0至多个StoreFile组成;
   memStore存储在内存中, StoreFile存储在HDFS上。
bfa4035bad3d7c086636d17d41bc0220e33.jpg

 

HBase架构

c2cc03ca89bc999c64766627f2704c73041.jpg

 

Hbase基本组件

Client
   包含访问Hbase的接口,并维护cache来加快对Hbase的访问
ZooKeeper
   保证任何时候,集群中只有一个master
   存贮所有Region的寻址入口
   实时监控Region server的上线和下线信息。并实时通知给Master
   存储HBase的schema和table元数据
Master
   为Region server分配region
   负责Region server的负载均衡
   发现失效的Region server并重新分配其上的region
   管理用户对table的增删改查操作
Region Server
   Region server维护region,处理对这些region的IO请求
   Region server负责切分在运行过程中变得过大的region
 

Zookeeper作用

HBase 依赖ZooKeeper
默认情况下, HBase 管理ZooKeeper 实例
   比如, 启动或者停止ZooKeeper
Master与RegionServers启动时会向ZooKeeper注册
Zookeeper的引入使得Master不再是单点故障

e18b5816d03362e1c42ec6537551806dfce.jpg

Write-Ahead-Log( WAL)

c71cc741d7c9c8ab6d7b4c57df45df38c05.jpg

Hbase容错性

Master容错: Zookeeper重新选择一个新的Master
   无Master过程中,数据读取仍照常进行;
   无master过程中, region切分、负载均衡等无法进行;
RegionServer容错:定时向Zookeeper汇报心跳,如果一旦时间内未出现心跳
   Master将该RegionServer上的Region重新分配到其他RegionServer上;
   失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer
Zookeeper容错: Zookeeper是一个可靠地服务
   一般配置3或5个Zookeeper实例。

Region定位

febf6e75a84fa93a79909f0fd0d4592792c.jpg

寻找RegionServer
   ZooKeeper
   -ROOT-(单Region)
   .META.
   用户表

-ROOT-表与.META.表

-ROOT-
   表包含.META.表所在的region列表,该表只会有一个Region;
   Zookeeper中记录了-ROOT-表的location。
 .META.
   表包含所有的用户空间region列表,以及RegionServer的服务器地址。

 

HDFS与Hbase比较

10f953a71ba198a80b2836a892be34e4020.jpg

 

关系数据库与Hbase比较

fadb1853dad49c37f047192fb70eb06ba95.jpg

 

何时使用Hbase

     需对数据进行随机读操作或者随机写操作;
     大数据上高并发操作,比如每秒对PB级数据进行上千次操作;
     读写访问均是非常简单的操作。

什么公司在使用Hbase

    国外有facebook,twitter,yahoo等 国内有阿里巴巴,百度,360等一些公司

Hbase在淘宝的应用

交易历史记录查询系统
   百亿行数据表,千亿级二级索引表
   每天千万行更新
   查询场景简单,检索条件较少
   关系型数据库所带来的问题
   基于userId+time+id rowkey设计
   成本考虑

 

转载于:https://my.oschina.net/u/3728166/blog/3065882

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值