Hbase学习总结

Hbase学习总结

作者:admin |  时间:2015-05-13 |  浏览:176 |  0 条评论

一、HBase产生背景
     现在各种网络应用的规模越来越大,其用户数量和业务模式决定了会以极快的速度不断产生海量数据,除了储存这些数据之外,还需要对其进行有效的管理和使用,而传统的数据处理模式已经不能适用于这类情况。
Google在这方面做出了很多尝试并取得成果,他们首先发布了GFS作为底层的数据存储系统。GFS是一种分布式、可扩展的文件系统,它可以运行在廉价的服务器上,通过服务器的大量堆积来实现对海量数据的支持,同时通过文件副本机制来实现容错功能。另一方面,Google还发布了MapReduce,这是对海量数据进行处理的一个计算框架,它将绝大多数数据运算分解为Map和Reduce两个阶段,大量的服务器对这两个阶段进行并行处理,从而极大的提高了数据处理的吞吐量,它与GFS一起构成了Google对海量数据进行处理的基本架构。
但是这个架构仍有不足,在数据随机访问和实时响应方面的表现并不理想,同时,GFS主要是针对大体积文件来设计的,在处理体积很小,但数目极大的文件时,表现并不很好,会对整个系统造成很大压力。因此,Google设想了这样的一种数据管理模式,该模式可以对大量的小体积数据实体进行管理,能够将这些数据实体合并压缩存储在大体积的数据文件中,同时应该对其进行排序以提高检索性能,另外还需要能够对MapReduce提供支持,从而有效填补GFS和MapReduce中间缺失的部分,将整个系统无缝连接起来。
在对现有的关系型数据库进行研究之后,Google采用了另外一套方案:不提供对关系连接(join)的支持,只保留基本的CRUD操作(create, read, update, delete),以及scan操作来遍历数据,该方案被称为BigTable。“BigTable是一个用于结构化数据的分布式存储系统,它可以用来实现对极大规模数据的支持:横跨在成千上万个廉价服务器上的PB级别的数据。”“BigTable是一种稀疏的、分布式的、多维、有序、永久化存储的数据结构(Map,由Key/Value对构成)”。BigTable和GFS、MapReduce一起被称之为Google的三驾马车。
Hadoop是上述三种技术的开源实现版本,对应包括HDFS(GFS)、HBase(BigTable)、Hadoop MapReduce(MapReduce),以及ZooKeeper(Chubby)来实现协同服务。其中,HBase的基本实现思想是和BigTable一致的,其中的很多架构和实现细节也都基本类似,因此,HBase也能够像BigTable那样实现较好的性能,满足各种业务需求。
二、HBase特点与应用
     HBase是一个高可靠性、高性能、面向列、可伸缩的数据库。
     高可靠性。在底层数据文件的存储上,采用HDFS作为文件系统,保证了数据的安全稳定。采用Write-ahead Log(WAL)来保证数据操作的安全,不会因意外情况丢失数据。每个更新操作限定于单行,且均为原子操作,简化了数据一致性的问题,保证了数据的强一致性。ZooKeeper和HMaster的架构设计,保证了访问服务的稳定,能够在短时间内发现失效节点并进行处理,重新恢复服务。
     高性能。HBase摒弃了传统的关系型数据库的严格范式(Normalization)限定,不提供多表的关系连接(join),大大简化了数据的关联性,简化了存储的限制和难度。所有数据都是按照字典顺序有序存储,提高了检索速度。通过合理设计能够在位置上体现数据的相关性,一次读取整块数据的cache机制能够保证批量数据的读取要求。采用分布式结构,一个表可以分为几个部分同时提供服务,互不影响,提供了响应速度和IO吞吐量。所有(大部分?)操作均是以写操作的方式完成,同时采用MemStore和StoreFile两级存储结构,保证了写操作的响应速度。
     面向列。相对于传统的以行为单位进行存储的方式,HBase采用以列(实际上是列族)为单位的方式进行存储,每个column family是单独的一个存储文件。采用键值(Key/Value)方式进行存储,不提供语义级别的数据类型定义,简化存储的复杂程度。每个column family中的column可以随时任意添加,能够快速响应业务逻辑变更需求。
     可伸缩。HBase在提供服务方面不存在单点限制,所有节点都是可以被代替的,同时也很容易进行水平扩展。通过对服务集群的扩容,能够实现服务性能的近似线性增长。可以根据业务需要,动态调整服务集群的规模,实现成本与性能的平衡。
     由上述的描述可以看出,HBase的优势不仅在于能够处理海量数据,同时在处理过程中能够有效保证性能,具备很强的扩展性,还可以灵活响应业务逻辑的变更。HBase适用于具有以下需求的场合:
