Hadoop原理简述

第1.1节 Hadoop架构

Hadoop系统由两部分组成，分别是分布式文件系统HDFS (Hadoop Distributed File System) 和分布式计算框架MapReduce。其中，分布式文件系统主要用于大规模数据的分布式存储，而MapReduce则构建在分布式文件系统之上，对存储在分布式文件系统中的数据进行分布式计算。下图简单展示了Hadoop系统的架构。

从图中可以清晰的看出Hadoop系统由MapReduce和HDFS两个部分组成。虚实线代表了其中的数据流向，在后期HDFS和MapReduce的各自介绍中，我们会详细介绍这些线条所代表的数据走向。

从软件架构角度来看，Hadoop基于每个节点上的本地文件系统，构建了逻辑上整体化的分布式文件系统（HDFS），以此提供大规模可扩展的分布式数据存储功能；同时，Hadoop利用每个节点的计算资源，协调管理集群中的各个节点完成计算任务。图中涉及到几个概念：

• 主控节点：JobTracker为MapReduce的主控节点，NameNode 为HDFS的主控节点，他们负责控制和管理整个集群的正常运行。
• 从节点：TaskTracker为MapReduce的从节点，负责具体的任务执行；DataNode为HDFS的从节点，负责存储具体的数据。

可以看出，Hadoop服从Master/Slaver（主从架构）。在集群部署的时候，一般JobTracker和NameNode部署在同一节点上，TaskTracker和DataNode部署在同一节点。

简单来看，图中的每个大框（框住JobTracker和NameNode，或者TaskTracker和DataNode的框）都可以认为是一个机器节点。很多个这样的机器节点会构成一个机架，分布在不同区域的机架会构成一个Hadoop集群。

第1.2节 HDFS原理简述

一、HDFS的特征

HDFS（Hadoop Distribute File System）是一个分布式文件系统，它是谷歌的被称为大数据的三驾马车之一的论文"Google File System"的开源实现。在谈HDFS具体特征之前，我们先讨论以下HDFS解决的是什么问题。在找到这个问题的答案之前，我们需要先了解为什么需要分布式文件系统。

既然是分布式，那自然是集中式存储造成了问题，问题出现的根源就在于数据量太大了。固然我们可以通过提高集中式设备的性能来达到扩大存储的目的，但是提升单个设备的性能，与其带来的对数据的存储能力的提升有时候并不成正比。举个例子，假设当前的文件系统的存储能力为X，网络带宽性能为Y，我们可以将文件系统的存储能力提升为2X，成本可能会变为原来的4倍或更多，但是设备的能力提升并不一定能给我们带来double的体验，因为网络带宽没有变。

同时，集中式的存储往往会带来单点瓶颈，集中式的服务器一旦出现故障，将造成大面的服务瘫痪，因为没有其他服务器可以提供这种级别的能力，由此引入了分布式。

从上述的讨论中，我们最起码可以看到分布式必须要给我们带来的益处：首先，它需要具备大数据的存储能力，这是我们最基础的诉求；其次，必须要保证服务具有高可用性，不能出现一个服务器故障，整体服务瘫痪的状况。所以，这两者也一定得是HDFS这一分布式文件系统必须具备的特征，当然，天才的科学家们定然不会仅仅只让HDFS做到这些，概括来看，它具有下面几个特征：

• 大规模数据的分布存储能力

  HDFS以分布式方式和良好的可扩展提供了大规模数据的存储能力。

• 高并发访问能力

  HDFS以多节点并发访问的方式提供很高的数据访问带宽（高数据吞吐率）。

• 容错能力

  在分布式环境中，失效应当被认为是常态。因此，HDFS必须具备正确检测硬件故障，并且能快速从故障中恢复过来，确保数据不丢失。为了保证数据的不丢不出错，HDFS采用了多副本的方式（默认副本数目为3）。

• 顺序文件访问

  大数据批处理在大多数情况下都是大量简单记录的顺序处理。针对这个特性，为了提高大规模数据访问的效率，HDFS对顺序读进行了优化，但是对于随机访问负载较高。

• 简单的一致性模型

  支持大量数据的一次写入，多次读取。

• 数据块存储模式

  HDFS采用基于大粒度数据块的方式进行文件存储。之前的默认的块大小是64MB，2.7.3之后，改为了128M，这样的好处是可以减少元数据的数量，减少寻址时间。

在后面，我们会一一探讨这些特征的实现方法，又或者这些特征设计为HDFS带来的巨大益处。

二、HDFS的架构

前文我们给出了Hadoop的架构图，并给出了大意讲解，这里给出了HDFS架构的基本示意图。

图中的线条代表数据的走向，也代表了HDFS中一些操作的流程，我们先忽视掉这些流程，只专注于每个节点。

• 客户端（Client, 代表用户）

  通过与NameNode和DataNode交互访问HDFS中的文件。Client提供了一个类似POSIⅩ的文件系统接口供用户调用。

• NameNode

  整个Hadoop集群中只有一个NameNode。它是整个系统的“总管”，负责管理HDFS的目录树和相关的文件元数据信息。这些信息是以“fsimage”（HDFS元数据镜像文件）和 “editlog”（HDFS文件改动日志），他们以文件形式存放在本地磁盘，当HDFS重启时会被重新构造出来的。此外，NameNode还负责监控各个DataNode的健康状态，一旦发现某个DataNode宕掉，则将该DataNode移出，则将该DataNode移出HDFS并重新备份其上面的数据。

