Hadoop系统架构Word格式.docx
《Hadoop系统架构Word格式.docx》由会员分享，可在线阅读，更多相关《Hadoop系统架构Word格式.docx（20页珍藏版）》请在冰点文库上搜索。
商业存储服务的不足有以下几点：
首先是文件数量太大，网络存储设备无法支撑，连接存储系统的服务器越来越多，网络连接数已经达到了网络存储设备的极限。
其次是商用存储系统不能根据企业特定的业务进行存储和读取优化，导致面对大规模的小文件存储与读取，磁盘磁头需要频繁的寻道和换道，造成读取上的延迟。
再加上高并发访问量的背景，系统很容易出现问题。
最后是花费问题，商业存储系统扩容成本太高，10T的存储容量需要几百万人民币。
在面临海量存储需求的时候，高成本并没有带来高效率，高可靠性，高容错性。
况且，过分依赖商业系统在维护性、创造性上受到商业公司约束，难以满足互联网企业的飞速发展。
云计算的出现带动了技术发展朝向一个新的方向。
它创造性的根据分布式处理、并行处理和网格计算的发展，提出了新的分布式集群技术。
云存储概是在云计算概念上延伸和发展出来的一个新的概念，是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。
当云计算系统运算和处理的核心是大量数据的存储和管理时，云计算系统中就需要配置大量的存储设备，那么云计算系统就转变成为一个云存储系统，所以云存储是一个以数据存储和管理为核心的云计算系统。
云存储的概念改变了存储领域，可以尝试以相对廉价的存储设备部署在云端作为存储服务器，利用分布式文件系统统一管理，对外提供存储和业务访问接口。
由云端提供存储服务，达到业务与存储的解稱合，不仅能根据不同业务背景设定不同的存储、访问接口，优化存取服务，还能将容灾和安全性固定在云端，此外，由于采用分布式文件系统，云端服务器扩展相对容易。
二、Hadoop云计算系统
Hadoop是一个分布式系统基础架构，由Apache基金会开发。
作为Google一系列产品的幵源实现，是一个更容易开发和运行处理大规模数据的软件平台。
Hadoop中包含一系列相关的子项目，这些项目都隶属于Apache软件基金会。
最著名的是并行计算模型（MapReduce）和分布式文件系统（HDFS），其他的子系统提供了一些附加功能，或者在core上增加了一些高级的抽象。
Core：
分布式系统和通用I/O组件和接口，支持序列化、Java远程过程调用等等。
Avro：
支持跨语言过程调用，持久数据存储的数据序列化系统。
MapReduce：
构建在廉价的PC机器上的分布式数据处理模型和运行环境。
HDFS：
构建在廉价的PC机器上的分布式文件系统。
Pig：
处理海量数据集的数据流语言和运行环境。
pig运行在HDFS和MapReduce之上。
HBase：
面向列的分布式数据库。
HBase使用HDFS作为底层存储，同时使用MapReduce支持批处理模式的计算和随机查询。
ZooKeeper：
提供分布式、高效的协作服务。
ZooKeeper提供分布式锁这样的原子操作，可以用来构建分布式应用。
Hive：
分布式数据仓库，Hive使用HDFS存储数据，提供类似SQL的语言（转换为MapReduce任务）查询数据。
Chukwa：
分布式数据采集和分析系统。
使用HDFS存储数据，使用Mapreduce输出分析报告。
三、分布式文件系统（HDFS）
Hadoop分布式文件系统HDFS被设计成稳定的存储海量数据，并且适合运行在普通硬件上的分布式文件系统。
HDFS能提供高吞吐量的数据访问性能，给用户的应用提供更高的带宽，非常适合海量数据集上的应用。
它运行于廉价的普通硬件之上，但是可以提供可靠性、稳定的容错功能。
面对海量数据和大量用户仍然可以提供高质量的服务，具有优秀的并发处理的能力。
3.1HDFS的特点
（1）HDFS认为硬件错误是一种正常的现象。
HDFS由成百上千的普通硬件构成的服务器所组成，其中每个服务器上都存储着文件系维的数据块。
HDFS文件系统非常庞大，其中的任何一个服务器都可能出现故障，这些服务器就会处于故障状态，从而导致系统的一部分数据丢失，而且有一部分机器损坏之后可能无法恢复到正常工作状态。
所以及时的检查、错误检测、数据备份容错、自动恢复是HDFS分布式文件系统非常重要的功能。
HDFS分布式文件系统通过自己的检测协议定时自动监控系统全部机器的状态，一旦检测到机器故障等问题，能够迅速地检测，定位、冗余并恢复这些故障机器上的数据。
基于以上设计的HDFS就具有错误检测和快速、自动恢复数据的功能。
（2）在HDFS上运行的应用需要以流式访问它们的数据集。
HDFS具有很好的数据批处理能力。
HDFS更注重用于数据访问的高吞吐量，而对于数据访问的延迟和响应时间要求不做很严格处理。
（3）HDFS上的应用一般都是处理海量数据集的程序。
HDFS上的文件大小一般都在GB至TB的大小。
HDFS可以非常好的支持大文件存储。
通过利用分布式集群HDFS能提供非常高的数据传输带宽，HDFS集群可以扩展到数百个节点。
同时一个HDFS文件系统可以支撑数以千万计的文件。
HDFS分布式文件系统可以处理快速增长的、包含数以万计的对象、长度达TB的数据集，也可以管理成千上万的KB规模的文件块。
（4）HDFS采用一次写入多次读取的方式。
在HDFS系统中一个文件经过创建、写入和关闭之后就不允许再去修改这个文件，简化了数据一致性问题，实现了高吞吐量访问数据的能力。
一般情况下，每次写入的数据的大小和大规模读取的模型基本一样，数据一旦被写入后，文件就不允许被修改了。
同时系统也支持小规模的随机位置写入操作。
MapReduce应用和网络爬虫应用是适应这个模型的最好应用说明。
（5）通常应用请求的计算的数据附近化是最高效的，处理海量数据的时候做到计算和数据距离最近可以得到最高的处理效率。
所以HDFS具有计算程序优先选择距离最近的数据的策略。
如果遇到网络阻塞将对计算程序访问数据的速度产生影响，采用附近化策略可以避免这种情况，同时可以提高系统整体处理数据的吞吐量。
把计算程序放到数据附近比把数据移动到计算的附近更高效。
HDFS为提供了把应用程序移动到数据附近的接口。
（6）HDFS具有非常好的平台可移植性。
HDFS使用JAVA开发，JAVA本身就具有跨平台的特性。
HDFS的可移植性推动它在大规模数据应用领域上的应用。
同时HDFS提供其他语言的接口，方便用户使用。
HDFS分布式文件系统的以上特点可以充分保证数据的可靠性、安全性，保证系统的多并发和高速处理海量数据的能力，同时基于以上的策略，HDFS分布式文件系统可以保证数据的一致性和自动修复，保证海量数据的安全和具有很好的存储性能。
3.2HDFS系统架构
HDFS采用Master/Slave的主从结构。
一个HDFS集群是由一个主控节点（Namenode）和一定数量的数据节点（Datanode）组成的，如图1所示。
主控节点是一个中心服务器，是整个文件系统的大脑，它负责管理文件系统的命名空间（Namespace）和客户端对文件的访问。
数据节点在集群中一般是一个节点对应一台服务器，负责管理节点上它们所附带的存储。
在内部，一个文件其实分成一个或多个数据块，这些块存储在数据节点集合中。
主控节点执行文件系统的命名空间操作，例如打开、关闭、重命名文件和目录，同时决定数据块到具体数据节点的映射。
数据节点在主控节点的指挥下进行块的创建、删除和复制。
主控节点和数据节点都是被设计成可以运行在普通的廉价的运行Linux的机器上。
HDFS采用Java语言开发，因此可以部署在很大范围的机器上。
一个典型的部署场景是一台机器跑一个单独的主控节点，集群中的其他机器各跑一个数据节点实例。
单一主控节点大大简化了系统的架构。
主控节点负责管理所有的HDFS元数据，客户端传输文件数据时就不需要通过主控节点，而是直接与数据节点建立连接。
图1HDFS系统架构
3.2.1HDFS的数据分布
一个文件系统中，最重要的数据，其实就是整个文件系统的目录结构和具体每个文件的数据。
具体的文件数据被切分成数据块，存放在数据服务器上。
每一个文件数据块，在数据服务器上都表征为一对文件（普通的Linux文件），一个是数据文件，一个是附加信息的元数据文件，我们把这对文件简称为数据块文件。
数据块文件存放在数据目录下，它有一个名为current的根目录，然后里面有若干个数据块文件和从dir0-dir63的最多64个的子目录，子目录内部结构等同于current目录，依次类推。
相比数据服务器，主控服务器的数据量不大，但逻辑非常复杂。
主控服务器主要有三类数据：
文件系统的目录结构数据，各个文件的分块信息，数据块的位置信息（就数据块放置在哪些数据服务器上）。
在HDFS架构中，只有文件的目录结构和分块信息才会被持久化到本地磁盘上，而数据块的位置信息则是通过动态汇总过来的，仅仅存活在内存数据结构中，机器挂了，就灰飞烟灭了。
每一个数据服务器启动后，都会向主控服务器发送注册消息，将其上数据块的状况都告知于主控服务器。
3.2.2HDFS的数据组织
兼容HDFS的应用都是处理大数据集合的。
这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。
HDFS支持文件的一次写入多次读取（write-once-read-many）语义。
一个典型的数据块（block）大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的数据节点。
某个客户端创建文件的请求其实并没有立即发给主控节点，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。
应用的写被透明地重定向到这个临时文件。
当这个临时文件累积的数据超过一个block的大小（默认64M），客户端才会联系主控节点。
主控节点将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后返回数据节点的标识符和目标数据块给客户端。
客户端将本地临时文件flush到指定的数据节点上。
当文件关闭时，在临时文件中剩余的没有flush的数据也会传输到指定的数据节点，然后客户端告诉主控节点文件已经关闭。
此时主控节点才将文件创建操作提交到持久存储。
如果主控节点在文件关闭前挂了，该文件将丢失。
3.2.3HDFS的数据复制
HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。
它将每个文件存储成block序列，除了最后一个block，所有的block都是同样的大小。
文件的所有block为了容错都会被复制。
每个文件的block大小和复制因子（replication）都是可配置的。
复制因子可以在文件创建的时候配置，以后也可以改变。
HDFS中的文件是一次写入（write-one），并且严格要求在任何时候只有一个writer。
主控节点全权管理block的复制，它周期性地从集群中的每个数据节点接收心跳包和一个数据块报告（Blockreport）。
心跳包的接收表示该数据节点正常工作，而块报告包括了该数据节点上所有数据块组成的列表。
图2HDFS的数据复制
3.2.4HDFS的通信协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。
客户端通过一个可配置的端口连接到主控节点，通过客户端协议（ClientProtocol）与主控节点交互。
而数据节点是使用数据节点协议（DatanodeProtocol）与主控节点交互。
从ClientProtocol和Datanodeprotocol抽象出一个远程调用（RPC），在设计上，主控节点不会主动发起RPC，而是响应来自客户端和数据节点的RPC请求。
如图3所示：
图3HDFS的通信协议
3.3HDFS的初始化与数据存取过程
3.3.1HDFS的启动过程
HDFS集群中，一般只有主控节点和数据节点两种节点，所以HDFS的启动就是数据节点和主控节点的启动。
HDFS启动过程：
首先是主控节点最先启动，主控节点必须在所有数据节点之前启动，而且在主控节点启动之后，数据节点也不会马上就启动，数据节点需要在主控节点完成必要的操作之后才开始启动。
主控节点和数据节点的启动过程如图4所示。
图4HDFS启动过程
主控节点启动时会先创建Server，Server是RFC服务器端的实现，主要负责和客户端通信，并对远程调用中的参数和返回值进行反序列化和序列化。
主控节点真正负责执行远程方法。
FSNamesystem保存了全部的关于文件系统的元数据信息和操作日志，操作日志负责数据的持久化来保证系统的可恢复性。
然后再创建FSNamesystem，主控节点在创建FSNamesystem的同时会把元数据信息加载到内存里，由于加载元数据到内存非常耗费时间，所以主控节点启动之后，其它的数据节点不能马上启动，需要等到主控节点加载完元数据之后的某个时机开始启动。
加载完成后，主控节点开启Server的远程调用服务。
在这之后主控节点会进入安全模式，安全模式下主控节点不接受任何数据的写入和读取，即不为客户端提供任何服务。
然后主控节点开始等待数据节点的注册和通信，数据节点此时上报数据块的Block信息以及自己本身的一些状态信息，这些信息为以后的存储策略服务。
当在一定的时间间隔之后没有收到数据节点新的注册，主控节点就认为集群中没有其它没有注册的数据节点了，主控节点就会离开安全模式进入正常模式为客户端服务。
在主控节点启动的过程中主要是自身的初始化和数据节点的注册，此时数据节点需要向主控节点汇报自身的一些状态信息，这些信息为数据存储策略服务。
数据节点的启动的时间必须要在主控节点启动之后，主控节点RPC的Server服务开启之后，数据节点才能开始启动。
数据节点主要有DataStorage、Server、DataXceiverServer、DataNodeProtocol四个服务组件，其中Datastorage保存数据块信息，DataNodeProtocol负责调用主控节点的服务，DataXceiverServer负责客户端和数据节点之间的数据传输，数据节点的Server负责为客户端和其它数据节点提供服务。
HDFS集群启动时，每个数据节点都要向主控节点发送注册的请求，在请求通过后才可以加入HDFS集群中。
数据节点调用DatanodeProtocol协议向主控节点进行注册，数据节点向主控节点注册有两个目的：
首先是通告主控节点其提供的服务的网络地址端口，其次是获取数据节点对其的管理与控制。
每一个客户端无需获取集群中所有的数据节点的服务地址，主控节点会记录所有的数据节点信息。
客户端通过主控节点来获取需要访问的数据节点的信息即可。
主控节点记录所有的数据节点汇报的状态信息，根据数据节点的状态信息调整集群的负载均衡与任务的合理安排和调度。
在HDFS启动过程中，数据节点需要向控制节点汇报状态信息，这些信息包括磁盘容量，块状态等信息。
数据节点的状态信息需要定时和控制节点汇报。
这些信息是通过一种叫做心跳协议的方式从数据节点汇报给控制节点的，心跳协议能够及时的汇报每个数据节点的状态信息，通过设计优化的心跳协议可以向控制节点汇报更多的状态信息。
通过汇报的状态信息，可以为节点选择策略提供更多依据，基于更多的依据就可以更加准确的判断一个节点的负载，可以保证选择的节点是比较空闲的数据节点。
3.3.2HDFS的数据存取过程
客户端访问HDFS一般都是通过调用Hadoop提供的API实现的，而底层数据操作的过程对客户端是透明的。
下面分别从数据读取和写入两方面介绍对HDFS数据操作进行剖析。
（1）HDFS文件读取剖析
客户端读取HDFS中数据的流程如图5所示：
图5HDFS数据读取流程图
客户端通过调用FileSystem对象的open（）方法来打开希望读取的文件（步骤1），对于HDFS来说，这个对象是分布式文件系统的一个实例。
DistributedFileSystem对象通过RPC来调用控制节点，以确定文件起始块的位置（步骤2）。
对于每一个块，控制节点返回存有该块复本的数据节点地址。
此外，这些数据节点根据它们与客户端的距离来排序（根据集群的网络拓扑）。
如果该客户端本身就是一个数据节点（比如在一个MapReduce任务中），并保存有相应数据块的一个复本时，该节点将从本地数据节点中读取数据。
DistributedFileSystem对象返回一个FSDataInputStream对象（一个支持文件定位的输入流）给客户端并读取数据。
FSDataInputStream类中封装了DFSInputStream对象，该对象管理着数据节点和控制节点的I/O操作。
接着，客户端对这个输入流调用read（）方法（步骤3）。
存储着文件起始块的数据节点地址的DFSInputStream随即连接距离最近的数据节点。
通过对数据流反复调用read（）方法，即可将数据从数据节点传输到客户端（步骤4），达到块的末端时，DFSInputStream会关闭与该数据节点的连接，然后寻找下一个块的最佳数据节点（步骤5）。
客户端只需要读取连续的流，上面这些对于客户端都是透明的。
客户端从流中读取数据时，块是按照打开DFSInputStream与数据节点新建连接的顺序读取的。
它也需要询问控制节点来检索下一批所需块的数据节点的位置。
一旦客户端完成读取，就对FSDataInputStream调用close（）方法（步骤6）。
在读取数据的时候，如果DFSInputStream在与数据节点通信时遇到错误，它便会尝试从这个块的另外一个最邻近的数据节点读取数据。
它也会记住那个出现故障的数据节点，以保证以后不会反复读取该节点上后续的块。
DFSInputStream也会通过校验和确认从数据节点发来的数据是否完整。
如果发现一个损坏的块，它就会在DFSInputStream试图从其他数据节点中读取一个块的复本之前通知控制节点。
（2）HDFS文件写入剖析
客户端将数据写入到HDFS的流程如图6所示：
图6HDFS数据写入流程图
客户端通过DistributedFileSystem对象调用create（）方法来创建文件（步骤1），DistributedFileSystem对控制节点创建一个RPC调用，在文件系统的命名空间中创建一个新文件，此时文件中还没有相应的数据块（步骤2）。
控制节点执行各种不同的检查以确保这个文件不存在，并且客户端有创建该文件的权限。
如果这些检查均通过，控制节点就会为创建新文件增加一条记录；
否则文件创建失败并向客户端抛出一个IOException异常。
DistributedFileSystem向客户端返回一个FSDataOutputStream对象，客户端通过此对象便可以写入数据。
与读取数据类似，FSDataOutputStream中封装着一个DFSOutputStream对象，该对象负责处理与数据节点和控制节点之间的通信。
在客户端写入数据时（步骤3），DFSOutputStream将需要写入的数据分成一个个的数据包，并写入内部队列（也称为数据队列-dataqueue）。
DataStreamer负责处理数据队列，他的责任是根据数据节点列表来要求控制节点分配合适的新块存储数据备份。
这一组数据节点构成一个管线（假设复本数为3），所以管线中有3个节点。
DataStreamer将数据包流式传输到管线中的第1个数据节点，该数据节点存储收到的数据包并将它发送到管线中的第2个数据节点。
同样第2个数据节点也存储该数据包并且发送给管线中的第3个数据节点（步骤4）。
DFSOutputStream也维护着一个内部数据包队列来等待数据节点的收到确认回执，称为“确认队列”（ackqueue）。
当收到管线中所有数据节点的确认信息后，该数据包才会从确认队列中移除（步骤5）。
如果在数据写入期间数据节点发生故障，则执行以下操作，这对于写入数据的客户端是透明的。
首先关闭管线，确认把队列中的任何数据包都添加回数据队列的最前端，以确保故障节点下游的数据节点不会漏掉任何一个数据包。
为存储在另一个正常数据节点的当前数据块指定一个新的标识，并将该标识传送给控制节点，以便故障数据节点在恢复后可以删除存储的部分数据块。
从管线中删除故障数据节点并且把余下的数据块写入到管线中两个正常的数据节点。
控制节点注意到块复本量不足时，会在另一个节点上创建一个新的复本。
后续的数据块继续正常接收处理。
客户端完成数据的写入后，会对数据流调用close（）方法（步骤6），该操作将剩余的所有数据包写入到数据节点管线中，并向控制节点发送文件写入完成的信号消息，等待确认。
控制节点已经知道文件由那些块组成（通过DataStreamer获取数据块的分配信息），所以它在返回成功之前只需要等待数据块进行最小量的复制。
四、并行计算模型（MapReduce）
4.1MapReduce系统架构
与HDFS类似，Hadoop的MapReduce集群也由三类服务器构成。
其中作业服务器，在Hadoop中称为JobTracker。
作业服务器负责管理运行在此框架下所有作业，同时它也是为各个作业分配任务的核心。
与HDFS的主控服务器NameNode类似，它也是作为单点存在的，简化了负责同步的流程。
具体负责执行用户定义操作的是任务服务器TaskTracker，每一个作业被拆分成很多个任务，包括Map任务和Reduce任务等，任务是具体的执行单元，它们都需要分配到合适
升级会员 