本章主要讲述开源的非关系型分布式数据库HBase,它可以满足大规模数据实时处理应用的需求。
HBase能否应用于实时响应查询计算的应用场景?
HBase的优势在于实时计算,所有实时数据都直接存入HBase中,客户端通过API直接访问HBase,实现实时计算。由于它使用的是nosql,或者说是列式结构,从而提高了查找性能,使其能运用于大数据场景,这是它跟MapReduce的区别。
为什么说HBase是键值类型数据库?
KV将简单的键映射到(可能)更复杂的值,就像一个巨大的哈希表。
HBase的主要角色有哪些?分别提供什么作用?
HMaster
监控RegionServer
处理RegionServer故障转移
处理元数据变更
处理region的分配或移除
空闲时对数据进行负载均衡
通过zookeeper发布自己的位置给客户端
RegionServer
负责存储Hbase的实际数据
处理分配给它的region
刷新缓存到HDFS上
维护HLog
执行压缩
负责处理Region分片
Zookeeper对HBase提供了什么服务支持?
Zookeeper 作用有三点:
1、分布式锁
2、事件监控
3、存储HBase的Region Server数据,充当微型数据库
HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。
适合于存储大表数据(表的规模可以达到数十亿行以及数百万列),并且对大表数据的读、写访问可以达到实时级别。
大表(bigtable)结构:BigTable是一个疏松的分布式的持久的多维排序的map,这个map有行健、列键和时间戳索引,每一个值都是连续的byte数组。
利用Hadoop HDFS ( Hadoop Distributed File System )作为其文件存储系统,提供实时读写的分布式数据库系统。
利用Zookeeper作为协同服务。
Zookeeper 作用有三点:
1、分布式锁
2、事件监控
3、存储HBase的Region Server数据,充当微型数据库
HBase与传统的关系数据库的区别主要体现在以下几个方面:
HBase适合具有如下需求的应用:
• 对象存储:1B~100M 对象存储(图片、网页、文本、新闻) —— 海量存储
• 时序数据:时间序列数据(传感器、监控数据、股票K线)—— 高并发/海量存储
• 气象数据:卫星轨道、气象数据 —— 高并发/海量存储
• Cube分析:实时报表 —— 高并发/海量存储
• NewSQL:元数据库、索引查询 —— SQL、二级索引、动态列
• Feeds流:朋友圈 —— 高并发请求
• 消息/订单存储:聊天信息、订单/保存存储 —— 强同步 海量数据
• 用户画像:用户特征存储 —— 万列稀疏矩阵
• 兼容结构化/非结构化数据,数据存储容量大,高并发,低时延,低成本的数据库
有一个名为webtable的表,包含两个列族: contents和anchor。在这个例子里面,anchor 有两列(anchor:aa.com, anchor:bb.com),contents仅有1列(contents:html),这是概念视图。
尽管在概念视图里,表可以被看成是一个稀疏的行的集合。但在物理上,它的是区分列族存储的。新的columns可以不经过声明直接加入一个列族。
行存储:数据按行存储在底层文件系统中。通常,每一行会被分配固定的空间。
优点:有利于增加/修改整行记录等操作;有利于整行数据的读取操作。
列存储:数据以列为单位,存储在底层文件系统中。
HBase采用列存储,为每个单元格中的值还要加上一个键。
优点:有利于面向单列数据的读取/统计等操作。
缺点:整行读取时,可能需要多次I/O操作。
表 Table 根据行键 rowkey 横向划分,起始 rowkey 和结束 rowkey 划为一个区域存储为 Region。
一个 Region 下包含若干个 Store,每个 Store 根据列簇存储相应的 Region 数据。
MemStore 是缓存,用于临时写和查找,StoreFile 把相应 Region 数据存储到具体的物理表上,Block 就是实际的数据表,采用 Block 方式存到 HDFS 上。
HBase表开始只有一个Region,随数据增多不断分裂。Region拆分操作非常快,拆分时的Region读取的仍然是原存储文件,直到分裂结束,把存储文件异步地写到独立的文件后,才会读取新文件。
旧版本HBase采用ZooKeeper文件 - root表 - meta表
三级表结构查找用户 Region。
新版本去掉了 root 表,仅保留元数据表 hbase:meta,其位置信息存储于 ZooKeeper 中,meta 表中记录了用户 Region 位置信息。
读写时先找 Meta Region,再由其中信息找 User Region。
为了加快访问速度,hbase:meta表会被保存在内存中。
假设hbase:meta表的每行(一个映射条目)在内存中大约占用1KB,并且每个Region限制为128MB。两层结构可以保存的Region数目是128MB/1KB = 2 17 2^{17} 217个Region。
HRegionServer是HBase中最核心的模块。负责存储维护分配给自己的Region,响应用户的读写请求,报告自己的心跳信息给ZooKeeper。
commit()
调用才会将其返回给客户端,带代表一个事务的完成。Store.compact()
把多个合并成一个(此过程比较耗费资源)。Store是HRegionServer的核心,数量过多时可以多个StoreFile合并成一个。单个StoreFile过大时,又触发分裂操作,1个父Region被分裂成两个子Region。这样可以提高用户的查询效率。
分布式环境必须要考虑系统出错,HBase采用HLog保证系统恢复。
共用日志的优点:提高对表的写操作性能。缺点:恢复时需要分拆日志。
随着时间的增长,业务数据不断的往HBase集群中灌入,这时HFile的数目越来越多,那么查询时延也就越来越大。
Compaction的目的,是为了减少同一个Region中同一个ColumnFamily下面的小文件(HFile)数目,从而提升读取的性能。Compaction 过程需要消耗计算资源,中途不能进行读写。
Compaction分为Minor, Major两类:
这个机制是为了进一步提升读写性能。
OpenScanner的过程中,会创建两种不同的Scanner来读取Hfile、MemStore的数据:
在寻找到rowkey所对应的RegionServer和Region之后,需要打开一个查找器Scanner,由其具体执行查找数据,Region中会包含内存数据MemStore,文件数据Hfiles,那么在open scanner的时候就需要分别读取这两块数据,打开对应不同的scanner做查询操作。
为了查找时缩小查找范围,使用BloomFilter用来优化一些随机读取的场景,即Get场景。它可以被用来快速的判断一条用户数据在一个大的数据集合(该数据集合的大部分数据都没法被加载到内存中)中是否存在。
BloomFilter在判断一个数据是否存在时,有一定的误判率(不存在判为存在)。但对于不存在的判断结果是可信的。
HBase的BloomFilter的相关索引数据被保存在HFile中。
行键是按照字典序存储,因此设计行键时,将经常一起读取的数据存储到一块,将最近可能会被访问的数据放在一块,可以提高性能。
举个例子:最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为行键的一部分,由于是字典序排序,所以可以使用Long.MAX-VALUE-timestamp作为行键,这样能保证新写入的数据在读取时可以被快速命中。
默认情况下,HBase 只有一个针对行健的素引。要访问HBase表中的行,只有三种方式:
为了提高访问速度,HBase 新版本中增加了 coprocessor 特性,可以构建二级索引,例如:
华为纯 Java 开发的的 Hindex 就能实现以上功能。redis、solor也能实现这些功能。
HBase中的数据以什么形式存储? ( D )
A. Int
В. Long
C. String
D. Byte[]
HBase的分布式存储的最基本单元是? ( A )
A. Region
B. Column Family
C. Column
D. Cell