From 916636b63f326bb414d3b57073a43032b5920d28 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=BD=97=E7=A5=A5?= <1366971433@qq.com>
Date: Fri, 31 May 2019 16:10:10 +0800
Subject: [PATCH] =?UTF-8?q?Hadoop=E5=88=86=E5=B8=83=E5=BC=8F=E6=96=87?=
 =?UTF-8?q?=E4=BB=B6=E7=B3=BB=E7=BB=9F=E2=80=94=E2=80=94HDFS?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 notes/Hadoop-HDFS.md | 50 +++++++++++++++++++-------------------------
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/notes/Hadoop-HDFS.md b/notes/Hadoop-HDFS.md
index 8249661..242a6bf 100644
--- a/notes/Hadoop-HDFS.md
+++ b/notes/Hadoop-HDFS.md
@@ -1,4 +1,4 @@
-# 分布式文件存储系统——HDFS
+# Hadoop分布式文件系统——HDFS
 
 <nav>
 <a href="#一介绍">一、介绍</a><br/>
@@ -29,7 +29,7 @@
 
 ## 一、介绍
 
-**HDFS** （**Hadoop Distributed File System**）是一种分布式文件系统，具有**高容错**、**高吞吐量**等特性，可以部署在**低成本**的硬件上。
+**HDFS** （**Hadoop Distributed File System**）是Hadoop下的分布式文件系统，具有**高容错**、**高吞吐量**等特性，可以部署在**低成本**的硬件上。
 
 
 
@@ -39,46 +39,40 @@
 
 ### 2.1 HDFS 架构
 
-HDFS 具有主/从架构，由单个NameNode （NN）和 多个 DataNode (DN) 组成：
+HDFS 遵循主/从架构，由单个NameNode(NN)和多个DataNode(DN)组成：
 
-- NameNode : 负责执行文件**系统命名空间**的操作，如打开，关闭和重命名文件、目录等，它还负责集群元数据的存储，记录着每个文件中各个块所在数据节点的信息。
-- DataNode：负责提供来自文件系统客户端的读写请求，执行块的创建，删除等操作。
+- **NameNode** : 负责执行有关**文件系统命名空间**的操作，例如打开，关闭、重命名文件和目录等。它同时还负责集群元数据的存储，记录着文件中各个数据块的位置信息。
+- **DataNode**：负责提供来自文件系统客户端的读写请求，执行块的创建，删除等操作。
 
 
 
 ### 2.2 文件系统命名空间
 
-HDFS 系统命名空间的层次结构与现在大多数文件系统类似（如 windows）, 可以进行目录、文件的创建、移动、删除和重命名等操作，支持用户配置和访问权限配置，但不支持硬链接和软连接。
-
-NameNode 负责维护文件系统名称空间,记录对名称空间或其属性的任何更改。
+`HDFS`系统命名空间的层次结构与大多数文件系统类似（如Linux）, 支持目录和文件的创建、移动、删除和重命名等操作，支持配置用户和访问权限，但不支持硬链接和软连接。`NameNode`负责维护文件系统名称空间，记录对名称空间或其属性的任何更改。
 
 
 
 ### 2.3 数据复制
 
-由于hadoop设计运行在廉价的机器上，这意味着硬件是不可靠的，为了保证高容错，数据复制孕育而生。
-
-HDFS 它将每一个文件存储为一系列**块**，复制文件的块以实现容错，块大小和复制因子可根据文件进行配置（默认块大小是128M,默认复制因子是3）。
+由于Hadoop被设计运行在廉价的机器上，这意味着硬件是不可靠的，为了保证容错性，HDFS提供了数据复制机制。HDFS 将每一个文件存储为一系列**块**，每个块由多个副本来保证容错，块的大小和复制因子可以自行配置（默认情况下，块大小是128M，默认复制因子是3）。
 
 <div align="center"> <img width="600px" src="https://github.com/heibaiying/BigData-Notes/blob/master/pictures/hdfsdatanodes.png"/> </div>
 
 ### 2.4 数据复制的实现原理
 
