分布式数据库hbase

上传人:小** 文档编号:56414428 上传时间:2018-10-12 格式:PPT 页数:99 大小:8.72MB
返回 下载 相关 举报
分布式数据库hbase_第1页
第1页 / 共99页
分布式数据库hbase_第2页
第2页 / 共99页
分布式数据库hbase_第3页
第3页 / 共99页
分布式数据库hbase_第4页
第4页 / 共99页
分布式数据库hbase_第5页
第5页 / 共99页
点击查看更多>>
资源描述

《分布式数据库hbase》由会员分享,可在线阅读,更多相关《分布式数据库hbase(99页珍藏版)》请在金锄头文库上搜索。

1、,石家庄铁道大学 信息科学与技术学院,第四章 分布式数据库HBase,大数据技术及应用,提纲,4.1 概述 4.2 HBase访问接口 4.3 HBase数据模型 4.4 HBase的实现原理 4.5 HBase运行机制 4.6 HBase应用方案 4.7 HBase编程实践,4.1 概述,4.1.1 从BigTable说起 4.1.2 HBase简介 4.1.3 HBase与传统关系数据库的对比分析,4.1.1 从BigTable说起 主流解决方案厂商的发展策略及现状,主流解决方案Google云计算,数据存储在“云”中,数据访问不受地理位置限制,数据能够很方便的共享,Google云计算技术具

2、体包括: Google文件系统海量数据分布存储技术( GFS)、 分布式计算编程模型MapReduce、 分布式锁服务Chubby 分布式结构化数据存储系统Bigtable等。,主流解决方案Google云计算,Google需要一个支持海量存储的文件系统 购置昂贵的分布式文件系统与硬件?,Google设计GFS的动机,是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统?,7,为什么不使用当时现存的文件系统? Google所面临的问题与众不同 不同的工作负载,不同的设计优先级(廉价、不可靠的硬件) 需要设计与Google应用和负载相符的文件系统,Google设计GFS的动机,8,一个适用于

3、大规模分布式数据处理相关应用的,可扩展的分布式文件系统。它基于普通的不算昂贵的硬件设备,实现了容错的设计,并且为大量客户端提供极高的聚合处理性能。,GFS的假设与目标,硬件出错是正常而非异常 系统应当由大量廉价、易损的硬件组成 必须保持文件系统整体的可靠性 主要负载是流数据读写 主要用于程序处理批量数据,而非与用户的交互或随机读写 数据写主要是“追加写”,“插入写”非常少 需要存储大尺寸的文件 存储的文件尺寸可能是GB或TB量级,而且应当能支持存储成千上万的大尺寸文件,9,将文件划分为若干块(Chunk)存储 每个块固定大小(64M) 通过冗余来提高可靠性 每个数据块至少在3个数据块服务器上冗

4、余 数据块损坏概率? 通过单个master来协调数据访问、元数据存储 结构简单,容易保持元数据一致性 无缓存,GFS的设计思路,10,GFS将容错的任务交给文件系统完成,利用软件的方法解决系统可靠性问题,使存储的成本成倍下降。 GFS将服务器故障视为正常现象,并采用多种方法,从多个角度,使用不同的容错措施,确保数据存储的安全、保证提供不间断的数据存储服务。,GFS架构是怎样的?,GFS系统架构,Client(客户端):应用程序的访问接口 Master(主服务器):管理节点,在逻辑上只有一个,保存系统的元数据,负责整个文件系统的管理 Chunk Server(数据块服务器):负责具体的存储工作。

5、数据以文件的形式存储在Chunk Server上,控制流,状态流,IO并行,需要存储的数据种类繁多:Google目前向公众开放的服务很多,需要处理的数据类型也非常多。包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的,海量的服务请求:Google运行着目前世界上最繁忙的系统,它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的,商用数据库无法满足Google的需求:一方面现有商用数据库设计着眼点在于通用性,根本无法满足Google的苛刻服务要求;另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利,设计动机,设计动机与目标,基本目标,高可用性,

6、Bigtable设计的重要目标之一就是确保几乎所有的情况下系统都可用,广泛的适用性,Bigtable是为了满足系列Google产品而非特定产品存储要求,简单性,底层系统简单性既可减少系统出错概率,也为上层应用开发带来便利,很强的可扩展性,根据需要随时可以加入或撤销服务器,BigTable为谷歌旗下的搜索、地图、财经、打印、以及社交网站Orkut、视频共享网站YouTube和博客网站Blogger等业务提供技术支持。,4.1.1 从BigTable说起,BigTable是一个分布式存储系统, 起初用于解决典型的互联网搜索问题, 利用谷歌提出的MapReduce分布式并行计算模型来处理海量数据,

7、使用GFS作为底层数据存储,采用Chubby提供协同服务管理, 可以扩展到PB级别的数据和上千台机器,具备广泛应用性、可扩展性、高性能和高可用性等特点。 建立互联网索引 1 爬虫持续不断地抓取新页面,这些页面每页一行地存储到BigTable里 2 MapReduce计算作业运行在整张表上,生成索引,为网络搜索应用做准备 搜索互联网 3 用户发起网络搜索请求 4 网络搜索应用查询建立好的索引,从BigTable得到网页 5 搜索结果提交给用户,数据模型,Bigtable是一个分布式多维映射表,表中的数据通过一个行关键字(Row Key)、一个列关键字(Column Key)以及一个时间戳(Tim

8、e Stamp)进行索引 Bigtable对存储在其中的数据不做任何解析,一律看做字符串 Bigtable的存储逻辑可以表示为:,(row:string, column:string, time:int64)string,数据模型,行Bigtable的行关键字可以是任意的字符串,但是大小不能超过64KB。Bigtable和传统的关系型数据库有很大不同,它不支持一般意义上的事务,但能保证对于行的读写操作具有原子性(Atomic) 表中数据都是根据行关键字进行排序的,排序使用的是词典序。 一个典型实例,其中n.www就是一个行关键字。不直接存储网页地址而将其倒排是Bigtable的一个巧妙设计。带

