简介
硬件错误
硬件错误(hardware failure)时有发生,并非意外。一个HDFS实例可能包含了成千上万台服务器, 它们各自存储了该文件系统的一部分数据。可以说,分布式系统中可能连接了数量极多的节点,而每个节点由于不同的可能性发生故障,这意味着在HDFS中总是有些节点不能正常提供服务。因此,自动和快速的检查并修复故障,是设计HDFS架构的一个核心目标.
流式访问数据
运行于HDFS之上的应用会流式访问它们的数据集。They are not general purpose applications that typically run on general purpose file systems. HDFS被设计为更适合批处理数据,而不是与用户有频繁交互的场景. 其侧重点为数据访问的高吞吐量,而不是低延迟性。 POSIX规定硬件方面导到一定要求,而以HDFS为存储目标的应用并不会用到这些资源;因此POSIX中一些关键的语义已经被更改,以提高数据吞吐率。
大数据
运行在HDFS之上的应用一般都拥有大量数据. 一个HDFS文件通常大小在GB到TB之间。因此,HDFS理应很好地支持大文件. 它在一个集群上应该能提供相当高的数据带宽,并能能将数据拓展到数百个节点. 在一个应用实例中. 它要支持数以百万计的数据文件。
简单一致性模型
HDFS应用要求文件访问为write-once-read-many模型. 一个文件被创建,写入并关闭后,就不应该再作修改。这个原则简化了文件的数据一致性问题,并使得数据能被高速率地访问。一个Map/Reduce或者web crawler应用就很适合这种模型. 现在已有计划在将来实现追加数据到文件中的功能。
“转移计算比移动数据本身更划算”
一个应用所需的计算,数据离应用越近该计算就越高效;对于大数据集的应用场景来说更是如此. 这最大程度地减少了网络开销并增加了系统整体的数据吞吐量。这个理念就是,将计算模块迁移到数据所在的节点中,会比将数据传输到应用所在的节点上的性能显然要好得多。而HDFS也提供了将应用本身移动到相关数据所在节点上的接口。
NameNode与DataNode
HDFS采用了master/slave架构设计。一个HDFS集群包含了一个NameNode, 也就是一个管理文件系统命名空间及用户对数据的访问相关信息的master服务节点. 另外,包含了一定数量的DataNode,通常集群中每一个节点都管理并存储了整体数据的一部分。HDFS对外暴露了文件系统的命名空间,同时允许用户数据存储于其中。一个文件通常会被分割成多个block同时存储在部分DataNode中。NameNode会执行类似于打开,关闭或重命名文件夹或文件的操作。同时它也会决定block在DataNote群中的存储节点。 DataNode的任务是响应文件系统的用户请求并提供数据的读写服务。DataNode同时会执行block的创建,删除和基于NameNode指示的冗余备份等工作。
NameNode和DataNode都是为了设计成运行在商业机器上的软件体。这些机器一般都安装了GNU/Linux操作系统. HDFS采用Java实现; 任何装有Java运行环境的机器都可以配置为NameNode或者DataNode。采用高可移植性的Java语言意味着HDFS可以部署在绝大部分类型的机器上。一种典型的集群部署为:专门用一台机器作为NameNode来管理相关的资源和任务调度;其他所有的机器作为DataNode来执行相关的计算及存储任务。HDFS架构并不排除在同一台机器上部署了多个DataNode,但这样的场景并不多见。
只存在一个NameNode实例的模型很大程度简化了系统的架构。而NameNode则是一个仲裁者并维护了所有的HDFS元数据,通过这样的方式使得用户数据的传输不用经过NameNode。
译文续接:HDFS架构(二)