重新复制缺失副本
如果名称节点停止从一个数据节点接收检测信号，假定它已经死亡，任何数据必须也消失了。基于块从死亡节点接受到报告，这个名称节点知道哪个副本连同节点块死亡，并可决定重新复制这些块到其他数据节点。它还将参考机架感知数据，以保持在一个机架内的两个副本。
考虑一下这个场景，整个机架的服务器网络脱落，也许是因为一个机架交换机故障或电源故障。这个名称节点将开始指示集群中的其余节点重新复制该机架中丢失的所有数据块。如果在那个机架中的每个服务器有12TB的数据，这可能是数百个TB的数据需要开始穿越网络。
二级名称节点
hadoop服务器角色被称为二级名称节点。一个常见的误解是，这个角色为名称节点提供了一个高可用性的备份，这并非如此。
二级名称节点偶尔连接到名字节点，并获取一个副本的名字节点内存中的元数据和文件用于存储元数据。二级名称节点在一个新的文件集中结合这些信息，并将其递送回名称节点，同时自身保留一份复本。
如果名称节点死亡，二级名称节点保留的文件可用于恢复名称节点。
从HDFS客户端读取
当客户想要从HDFS读取一个文件，它再一次咨询名称节点，并要求提供文件块的位置。
客户从每个块列表选择一个数据节点和用TCP的50010端口读取一个块。直到前块完成，它才会进入下一个块。
从HDFS中读取数据节点
有些情况下，一个数据节点守护进程本身需要从HDFS中读取数据块。一种这样的情况是数据节点被要求处理本地没有的数据，因此它必须从网络上的另一个数据节点检索数据，在它开始处理之前。
另一个重要的例子是这个名称节点的Rack Awareness认知提供了最佳的网络行为。当数据节点询问数据块里名称节点的位置时，名称节点将检查是否在同一机架中的另一种数据节点有数据。如果是这样，这个名称节点从检索数据里提供了机架上的位置。该流程不需要遍历两个以上的交换机和拥挤的链接找到另一个机架中的数据。在机架上检索的数据更快，数据处理就可以开始的更早，,工作完成得更快。
Map Task
现在file.txt在我的机器集群中蔓延，我有机会提供极其快速和高效的并行处理的数据。包含Hadoop的并行处理框架被称为Map Reduce，模型中命名之后的两个步骤是Map和Reduce。
第一步是Map过程。这就是我们同时要求我们的机器他们本地的数据块上来运行一个计算。在这种情况下，我们要求我们的机器对“Refund”这个词在File.txt的数据块中出现的次数进行计数。
开始此过程，客户端机器提交Map Reduce作业的Job Tracker，询问“多少次不会在File.txt 中出现Refund”(意译Java代码)。Job Tracker查询名称节点了解哪些数据节点有File.txt块。Job Tracker提供了这些节点上运行的Task Tracker与Java代码需要在他们的本地数据上执行的Map计算。这个Task Tracker启动一个Map任务和监视任务进展。这Task Tracker提供了检测信号并向Job Tracker返回任务状态。
每个Map任务完成后，每个节点在其临时本地存储中存储其本地计算的结果。这被称作“中间数据”。 下一步将通过网络传输发送此中间数据到Reduce任务最终计算节点上运行。
Map Task非本地
虽然Job Tracker总是试图选择与当地数据做Map task的节点，但它可能并不总是能够这样做。其中一个原因可能是因为所有的节点与本地数据，已经有太多的其他任务运行，并且不能接受了。
在这种情况下, Job Tracker将查阅名称节点的Rack Awareness知识，可推荐同一机架中的其他节点的名称节点。作业跟踪器将把这个任务交给同一机架中的一个节点，节点去寻找的数据时，它需要的名称节点将指示其机架中的另一个节点来获取数据。
Reduce Task从Map Tasks计算接收到的数据
第二阶段的Map Reduce框架称为Reduce。机器上的Map任务已经完成了和生成它们的中间数据。现在我们需要收集所有的这些中间数据，组合并提纯以便进一步处理，这样我们会有一个最终结果。
Job Tracker在集群中的任何一个节点上开始一个Reduce任务，并指示Reduce任务从所有已完成的Map任务中获取中间数据。Map任务可能几乎同时应对Reducer，导致让你一下子有大量的节点发送TCP数据到一个节点。这种流量状况通常被称为“Incast”或者“fan-in”。对于网络处理大量的incast条件，其重要的网络交换机拥有精心设计的内部流量管理能力，以及足够的缓冲区(不太大也不能太小)。
Reducer任务现在已经从Map任务里收集了所有的中间数据，可以开始最后的计算阶段。在本例中，我们只需添加出现“Refund”这个词的总数，并将结果写入到一个名为Results的txt文件里。
这个名为Results的txt文件，被写入到HDFS以下我们已经涵盖的进程中，把文件分成块，流水线复制这些块等。当完成时，客户机可以从HDFS和被认为是完整的工作里读取Results.txt。
我们简单的字数统计工作并不会导致大量的中间数据在网络上传输。然而，其他工作可能会产生大量的中间数据，比如对TB级数据进行排序。
如果你是一个勤奋的网络管理员，你将了解更多关于Map Reduce和你的集群将运行的作业类型，以及作业类型如何影响你的网络流量。如果你是一个Hadoop网络明星，你甚至能够提出更好的代码来解决Map Reduce任务，以优化网络的性能，从而加快工作完工时间。
不平衡的Hadoop集群
Hadoop可以为你的组织提供一个真正的成功，它让你身边的数据开发出了很多之前未发现的业务价值。当业务人员了解这一点，你可以确信，很快就会有更多的钱为你的Hadoop集群购买更多机架服务器和网络。
当你在现有的Hadoop集群里添加新的机架服务器和网络这种情况时，你的集群是不平衡的。在这种情况下，机架1&2是我现有的包含 File.txt的机架和运行我的Map Reduce任务的数据。当我添加了两个新的架到集群，我的File.txt数据并不会自动开始蔓延到新的机架。
新的服务器是闲置的，直到我开始加载新数据到集群中。此外,如果机架1&2上服务器都非常繁忙，Job Tracker可能没有其他选择，但会指定File.txt上的Map任务到新的没有本地数据的服务器上。新的服务器需要通过网络去获取数据。作为结果，你可能看到更多的网络流量和较长工作完成时间。
Hadoop集群均衡器
为了弥补集群的平衡性，Hadoop还包含了均衡器。
Balancer目光聚焦于节点间有效储存的差异，力所能及的将平衡维持在一定的临界值上。假如发现剩余大量储存空间的节点，Balancer将找出储存空间剩余量少的节点并把数据剪切到有大量剩余空间的节点上。只有的终端上输入指令Balancer才会运行，当接收到终端取消命令或者终端被关闭时，Balancer将会关闭。
Balancer可以调用的网络带宽很小，默认只有1MB/s。带宽可以通过hdfs-site.xml文件中的dfs.balance.bandwidthPerSec参数来设置。
Balancer是集群的好管家。没当有新机组添加时候就会用到它，甚至一经开启就会运行整个星期。给均衡器低带宽可以让它保持着长时间的运行。
个人认为假如均衡器能成为Hadoop的核心而不是只是一项功能，那样一定会比较有意思!
