自建购物网站,生鲜电商网站建设与管理,益阳市城乡和住房建设部网站,wordpress留言代码引入
前面我们通过深入HDFS到深入MapReduce #xff0c;从设计和落地#xff0c;去深入了解了大数据最底层的基石——存储与计算是如何实现的。
这个专栏则开始来看大数据的三驾马车中最后一个。
通过前面我们对于GFS和MapReduce论文实现的了解#xff0c;我们知道GFS在数…引入
前面我们通过深入HDFS到深入MapReduce 从设计和落地去深入了解了大数据最底层的基石——存储与计算是如何实现的。
这个专栏则开始来看大数据的三驾马车中最后一个。
通过前面我们对于GFS和MapReduce论文实现的了解我们知道GFS在数据写入时只对顺序写入有比较弱的一致性保障而对于数据读取虽然GFS支持随机读取但在当时的硬件条件下实际上也是支撑不了真正的高并发读取的此外MapReduce虽然是一个批量处理数据的框架吞吐量很大但其延时和额外开销也不小。 在计算机数据存储领域一直是关系数据库RDBMS的天下以至于在传统企业的应用领域许多应用系统设计都是面向数据库设计也就是先设计数据库然后设计程序从而导致关系模型绑架对象模型并由此引申出旷日持久的业务对象贫血模型业务逻辑由服务层处理领域对象只包含数据。服务层通过调用领域对象的属性和方法来完成业务逻辑。与充血模型业务逻辑在领域对象中实现。领域对象不仅包含数据还包含与数据相关的业务逻辑。服务层只负责接收用户的请求并调用领域对象的方法来完成业务逻辑。之争。 业界为了解决关系数据库的不足提出了诸多方案比较有名的是对象数据库但是这些数据库的出现似乎只是进一步证明关系数据库的优越而已。直到人们遇到了关系数据库难以克服的缺陷——糟糕的海量数据处理能力及僵硬的设计约束局面才有所改善。从Google的BigTable开始一系列的可以进行海量数据存储与访问的数据库被设计出来更进一步说NoSQL这一概念被提了出来。 NoSQL主要指非关系的、分布式的、支持海量数据存储的数据库设计模式。不过随着技术的演进NoSQL的解释也从最初的“No SQL”到现在的“Not Only SQL”表示NoSQL只是关系数据库的补充而不是替代方案。其中HBase是这一类NoSQL系统的杰出代表。 HBase之所以能够具有海量数据处理能力其根本在于和传统关系型数据库设计的不同思路。传统关系型数据库对存储在其上的数据有很多约束学习关系数据库都要学习数据库设计范式事实上是在数据存储中包含了一部分业务逻辑。而NoSQL数据库则简单暴力地认为数据库就是存储数据的业务逻辑应该由应用程序去处理。 我们可以梳理出来Bigtable要解决核心问题就是如何支撑业务海量数据的随机读写例如百万级别的随机读写IOPS。
我们自然而然能想到的就是借鉴GFS的设计思路除此之外还需要考虑到实时处理场景下如何提高容错。
Bigtable的答案其实总结起来就三点 将整个系统的存储层搭建在GFS上。然后通过单Master调度多Tablets的方式使得整个集群非常容易伸缩和维护。 通过MemTableSSTable这样一个底层文件格式解决高速随机读写数据的问题。 通过Chubby这个高可用的分布式锁服务解决一致性的挑战。
而本专栏的主角HBase就是源自于Google的Bigtable论文。
HBase 同样利用 HDFS 作为底层存储但是并不是简单地使用原本的数据只是使用 HDFS 作为它的存储系统。也就是说HBase 只是利用 Hadoop 的 HDFS 帮助其管理数据的持久化文件。HBase 提供超大规模数据集的实时随机读写弥补了早期 Hadoop只能离线处理数据的不足。
一句话概括的话HBase就是基于Hadoop构建的一个高可用、高性能、多版本的分布式NoSQL数据库是Google BigTable的开源实现通过在廉价服务器上搭建大规模结构化存储集群提供海量数据高性能的随机读写能力。
下面我们先通过HBase的一些核心概念去初步了解一下它。
基本概念 表TableHBase中的表由行和列组成一个表包含多行数据。表中的数据按照RowKey进行排序存储支持范围查询。 行row一行数据包含一个唯一标识rowkey、多个column以及对应的值。在HBase中一张表中所有row都按照rowkey的字典序由小到大排序。 行键Row Key行是表中数据的基本单位由RowKey标识。RowKey是字节序列可以是任意长度通常设计为能够反映数据的逻辑顺序。这是我们一行数据的唯一标识比如说我们平时的数据都会有一个唯一 ID就可以用来作为 Row Key。但是需要注意的是HBase 在存储 Row Key 的时候是按照字典顺序存放的所以如果你的 Row Key 不是以分布均匀的数字或字母开头的很可能造成存储集中在某一台机器上这会大大降低查询效率所以这种时候需要设计存储的 Row Key比如在每个 ID 的前面都加一个 HASH 值来提升查询性能。 列column与关系型数据库中的列不同HBase中的column由column family列簇以及qualifier列名两部分组成两者中间使用:相连。column family在表创建的时候需要指定用户不能随意增减。一个column family下可以设置任意多个qualifier因此可以理解为HBase中的列可以动态增加理论上甚至可以扩展到上百万列。 列簇Column Family列簇是表中数据的物理存储单位用于组织数据。列簇内的数据具有相同的列前缀并且通常一起存储在同一个磁盘文件中。可以看作是一组列实际上一个列簇的作用也是用来管理若干个列优化查询速度。所以列簇的名字要尽量短同时对于经常需要一起查询的列放在一个列簇下面。比如说对于用户信息一个用户的静态属性姓名、年龄、电话、地址等可以放在一个列簇下面动态属性点赞、收藏、评论等可以放在一个列簇下面。HBase表中的列簇需要预先定义如果要新增列簇就要先停用这个表。 列名Column Qualifier是用于唯一标识列簇中具体列的标签。它与列簇一起组成列的完整标识。Qualifier可以动态地添加到列簇中而无需预先定义这使得HBase能够适应不同数据模式和需求的变化而无需对表格的架构进行修改。 单元Cell指的是一个确定的存储单元。由五元组row, column, timestamp, type, value组成的结构其中type表示 Put/Delete 这样的操作类型timestamp代表这个cell的版本。这个结构在数据库中实际是以KV结构存储的其中row, column, timestamp,type是Kvalue字段对应KV结构的V。单元格中的数据没有类型的概念而是以字节序列的形式存储( 字符串正常存储非字符串类型数据底层字节序列会转换成十六进制显示)。每个列簇中的列可以存储多个版本的数据每个版本由其对应的时间戳标识并且每个版本的值都构成一 个单元格。 时间戳Timestamp时间戳用于记录数据的创建或修改时间并支持多版本数据。每个单元格Cell都可以存储多个版本的数据版本通过时间戳来索引。 区域Region一个 Region 可以看作是多行数据的集合。当一个表的数据逐渐增多需要进行分布式存储那么这个表就会自动分裂成多个 Region然后分配到不同的 RegionServer 上面去。
数据模型
既然HBase是一个数据库那最核心的自然是怎么组织存储数据了HBase的数据模型设计主要包括以下几个方面 面向列的存储模型HBase采用面向列的存储模型表的基本单元是“列簇Column Family”。 数据多版本支持HBase支持数据的多版本每个单元格的数据可以有多个版本版本通过时间戳来索引。 稀疏数据支持HBase支持稀疏数据即某些列可以为空不会占用存储空间。
数据目录
HBase的数据目录主要包括以下几个方面 根目录HBase的根目录在HDFS中是/hbase这是所有HBase数据的顶级目录。 数据目录在根目录下有一个名为/data的目录它是HBase数据的核心存储区域包含了所有的表数据、日志数据等。 Namespace目录HBase中的Namespace是用来组织和管理表的命名空间。在/data目录下根据Namespace的不同会有相应的子目录例如/data/default。 表目录每个表在Namespace目录下都有一个对应的子目录例如/data/default/mytable。这个目录下包含了该表的所有数据。 Region目录HBase中的表会被切分为多个Region每个Region由一个或多个Store组成。每个Region在表目录下都有一个对应的子目录例如/data/default/mytable/a3d605ed-33fe-4458-90ad-57c79989c730。 ColumnFamily目录每个ColumnFamily在Region目录下都有一个对应的子目录例如/data/default/mytable/a3d605ed-33fe-4458-90ad-57c79989c730/cf1。这个目录下包含了该ColumnFamily的所有数据。
为了更好理解HBase表存储结构这里将HBase表存储结构分为表逻辑结构和表物理结构两个部 分介绍。
表逻辑结构
RowKeyColumn FamilyColumn FamilyColumn QualifierColumn QualifierColumn QualifierColumn Qualifierrowkeycellcellcellcellrowkeycellcellcellcell...............
为了更清晰理解HBase表逻辑结构填充样例数据如下(其中89c730对应的age为空):
RowKeystaticattributedynamicattributenameagelikefavorites57c799chaos18hadoophadoop89c730hbasezookeeperhdfs...............
表物理结构
在HBase中表数据存储并不是按照表逻辑结构进行存储而是按照如下方式进行存储(以先前样例数据为例):
RowKeyColumn FamilyColumn QualifierTimestampValue57c799staticattributename1000chaosRegion57c799staticattributeage10001857c799dynamicattributelike1000hadoop57c799dynamicattributefavorites1000hadoop89c730staticattributename2000hbaseRegion89c730dynamicattributelike2000zookeeper89c730dynamicattributefavorites2000hdfs 注意在表逻辑结构中的空值在HBase底层不会进行存储。 HBase的物理存储结构设计主要包括以下几个方面 HDFS存储HBase的数据最终存储在HDFS上以HFile的形式存在。HFile是HBase的物理存储文件以列簇为单位进行存储。 RegionHBase通过Region来对表进行分片每个Region负责存储某个RowKey范围内的行。当表中的数据增长到一定程度时Region会被拆分为两个新的Region。 Store每个列簇对应一个Store用于管理该列簇的数据。Store由内存中的MemStore和磁盘上的HFile组成。数据先写入MemStore然后定期将MemStore中的数据刷到磁盘形成HFile。 MemStore和HFileMemStore是内存中的数据结构用于缓存写入操作。当MemStore达到一定大小后数据将被刷写到HFile中。HFile是磁盘上的物理存储文件存储了列簇的数据。
架构设计
HBase建立在Hadoop HDFS之上底层使用HDFS进行数据存储HBase集群中主要由以下几个部分组成 ClientClient为访问HBase的客户端包含访问HBase的接口并维护cache来加快对HBase的访问。Client通过zookeeper获取hbase:meta表位置信息然后获取要操作的Region信息并与该 region的RegionServer通信发出读取或写入请求。获取的Region信息会缓存在客户端中以便后续请求无需经过查找过程。如果Master的负载均衡器重新平衡或者由于HRegionserver宕机都会重新指定该region的 regionserver客户端将重新查询hbase:meta表以确定用户region的新位置。 HMasterHMaster是HBase集群的主节点负责管理RegionServer和Region的元数据、表的创建、分区的拆分和合并、Region的分配和迁移等任务。一个HBase集群中可以有多个 HMaster节点由zk进行协调保证只有一个HMaster运行其余HMaster为Backup Master。 管理库表的元数据如表对应Region信息负责将Region分配给HRegionServer。 负责HRegionServer的负载均衡。当写入数据时负责将数据均衡的分布到各个Region上避免HRegionServer数据存储倾斜;当读取数据时将请求均衡的发送到各个RegionServer上避免HRegionSever负载过大。 通过zk发现失效的HRegionServer并重新分配该HRegionServer上的Region。 HRegionServerHRegionServer可以看成HBase架构中的从节点习惯上也可称为RegionServerHBase集群中一般有多台HRegionServer主要负责数据读写请求。 一个HRegionServer包含一个HLog和多个HRegion每个HRegion中有包含多个Store每个 Store中又包含MemStore和StoreFile。 管理HMaster分配的Region处理来自客户端的读写请求(如:put、get请求)定期向 HMaster汇报Region状态。 负责Region变大拆分。当一个Region的数据量增大到一定程度HRegionServer负责将 Region拆分为两个新的Region实现数据均衡分布。 负责StoreFile合并。 负责与HDFS交互将数据存储到HDFS中。 ZookeeperHBase用Zookeeper进行分布式协调帮助管理元数据、故障恢复和分布式锁。 存储HBase元数据如:HMaster信息、HRegionServer信息、表对应HMaster信息、hbase: meta表位置信息。 协调HMaster的HA。通过zk保证HBase集群中只有一个HMaster运行如果HMaster发生异常则通过zk选举新的HMaster提供服务。 监控RegionServer。zk监控RegionServer状态当RegionServer异常时会通知给HMaster 对应RegionServer上下线信息。 HDFSHBase底层使用HFile格式将数据存储在HDFS中HDFS中数据多副本可以为HBase提供高可靠、高可用性。 优缺点
优点 高扩展性HBase采用分布式架构能够轻松扩展到数千个节点处理PB级别的数据。 高性能HBase在处理大规模数据时表现出色特别是在随机读写操作方面。 高可靠性HBase通过数据冗余和自动故障恢复机制确保数据的高可用性和系统的稳定性。 灵活的数据模型HBase支持动态列可以根据需要随时增加新的列而无需预先定义表结构。 面向列的存储HBase采用面向列的存储模型使得数据的读写操作更加高效特别适合处理稀疏数据。 适用于实时数据处理HBase特别适合于实时数据处理、海量数据存储和高速随机读写等应用场景。
缺点 数据模型的限制 强烈的Schema依赖HBase的数据模型是基于列簇和列的这要求在设计表结构时就必须明确定义列簇和列。Schema的修改成本较高需要进行表结构的重建或者复杂的在线调整这会影响系统可用性和性能。 缺乏丰富的查询功能与关系型数据库相比HBase的查询功能相对简陋。它主要支持基于行键的精确查找以及范围扫描缺乏复杂的JOIN操作、聚合函数等功能。 数据原子性HBase的行是原子性的但列不是。这意味着在一个事务中你只能更新整行数据而不能单独更新某一列。 性能方面的问题 写性能瓶颈虽然HBase的读写性能都相对较高但在高并发写操作下HBase的写性能可能会成为瓶颈。 读性能瓶颈当数据量非常大时扫描大量数据可能会导致读性能下降。 热点区域不均匀的数据分布会导致某些Region Server负载过重形成热点区域从而影响整体性能。 可用性和维护性 数据一致性HBase采用最终一致性模型这意味数据在不同节点之间的同步存在延迟。 缺乏成熟的GUI工具与一些关系型数据库相比HBase缺乏成熟易用的GUI工具这给数据的管理和监控带来不便。 数据备份和恢复HBase的数据备份和恢复也相对复杂需要额外的工具和策略来保障数据的安全性和可靠性。
