3.1：Hadoop的一些基本概念

一 Hadoop的构建模块

• NameNode(名字节点)

• DataNode(数据节点)

• Secondary NameNode(次名字节点)

• JobTracker(作业跟踪节点)

• TaskTracker(任务跟踪节点)

1.HDFS系统的文件特征

A、存储极大数目的信息（terabytes or petabytes），将数据保存到大量的节点当中。支持很大单个文件。

B、提供数据的高可靠性，单个或者多个节点不工作，对系统不会造成任何影响，数据仍然可用。

C、提供对这些信息的快速访问，并提供可扩展的方式。能够通过简单加入更多服务器的方式就能够服务更多的客户端。

D、HDFS是针对MapReduce设计的，使得数据尽可能根据其本地局部性进行访问与计算。

2.HDFS的缺陷

• 低延迟数据访问

  比如毫秒级 比如低延迟与高吞吐

• 小文件存取

  占用NameNode大量内存 寻道时间超过读取时间

• 并发写入/文件随机修改

  一个文件只能有一个写者 仅支持append

3.MapReduce的系统工作原理

4.NameNode

NameNode是Hadoop守护进程中最重点的一个,Hadoop在分布式计算与分布式存付中都采用了主/从(Master/slave)结构.分布式存储系统被称为Hadoop文件系统,或简单称为HDFS.NameNode位于HDFS的主端,它指导DataNode执行底层的IO任务.

       运行NameNode消耗大量的内存与IO资源.因此,为了减轻机器的负载,驻留NameNode的服务器通常不会存储用户数据或者执行MapReduce程序的计算任务.这意味着NameNode服务器不会同时是DataNode或者TaskTracker.

       不过NameNode的重要性也带来一个负面影响-Hadoop集群的失效.

5.DataNode

每一个集群上的从节点都会驻留一个DataNode守护进程,来执行分布式文件系统的繁重工作,将HDFS数据块读取或者写入到本地文件系统的实际文件中.当希望对HDFS文件进行读写时,文件被分割为多个块,由NameNode告知客户端每个数据块驻留在那个DataNode.客户端直接与DataNode守护进程通信,来处理与数据块相对应的本地文件.然而DataNode会与其他DataNode进行通信,复制这些数据块以实现冗余.

6.Secondary NameNode

       SNN是一个监测HDFS集群状态的辅助守护进程,它通常独占一台服务器,该服务器不会运行其他DataNode或者TaskTracker守护进程.SNN与NameNode的不同在于它不接收或者记录HDFS的任何实时变化.相反它与NameNode通信,感觉集群所配置的时间间隔获取HDFS元数据的快照.

       NameNode是Hadoop集群的单一故障点,而SNN的快照可以有助于减少停机的时间并降低数据丢失的风险.然而NameNode的失效处理需要人工的干预,即手动地重新配置集群,将SNN用作主要的NameNode.

7.JobTracker

       JobTracker守护进程是应用程序和Hadoop之间的纽带.一旦提交代码到集群上,JobTracker就会确定执行计划,包括决定处理哪些文件,为不同的任务分配节点以及监控所有任务的运行.如果任务失败,JobTracker将自动重启任务,但所分配的节点可能会不同,同时受到预定义的重试次数限制.

       每一个Hadoop集群只有一个JobTracker守护进程,它通常运行在服务器集群的主节点上.

8.TaskTracker

       与存储的守护进程一样,计算的守护进程也遵循主从架构:JobTracker作为主节点,监测MapReduce作业的整个执行过程,同时,TaskTracker管理各个任务在每个从节点上的执行情况.

       TaskTracker的一个职责就是负责持续不断地与JobTracker通讯.如果JobTracker在指定的时间内没有收到来自TaskTracker的心跳,它会假定TaskTracker已经崩溃了,进而重新提交相应的任务到集群的其他节点中.

HDFS文件系统工作原理

Hadoop分布式文件系统(HDFS)是一种被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。它能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。要理解HDFS的内部工作原理，首先要理解什么是分布式文件系统。

1.分布式文件系统

多台计算机联网协同工作(有时也称为一个集群)就像单台系统一样解决某种问题，这样的系统我们称之为分布式系统。 分布式文件系统是分布式系统的一个子集，它们解决的问题就是数据存储。换句话说，它们是横跨在多台计算机上的存储系统。存储在分布式文件系统上的数据自动分布在不同的节点上。

