本文主要是作者自己的学习过程，主要是对原文的翻译及理解，某些地方根据自己的理解，在表述上稍做些改动，以便更易于理解。
官方原文
hdfs与现有的分布式文件系统有许多相似之处。但是，与其他分布式文件系统的区别非常明显。HDFS是高度容错的，设计用于部署在低成本硬件上。HDFS提供对应用程序数据的高吞吐量访问，适用于具有大数据集的应用程序。HDFS放宽了一些POSIX要求，以支持对文件系统数据的流式访问。
硬件故障首先明确：硬件故障是常态而不是意外。检测到错误并且自动的，快速的恢复是hdfs的核心架构目标
流式数据访问运行在HDFS上的应用程序需要对其数据集进行流访问。它们不是通常在通用文件系统上运行的通用应用程序。HDFS更多的是为批处理而设计的，而不是用户的交互使用。重点是数据访问的高吞吐量，而不是数据访问的低延迟。POSIX强加了许多针对HDFS的应用程序不需要的硬需求
大数据集运行在HDFS上的应用程序拥有大型数据集。HDFS中的一个典型文件的大小是gb到tb。因此，HDFS被调优为支持大文件。它应该提供高聚合数据带宽，并可扩展到单个集群中的数百个节点。它应该在一个实例中支持数千万个文件。
简单一致性模型HDFS应用需要文件的write-once-read-many访问模型。文件一旦被创建，写和关闭操作出了追加和截断，无需修改操作。支持将内容附加到文件末尾，但不能在任意点进行更新。这个假设简化了数据一致性问题，并支持高吞吐量数据访问。MapReduce应用程序或web爬虫应用程序非常适合这个模型。
移动计算比移动数据廉价如果应用程序请求的计算在其操作的数据附近执行，那么它的效率会高得多。当数据集的大小很大时尤其如此。这将最小化网络拥塞，并提高系统的总体吞吐量。这里的假设是，将计算迁移到离数据更近的地方通常比将数据迁移到应用程序运行的地方要好。HDFS为应用提供接口来移动他们自己以达到离数据所在的位置更近。
跨异构硬件和软件平台的可移植性HDFS被设计成易于从一个平台移植到另一个平台。这有助于广泛采用HDFS作为一组大型应用程序的首选平台。
NameNode and DataNodesHDFS有一个主/从架构。HDFS集群由一个NameNode(可选secondary NameNode)，NameNode是一个主服务器，它管理文件系统名称空间并控制客户机对文件的访问。此外，还有许多datanode，通常是集群中的每个物理节点一个datanode，它们管理附加到它们所运行的物理节点上的存储设备。HDFS对外暴露一个文件系统名称空间，并允许将用户数据存储在文件中。在内部，一个文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行namespace operations，如打开、关闭和重命名文件和目录。它还决定块到数据块(blocks)和数据节点(DataNodes)间的映射。DataNodes 负责处理来自文件系统客户端的读和写请求。DataNodes还根据来自NameNode的指令执行块的创建、删除和复制。
集群中单个NameNode的存在极大地简化了系统的体系结构。NameNode是所有HDFS元数据的仲裁器和存储库。系统以这样的方式设计，用户数据本身永远不会流经NameNode。 The File System Namespace
HDFS支持传统的分层文件组织。用户或应用程序可以在这些目录中创建目录并存储文件。文件系统名称空间层次结构与大多数现有文件系统相似;可以创建和删除文件，将文件从一个目录移动到另一个目录，或者重命名文件。HDFS支持用户配额和访问权限。HDFS不支持硬链接或软链接。然而，HDFS体系结构并不排除实现这些特性。
NameNode维护文件系统名称空间。对文件系统名称空间或其属性的任何更改都由NameNode记录。应用程序可以指定HDFS应该维护的文件副本的数量。一个文件的拷贝数称为该文件的复制因子。此信息由NameNode存储。
HDFS的设计目的是在跨机器的大型集群中可靠地存储非常大的文件。它将每个文件存储为一系列块(block)。复制文件的块是为了容错。每个文件都可以配置块大小和复制因子。
除了最后一个块之外，文件中的所有块大小都相同，而用户可以在append和hsync中添加了对可变长度块的支持之后，启动一个新块，而不需要将最后一个块填充到所配置的块大小。
应用程序可以指定文件的副本数量。复制因子可以在文件创建时指定，稍后可以更改。HDFS中的文件是写一次的(除了追加和截断)，并且任何时候只有一个writer。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
