diff --git a/notes/Hadoop-HDFS.md b/notes/Hadoop-HDFS.md index 574d46c..bfe69a9 100644 --- a/notes/Hadoop-HDFS.md +++ b/notes/Hadoop-HDFS.md @@ -1,115 +1,139 @@ -# HDFS 架构 - -## 一、介绍 - -**HDFS** （**Hadoop Distributed File System**）是一种分布式文件系统，具有**高容错**、**高吞吐量**等特性，可以部署在**低成本**的硬件上。 - - - -## 二 、HDFS 设计原理 - -
- -### 2.1 HDFS 架构 - -HDFS 具有主/从架构，由单个NameNode （NN）和 多个 DataNode (DN) 组成： - -- NameNode : 负责执行文件**系统命名空间**的操作，如打开，关闭和重命名文件、目录等，它还负责集群元数据的存储，记录着每个文件中各个块所在数据节点的信息。 -- DataNode：负责提供来自文件系统客户端的读写请求，执行块的创建，删除等操作。 - - - -### 2.2 文件系统命名空间 - -HDFS 系统命名空间的层次结构与现在大多数文件系统类似（如 windows）, 可以进行目录、文件的创建、移动、删除和重命名等操作，支持用户配置和访问权限配置，但不支持硬链接和软连接。 - -NameNode 负责维护文件系统名称空间,记录对名称空间或其属性的任何更改。 - - - -### 2.3 数据复制 - -由于hadoop设计运行在廉价的机器上，这意味着硬件是不可靠的，为了保证高容错，数据复制孕育而生。 - -HDFS 它将每一个文件存储为一系列**块**，复制文件的块以实现容错，块大小和复制因子可根据文件进行配置（默认块大小是128M,默认复制因子是3）。 - -
- -### 2.4 数据复制的实现原理 - -大型HDFS实例在通常分布在多个机架上的计算机群集上运行。不同机架中两个节点之间的通信必须通过交换机。在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。 - -对于常见情况，当复制因子为3时，HDFS的放置策略是： - -在编写器位于datanode上时，将一个副本放在本地计算机上，否则放在随机datanode上；在另一个（远程）机架上的节点上放置另一个副本，最后一个在同一个远程机架中的另一个节点上。此策略可以减少机架间写入流量，从而提高写入性能。 - -
- -如果复制因子大于3，则随机确定第4个和以下副本的放置，同时保持每个机架的副本数量低于上限，上限值通常为`（复制系数 - 1）/机架数量 + 2`，但是不允许同一个dataNode具有同一块的多个副本。 - - - -### 2.5 副本的选择 - -为了最大限度地减少全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在副本，则该副本首选满足读取请求。如果HDFS群集跨越多个数据中心，则本地数据中心的副本优先于任何远程副本。 - - - -### 2.6 架构的稳定性 - -#### 1. 心跳机制和重新复制 - -每个DataNode定期向NameNode发送心跳消息，如果超过指定时间没有收到心跳消息，则将DataNode标记为死亡。NameNode不会将任何新的IO请求转发给标记为死亡的DataNode，且标记为死亡的DataNode上的数据也不在可用。 由于数据不在可用，可能会导致某些块的复制因子小于其指定值，NameNode会跟踪这些需要复制的块，并在必要的时候进行复制。 - -#### 2. 数据的完整性 - -由于存储设备中故障等原因，存储在DataNode获取的数据块可能会发生此损坏。 - -当客户端创建HDFS文件时，它会计算文件每个块的`校验和`，并将这些`校验和`存储在同一HDFS命名空间中的单独隐藏文件中。当客户端检索文件内容时，它会验证从每个DataNode接收的数据是否与存储在关联校验和文件中的`校验和`匹配。如果没有，则客户端可以选择从另一个DataNode中检索该块。 - -#### 3.元数据的磁盘故障 - -`FsImage`和`EditLog`是HDFS架构的中心数据。这些数据的失效会引起HDFS实例失效。因为这个原因，可以配置NameNode使其支持`FsImage`和`EditLog`多副本同步，使得`FsImage`或`EditLog`的任何改变会引起每一份`FsImage`和`EditLog`同步更新。 - -#### 4.快照支持 - -[快照](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsSnapshots.html)支持在特定时刻存储数据副本，以便可以将损坏的HDFS实例回滚到先前良好时间点。 - - - -## 三、HDFS 的特点 - -### 3.1 高容错 - -由于HDFS 采用数据的多副本方案、所以哪怕部分硬件的损坏，也不会导致数据的丢失。 - -### 3.2 高吞吐量 - -HDFS是被设计用于批量处理而非用户交互。设计的重点是高吞吐量访问而不是低延迟数据访问。 - -### 3.3 大文件支持 - -在HDFS上运行的应用程序具有大型数据集。一个典型文档在HDFS是GB到TB级别的。因此，HDFS被设计为支持大文件。 - -### 3.3 简单一致性模型 - -HDFS更适合于一次写入多次读取（write-once-read-many）的访问模型。支持将内容附加到文件末尾，但无法在任意点更新。此假设简化了数据一致性问题，并实现了高吞吐量数据访问。 - -### 3.4 跨平台移植性 - -HDFS的设计便于从一个平台移植到另一个平台。这有助于HDFS作为大数据首选应用存储程序。 - - - -## 四、HDFS shell - - - -## 五、HDFS API - - - -## 参考文档 - -1. [Apache Hadoop 2.9.2 > HDFS Architecture](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) - +# Hadoop-HDFS + + + +## 一、介绍 + +**HDFS** （**Hadoop Distributed File System**）是一种分布式文件系统，具有**高容错**、**高吞吐量**等特性，可以部署在**低成本**的硬件上。 + + + +## 二、HDFS 设计原理 + +
+ +### 2.1 HDFS 架构 + +HDFS 具有主/从架构，由单个NameNode （NN）和 多个 DataNode (DN) 组成： + +- NameNode : 负责执行文件**系统命名空间**的操作，如打开，关闭和重命名文件、目录等，它还负责集群元数据的存储，记录着每个文件中各个块所在数据节点的信息。 +- DataNode：负责提供来自文件系统客户端的读写请求，执行块的创建，删除等操作。 + + + +### 2.2 文件系统命名空间 + +HDFS 系统命名空间的层次结构与现在大多数文件系统类似（如 windows）, 可以进行目录、文件的创建、移动、删除和重命名等操作，支持用户配置和访问权限配置，但不支持硬链接和软连接。 + +NameNode 负责维护文件系统名称空间,记录对名称空间或其属性的任何更改。 + + + +### 2.3 数据复制 + +由于hadoop设计运行在廉价的机器上，这意味着硬件是不可靠的，为了保证高容错，数据复制孕育而生。 + +HDFS 它将每一个文件存储为一系列**块**，复制文件的块以实现容错，块大小和复制因子可根据文件进行配置（默认块大小是128M,默认复制因子是3）。 + +
+ +### 2.4 数据复制的实现原理 + +大型HDFS实例在通常分布在多个机架上的计算机群集上运行。不同机架中两个节点之间的通信必须通过交换机。在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。 + +HDFS采用机架感知副本放置策略，对于常见情况，当复制因子为3时，HDFS的放置策略是： + +在编写器位于datanode上时，将一个副本放在本地计算机上，否则放在随机datanode上；在另一个（远程）机架上的节点上放置另一个副本，最后一个在同一个远程机架中的另一个节点上。此策略可以减少机架间写入流量，从而提高写入性能。 + +
+ +如果复制因子大于3，则随机确定第4个和以下副本的放置，同时保持每个机架的副本数量低于上限，上限值通常为`（复制系数 - 1）/机架数量 + 2`，但是不允许同一个dataNode具有同一块的多个副本。 + + + +### 2.5 副本的选择 + +为了最大限度地减少全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在副本，则该副本首选满足读取请求。如果HDFS群集跨越多个数据中心，则本地数据中心的副本优先于任何远程副本。 + + + +### 2.6 架构的稳定性 + +#### 1. 心跳机制和重新复制 + +每个DataNode定期向NameNode发送心跳消息，如果超过指定时间没有收到心跳消息，则将DataNode标记为死亡。NameNode不会将任何新的IO请求转发给标记为死亡的DataNode，且标记为死亡的DataNode上的数据也不在可用。 由于数据不再可用，可能会导致某些块的复制因子小于其指定值，NameNode会跟踪这些需要复制的块，并在必要的时候进行复制。 + +#### 2. 数据的完整性 + +由于存储设备中故障等原因，存储在DataNode获取的数据块可能会发生此损坏。 + +当客户端创建HDFS文件时，它会计算文件每个块的`校验和`，并将这些`校验和`存储在同一HDFS命名空间中的单独隐藏文件中。当客户端检索文件内容时，它会验证从每个DataNode接收的数据是否与存储在关联校验和文件中的`校验和`匹配。如果没有，则客户端可以选择从另一个DataNode中检索该块。 + +#### 3.元数据的磁盘故障 + +`FsImage`和`EditLog`是HDFS架构的中心数据。这些数据的失效会引起HDFS实例失效。因为这个原因，可以配置NameNode使其支持`FsImage`和`EditLog`多副本同步，使得`FsImage`或`EditLog`的任何改变会引起每一份`FsImage`和`EditLog`同步更新。 + +#### 4.支持快照 + +快照支持在特定时刻存储数据副本，以便可以将损坏的HDFS实例回滚到先前良好时间点。 + + + +## 三、HDFS 的特点 + +### 3.1 高容错 + +由于HDFS 采用数据的多副本方案、所以哪怕部分硬件的损坏，也不会导致数据的丢失。 + +### 3.2 高吞吐量 + +HDFS是被设计用于批量处理而非用户交互。设计的重点是高吞吐量访问而不是低延迟数据访问。 + +### 3.3 大文件支持 + +在HDFS上运行的应用程序具有大型数据集。一个典型文档在HDFS是GB到TB级别的。因此，HDFS被设计为支持大文件。 + +### 3.3 简单一致性模型 + +HDFS更适合于一次写入多次读取（write-once-read-many）的访问模型。支持将内容附加到文件末尾，但无法在任意点更新。此假设简化了数据一致性问题，并实现了高吞吐量数据访问。 + +### 3.4 跨平台移植性 + +HDFS的设计便于从一个平台移植到另一个平台。这有助于HDFS作为大数据首选存储方案。 + + + +## 四、HDFS shell + + + +## 五、HDFS API + + + +## 参考资料 + +1. [Apache Hadoop 2.9.2 > HDFS Architecture](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) +2. Tom White. hadoop权威指南 [M]. 清华大学出版社, 2017. + diff --git a/notes/Hadoop-YARN.md b/notes/Hadoop-YARN.md new file mode 100644 index 0000000..e3651ec --- /dev/null +++ b/notes/Hadoop-YARN.md @@ -0,0 +1,110 @@ +# Hadoop-YARN + + +## 一、hadoop yarn 简介 + +**Apache YARN** (Yet Another Resource Negotiator) 在 hadoop 2 中被引入，作为hadoop集群资源管理系统。用户可以将各种各样的计算框架部署在YARN上，由YARN进行统一管理和资源的分配。 + +
+ + + +## 二、YARN架构 + +
+ +#### 1. ResourceManager + +以主要后台进程的形式运行，它通常在专用机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。ResourceManager 会追踪集群中有多少可用的活动节点和资源，协调用户提交的哪些应用程序应该在何时获取这些资源。ResourceManager 是惟一拥有此信息的进程，所以它可通过某种共享的、安全的、多租户的方式制定分配（或者调度）决策（例如，依据应用程序优先级、队列容量、ACLs、数据位置等）。 + +#### 2. ApplicationMaster + +在用户提交一个应用程序时，一个称为 ApplicationMaster 的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务，重新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。这些职责以前分配给所有作业的单个 JobTracker。ApplicationMaster 和属于它的应用程序的任务，在受 NodeManager 控制的资源容器中运行。 + +ApplicationMaster 可在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster 请求一个容器来启动 map 或 reduce 任务，而 Giraph ApplicationMaster 请求一个容器来运行 Giraph 任务。 + +#### 3. NodeManager + +NodeManager管理YARN集群中的每个节点。NodeManager 提供针对集群中每个节点的服务，负责节点内容器生命周期的管理、监视资源和跟踪节点健康。 + + + +## 三、YARN工作原理简述 + +
+ +1. Client提交作业到YARN上； + +2. Resource Manager选择一个Node Manager，启动一个Container并运行Application Master实例； + +3. Application Master根据实际需要向Resource Manager请求更多的Container资源（如果作业很小, 应用管理器会选择在其自己的JVM中运行任务）； + +4. Application Master通过获取到的Container资源执行分布式计算。 + + + +## 四、YARN工作原理详述 + +
+ + + +#### 1. 作业提交 + +client 调用job.waitForCompletion方法，向整个集群提交MapReduce作业 (第1步) 。新的作业ID(应用ID)由资源管理器分配(第2步)。作业的client核实作业的输出, 计算输入的split, 将作业的资源(包括Jar包，配置文件, split信息)拷贝给HDFS(第3步)。 最后, 通过调用资源管理器的submitApplication()来提交作业(第4步)。 + +#### 2. 作业初始化 + +当资源管理器收到submitApplciation()的请求时, 就将该请求发给调度器(scheduler), 调度器分配container, 然后资源管理器在该container内启动应用管理器进程, 由节点管理器监控(第5步)。 + +MapReduce作业的应用管理器是一个主类为MRAppMaster的Java应用，其通过创造一些bookkeeping对象来监控作业的进度, 得到任务的进度和完成报告(第6步)。然后其通过分布式文件系统得到由客户端计算好的输入split(第7步)，然后为每个输入split创建一个map任务, 根据mapreduce.job.reduces创建reduce任务对象。 + +#### 3. 任务分配 + +如果作业很小, 应用管理器会选择在其自己的JVM中运行任务。 + +如果不是小作业, 那么应用管理器向资源管理器请求container来运行所有的map和reduce任务(第8步)。这些请求是通过心跳来传输的, 包括每个map任务的数据位置，比如存放输入split的主机名和机架(rack)，调度器利用这些信息来调度任务，尽量将任务分配给存储数据的节点, 或者分配给和存放输入split的节点相同机架的节点。 + +#### 4. 任务运行 + +当一个任务由资源管理器的调度器分配给一个container后，应用管理器通过联系节点管理器来启动container(第9步)。任务由一个主类为YarnChild的Java应用执行， 在运行任务之前首先本地化任务需要的资源，比如作业配置，JAR文件, 以及分布式缓存的所有文件(第10步。 最后, 运行map或reduce任务(第11步)。 + +YarnChild运行在一个专用的JVM中, 但是YARN不支持JVM重用。 + +#### 5. 进度和状态更新 + +YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。 + +#### 6. 作业完成 + +除了向应用管理器请求作业进度外, 客户端每5分钟都会通过调用waitForCompletion()来检查作业是否完成，时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和container会清理工作状态， OutputCommiter的作业清理方法也会被调用。作业的信息会被作业历史服务器存储以备之后用户核查。 + +本小结内容引用自博客[初步掌握Yarn的架构及原理](https://www.cnblogs.com/codeOfLife/p/5492740.html) + + + +## 五、提交作业到YARN上运行 + + + +## 参考资料 + +1. [Apache Hadoop 2.9.2 > Apache Hadoop YARN](http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/YARN.html) +2. [YARN：下一代 Hadoop 计算平台](https://www.ibm.com/developerworks/cn/data/library/bd-yarn-intro/index.html?mhq=yarn) +3. [初步掌握Yarn的架构及原理](https://www.cnblogs.com/codeOfLife/p/5492740.html) + diff --git a/pictures/Figure3Architecture-of-YARN.png b/pictures/Figure3Architecture-of-YARN.png new file mode 100644 index 0000000..41cc109 Binary files /dev/null and b/pictures/Figure3Architecture-of-YARN.png differ diff --git a/pictures/yarn-base.png b/pictures/yarn-base.png new file mode 100644 index 0000000..6fb6e11 Binary files /dev/null and b/pictures/yarn-base.png differ diff --git a/pictures/yarn工作原理.png b/pictures/yarn工作原理.png new file mode 100644 index 0000000..e68f0e2 Binary files /dev/null and b/pictures/yarn工作原理.png differ diff --git a/pictures/yarn工作原理简图.png b/pictures/yarn工作原理简图.png new file mode 100644 index 0000000..8930478 Binary files /dev/null and b/pictures/yarn工作原理简图.png differ