9、来两个好处 : 同一地址域的网页会被存储在表中的连续位置,有利于用户查找和分析 倒排便于数据压缩,可以大幅提高压缩率,由于规模的问题,单个的大表不利于数据处理,因此Bigtable将一个表分成了多个子表,每个子表包含多个行。 子表是Bigtable中数据划分和负载均衡的基本单位。,数据模型,列 Bigtable并不是简单地存储所有的列关键字,而是将其组织成所谓的列族每个族中的数据都属于同一个类型,并且同族的数据会被压缩在一起保存。引入了列族的概念之后,列关键字就采用下述的语法规则来定义:族名:限定词(family:qualifier)族名必须有意义,限定词则可以任意选定图中,内容、锚点都是不同

10、的族。而和my.look.ca则是锚点族中不同的限定词族同时也是Bigtable中访问控制(Access Control)基本单元,也就是说访问权限的设置是在族这一级别上进行的,数据模型,时间戳 为了简化不同版本的数据管理,Bigtable目前提供了两种设置: 一种是保留最近的N个不同版本,图中数据模型采取的就是这种方法,它保存最新的三个版本数据。 另一种就是保留限定时间内的所有不同版本,比如可以保存最近10天的所有不同版本数据。失效的版本将会由Bigtable的垃圾回收机制自动处理,Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据,这些不同的数据版本必须通过时间

11、戳来区分。,系统架构,一个分布式的任务调度器,主要被用来处理分布式系统队列分组和任务调度,Bigtable数据库的架构,由主服务器和分服务器构成,把数据库看成是一张大表,那么可将其划分为许多基本的小表,这些小表就称为tablet,是bigtable中最小的处理单位了。 主服务器负责将Tablet分配到Tablet服务器、检测新增和过期的Tablet服务器、平衡Tablet服务器之间的负载、GFS垃圾文件的回收、数据模式的改变(例如创建表)等。Tablet服务器负责处理数据的读写,并在Tablet规模过大时进行拆分。 Bigtable使用集群管理系统来调度任务、管理资源、监测服务器状态并处理服务

12、器故障。 BigTable将数据存储分为两部分:最近的更新存储在内存中,较老的更新则以SSTable的格式存储在GFS,后者是主体部分,不可变的数据结构。写操作的内容插入到memtable中,当memtable的大小达到一个阈值时就冻结,然后创建一个新的memtable,旧的就转换成一个SSTable写入GFS。 使用分布式的锁服务Chubby来保证集群中主服务器的唯一性、保存Bigtable数据的引导区位置、发现Tablet服务器并处理Tablet服务器的失效、保存Bigtable的数据模式信息、保存存取控制列表。,系统架构,在Bigtable中Chubby主要有以下几个作用: 1.选取并保

13、证同一时间内只有一个主服务器(Master Server) 2.获取子表的位置信息 3.保存Bigtable的模式信息及访问控制列表,另外在Bigtable的实际执行过程中,Google的MapReduce 等技术也被用来改善其性能,系统架构,Bigtable主要由三个部分组成:客户端程序库(Client Library),一个主服务器(Master Server)和多个子表服务器(Tablet Server)客户访问Bigtable服务时,首先要利用其库函数执行Open()操作来打开一个锁(实际上就是获取了文件目录),锁打开以后客户端就可以和子表服务器进行通信和许多具有单个主节点分布式系统一

14、样,客户端主要与子表服务器通信,几乎不和主服务器进行通信,这使得主服务器的负载大大降低主服务主要进行一些元数据操作以 及子表服务器之间负载调度问题, 实际数据是存储在子表服务器上,4.1.2 HBase简介,HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库,是谷歌BigTable的开源实现,主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表,可以通过水平扩展的方式,利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表,Hadoop生态系统中HBase与其他部分的关系,4.1.2 HBase简介,HBase和BigTable的底层技术对应关系,

15、4.1.2 HBase简介,关系数据库已经流行很多年,并且Hadoop已经有了HDFS和MapReduce,为什么需要HBase? Hadoop可以很好地解决大规模数据的离线批量处理问题,但受限于Hadoop MapReduce编程框架的高延迟数据处理机制,无法满足大规模数据实时处理应用的需求 HDFS面向批量访问模式,不是随机访问模式 传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不能很好解决) 传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间 因此,出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统,例如,键值数据库

16、、文档数据库和列族数据库(如BigTable和HBase等)。HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中。,4.1.3 HBase与传统关系数据库的对比分析,HBase与传统的关系数据库的区别主要体现在以下几个方面: (1)数据类型:关系数据库采用关系模型,具有丰富的数据类型和存储方式,HBase则采用了更加简单的数据模型,它把数据存储为未经解释的字符串。 (2)数据操作:关系数据库中包含了丰富的操作,其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,因为HBase在设计上就避免了复杂的表和表之间的关系。 (3)存储模式:关系数据库是基于行模式存储的。HBase是基于列存储的,每个列族都由几个文件保存,不同列族的文件是分离的。,

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 管理学资料

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号