目录
一、 HDFS简介
Hbase是bigtable的开源山寨版本。是建立的hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。
它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。
与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。
HBase 中的表一般有这样的特点：
1、大：一个表可以有上十亿行，上百万列；
2、面向列：面向列(族)的存储和权限控制，列(族)独立检索；
3、稀疏:对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。
二、HBase储存结构详解
从上面的架构图可以看出HBase是建立在hadoop之上的,HBase底层依赖于HDFS。HBase有3个重要的组件：Zookeeper、HMaster、HRegionServer。
Zookeeper为整个HBase集群提供协助的服务，HMaster主要用于监控和操作集群的所有RegionServer。RegionServer主要用于服务和管理分区（Regions）
2.1、HDFS
HBase底层依赖于HDFS的
2.2、HMaster
HMaster是HBase集群架构中的主节点，通常一个HBase集群存在多个HMaster节点,其中一个为Active Master,其余为Backup Master。
Hbase每时每刻只有一个HMaster主服务器程序在运行，HMaster将region分配给HRegionServer，协调HRegionServer的负载并维护集群的状态。Hmaster不会对外提供数据服务，而是由HRegionServer负责所有regions的读写请求及操作。
由于HMaster只维护表和region的元数据，负责Region的分配及数据库的创建和删除等操作而不参与数据的输入/输出过程，HMaster失效仅仅会导致所有的元数据无法被修改，但表的数据读/写还是可以正常进行的。备注：region,HRegionServer职责与功能下面内容中会讲解
2.2.1HMaster的作用：
A、调控Region server的工作
为Region server分配region,
负责HRegionServer的负载均衡,,
监控集群中的Region server的工作状态, 发现失效的HRegionServer并重新分配其上的Hregion（通过监听zookeeper对于ephemeral node状态的通知）。备注：HRegion,习惯把它称为region,表的意思HRegionServer,习惯把它称为Region server,HRegionServer是HBase集群架构中的从节点
2.3、HRegionServer
HRegionServer是HBase集群架构中的从节点，HBase中的表是根据row key的值水平分割成所谓的region的。一个region包含表中所有row key位于region的起始键值和结束键值之间的行。
集群中负责管理Region的结点叫做Region server。Region server负责数据的读写。每一个Region server大约可以管理1000个region。备注：HRegionServer,习惯把它称为Region server,HRegionServer是HBase集群架构中的从节点。（一些文章写的是Region server、一些写的是HRegionServer，两个意思都是一样的）
2.3.1、HRegionServer由如下几个部分组成
一个HRegionServer会有多个HRegion和一个HLog。
HLog:预写入日志，防止内存中数据丢失
HRegion：表,一个HRegionServer可以维护多个HRegion（习惯称为一个Region Server可以维护多个Region）
2.3.2、HRegionServer的职责
维护HMaster分配给它的HRegion，处理对这些HRegion的IO请求，也就是说客户端直接和HRegionServer打交道。
2.4、HRegion
概述
Region是HBase数据管理的基本单位，每个HRegion由多个Store构成，每个Store保存一个列族（Columns Family），表有几个列族，则有几个Store，每个Store由一个MemStore和多个StoreFile组成，MemStore是Store在内存中的内容，写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。
2.4.1、Region/Store/StoreFile/Hfile之间的关系
2.4.1.1、 Region
table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。
Region按大小分隔，表中每一行只能属于一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。
2.4.1.2、 Store
每一个region有一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个ColumnFamily建一个store（即有几个ColumnFamily，也就有几个Store）。一个Store由一个memStore和0或多个StoreFile组成。
HBase以store的大小来判断是否需要切分region。store的数据存储在两个地方MemStore和StoreFile
2.4.1.3、 MemStore
写缓存，memStore 是放在内存里的。由于 HFile 中的数据要求是有序的，所以数据是先存储在 MemStore 中，排好序后，等到达刷写时机才会刷写到 HFile（当memStore的大小达到一个阀值【默认64MB】时，memStore会被flush到文件），每次刷写都会形成一个新的 HFile。
2.4.1.4、StoreFile
memStore内存中的数据写到文件后就是StoreFile（即memstore的每次flush操作都会生成一个新的StoreFile），StoreFile底层是以HFile的格式保存。
2.4.1.5、HFile
HFile是HBase中keyvalue数据的存储格式，是hadoop的二进制格式文件。一个StoreFile对应着一个HFile。而HFile是存储在HDFS之上的。
三、HBase写流程
有一个文件FileA，100M大小。Client将FileA写入到HDFS上。
HDFS按默认配置。
HDFS分布在三个机架上Rack1，Rack2，Rack3。
a. Client将FileA按64M分块。分成两块，block1和Block2;
b. Client向nameNode发送写数据请求，如图蓝色虚线①------>。
c. NameNode节点，记录block信息。并返回可用的Datanode，如粉色虚线②--------->。
Block1: host2,host1,host3
Block2: host7,host8,host4
原理：
NameNode具有RackAware机架感知功能，这个可以配置。
若client为Datanode节点，那存储block时，规则为：副本1，同client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选。
若client不为Datanode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1，机架上；副本3，同副本2相同的另一个节点上；其他副本随机挑选。
d. client向Datanode发送block1；发送过程是以流式写入。
流式写入过程，
1>将64M的block1按64k的package划分;
2>然后将第一个package发送给host2;
3>host2接收完后，将第一个package发送给host1，同时client想host2发送第二个package；
4>host1接收完第一个package后，发送给host3，同时接收host2发来的第二个package。
5>以此类推，如图红线实线所示，直到将block1发送完毕。
6>host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。
7>client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线
8>发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示。
9>发送完block2后，host7,host8,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。
10>client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。
分析，通过写过程，我们可以了解到：
①写1T文件，我们需要3T的存储，3T的网络流量贷款。
②在执行读或写的过程中，NameNode和Datanode通过HeartBeat进行保存通信，确定Datanode活着。如果发现Datanode死掉了，就将死掉的Datanode上的数据，放到其他节点去。读取时，要读其他节点去。
③挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份。
四、HBase读流程
读操作就简单一些了，如图所示，client要从datanode上，读取FileA。而FileA由block1和block2组成。
那么，读操作流程为：
a. client向namenode发送读请求。
b. namenode查看Metadata信息，返回fileA的block的位置。
block1:host2,host1,host3
block2:host7,host8,host4
c. block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取；
上面例子中，client位于机架外，那么如果client位于机架内某个Datanode上，例如,client是host6。那么读取的时候，遵循的规律是：
优选读取本机架上的数据。
五、HDFS 2.0
有问题，就得改。1.0上有很多的毛病，为了修复这些问题才出了2.0
- 引入了NameNode Federation，解决了横向内存扩展
- 引入了 Namenode HA，解决了namenode单点故障
- 引入了YARN，负责资源管理和调度
- 增加了ResourceManager HA解决了ResourceManager单点故障
解决上面这些问题所使用的手段就是：热备份、federation
5.1 热备份 (NameNode HA)
NameNode HA 是为了解决单点故障问题
- HA集群设置两个NameNode ，“
活跃（Active）”和“待命（Standby）” - 两种NameNode 的状态同步，可以借助于一个共享存储系统来实现
- 一旦活跃NameNode 出现故障，就可以立即切换到待命NameNode
- Zookeeper确保一个NameNode 在对外服务
- NameNode 维护映射信息，Datanode同时向两个NameNode 汇报信息
5.2 Federation(联盟)
多个命名空间。为了处理一个namenode的局限性，搞了几个namanode大家一起来管理。就像编程中的命名空间一样。
- 在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。并且向后兼容
- HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报
- 属于同一个命名空间的块构成一个“块池
HDFS Federation设计可解决单名称节点存在的以下几个问题：
- HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目
- 性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率
- 良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