分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理来自网络和其它地方的超大规模数据提供所需的扩展能力。

2.分离元数据和数据：NameNode和DataNode

存储到文件系统中的每个文件都有相关联的元数据。元数据包括了文件名、i节点(inode)数、数据块位置等，而数据则是文件的实际内容。

在传统的文件系统里，因为文件系统不会跨越多台机器，元数据和数据存储在同一台机器上。

为了构建一个分布式文件系统，让客户端在这种系统中使用简单，并且不需要知道其他客户端的活动，那么元数据需要在客户端以外维护。HDFS的设计理念是拿出一台或多台机器来保存元数据，并让剩下的机器来保存文件的内容。

NameNode和DataNode是HDFS的两个主要组件。其中，元数据存储在NameNode上，而数据存储在DataNode的集群上。NameNode不仅要管理存储在HDFS上内容的元数据，而且要记录一些事情，比如哪些节点是集群的一部分，某个文件有几份副本等。它还要决定当集群的节点宕机或者数据副本丢失的时候系统需要做什么。

存储在HDFS上的每份数据片有多份副本(replica)保存在不同的服务器上。在本质上，NameNode是HDFS的Master(主服务器)，DataNode是Slave(从服务器)。

3.HDFS写过程

NameNode负责管理存储在HDFS上所有文件的元数据，它会确认客户端的请求，并记录下文件的名字和存储这个文件的DataNode集合。它把该信息存储在内存中的文件分配表里。

例如，客户端发送一个请求给NameNode，说它要将“zhou.log”文件写入到HDFS。那么，其执行流程如图1所示。具体为： HDFS写 图1 HDFS写过程示意图

第一步：客户端发消息给NameNode，说要将“zhou.log”文件写入。(如图1中的①)

第二步：NameNode发消息给客户端，叫客户端写到DataNode A、B和D，并直接联系DataNode B。(如图1中的②)

第三步：客户端发消息给DataNode B，叫它保存一份“zhou.log”文件，并且发送一份副本给DataNode A和DataNode D。(如图1中的③)

第四步：DataNode B发消息给DataNode A，叫它保存一份“zhou.log”文件，并且发送一份副本给DataNode D。(如图1中的④)

第五步：DataNode A发消息给DataNode D，叫它保存一份“zhou.log”文件。(如图1中的⑤)

第六步：DataNode D发确认消息给DataNode A。(如图1中的⑤)

第七步：DataNode A发确认消息给DataNode B。(如图1中的④)

第八步：DataNode B发确认消息给客户端，表示写入完成。(如图1中的⑥)

在分布式文件系统的设计中，挑战之一是如何确保数据的一致性。对于HDFS来说，直到所有要保存数据的DataNodes确认它们都有文件的副本时，数据才被认为写入完成。因此，数据一致性是在写的阶段完成的。一个客户端无论选择从哪个DataNode读取，都将得到相同的数据。

4.HDFS读过程

为了理解读的过程，可以认为一个文件是由存储在DataNode上的数据块组成的。客户端查看之前写入的内容的执行流程如图2所示，具体步骤为：HDFS读写图2 HDFS读过程示意图

第一步：客户端询问NameNode它应该从哪里读取文件。(如图2中的①)

第二步：NameNode发送数据块的信息给客户端。(数据块信息包含了保存着文件副本的DataNode的IP地址，以及DataNode在本地硬盘查找数据块所需要的数据块ID。) (如图2中的②)

第三步：客户端检查数据块信息，联系相关的DataNode，请求数据块。(如图2中的③)

第四步：DataNode返回文件内容给客户端，然后关闭连接，完成读操作。(如图2中的④)

客户端并行从不同的DataNode中获取一个文件的数据块，然后联结这些数据块，拼成完整的文件。

5.通过副本快速恢复硬件故障

当一切运行正常时，DataNode会周期性发送心跳信息给NameNode(默认是每3秒钟一次)。如果NameNode在预定的时间内没有收到心跳信息(默认是10分钟)，它会认为DataNode出问题了，把它从集群中移除，并且启动一个进程去恢复数据。DataNode可能因为多种原因脱离集群，如硬件故障、主板故障、电源老化和网络故障等。

对于HDFS来说，丢失一个DataNode意味着丢失了存储在它的硬盘上的数据块的副本。假如在任意时间总有超过一个副本存在(默认3个)，故障将不会导致数据丢失。当一个硬盘故障时，HDFS会检测到存储在该硬盘的数据块的副本数量低于要求，然后主动创建需要的副本，以达到满副本数状态。

