HBase入门与基本使用

HBase是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

Hadoop生太圈


通过Hadoop生态圈,可以看到HBase的身影,可见HBase在Hadoop的生态圈是扮演这一个重要的角色那就是 实时分布式高维数据 的数据存储。

相比关系型数据库的表模型不同:

  • HBase的表没有固定的字段定义;
  • HBase的表每行存储的都是一些 key-value 键值对;
  • HBase的表有列族的划分,用户可以指定将哪些 kv 插入哪个列族
  • HBase的表在物理存储上,是按照列族来分隔的,不同列族的数据一定存储在不同的文件中;
  • HBase的表中的每一行都固定有一个行键,而且每一样的行键在表中不能重复;
  • HBase中的数据,包含行键,包含key,包含value,都是byte[]类型,HBae不负责为用户维护数据类型
  • HBase对事务的支持很差
HBase和其它数据库之间差异

HBase特性

HBase相比于其它 NoSQL数据库(mongodb、redis、cassendra、hazelcast)的特点,HBase的表数据库存储在HDFS文件系统中,从而,HBase具备如下特性:

  • 数据的最终持久化存储是基于: HDFS --> 存储容量可以线性扩展
  • HBase的数据增删改查功能模块是:分布式系统 --> HBase是一个分布式数据库系统
  • 主要用来存储非结构化和半结构化的松散数据(列存NoSQL数据库)

HBase体系架构

  • Client
    包含访问HBase的接口并维护cache来加快对HBase的访问

  • Zookeeper

    • 保证任何时候,集群中只有一个master
    • 存贮所有Region的寻址入口。
    • 实时监控Region server的上线和下线信息。并实时通知Master
    • 存放整个HBase集群的元数据以及集群的状态信息
  • Master

    • 管理HRegionServer,实现其负载均衡
    • 发现失效的Region server并重新分配其上的region
    • 管理用户对table的增删改操作
    • 管理namespace和table的元数据(实际存储在HDFS上)
    • 权限控制(ACL)
    • 监控集群中所有HRegionServer的状态(通过Heartbeat和监听ZooKeeper中的状态)
  • RegionServer

    • 管理自己所负责的region数据的读写
    • 读写HDFS,管理Table中的数据
    • Client直接通过HRegionServer读写数据(从HMaster中获取元数据,找到RowKey所在的HRegion/HRegionServer后)
  • HLog(WAL log)

    • HLog文件就是一个普通的Hadoop Sequence File,Sequence File 的Key是 HLogKey对象,HLogKey中记录了写入数据的归属信息,
    • 除了table和 region名字外,同时还包括sequence number和timestamp,timestamp是” 写入时间”,sequence number的起始值为0,
    • 或者是最近一次存入文件系 统中sequence number。
    • HLog SequeceFile的Value是HBase的KeyValue对象,即对应HFile中的 KeyValue
  • Region

    • HBase自动把表水平划分成多个区域(region),每个region会保存一个表 里面某段连续的数据;每个表一开始只有一个region,随着数据不断插 入表,
    • region不断增大,当增大到一个阀值的时候,region就会等分会 两个新的region(裂变);
    • 当table中的行不断增多,就会有越来越多的region。这样一张完整的表 被保存在多个Regionserver上。
  • Memstore 与 storefile

    • 一个region由多个store组成,一个store对应一个CF(列族)
    • store包括位于内存中的memstore和位于磁盘的storefile写操作先写入 memstore,当memstore中的数据达到某个阈值,
    • hregionserver会启动 flashcache进程写入storefile,每次写入形成单独的一个storefile
    • 当storefile文件的数量增长到一定阈值后,系统会进行合并(minor、 major compaction),在合并过程中会进行版本合并和删除工作 (majar),形成更大的storefile。
    • 当一个region所有storefile的大小和超过一定阈值后,会把当前的region 分割为两个,并由hmaster分配到相应的regionserver服务器,实现负载均衡。
    • 客户端检索数据,先在memstore找,找不到再找storefile
    • HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表 示不同的HRegion可以分布在不同的HRegion server上。
    • HRegion由一个或者多个Store组成,每个store保存一个columns family。
    • 每个Strore又由一个memStore和0至多个StoreFile组成。

    如图:StoreFile 以HFile格式保存在HDFS上。



Hbase客户端读写数据时的路由流程

  1. 客户端先到zookeeper查找hbase:meta所在的RegionServer服务器
  2. 去hbase:meta表查找自己所要的数据所在的region server
  3. 去目标region server上的region要自己的数据

可以看出客户端查找数据可以不经过master

HBase数据模型

在关系型数据的思维下会感觉,上面的表格是一个5列4行的数据表格,但是在HBase中其实只是一行数据。

