1.整体架构

  HBase系统架构由Client、Zookeeper、HMaster、RegionServer、Region、Store、HLog、HDFS等部件组成。
  HBase存储结构图如下：
    
 

2.Client

  • 使用HBase RPC机制（远程）与HMaster和HRegionServer进行通信。
  • Client 与HMaster进行管理类操作；
  • Client 与HRegionServer进行数据读写类操作。
 

3.Zookeeper

  • 存储所有 Region 的寻址入口：-ROOT-表在哪台服务器上。-ROOT-这张表的位置信息
  • 实时监控 RegionServer 的健康状态，将 RegionServer 的信息实时通知给 Master
  • ZooKeeper 为 HBase 提供 Failover 机制，选举 Master，保证集群都有一个Master存活
 

4.HMaster

  HMaster没有单点问题，高可用，HBase中可以启动多个HMaster,通过 Zookeeper的Master选举 机制保证总有一个Master在运行。
client 访问 HBase 上数据的过程并不需要 master 参与（寻址访问 zookeeper 和 RegioneServer，数据读写访问 RegioneServer），Master维护 Table 和 Region 的元数据信息，负载很低。
 
主要负责Table和Region的管理工作：
  • 管理用户对表的增删改查操作
  • 管理RegionServer的负载均衡，为RegionServer分配Region
  • Region Split后，负责新Region的分布
  • 在RegionServer停机后，负责失效的RegionServer上的Region重新分配
 

5.RegionServer

  HBase中最核心的模块，主要负责响应用户I/O请求。向HDFS中读写数据（读写数据和Master没关系）。RegionServer的作用：
  • 维护master分配给他的region，处理对这些region的IO请求。
  • 负责split正在运行过程中变的过大的Region
  • RegionServer管理Region对象
  • 每个HRegion对应Table中一个Region,HRegion由多个HStore组成
具体：
  client访问hbase上的数据并不需要master参与（寻址访问zookeeper和region server，数据读写访问region server），master仅仅维护table和region的元数据信息（table的元数据信息保存在zookeeper上），负载很低。
 

6.Region

  Region是HBase数据存储和管理的基本单位。一个表中可以包含一个或多个Region。
  当Table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startKey,endKey)表示，不同的region会被Master分配给相应的HRegionServer进行管理。
    
 
  • Store：每个HRegion由多个Store构成，每个Store保存一个列族（Columns Family），表有几个列族，则有几个Store，每个Store由一个MemStore和多个StoreFile组成，MemStore是Store在内存中的内容，写到文件后就是StoreFile。StoreFile底层是以HFile的格式保存。
  • MemStore：每一个region由一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个 ColumnFamily建一个store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者 多个StoreFile组成。 HBase以store的大小来判断是否需要切分region。
  • StoreFile：memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。
 

7.HLog

  WAL意为write ahead log（预写日志），用来做灾难恢复使用，HLog记录数据的变更，包括序列号和实际数据，所以一旦RegionServer 宕机，就可以从log中恢复数据。
 

8.HFile

  HBase的数据最终是以HFile的形式存储在HDFS中的，HFile是Hadoop的 二进制格式文件，实际上StoreFile就是对Hfile做了轻量级包装，即StoreFile底层就是HFile
 
 
 
# hbase # 大数据 # hadoop
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods