hbase(1)-基础

1、hbase产生背景

hadoop只能执行批量处理，并且只能以顺序方式访问数据，这意味着即使最简单的搜索工作，也必须搜索整个数据集。那么当处理一个庞大的数据集，也是按照顺序处理一个巨大的数据集。

基于上述hadoop的限制，急需一个新的解决方案，需要（随机）访问数据中的任何点单元。

由此，诞生了大批的hadoop随机存取数据库的框架。如：hbase、cassandra、CouchDB和MongoDB等都是一些可以存储大量数据，也能以随机方式访问数据的数据库。

2、什么是hbase?

1）、hbase是BigTable的开源版本（源码使用java编写）

2）、hbase是一个高可靠、高性能、面向列、可伸缩的分布式存储系统，利用hbase技术可以在廉价的PC Server上搭建起大规模的结构化数据存储集群。

3）、hbase的目标是存储并处理大型的数据，即仅需要使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。

序号	Hbase	BigTable
1	依赖HDFS做底层的数据存储	依赖Google GFS做底层的数据存储
2	依赖MapReduce做数据计算	依赖Google MapReduce做数据计算
3	依赖zookeeper做服务协调	依赖Google Chubby做服务协调

3、Hbase这个NoSQL数据库的要点

1）、hbase介于NoSQL和RDBMS之间，仅能通过主键Rowkey和主键的range来检索数据

2）、hbase不支持复杂的事务，只支持行级事务（可以通过hive支持来实现多表join等复杂操作）

3）、hbase查询数据的功能非常简单，不支持join等复杂操作（可以通过hive支持来实现多表join等复杂操作）。

4）、hbase中支持的数据类型为byte[]，即底层所有数据的存储都是字节数组

5）、hbase主要用来存储结构化和半结构化的松散数据。

注：

结构化：数据结构字段确定且清晰，如数据库中的表结构

半结构化：具有一定的结构，但是语义不够确定，如HTML网页，有些字段是确定的如title,有些不确定如table

非结构化：杂乱无章的数据

4、hbase中表的特点

1）、大：一个表可以由上十亿行，上百万列组成

2）、列式存储数据：hbase是根据列簇来存储数据，创建表时必须指定列簇，列簇下面可以有非常多的列。

3）、稀疏：对于为空(null)的列，并不占用存储空间，因此hbase中的表可以设计得非常稀疏。

4）、极易扩展：hbase基于存储的扩展依赖于HDFS，基于数据处理的能力依赖于RegionServer的扩展。可以横向的添加RegionServer的机器，进行水平扩展。

5）、高并发处理能力：hbase架构都是采用廉价的PC Server,在高并发的情况下，hbase的单个IO延迟下降并不多。能够获得高并发、低延迟的服务。

5、hbase表结构

如下图是一张hbase表的数据

1）、Rowkey（键）

Rowkey和mysql中的主键完全一样，hbase使用rowkey来唯一的区分某一行的数据。

由于hbase只支持3种查询方式：基于rowkey的单行查询；基于rowkey的范围扫描；全表扫描。

因此，rowkey对hbase的性能影响非常大，rowkey的设计就显得尤为重要。那么，设计的时候就需要兼顾基于rowkey的单行查询，也要键入rowkey的范围扫描。

注：rowkey行键可以是任意字符串（最大长度为64kb,实际应用中长度一般为10-100bytes）,那么最好是16bytes。在hbase内部，rowkey保存为字节数组，hbase会对表中的数据按照rowkey排序（字典顺序）。

2）、columnFamily（列簇）

• hbase通过列簇划分数据的存储，列簇下面可以包含任意多的列，实现灵活的数据存取。
• hbase表在创建时就必须指定列簇，就像关系型数据库创建的时候必须指定具体的列是一样的。
• hbase的列簇并不是越多越好，官方推荐列簇最好小于或者等于3。一般场景为一个列簇。

注：列簇类似于家族，家族下面由很多个家庭组成。

3）、column（列）：同mysql中的列

4）、TimeStamp（时间戳）

• TimeStamp是实现hbase多版本的关键，使用不同的timestamp来标识相同rowkey行对应的不同版本的数据。
• hbase中通过rowkey和columns确定的为一个存储单元称之为cell,每个cell都保存着同一份数据的多个版本，版本通过时间戳来索引。时间戳的类型是64位整型。
• 时间戳可以由hbase(在数据写入时自动）赋值，此时时间戳是精确到毫秒的当前系统时间。
• 时间戳也可以由客户显示赋值，如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。

为了避免数据存在过多版本造成管理负担，hbase提供了两种数据版本回收方式：

• 保存数据的最后n个版本
• 保存最近一段时间内的版本（设置数据的生命周期TTL）

5）、cell（单元格）

 由{rowkey,column（=+），version}唯一确定的单元。Cell中的数据是没有类型的，全部都是字节码形式存储。

6、Hbase架构图

从图中可以看出，hbase由client、zookeeper、HMaster、HRegionServer、HDFS等几个组件组成。

1 ）、client：提供访问hbase的接口，另外还维护了对应的cache来加速hbase的访问。比如：cache中的.META.元数据的信息。

2）、hbase通过zookeeper来做master的高可用、regionServer的监控、元数据的入口以及集群配置的维护等工作。

• 通过zookeeper保证集群中只有1个master在运行，如果master异常，会通过竞争机制产生新的master来提供服务
• 通过zookeeper来监控regionserver的状态，当regionserver有异常，通过回调的形式通知master regionserver上下线的信息。
• 通过zookeeper存储元数据的统一入口地址

3）、hmaster节点

主要职责：

• 为HRegionServer分配Region
• 维护整个集群的负载均衡
• 维护集群的元数据信息
• 发现失效的Region后，将失效的region分配到正常的HRegion上运行
• 当RegionServer失效的时候，协调对应的Hlog的拆分

4）、HRegionServer

• 直接对接用户的读写请求，是真正的干活节点
• 管理master,并为其分配Region
• 处理来自客户端的读写请求
• 负责和底层HDFS的交互，存储数据到HDFS
• 负责storefile的合并工作

5）、HDFS

hdfs为hbase提供最终的底层数据存储服务，同时为habse提供高可用的支持（hlog存储在HDFS）

提供元数据和表数据的底层分布式存储服务；

数据多副本，保证的高可靠和高可用性。

注：

1）、store：HFile存储在store中，一个store对应hbase表中的一个列簇

2）、memstore：内存存储，位于内存中，用来保存当前的数据操作，所以当数据保存到WAL中之后，RegionServer会在内存中存储键值对。

3）、HFile：这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile是以hFile的形式存储在HDFS上的。

4）、write-Ahead logs

hbase的修改记录，当对hbase读写数据的时候，数据不是直接写进磁盘，它会在内存中保留一段时间（时间以及数据量阀值可以设定）。但将数据保存在内存中的可能有高概率引起数据丢失，为了解决这个问题，数据会先写在一个叫做write-Ahead logfile的文件中，然后再写入内存中，所以系统出现故障的时候，数据可以通过这个日志文件重建。