• DataNode

  一般而言，每个Slave节点上安装一个DataNode，它负责实际的数据存储，并将数据信息定期汇报给NameNode。DataNode以固定大小的block为基本单位组织文件内容，默认情况下block大小为64MB。当用户上传一个大的文件到HDFS上时，该文件会被切分成若干个block，分别存储到不同的DataNode；同时，为了保证数据可靠，会将同一个block以流水线方式写到若干个（默认是3，该参数可配置）不同的DataNode上。这种文件切割后存储的过程是对用户透明的，同时这些过程也与上文中的HDFS特性对应了起来。

• Secondary NameNode

  Secondary NameNode在图中没有体现，他会在NameNode失效时，为NameNode恢复元数据。他最重要的任务并不是为NameNode元数据进行热备份，而是定期合并fsimage（文件镜像数据）和edits日志，并传输给NameNode。这里需要注意的是，为了减小NameNode压力，NameNode自己并不会合并fsimage和edits，并将文件存储到磁盘上，而是交由Secondary NameNode完成。

三、HDFS特征引入背景时的一些思考

我们说HDFS面向的是大数据存储，其实这里引入了一道面试题。如果你面的是数据开发岗或者大数据开发岗的校招，那么你就很可能会遇到，即：

Q: 你认为数据量达到多少就能被称为大数据了？

我个人倾向于，谈到具体的数据量，就输了。谈到大数据总躲不过5V特征：

【1】Volumn（大体量）：即可从数百TB到数十数百PB甚至EB级别的数据；

【2】Variety（多样性）：大数据会包含各种格式或者形态的数据；

【3】Velocity（时效性）：数据大多需要在一定时间限度内被处理；

【4】Veracity（精确性）：数据处理的结果需要保证一定的精度；

【5】Value（大价值）：数据会包含很多深度的价值。

从这个角度而言，量仅是大数据的特征，但并不意味着大数据会和数据大画上某等于或者线性的关系。大体积的无用数据，仅仅是占用存储的垃圾而已，需要清楚。体量大，且包含大价值的数据，才能够被称为大数据。

第1.3节 MapReduce原理简述

一、MapReduce思想

分而治之是大数据技术的基本基本思想。MapReduce同样借助了分治思想，将大数据切分为“小”数据，再并行进行处理。

MapReduce能够解决的问题有一个共同特点：任务可以被分解为多个子问题，且这些子问题相对独立，彼此之间不会有牵制，待并行处理完这些子问题后，任务便被解决。在实际应用中，这类问题非常庞大，谷歌在论文中提到了MapReduce的一些典型应用，包括分布式grep、URL访问频率统计、Web连接图反转、倒排索引构建、分布式排序等。

说到这里，其实MapReduce的核心就完了。分治就是核心，但是我们不妨再去想想，大数据的解决方案只有分治吗？

当然不止！！！

（1）大数据带来的问题主要是海量数据带来了算法执行时的时间问题。我们可以去寻找新的、低复杂度算法。但是问题也是显然的，太难了。当前我们流行的算法是先辈们百年来的智慧结晶，短时间内寻找更好、性能更好的算法显然不太显示。

（2）寻找或者采用降低数据尺度的算法。在保证结果结果精度的前提下，寻找尺度无关的算法。这确实是一种方案，但是放弃一些尺度的数据，意味会丢失一些信息。

（3）分治。

这应该是大数据问题的三个基本解决方案了。前两种也各有应用场景，但是相较而言，分治思想简单，且有效。MapReduce框架的成功就是铁证。

二、MapReduce架构

同HDFS的介绍类似，我们先给出架构图，忽略表示数据流向的线条，我们先关注每个节点。

• Job Client

  作用客户端接口程序，用户可以通过该程序提交一个MapReduce程序

• Job Tracker

  JobTracker是整个MapReduce计算框架中的主服务，相当于集群的“管理者”，负责整个集群的作业控制和资源管理。在Hadoop内部，每个应用程序被表示成一个作业，每个作业又被进一步分成多个任务，而JobTracker的作业控制模块则负责作业的分解和状态监控。其中，最重要的是状态监控，主要包括TaskTracker状态监控、作业状态监控和任务状态监控等。其主要作用有两个：容错和为任务调度提供决策依据。一方面，通过状态监控， JobTracker能够及时发现存在异常或者出现故障的TaskTracker、作业或者任务，从而启动相应的容错机制进行处理；另一方面，由于JobTracker保存了作业和任务的近似实时运行信息，这些可用于任务调度时进行任务选择的依据。资源管理模块的作用是通过一定的策略将各个节点上的计算资源分配给集群中的任务。它由可插拔的任务调度器完成，用户可根据自己的需要编写相应的调度器。

• Task Tracker

  TaskTracker是Hadoop集群中运行于各个节点上的服务。它扮演着“通信枢纽”的角色，是JobTracker与Task之间的“沟通桥梁”：一方面，它从JobTracker端接收并执行各种命令，比如运行任务、提交任务、杀死任务等；另一方面，它将本节点上的各个任务状态通过周期性心跳汇报给JobTracker。