hadoop安装配置实验报告
Hadoop三种模式安装配置实验报告
2.1. Hadoop分布式⽂件系统（HDFS）
Hadoop分布式⽂件系统(HDFS)被设计成适合运⾏在通⽤硬件(commodity hardware)上的分布式⽂件系统。它和现有的分布式⽂件系统有很多共同点。但同时，它和其他的分布式⽂件系统的区别也是很明显的。HDFS是⼀个⾼度容错性的系统，适合部署在廉价的机器上。HDFS能提供⾼吞吐量的数据访问，⾮常适合⼤规模数据集上的应⽤。HDFS放宽了⼀部分POSIX约束，来实现流式读取⽂件系统数据的⽬的。
2.2. 简单的⼀致性模型
HDFS应⽤需要⼀个“⼀次写⼊多次读取”的⽂件访问模型。⼀个⽂件经过创建、写⼊和关闭之后就不需要改变。这⼀假设简化了数据⼀致性问题，并且使⾼吞吐量的数据访问成为可能。Map/Reduce应⽤或者⽹络爬⾍应⽤都⾮常适合这个模型。⽬前还有计划在将来扩充这个模型，使之⽀持⽂件的附加写操作。
2.3. “移动计算⽐移动数据更划算”
⼀个应⽤请求的计算，离它操作的数据越近就越⾼效，在数据达到海量级别的时候更是如此。因为这样就能降低⽹络阻塞的影响，提⾼系统数据的吞吐量。将计算移动到数据附近，⽐之将数据移动到应⽤所在显然更好。HDFS为应⽤提供了将它们⾃⼰移动到数据附近的接⼝。
2.4. 数据复制
HDFS被设计成能够在⼀个⼤集中跨机器可靠地存储超⼤⽂件。它将每个⽂件存储成⼀系列的数据块，除了最后⼀个，所有的数据块都是同样⼤⼩的。为了容错，⽂件的所有数据块都会有副本。每个⽂件的数据块⼤⼩和副本系数都是可配置的。应⽤程序可以指定某个⽂件的副本数⽬。副本系数可以在⽂件创建的时候指定，也可以在之后改变。HDFS中的⽂件都是⼀次性写⼊的，并且严格要求在任何时候只能有⼀个写⼊者。
Namenode全权管理数据块的复制，它周期性地从集中的每个Datanode接收⼼跳信号和块状态报告(Blockreport)。接收到⼼跳信号意味着该Datanode节点⼯作正常。块状态报告包含了⼀个该Datanode上所有数据块的列表。
2.5. 副本选择
为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程
序的同⼀个机架上有⼀个副本，那么就读取该副本。如果⼀个HDFS集跨越多个数据中⼼，那么客户端也将⾸先读本地数据中⼼的副本。
2.6. ⽂件系统元数据的持久化
Namenode上保存着HDFS的名字空间。对于任何对⽂件系统元数据产⽣修改的操作，Namenode都会使⽤⼀种称为EditLog的事务⽇志记录下来。例如，在HDFS中创建⼀个⽂件，Namenode就会在Editlog中插⼊⼀条记录来表⽰；同样地，修改⽂件的副本系数也将往Editlog 插⼊⼀条记录。Namenode在本地操作系统的⽂件系统中存储这个Editlog。整个⽂件系统的名字空间，包括数据块到⽂件的映射、⽂件的属性等，都存储在⼀个称为FsImage的⽂件中，这个⽂件也是放在Namenode所在的本地⽂件系统上。
Namenode在内存中保存着整个⽂件系统的名字空间和⽂件数据块映射(Blockmap)的映像。这个关键的元数据结构设计得很紧凑，因⽽⼀个有4G内存的Namenode⾜够⽀撑⼤量的⽂件和⽬录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作⽤在内存中的FsImage上，并将这个新版本的FsImage从内存中保存到本地磁盘上，然后删除旧的Editlog，因为这个旧的Editlog的事务都已经作⽤在FsImage上了。这个过程称为⼀个检查点(checkpoint)。在当前实现中，检查点只发⽣在Namenode启动时，在不久的将来将实现⽀持周期性的检查点。
Datanode将HDFS数据以⽂件的形式存储在本地的⽂件系统中，它并不知道有关HDFS⽂件的信息。它把每个HDFS数据块存储在本地⽂件系统的⼀个单独的⽂件中。Datanode并不在同⼀个⽬录创建所有的⽂件，实际上，它⽤试探的⽅法来确定每个⽬录的最佳⽂件数⽬，并且在适当的时候创建⼦⽬录。在同⼀个⽬录中创建所有的本地⽂件并不是最优的选择，这是因为本地⽂件系统可能⽆法⾼效地在单个⽬录中⽀持⼤量的⽂件。当⼀个Datanode启动时，它会扫描本地⽂件系统，产⽣⼀个这些本地⽂件对应的所有HDFS数据块的列表，然后作为报告发送到Namenode，这个报告就是块状态报告。
2.7. 集均衡
HDFS的架构⽀持数据均衡策略。如果某个Datanode节点上的空闲空间低于特定的临界点，按照均衡策略系统就会⾃动地将数据从这个Datanode移动到其他空闲的Datanode。当对某个⽂件的请求突然增加，那么也可能启动⼀个计划创建该⽂件新的副本，并且同时重新平衡集中的其他数据。这些均衡策略⽬前还没有实现。
2.8. 数据完整性
从某个Datanode获取的数据块有可能是损坏的，损坏可能是由Datanode的存储设备错误、⽹络错误或者软件bug造成的。HDFS客户端软件实现了对HDFS⽂件内容的校验和(checksum)检查。当客户端创建⼀个新的HDFS⽂件，会计算这个⽂件每个数据块的校验和，并将校验和作为⼀个单独的隐藏⽂件
保存在同⼀个HDFS名字空间下。当客户端获取⽂件内容后，它会检验从Datanode获取的数据跟相应的校验和⽂件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该数据块的副本。
3. Hadoop进程简介
我们在启动Hadoop以后，会启动相应的Hadoop进程，可以通过在终端中输⼊：jps来查看当前进程，下⾯来详解介绍这些进程的具体含义及作⽤。
3.1. Namenode 和 Datanode
HDFS采⽤master/slave架构。⼀个HDFS集是由⼀个Namenode和⼀定数⽬的Datanodes组成。Namenode是⼀个中⼼服务器，负责管理⽂件系统的名字空间(namespace)以及客户端对⽂件的访问。集中的Datanode⼀般是⼀个节点⼀个，负责管理它所在节点上的存储。HDFS暴露了⽂件系统的名字空间，⽤户能够以⽂件的形式在上⾯存储数据。从内部看，⼀个⽂件其实被分成⼀个或多个数据块，这些块存储在⼀组Datanode上。Namenode执⾏⽂件系统的名字空间操作，⽐如打开、关闭、重命名⽂件或⽬录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理⽂件系统客户端的读写请求。在Namenode的统⼀调度下进⾏数据块的创建、删除和复制。
Namenode和Datanode被设计成可以在普通的商⽤机器上运⾏。这些机器⼀般运⾏着GNU/Linux操作系统(OS)。HDFS采⽤Java语⾔开发，因此任何⽀持Java的机器都可以部署Namenode或Datanode。由于采⽤了可移植性极强的Java语⾔，使得HDFS可以部署到多种类型的机器上。⼀个典型的部署场景是⼀台机器上只运⾏⼀个Namenode实例，⽽集中的其它机器分别运⾏⼀个Datanode实例。这种架构并不排斥在⼀台机器上运⾏多个Datanode，只不过这样的情况⽐较少见。
集中单⼀Namenode的结构⼤⼤简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者，这样，⽤户数据永远不会流过Namenode。
3.2. Secondary NameNode
NameNode将对⽂件系统的改动追加保存到本地⽂件系统上的⼀个⽇志⽂件（edits）。当⼀个NameNode启动时，它⾸先从⼀个映像⽂件（fsimage）中读取HDFS的状态，接着应⽤⽇志⽂件中的edits操作。然后它将新的HDFS状态写⼊（fsimage）中，并使⽤⼀个空的edits⽂件开始正常操作。因为NameNode只有在启动阶段才合并fsimage和edits，所以久⽽久之⽇志⽂件可能会变得⾮常庞⼤，特别是对⼤型的集。⽇志⽂件太⼤的另⼀个副作⽤是下⼀次NameNode启动会花很长时间。
Secondary NameNode定期合并fsimage和edits⽇志，将edits⽇志⽂件⼤⼩控制在⼀个限度下。因为内存需求和NameNode在⼀个数量级上，所以通常secondary NameNode和NameNode运⾏在不同的
机器上。Secondary NameNode通过bin/start-dfs.sh在
conf/masters中指定的节点上启动。
Secondary NameNode的检查点进程启动，是由两个配置参数控制的：
l fs.checkpoint.period，指定连续两次检查点的最⼤时间间隔，默认值是1⼩时。
l fs.checkpoint.size定义了edits⽇志⽂件的最⼤值，⼀旦超过这个值会导致强制执⾏检查点（即使没到检查点的最⼤时间间隔）。默认值是64MB。
Secondary NameNode保存最新检查点的⽬录与NameNode的⽬录结构相同。 所以NameNode可以在需要的时候读取Secondary NameNode上的检查点镜像。如果NameNode上除了最新的检查点以外，所有的其他的历史镜像和edits⽂件都丢失了， NameNode可以引⼊这个最新的检查点。以下操作可以实现这个功能：
l 在配置参数dfs.name.dir指定的位置建⽴⼀个空⽂件夹；
l 把检查点⽬录的位置赋值给配置参数fs.checkpoint.dir；
l 启动NameNode，并加上-importCheckpoint。
NameNode会从fs.checkpoint.dir⽬录读取检查点， 并把它保存在dfs.name.dir⽬录下。 如果dfs.name.dir⽬录下有合法的镜像⽂
件，NameNode会启动失败。 NameNode会检查fs.checkpoint.dir⽬录下镜像⽂件的⼀致性，但是不会去改动它。
3.3. JobTracker
创建⼀个InputFormat的实例，调⽤它的getSplits()⽅法，把输⼊⽬录的⽂件拆分成FileSplist作为Mapper task 的输⼊，⽣成Mapper task加⼊Queue。
3.4. TaskTracker
向JobTracker索求下⼀个Map/Reduce。Mapper Task先从InputFormat创建RecordReader，循环读⼊FileSplits的内容⽣成Key与Value，传给Mapper函数，处理完后中间结果写成SequenceFile。Reducer Task 从运⾏Mapper的TaskTracker的Jetty上使⽤http协议获取所需的中间内容（33%），Sort/Merge后（66%），执⾏Reducer函数，最后按照OutputFormat写⼊结果⽬录。 TaskTracker 每10秒向JobTracker报告⼀次运⾏情况，每完成⼀个Task10秒后，就会向JobTracker索求下⼀个Task。
4. Hadoop Map/Reduce教程
4.1. 概述
Hadoop Map/Reduce是⼀个使⽤简易的软件框架，基于它写出来的应⽤程序能够运⾏在由上千个商⽤机器组成的⼤型集上，并以⼀种可靠容错的⽅式并⾏处理上T级别的数据集。⼀个Map/Reduce 作业（job） 通常会把输⼊的数据集切分为若⼲独⽴的数据块，由 map任务（task）以完全并⾏的⽅式处理它们。框架会对map的输出先进⾏排序，然后把结果输⼊给reduce任务。通常作业的输⼊和输出都会被存储在⽂件系统中。整个框架负责任务的调度和监控，以及重新执⾏已经失败的任务。
通常Map/Reduce框架和分布式⽂件系统是运⾏在⼀组相同的节点上的，也就是说，计算节点和存储节点通常在⼀起。这种配置允许框架在那些已经存好数据的节点上⾼效地调度任务，这可以使整个集的⽹络带宽被⾮常⾼效地利⽤。
Map/Reduce框架由⼀个单独的master JobTracker 和每个集节点⼀个slave TaskTracker共同组成。master负责调度构成⼀个作业的所有任务，这些任务分布在不同的slave上，master监控它们的执⾏，重新执⾏已经失败的任务。⽽slave仅负责执⾏由master指派的任务。
应⽤程序⾄少应该指明输⼊/输出的位置（路径），并通过实现合适的接⼝或抽象类提供map和reduce函数。再加上其他作业的参数，就构成了作业配置（job configuration）。然后，Hadoop的 job client提交作业（jar包/可执⾏程序等）和配置信息给JobTracker，后者负责分发这些软件和配置信息给slav
e、调度任务并监控它们的执⾏，同时提供状态和诊断信息给job-client。
虽然Hadoop框架是⽤JavaTM实现的，但Map/Reduce应⽤程序则不⼀定要⽤ Java来写 。Hadoop Streaming是⼀种运⾏作业的实⽤⼯具，它允许⽤户创建和运⾏任何可执⾏程序 （例如：Shell⼯具）来做为mapper和reducer。Hadoop Pipes是⼀个与SWIG兼容的C++ API（没有基于JNITM技术），它也可⽤于实现Map/Reduce应⽤程序。
5. 输⼊与输出
Map/Reduce框架运转在 键值对上，也就是说，框架把作业的输⼊看为是⼀组 键值对，同样也产出⼀组 键值对做为作业的输出，这两组键值对的类型可能不同。框架需要对key和value的类(classes)进⾏序列化操作，因此，这些类需要实现 Writable接⼝。另外，为了⽅便框架执⾏排序操作，key类必须实现 WritableComparable接⼝。
shell创建文件并写入内容⼀个Map/Reduce 作业的输⼊和输出类型如下所⽰：(input) -> map -> -> combine -> -> reduce -> (output)

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。