《Hadoop批处理技术与应用》课件-第三章 分布式文件系统HDFS

第三章分布式文件系统HDFS12Hadoop的生态体系圈HDFS的体系架构3操作HDFS4HDFS的高级功能5HDFSNameNode的联盟HDFS的底层原理6

Hadoop的生态体系圈

第三章分布式文件系统HDFS01Hadoop的生态系统第三章分布式文件系统HDFS分布式文件系统HDFS第三章分布式文件系统HDFS源自于Google的GFS论文，发表于2003年10月，HDFS是GFS克隆版。

是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。Mapreduce（分布式计算框架)第三章分布式文件系统HDFS源自于google的MapReduce论文，发表于2004年12月，HadoopMapReduce是googleMapReduce克隆版。MapReduce是一种计算模型，用以进行大数据量的计算。其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。MapReduce这样的功能划分，非常适合在大量计算机组成的分布式并行环境里进行数据处理。MapReduce计算框架发展到现在有两个版本的MapReduce的API。Page

7Yarn（资源管理框架）第三章分布式文件系统HDFSYARN（YetAnotherResourceNegotiator，另一种资源协调者）是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。YARN的基本思想是将JobTracker的两个主要功能（资源管理和作业调度/监控）分离，主要方法是创建一个全局的ResourceManager（RM）和若干个针对应用程序的ApplicationMaster（AM）。这里的应用程序是指传统的MapReduce作业或作业的DAG（有向无环图）。该框架是hadoop2.x以后对hadoop1.x之前JobTracker和TaskTracker模型的优化，而产生出来的，将JobTracker的资源分配和作业调度及监督分开。该框架主要有ResourceManager，Applicationmatser，nodemanager。Page

8Sqoop（数据同步工具）第三章分布式文件系统HDFSSqoop是SQL-to-Hadoop的缩写，主要用于传统数据库和Hadoop之间传输数据。数据的导入和导出本质上是Mapreduce程序，充分利用了MR的并行化和容错性。其中主要利用的是MP中的Map任务来实现并行导入，导出。Sqoop发展到现在已经出现了两个版本，一个是sqoop1.x.x系列，一个是sqoop1.99.X系列。对于sqoop1系列中，主要是通过命令行的方式来操作。Mahout（数据挖掘算法库）第三章分布式文件系统HDFSMahout起源于2008年，最初是ApacheLucent的子项目，它在极短的时间内取得了长足的发展，现在是Apache的顶级项目。相对于传统的MapReduce编程方式来实现机器学习的算法时，往往需要话费大量的开发时间，并且周期较长，而Mahout的主要目标是创建一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。HBase（分布式列存数据库）第三章分布式文件系统HDFS源自Google的Bigtable论文，发表于2006年11月，传统的关系型数据库是对面向行的数据库。HBase是GoogleBigtable克隆版，HBase是一个针对结构化数据的可伸缩、高可靠、高性能、分布式和面向列的动态模式数据库。和传统关系数据库不同，HBase采用了BigTable的数据模型：增强的稀疏排序映射表（Key/Value），其中，键由行关键字、列关键字和时间戳构成。HBase提供了对大规模数据的随机、实时读写访问，同时，HBase中保存的数据可以使用MapReduce来处理，它将数据存储和并行计算完美地结合在一起。Zookeeper（分布式协作服务）第三章分布式文件系统HDFS源自Google的Chubby论文，发表于2006年11月，Zookeeper是Chubby克隆版，主要解决分布式环境下的数据管理问题：统一命名，状态同步，集群管理，配置同步等。Pig第三章分布式文件系统HDFS由yahoo!开源，设计动机是提供一种基于MapReduce的ad-hoc(计算在query时发生)数据分析工具。定义了一种数据流语言—PigLatin，将脚本转换为MapReduce任务在Hadoop上执行。通常用于进行离线分析。Hive（基于Hadoop的数据仓库）第三章分布式文件系统HDFS由facebook开源，最初用于解决海量结构化的日志数据统计问题。Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行。通常用于离线分析。Flume（日志收集工具）第三章分布式文件系统HDFSCloudera开源的日志收集系统，具有分布式、高可靠、高容错、易于定制和扩展的特点。它将数据从产生、传输、处理并最终写入目标的路径的过程抽象为数据流，在具体的数据流中，数据源支持在Flume中定制数据发送方，从而支持收集各种不同协议数据。同时，Flume数据流提供对日志数据进行简单处理的能力，如过滤、格式转换等。此外，Flume还具有能够将日志写往各种数据目标（可定制）的能力。总的来说，Flume是一个可扩展、适合复杂环境的海量日志收集系统。Oozie第三章分布式文件系统HDFS在Hadoop中执行的任务有时候需要把多个Map/Reduce作业连接到一起，这样才能够达到目的。在Hadoop生态圈中，有一种相对比较新的组件叫做Oozie，它让我们可以把多个Map/Reduce作业组合到一个逻辑工作单元中，从而完成更大型的任务。