这里面设计概念:

  • Row Key:

    • 决定一行数据的唯一标识
    • RowKey是按照字典顺序排序的
    • RowKey最多只能存储64k的字节数据
  • Timestamp时间戳:

    • 在HBase每个cell存储单元对同一份数据有多个版本,根据唯一的时间 戳来区分每个版本之间的差异,不同版本的数据按照时间倒序排序,最新的数据版本排在最前面。
    • 时间戳的类型是64位整型。
    • 时间戳可以由HBase(在数据写入时自动)赋值,此时时间戳是精确到毫 秒的当前系统时间。
    • 时间戳也可以由客户显式赋值,如果应用程序要避免数据版本冲突, 就必须自己生成具有唯一性的时间戳。
  • Column Family列族(CF1、CF2、CF3) & qualifier列:

    • HBase表中每个列都归属于某个列族,列族必须作为表模式(schema)定义的一部分预先给出。
      如:create 't_user_info','base_info','extra_info'
                        表名      列族名   列族名
    
    • 列名以列族作为前缀,每个“列族”都可以有多个列成员(column,每个列族中可以存放几千~上千万个列);如 CF1:q1, CF2:qw,
    • 新的列族成员(列)可以随后按需、动态加入,Family下面可以有多个Qualifier,所以可以简单的理解为,HBase中的列是二级列,
    • 也就是说Family是第一级列,Qualifier是第二级列。两个是父子关系。
    • 权限控制、存储以及调优都是在列族层面进行的;
    • HBase把同一列族里面的数据存储在同一目录下,由几个文件保存。
    • 目前为止HBase的列族能能够很好处理最多不超过3个列族。
  • Cell单元格:

    • 由行和列的坐标交叉决定;
    • 单元格是有版本的(由时间戳来作为版本);
    • 单元格的内容是未解析的字节数组(Byte[]),cell中的数据是没有类型的,全部是字节码形式存贮。
    • 由{row key,column(=<family> +<qualifier>),version}唯一确定的单元。

HBase命令行客户端操作

  • 建表:

    create 't_user_info','base_info','extra_info'
           表名      列族名   列族名
    
  • 插入数据:

    hbase(main):011:0> put 't_user_info','001','base_info:username','zhangsan'
    0 row(s) in 0.2420 seconds
    
    hbase(main):012:0> put 't_user_info','001','base_info:age','18'
    0 row(s) in 0.0140 seconds
    
    hbase(main):013:0> put 't_user_info','001','base_info:sex','female'
    0 row(s) in 0.0070 seconds
    
    hbase(main):014:0> put 't_user_info','001','extra_info:career','it'
    0 row(s) in 0.0090 seconds
    
    hbase(main):015:0> put 't_user_info','002','extra_info:career','actoress'
    0 row(s) in 0.0090 seconds
    
    hbase(main):016:0> put 't_user_info','002','base_info:username','liuyifei'
    0 row(s) in 0.0060 seconds
    
  • 查询数据:

    • 方式一:scan 扫描
    hbase(main):017:0> scan 't_user_info'
    ROW                               COLUMN+CELL                                                                                     
    001                              column=base_info:age, timestamp=1496567924507, value=18                                         
    001                              column=base_info:sex, timestamp=1496567934669, value=female                                     
    001                              column=base_info:username, timestamp=1496567889554, value=zhangsan                              
    001                              column=extra_info:career, timestamp=1496567963992, value=it                                     
    002                              column=base_info:username, timestamp=1496568034187, value=liuyifei                              
    002                              column=extra_info:career, timestamp=1496568008631, value=actoress                               
    2 row(s) in 0.0420 seconds
    
    • 方式二:get 单行数据
    hbase(main):020:0> get 't_user_info','001'
    COLUMN                            CELL                                                                                            
    base_info:age                    timestamp=1496568160192, value=19                                                               
    base_info:sex                    timestamp=1496567934669, value=female                                                           
    base_info:username               timestamp=1496567889554, value=zhangsan                                                         
    extra_info:career                timestamp=1496567963992, value=it                                                               
    4 row(s) in 0.0770 seconds
    
  • 删除数据:

    • 删除一个kv数据
      hbase(main):021:0> delete 't_user_info','001','base_info:sex'
      0 row(s) in 0.0390 seconds
      
    • 删除整行数据
      hbase(main):024:0> deleteall 't_user_info','001'
      0 row(s) in 0.0090 seconds
      
      hbase(main):025:0> get 't_user_info','001'
      COLUMN                            CELL                                                                                            
      0 row(s) in 0.0110 seconds
      
    • 删除整个表
      hbase(main):028:0> disable 't_user_info'
      0 row(s) in 2.3640 seconds
      
      hbase(main):029:0> drop 't_user_info'
      0 row(s) in 1.2950 seconds
      
      hbase(main):030:0> list
      TABLE                                                                                                                             
      0 row(s) in 0.0130 seconds
      
      => []
      

Hbase重要特性

  • 排序特性(行键)
    插入到HBase中的数据,HBase会自动排序存储,排序规则:
    首先看行键(RowKey),然后看(key) 名 --> 按字典顺序

    HBase的这个特性他跟查询效率有极大关系
    比如:一张用来存储用户信息的表,有名称、户籍、年龄、职业......等信息,然后,在业务系统中经常需要:

    1. 查询某个省的所有用户
    2. 经常需要查询某个省的指定姓的所有用户

    思路:如果能将相同省的用户在Hbase存储文件中连续存储,并且能将相同姓的用户连续存储,那么,上述查询需求效率就会很高!

    做法:将查询条件拼接到 RowKey 中

  • HBase的表中能存储 byte[] 数据类型
    此处的byte[] 包括了: rowkey,key,value,列族名,表名

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,258评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,335评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,225评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,126评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,140评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,098评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,018评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,857评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,298评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,518评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,678评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,400评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,993评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,638评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,801评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,661评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,558评论 2 352

推荐阅读更多精彩内容