-大型HDFS实例在通常分布在多个机架上的计算机群集上运行。不同机架中两个节点之间的通信必须通过交换机。在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。
+大型的HDFS实例在通常分布在多个机架的多台服务器上，不同机架上的两台服务器之间通过交换机进行通讯。在大多数情况下，同一机架中的服务器间的网络带宽大于不同机架中的服务器之间的带宽。因此HDFS采用机架感知副本放置策略，对于常见情况，当复制因子为3时，HDFS的放置策略是：
 
-HDFS采用机架感知副本放置策略，对于常见情况，当复制因子为3时，HDFS的放置策略是：
-
-在编写器位于datanode上时，将一个副本放在本地计算机上，否则放在随机datanode上；在另一个（远程）机架上的节点上放置另一个副本，最后一个在同一个远程机架中的另一个节点上。此策略可以减少机架间写入流量，从而提高写入性能。
+在写入程序位于`datanode`上时，就优先将写入文件的一个副本放置在该`datanode`上，否则放在随机`datanode`上。之后在另一个远程机架上的任意一个节点上放置另一个副本，并在该机架上的另一个节点上放置最后一个副本。此策略可以减少机架间的写入流量，从而提高写入性能。
 
 <div align="center"> <img src="https://github.com/heibaiying/BigData-Notes/blob/master/pictures/hdfs-机架.png"/> </div>
 
-如果复制因子大于3，则随机确定第4个和以下副本的放置，同时保持每个机架的副本数量低于上限，上限值通常为`（复制系数 - 1）/机架数量 + 2`，但是不允许同一个dataNode具有同一块的多个副本。
+如果复制因子大于3，则随机确定第4个和之后副本的放置位置，同时保持每个机架的副本数量低于上限，上限值通常为`（复制系数 - 1）/机架数量 + 2`，需要注意的是不允许同一个`dataNode`上具有同一个块的多个副本。
 
 
 
 ### 2.5  副本的选择
 
-为了最大限度地减少全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在副本，则该副本首选满足读取请求。如果HDFS群集跨越多个数据中心，则本地数据中心的副本优先于任何远程副本。
+为了最大限度地减少带宽消耗和读取延迟，HDFS在执行读取请求时，优先读取距离读取器最近的副本。如果在与读取器节点相同的机架上存在副本，则优先选择该副本。如果HDFS群集跨越多个数据中心，则优先选择本地数据中心上的副本。
 
 
 
@@ -86,21 +80,21 @@ HDFS采用机架感知副本放置策略，对于常见情况，当复制因子
 
 #### 1. 心跳机制和重新复制
 
-每个DataNode定期向NameNode发送心跳消息，如果超过指定时间没有收到心跳消息，则将DataNode标记为死亡。NameNode不会将任何新的IO请求转发给标记为死亡的DataNode，且标记为死亡的DataNode上的数据也不在可用。 由于数据不再可用，可能会导致某些块的复制因子小于其指定值，NameNode会跟踪这些需要复制的块，并在必要的时候进行复制。
+每个DataNode定期向NameNode发送心跳消息，如果超过指定时间没有收到心跳消息，则将DataNode标记为死亡。NameNode不会将任何新的IO请求转发给标记为死亡的DataNode，也不会再使用这些DataNode上的数据。 由于数据不再可用，可能会导致某些块的复制因子小于其指定值，NameNode会跟踪这些块，并在必要的时候进行重新复制。
 
 #### 2. 数据的完整性
 
-由于存储设备中故障等原因，存储在DataNode获取的数据块可能会发生此损坏。
+由于存储设备故障等原因，存储在DataNode上的数据块也会发生损坏。为了避免读取到已经损坏的数据而导致错误，HDFS提供了数据完整性校验机制来保证数据的完整性，具体操作如下：
 
