| 编辑推荐: |
本文主要介绍了HBase与Hadoop之间的关系、HBase的核心功能模块、HBase的使用场景、经典案例及使用场景等。
本文来自CSDN，由火龙果软件Linda编辑、推荐。
|
|
一、HBase与Hadoop之间的关系
Hadoop框架中的HDFS分布式文件系统为HBase提供了可靠的底层存储支持。
Hadoop框架中的MapReduce为HBase提供了高性能的计算能力。
二、HBase的核心功能模块
1.Client
Client是整个HBase系统的入口
客户端使用RPC协议与HMaster和RegionServer进行通信
对于管理类（表的增删）操作，Client与HMaster进行RPC通信
对于数据读写类操作Client与RegionServer进行RPC交互
客户端可以是多个，也可以以不同形式访问，如Java接口、HBase shell命令行、Avro等
2.Zookeeper
Zookeeper负责消息协调通信-------由雅虎公司开发出的
Zookeeper是一个高可用的分布式数据管理与系统协调框架。
Zookeeper底层基于Paxos算法的实现，使的该框架保证了分布式环境中数据的一致性。
HBase中Zookeeper实例负责协调工作{
-储存Hbase元数据信息。
-实时监控RegionServer
-储存所有Region的寻址入口
-保证HBase中只有一个HMaster节点（通过Zoookeeper的选举机制来选出HMaster）
}
3.HMaster
-管理用户对表的增删改查操作
-管理HRegionServer的负载均衡，调整Region分布
-在RegionSplit后，负责新Region的分配
-在HRegionServer停机后，负责失效
-HRegionServer上的Regions迁移
4.HRegionServer
-主要负责响应用户I/O，向HDFS读写数据，是HBase中最核心的模块。
-HRegionServer内部管理了一系列的HRegion对象
-每个HRegion对应了表中的一个Region
-HRegion中由多个Hstore组成
-每个Hstore对应了表中的一个ColumnFamily的存储。
store存储是HBase的存储核心，由两部分组成
-MemStore：用户写入的数据首先会放入MemStore，MemStore的大小为64MB
-StoreFiles:当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）
当Store File文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除
HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的
三、HBase的使用场景
存储大量的数据（>TB）
需要很高的吞吐量（如京东商城或12306购票）
大规模数据集很好性能的随机访问（按列）
需要进行优雅的数据扩展
结构化和半结构化的数据
不需要全部的关系数据库特性，例如交叉列、交叉表，事务，连接等等。
四、HBase的经典案例
搜索引擎应用
爬虫持续不断的爬取新页面存储到HBase中
在整张表上使用MapReduce计算并生成索引，供网络搜索应用使用
用户发起网络搜索请求
网络搜索应用查询简历好的索引，或者直接从HBase得到单个文档
搜索结果直接提交给用户
五、HBase的基本概念
数据模型
数据逻辑模型
数据物理模型
逻辑模型的重要概念
Table--------表
Rowkey---------行键（类似关系型数据库的主键）
Column family------------列族/列簇（HBase中列族是一些列的集合）
Timestamp----------时间戳（每个时间戳对应不同的版本）
Cell----------------单元格（通过行键、列簇和列簇名、版本号来确定具体的一个单元格内容）唯一确定，无数据类型，全部是字节码形式
单元格的内容是不可再分割的字节数组
每个单元格保存着同一份数据的多个版本
不同时间版本的数据按照时间顺序倒序排序
事务特性ACID
传统SQL数据库通常都支持ACID的强事务机制
HBase NoSQL数据库仅提供对行级别的原子性保证。
-同时对同一个key下的数据进行两个操作，在实际执行的过程中会串行操作，保证每一个keyvalue对不会被破坏
-对同一行的所有列的操作是原子性的，对于该行的Put操作要么整体成功要么整体失败。
模式设计
数据库的模式设计不是一个新概念，系统都存在模式设计问题。只要称为数据库
HBase的模式结构包括表、Rowkey、列族、Timestamp（时间戳/时间版本）
模式是一个三维有序结构，表，Rowkey，列族三个维度确定一行数据
HBase模式设计过程中需要关注的问题
-表应该有多少个列族，列族使用什么数据，每个列族应该有多少列
-列名是什么，单元应该存储什么数据，每个单元存储多少个时间版本
-行键结构是什么，应该包含哪些信息。
Rowkey-行键设计
Rowkey是不可分割的字节数，按照字典排序由低到高存储在表中
Rowkey应该基于预期的访问模式来为Rowkey建模
Rowkey决定了访问HBase表时可以得到的性能
HBase只能在Rowkey上建立索引，在不清楚Rowkey的前提下访问表，可以使用扫描全表。
-原生HBase只支持Rowkey以字典顺序从小到大
-Rowkey=Integer.MAX_VALUE-Rowkey 转换为以字典顺序从大到小的排序
-Rowkey尽量散列Rowkey设计
-保证散列，就会保证所有的数据不是在一个Region上，避免读写时负载会集中在个别Region上
-Rowkey的长度尽量短
-如果Rowkey太长，存储开销增加，影响存储效率
ColumnFamily-列族定义
列族，是一些列的集合
-一个列族的所有成员都有着相同的前缀。
在物理上，列族的成员在文件系统上都存储在一起。
多个列族在执行flush和compaction时，造成很多IO负载
-Flush和compaction操作是针对一个Region的，当一个列族操作大量数据时会引发一个flush，那些不相关的列族也要进行flush，会造成很多没用的I/O负载。
-尽量在应用中使用一个列族 |