HDFS的体系架构

第三章分布式文件系统HDFS02HDFS的总体架构第三章分布式文件系统HDFS

NameNode第三章分布式文件系统HDFS维护HDFS文件系统，是HDFS的主节点。接受客户端的请求:上传文件、下载文件、创建目录等等记录客户端操作的日志（edits文件），保存了HDFS最新的状态维护文件元信息，将内存中不常用（采用LRU算法）的文件元信息保存在硬盘上（fsimage文件）DataNode第三章分布式文件系统HDFS以数据块为单位，保存数据在全分布模式下，至少两个DataNode节点数据保存的目录：由hadoop.tmp.dir参数指定SecondaryNameNode第三章分布式文件系统HDFS主要作用是进行日志合并

数据上传的过程第三章分布式文件系统HDFSHDFS数据上传的过程第三章分布式文件系统HDFS首先用户即客户端想要上传文件，就先要给namenode发个请求，告诉它说我要上传文件了（即写数据），然后namenode会返回一个响应，这个响应是namenode根据自身情况，比如会先查一下namenode里面还能存数据吗？能存多少？有几个datanode能存？（心跳信息）然后返回一个可以存储的节点列表，意思是这些里面能存，但不是能存的datanode全部返回，它会根据上传文件的大小来适当的返回，客户端收到这个列表后，就向根据返回的列表里面的datanode中写数据，文件会分为多个块（block），写的过程是以流的方式写入的，一个块存入一个DataNode，存完后DataNode就会备份，我们默认的备份数是3，存完后，会告诉namenode说我存完了。这样就结束了hdfs文件上传的流程。数据下载的过程第三章分布式文件系统HDFS

HDFS数据下载的过程第三章分布式文件系统HDFS客户端向namenode请求下载文件，namenode通过查询元数据，找到文件块所在的datanode地址。挑选一台datanode（就近原则，然后随机）服务器，请求读取数据。datanode开始传输数据给客户端（从磁盘里面读取数据放入流，以packet为单位来做校验）。客户端以packet为单位接收，先在本地缓存，然后写入目标文件。

操作HDFS

第三章分布式文件系统HDFS03命令行操作HDFS第三章分布式文件系统HDFSJavaAPI操作HDFS第三章分布式文件系统HDFS通过HDFS提供的JavaAPI，我们可以完成以下的功能：在HDFS上创建目录通过FileSystemAPI读取数据（下载文件）写入数据（上传文件）查看目录及文件信息查找某个文件在HDFS集群的位置删除数据获取HDFS集群上所有数据节点信息

JavaAPI操作HDFS示例第三章分布式文件系统HDFS在HDFS上创建目录JavaAPI操作HDFS示例第三章分布式文件系统HDFS通过FileSystemAPI读取数据（下载文件）JavaAPI操作HDFS示例第三章分布式文件系统HDFS写入数据（上传文件）JavaAPI操作HDFS示例第三章分布式文件系统HDFS查看目录及文件信息

JavaAPI操作HDFS示例第三章分布式文件系统HDFS查找某个文件在HDFS集群的位置JavaAPI操作HDFS示例第三章分布式文件系统HDFS删除数据JavaAPI操作HDFS示例第三章分布式文件系统HDFS获取HDFS集群上所有数据节点信息通过WebConsole访问HDFS第三章分布式文件系统HDFSNameNode的WebConsole端口：50070通过WebConsole访问HDFS第三章分布式文件系统HDFSSecondaryNameNode的WebConsole端口：50090