•     数据量很大,需要海量分布式文件系统,能对TB级甚至PB级别的数据提供在线服务
•     数据量的增长很快且不一定能准确预计,因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求,且不希望存在单点制约
•     只需要简单的kv读取,没有复杂的join等需求。但对系统的并发能力以及吞吐量、响应延时有非常高的需求,并且希望系统能够保持强一致性
•     通常系统的写入非常频繁,
•     希望能够快速读取批量数据
•     schema灵活多变,可能经常更新列属性或新增列
     当然,HBase也有自身的一些限制,并不是适用于所有场合。比如,索引只支持主索引,可能需要更复杂和精心的Schema设计,来实现传统RDBMS表连接查询的业务需求;数据服务是单点的,当出现意外情况时会在短时间内无法提供服务(虽然恢复很快,但毕竟需要时间)。
三、HBase逻辑视图与物理架构
     在HBase的逻辑视图当中,列(column)是最基本的结构,一个或多个列构成的行(row)由row key来区分,row key类似于RDBMS的主键,是HBase中row的唯一性标识(好像还有Secondary Index,还没有研究),也是对row进行排序的依据,HBase对其采用二进制排序,row-10排序在row-2之前,如果要使得排序结果更具可读性,需要写成row-02的格式。
     多个column可组成列族(column family),column family是HBase中Schema的组成部分,在建表时确定,不应该频繁对其进行修改,对于一个表而言,column family的数目不宜太多,理论上几十个就会出现问题,实际应用中应该更少。在HBase的底层实现中,同一个column family内的column都是一起存储的,在同一个HFile中(HDFS结构),因此应该把具有相同特性的column归为一个family,这样可以提高压缩以及I/O吞吐等性能。
     Column由family:qualifier来表示,其中qualifier可以理解为列名,column不属于Schema的一部分,因此可以在建表后任意添加,在一个column family中column的个数不受限制,其qualifier的长度和数据类型也都是任意的,HBase不区分存储数据的数据类型,所有数据均以二进制形式存储,其具体语义由外部调用自行解释。
     由row key和family:qualifier就可以确定一个cell,即存放具体数据的位置,HBase中每个cell可以包含多个版本(version),由timestamp来区分,时间戳可以由用户在更新数据时指定,也可以由系统隐式确定,采用从1970年1月1日起过去的毫秒数作为具体数值。不同版本的数据是以降序方式存储的,即最后更新的数据排在最前,可以最先读到,这一特性也可以提高日常检索的性能。HBase支持对版本保留的设置,可以设定只保留最后的几个版本,或者多长时间以内的版本(比如一周),超出此范围的版本会被自动删除,节省空间,而不需用户特意执行操作。
     通过上述的逻辑视图可以看出,在HBase中取出一个数据,通常需要五个维度,即:
          (Table, RowKey, Family, Qualifier, Timestamp) -> value,
或者从另外一个角度:
          SortedMap<RowKey, List<SortedMap<Column, List<Value, TimeStamp>>>>
     其中,第一个有序Map是RowKey和所有column family列表的集合,第二个SortedMap指的则是某个具体的column family,它包括column和所有value的集合,每个value和对应的timestamp构成了最后的List。

     HBase支持对数据以row的方式进行分片(Sharding),每片的基本单位称为region。当数据文件的体积超过预定阈值时,会按照中间row key自动分为两部分,每个部分可以交由不同的region server进行处理。Region server和region是一对多的关系,即一个region只会交给一个region server进行处理,而一个region server可能同时处理多个region。另外,当数据文件体积小但数量多时,有可能会执行合并操作,变为一个region。
     自动分片的实现基础在于,HBase中所有数据都是按照row key有序排列的,这样使得分片或者合并都不需要过多的开销,同时HBase规定只支持单行事务,保证单行的原子操作,
