hdfs与hbase关系原理简述

hdfs本质是分布式文件系统，可部署于大量价格低廉的服务器，提供了可扩展的、高容错性的文件读写服务。

hbase本身不负责文件层面的高可用和扩展性，通过把文件存储在hdfs实现大容量文件存储和备份。

与其他的分布式文件系统相比，HDFS擅长的场景是大文件（一般认为字节数超过数十MB的文件为大文件）的顺序读、随机读和顺序写。

一个线上的高可用HDFS集群主要由4个重要的服务组成：NameNode、DataNode、JournalNode、ZkFailoverController。

数据块（Block，大小默认为128MB)，读取的时候只需要依次读取组成这个文件的Block即可完整读取整个文件。

线上需要部署2个NameNode ：一个节点是Active状态并对外提供服务；另一个节点是StandBy状态，作为Active的备份，备份状态下不提供对外服务，也就是说HDFS客户端无法通过请求StandBy状态的NameNode来实现修改文件元数据的目的。如果ZkFailoverController服务检测到Active状态的节点发生异常，会自动把StandBy状态的NameNode服务切换成Active的NameNode。

NameNode存储并管理HDFS的文件元数据，这些元数据主要包括文件属性（文件大小、文件拥有者、组以及各个用户的文件访问权限等）以及文件的多个数据块分布在哪些存储节点上。文件元数据是在不断更新的

NameNode本质上是一个独立的维护所有文件元数据的高可用KV数据库系统（键值对存储数据的数据库）。

NameNode采用写EditLog（日志）和FsImage（镜像）的方式来保证元数据的高效持久化。

NameNode会把所有文件的元数据全部维护在内存中。HDFS中存放大量的小文件，则造成分配大量的Block，这样可能耗尽NameNode所有内存而导致OOM

组成文件的所有Block都是存放在DataNode节点上的。一个逻辑上的Block会存放在N个不同的DataNode上

存在一个问题——在StandBy状态下的NameNode切换成Active状态后，如何才能保证新Active的NameNode和切换前Active状态的NameNode拥有完全一致的数据？
HDFS单独实现了一个叫做JournalNode的服务。线上集群一般部署奇数个JournalNode（一般是3个，或者5个），在这些JournalNode内部，通过Paxos协议来保证数据一致性。因此可以认为，JournalNode其实就是用来维护EditLog一致性的Paxos组。

ZKFailoverController主要用来实现NameNode的自动切换。

HDFS的视角看，HBase就是它的客户端。

HBase本身并不存储文件，它只规定文件格式以及文件内容，实际文件存储由HDFS实现。

HBase不提供机制保证存储数据的高可靠，数据的高可靠性由HDFS的多副本机制保证。

HBase-HDFS体系是典型的计算存储分离架构。

详细请参考《HBase原理与实践》
————————————————
版权声明：本文为CSDN博主「侬本多情。」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_44692890/article/details/120074611