HDFS的高级特性

第三章分布式文件系统HDFS04回收站第三章分布式文件系统HDFS回收站里的文件可以快速恢复可以设置一个时间阈值，当回收站里文件的存放时间超过返个阈值，就被彻底删除，并且释放占用的数据块默认回收站是关闭的，可以通过在core-site.xml中添加erval来打开幵配置时间阀值，例如回收站的基本操作第三章分布式文件系统HDFS查看回收站hdfsdfs-lsr/user/root/.Trash/Current从回收站中恢复hdfsdfs-cp/user/root/.Trash/Current/input/data.txt/input快照第三章分布式文件系统HDFS一个snapshot(快照)是一个全部文件系统、或者某个目录在某一时刻的镜像快照应用在以下场景中：防止用户的错误操作备份试验/测试灾难恢复Page

41快照的基本操作第三章分布式文件系统HDFS开启快照 hdfsdfsadmin-allowSnapshot/input创建快照 hdfsdfs-createSnapshot/inputbackup_input_01查看快照 hdfslsSnapshottableDir对比快照 hdfssnapshotDiff/inputbackup_input_01backup_input_02恢复快照 hdfsdfs-cp/input/.snapshot/backup_input_01/data.txt/inputPage

42配额的管理第三章分布式文件系统HDFS什么是配额？配额就是HDFS为每个目录分配的大小空间，新建立的目录是没有配额的，最大的配额是Long.Max_Value。配额为1可以强制目录保持为空。配额的类型名称配额用于设置该目录中能够存放的最多文件（目录）个数。空间配额用于设置该目录中最大能够存放的文件大小。名称配额的操作第三章分布式文件系统HDFS命令：dfsadmin-setQuota<N><directory>...<directory>dfsadmin-clrQuota<directory>...<directory>示例：设置/input目录的名称配额为3hdfsdfsadmin-setQuota3/input清除/input目录的名称配额hdfsdfsadmin-clrQuota/input空间配额的操作第三章分布式文件系统HDFS命令：dfsadmin-setSpaceQuota<quota><dirname>...<dirname>dfsadmin-clrSpaceQuota<dirname>...<dirname>示例：设置/input目录的空间配额为1Mhdfsdfsadmin-setSpaceQuota1048576/input清除input目录的空间配额hdfsdfsadmin-clrSpaceQuota/input安全模式第三章分布式文件系统HDFS安全模式是hadoop的一种保护机制，用于保证集群中的数据块的安全性。如果HDFS处于安全模式，则表示HDFS是只读状态。当集群启动的时候，会首先进入安全模式。当系统处于安全模式时会检查数据块的完整性。假设我们设置的副本数（即参数dfs.replication）是5，那么在datanode上就应该有5个副本存在，假设只存在3个副本，那么比例就是3/5=0.6我们的副本率0.6明显小于0.99，因此系统会自动的复制副本到其他的dataNode,使得副本率不小于0.999.如果系统中有8个副本，超过我们设定的5个副本，那么系统也会删除多余的3个副本

HDFSNameNode联盟

第三章分布式文件系统HDFS05什么是HDFSNameNode的联盟？第三章分布式文件系统HDFSHDFSFederation使用了多个独立的Namenode/namespace来使得HDFS的命名服务能够水平扩展。在HDFSFederation中的Namenode之间是联盟关系，他们之间相互独立且不需要相互协调。HDFSFederation中的Namenode提供了提供了命名空间和块管理功能。HDFSFederation中的datanode被所有的Namenode用作公共存储块的地方。每一个datanode都会向所在集群中所有的Namenode注册，并且会周期性的发送心跳和块信息报告，同时处理来自Namenode的指令。为什么要引入HDFSNameNode的联盟？第三章分布式文件系统HDFS引入Federation的最主要原因是简单，其简单性是与真正的分布式Namenode相比而言的。Federation能够快速的解决了大部分单NamenodeHDFS的问题。Federation是简单鲁棒的设计，由于联盟中各个Namenode之间是相互独立的。Federation整个核心设计实现大概用了3.5个月。大部分改变是在Datanode、Config和Tools，而Namenode本身的改动非常少，这样Namenode原先的鲁棒性不会受到影响。比分布