这样即使region在不同server上进行处理,也不需考虑一致性问题。采用这种region server机制的好处是很明显的,不仅能够对数据进行并发处理,还可以通过实时调度实现负载均衡,同时这种结构具备很强的水平扩展性,出故障的机器能够很容易被接替,机群的扩容能够实现性能的近似线性增长。

     HBase的基本物理结构可以分为三个部分,分别是:客户端、一个Master Server和很多个Region Server,此外还需要ZooKeeper来提供协同服务,如图1所示。客户端通过HBase的RPC机制与HMaster和HRegionServer进行通信,数据管理操作与HMaster进行通信,数据读写类操作则与HRegionServer交互来完成。HMaster主要负责表结构Schema的更改,调整HRegionServer的负载均衡,负责region split后的重新分配,以及HRegionServer停机后region恢复和迁移。HMaster由ZooKeeper来保证总有一个在运行,不存在单点问题,由于其不参与具体的数据传输工作,因此负荷很低。
每个HRegionServer负责一个或多个region的处理,即HRegion结构。在HBase的物理存储结构中,数据是以column family为单位进行维护的,每个column family即表现为HStore结构。HStore包含MemStore和StoreFile两个部分,MemStore是内存中的存储结构,所有更新的数据都会首先以有序方式存放在MemStore中,当MemStore体积达到一定阈值后,就会写入磁盘,称为StoreFile,StoreFile一旦写入磁盘就不会再改变,唯一能够对其数据进行修改的方式是进行compaction。
当StoreFile的个数太多时,HRegionServer会启动compaction,这又分为minor compaction和major compaction两种,minor会相对较频繁的进行,是对一部分StoreFile进行多路合并,例如100个文件合并为80个,major则是将所有100个StoreFile全部写入一个文件,由于此操作会导致很大的IO压力,因此一般执行次数较少。另外,由于不能修改StoreFile文件,delete操作时通过更新一条带有delete marker的方式来实现的,当对一个指定版本进行delete之后,其它更低版本的数据也不能再查出。

HRegion中还包含一个结构叫做HLog,它记录了所有还未flush的操作,这些数据不会服务于查询等操作,唯一的作用是在HRegion出故障后用来恢复数据。在每个操作被写入MemStore之前,就会首先写入HLog,又称为write-ahead log,WAL,这是为了防止MemStore因故障丢失数据。当MemStore被持久化到HFile之后,数据的安全由HDFS来保证,HBase可以认为数据是安全的,因此需要将对应的操作记录从WAL中删除。如果HRegionServer出现故障,MemStore中的数据就会丢失,此时HMaster会安排region的重新上线,WAL也会根据重新分配的region转移到新的HRegionServer中,由新的HRegionServer按照WAL记录来恢复数据,并重新提供HRegion服务。


图1 HBase系统架构图

HBase中存在两张特殊类型的表,-ROOT-和.META.,其中.META.存储的是各种user table的region 的具体位置信息,.META.本身也可能分为几个region,存在于几个region server上,每个.META. region的位置记录在-ROOT-表中,该表只有一个region,不会split,从而保证寻表过程最多只有三级结构,-ROOT-表的入口位置由ZooKeeper来提供。整个结构如图2所示。
当客户端发起一个数据读写请求时,

1)会通过RPC与ZooKeeper进行通信,来获取-ROOT-所在的region server,

2)访问-ROOT-所在的region server,来获取对应的.META. region所在的region server,

3)访问对应的.META. region,其内容是以table和rowkey(应该是范围)来确定的user table region所在位置,

4)访问user table region server,获取具体数据。

以上是Client第一次访问某个数据时的过程,当访问一次之后,Client会缓存相关信息,当下次再访问同样数据时,根据cache内容可以直接进行第四步,简化了过程。cache当然也会存在失效的问题,当根据cache内容进行第四步不能获取数据时,会重新进行上述的全部过程,并更新cache内容。


图2 HBase寻表结构示意图

本文标签:

相关推荐

问题驱动式的学习方式的优劣
Posted on 02月27日
一张图了解Git
Posted on 03月15日
一招破解混淆后的JavaScript代码
Posted on 02月05日
LVS+Keepalived-DR模式
Posted on 03月10日

发表评论

电子邮件地址不会被公开。

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>