-当客户端创建HDFS文件时，它会计算文件每个块的`校验和`，并将这些`校验和`存储在同一HDFS命名空间中的单独隐藏文件中。当客户端检索文件内容时，它会验证从每个DataNode接收的数据是否与存储在关联校验和文件中的`校验和`匹配。如果没有，则客户端可以选择从另一个DataNode中检索该块。
+当客户端创建HDFS文件时，它会计算文件的每个块的`校验和`，并将`校验和`存储在同一HDFS命名空间下的单独的隐藏文件中。当客户端检索文件内容时，它会验证从每个DataNode接收的数据是否与存储在关联校验和文件中的`校验和`匹配。如果匹配失败，则证明数据已经损坏，此时客户端会选择从其他DataNode获取该块的其他可用副本。
 
 #### 3.元数据的磁盘故障
 
-`FsImage`和`EditLog`是HDFS架构的中心数据。这些数据的失效会引起HDFS实例失效。因为这个原因，可以配置NameNode使其支持`FsImage`和`EditLog`多副本同步，使得`FsImage`或`EditLog`的任何改变会引起每一份`FsImage`和`EditLog`同步更新。
+`FsImage`和`EditLog`是HDFS的核心数据，这些数据的意外丢失可能会导致整个HDFS服务不可用。为了避免这个问题，可以配置NameNode使其支持`FsImage`和`EditLog`多副本同步，这样`FsImage`或`EditLog`的任何改变都会引起每个副本`FsImage`和`EditLog`的同步更新。
 
 #### 4.支持快照
 
-快照支持在特定时刻存储数据副本，以便可以将损坏的HDFS实例回滚到先前良好时间点。
+快照支持在特定时刻存储数据副本，在数据意外损坏时，可以通过回滚操作恢复到健康的数据状态。
 
 
 
@@ -108,29 +102,29 @@ HDFS采用机架感知副本放置策略，对于常见情况，当复制因子
 
 ### 3.1 高容错
 
-由于HDFS 采用数据的多副本方案、所以哪怕部分硬件的损坏，也不会导致数据的丢失。
+由于HDFS 采用数据的多副本方案、所以部分硬件的损坏不会导致全部数据的丢失。
 
 ### 3.2 高吞吐量
 
-HDFS是被设计用于批量处理而非用户交互。设计的重点是高吞吐量访问而不是低延迟数据访问。
+HDFS设计的重点是支持高吞吐量的数据访问，而不是低延迟的数据访问。
 
 ### 3.3  大文件支持
 
-在HDFS上运行的应用程序具有大型数据集。一个典型文档在HDFS是GB到TB级别的。因此，HDFS被设计为支持大文件。
+HDFS适合于大文件的存储。文档的大小应该是是GB到TB级别的。
 
 ### 3.3 简单一致性模型
 
-HDFS更适合于一次写入多次读取（write-once-read-many）的访问模型。支持将内容附加到文件末尾，但无法在任意点更新。此假设简化了数据一致性问题，并实现了高吞吐量数据访问。
+HDFS更适合于一次写入多次读取(write-once-read-many)的访问模型。支持将内容追加到文件末尾，但不支持数据的随机访问，不能从文件任意位置新增数据。
 
 ### 3.4 跨平台移植性
 
-HDFS的设计便于从一个平台移植到另一个平台。这有助于HDFS作为大数据首选存储方案。
+HDFS具有良好的跨平台移植性，这使得其他大数据计算框架都将其作为数据持久化存储的首选方案。
 
 
 
 ## 附：图解HDFS存储原理
 
-说明：本小结图片引用自博客[翻译经典 HDFS 原理讲解漫画](https://blog.csdn.net/hudiefenmu/article/details/37655491)
+> 说明：以下图片引用自博客：[翻译经典 HDFS 原理讲解漫画](https://blog.csdn.net/hudiefenmu/article/details/37655491)
 
 ### 1. HDFS写数据原理