【摘要】 本文主要介绍HBase与HDFS的关系，一些关键进程角色，以及在部署上的建议
HBase与HDFS
我们都知道HBase的数据是存储于HDFS里面的，相信大家也都有这么的认知：
HBase是一个分布式数据库，HDFS是一个分布式文件系统
理解了这一点，我们先来粗略回答本文已开始提出的其中两个问题：
-
HBase中的数据为何不直接存放于HDFS之上？
HBase中存储的海量数据记录，通常在几百Bytes到KB级别，如果将这些数据直接存储于HDFS之上，会导致大量的小文件产生，为HDFS的元数据管理节点(NameNode)带来沉重的压力。
-
文件能否直接存储于HBase里面？
如果是几MB的文件，其实也可以直接存储于HBase里面，我们暂且将这类文件称之为小文件，HBase提供了一个名为MOB的特性来应对这类小文件的存储。但如果是更大的文件，强烈不建议用HBase来存储，关于这里更多的原因，希望你在详细读完本文所有内容之后能够自己解答。
集群角色
关于集群环境，你可以使用国内外大数据厂商的平台，如Cloudera，Hontonworks以及国内的华为，都发行了自己的企业版大数据平台，另外，华为云、阿里云中也均推出了全托管式的HBase服务。
我们假设集群环境已经Ready了，先来看一下集群中的关键角色：
相信大部分人对这些角色都已经有了一定程度的了解，我们快速的介绍一下各个角色在集群中的主要职责(注意：这里不是列出所有的职责)：
-
ZooKeeper
在一个拥有多个节点的分布式系统中，假设，只能有一个节点是主节点，如何快速的选举出一个主节点而且让所有的节点都认可这个主节点？这就是HBase集群中存在的一个最基础命题。
利用ZooKeeper就可以非常简单的实现这类"仲裁"需求，ZooKeeper还提供了基础的事件通知机制，所有的数据都以 ZNode的形式存在，它也称得上是一个"微型数据库"。
-
NameNode
HDFS作为一个分布式文件系统，自然需要文件目录树的元数据信息，另外，在HDFS中每一个文件都是按照Block存储的，文件与Block的关联也通过元数据信息来描述。NameNode提供了这些元数据信息的存储。
-
DataNode
HDFS的数据存放节点。
-
RegionServer
HBase的数据服务节点。
-
Master
HBase的管理节点，通常在一个集群中设置一个主Master，一个备Master，主备角色的"仲裁"由ZooKeeper实现。 Master主要职责：
-
负责管理所有的RegionServer
-
建表/修改表/删除表等DDL操作请求的服务端执行主体
-
管理所有的数据分片(Region)到RegionServer的分配
-
如果一个RegionServer宕机或进程故障，由Master负责将它原来所负责的Regions转移到其它的RegionServer上继续提供服务
-
Master自身也可以作为一个RegionServer提供服务，该能力是可配置的
集群部署建议
如果基于物理机/虚拟机部署，通常建议：
-
RegionServer与DataNode联合部署，RegionServer与DataNode按1:1比例设置。
这种部署的优势在于，RegionServer中的数据文件可以存储一个副本于本机的DataNode节点中，从而在读取时可以利用HDFS中的短路径读取(Short Circuit)来绕过网络请求，降低读取时延。
-
管理节点独立于数据节点部署
如果是基于物理机部署，每一台物理机节点上可以设置几个RegionServers/DataNodes来提升资源使用率。
也可以选择基于容器来部署，如在HBaseCon Asia 2017大会知乎的演讲主题中，就提到了知乎基于Kubernetes部署HBase服务的实践。
对于公有云HBase服务而言，为了降低总体拥有成本(TCO)，通常选择"计算与存储物理分离"的方式，从架构上来说，可能导致平均时延略有下降，但可以借助于共享存储底层的IO优化来做一些"弥补"。
HBase集群中的RegionServers可以按逻辑划分为多个Groups，一个表可以与一个指定的Group绑定，可以将RegionServer Group理解成将一个大的集群划分成了多个逻辑子集群，借此可以实现多租户间的隔离，这就是HBase中的RegionServer Group特性。
作者：Jaison
转载：https://blog.csdn.net/devcloud/article/details/100554078