6.跨多个DataNode切分文件

在HDFS里，文件被切分成数据块，通常每个数据块64MB~128MB，然后每个数据块被写入文件系统。同一个文件的不同数据块不一定保存在相同的DataNode上。这样做的好处是，当对这些文件执行运算时，能够通过并行方式读取和处理文件的不同部分。

当客户端准备写文件到HDFS并询问NameNode应该把文件写到哪里时，NameNode会告诉客户端，那些可以写入数据块的DataNode。写完一批数据块后，客户端会回到NameNode获取新的DataNode列表，把下一批数据块写到新列表中的DataNode上。

7.HDFS数据存储单元(block)

文件被切分成固定大小的数据块

• 默认数据块大小为64MB,可配置

• 若文件大小不到64MB,则单独保存到一个block

一个文件存储方式

• 按大小切分成若干个block,存储到不同节点上

• 默认情况下每个block都有三个副本

• block大小和副本数通过Client端上传文件时设置,文件上传成功后副本数可以变更,Block Size不可以变更

二 MPP与MapReduce之争

       这些年大数据概念已经成为IT界的热门，我们经常也会在新闻和报纸中看到。大数据概念中最为关键的技术就是数据库管理系统，伴随着hadoop和MapReduce技术的流行，大数据的数据库中Hive和Spark等新型数据库脱颖而出；而另一个技术流派是基于传统的并行数据库技术演化而来的大规模并行处理（MPP）数据库比如GreenPlum和HAWQ 也在最近几年突飞猛进，这两种流派都有对应的比较知名的产品，他们都已得到了市场的认可。

       然而对于一个不是搞大数据的门外汉，如何理解大数据概念，如何根据自身的需求来选择对应的数据库管理系统，就成了很多用户很关心的话题。我们将采用比较通俗易懂的介绍，让大家从本质上认识这些大数据库管理系统的技术实现和应用场景。

MPP是一种海量数据实时分析架构，MPP作为一种不共享架构，每个节点运行自己的操作系统和数据库，节点之间信息交互只能通过网络连接实现，横向扩展是MPP数据库的主要设计目标，MPP数据库的核心仍是关系型数据库模型。

MPP和Hadoop的区别与联系

　　其实MPP架构的关系型数据库与Hadoop的理论基础是极其相似的，都是将运算分布到节点中独立运算后进行结果合并。区别仅仅在于前者跑的是SQL，后者底层处理则是MapReduce程序。MPP也支持横向扩展，但是这种扩展一般是扩到100左右，而Hadoop一般可以扩展1000+，这也是主要区别之一。 原因可以从CAP理论上解释。因为MPP始终还是DB，一定要考虑C(Consistency)，其次考虑 A(Availability)，最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的，所有数据都是以文件存储，所以优先考虑的是P，然后是A，最后再考虑C。所以后者的可扩展性当然好于前者。

　　以下几个方面制约了MPP数据库的扩展

• 高可用：MPP DB是通过Hash计算来确定数据行所在的物理机器(而Hadoop无需此操作)，对存储位置的不透明导致MPP的高可用很难办。

• 并行任务：数据是按照Hash来切分了，但是任务没有。每个任务，无论大小都要到每个节点去走一圈。

• 文件系统：数据切分了，但是文件数没有变少，每个表在每个节点上一定有一到多个文件。同样节点数越多，存储的表就越多，导致每个文件系统上有上万甚至十万多个文件。

  
  

• 网络瓶颈：MPP强调对等的网络，点对点的连接也消耗了大量的网络带宽，限制了网络上的线性扩展(想象一台机器可能要给1000台机器发送信息)。更多的节点并没有提供更高的网络带宽，反而导致每个组节点间平均带宽降低。

• 其他关系数据库的枷锁：比如锁、日志、权限、管理节点瓶颈等均限制了MPP规模的扩大。

但是MPP数据库有对SQL的完整兼容和一些事务处理功能，对于用户来说，在实际的使用场景中，如果数据扩展需求不是特别大，需要的处理节点不多，数据都是结构化数据，习惯使用传统RDBMS的很多特性的场景，可以考虑MPP如Greenplum/Gbase等。但如果有很多非结构化数据，或者数据量巨大，有需要扩展到成百上千个数据节点需求的，这个时候Hadoop是更好的选择。