HDFS具体内容详解
第三章 分布式文件系统HDFS
3.1 HDFS简介
HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征，为海量数据提供了不怕故障的存储。
3.2 HDFS 结构和工作机制
HDFS集群包括，NameNode和DataNode以及Secondary Namenode。
3.2.1 NameNode和SecondaryNameNode的作用
NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息，主要三个功能，分别是
(1) 管理元数据
(2) 维护目录树
(3) 响应客户请求
Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。
3.2.2 NameNode和Secondary NameNode工作机制
1.镜像文件和编辑日志文件
1）第一阶段：namenode启动
（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志(edits)和镜像文件(fsimage)到内存
（2）客户端对元数据进行增删改的请求
（3）namenode记录操作日志，更新滚动日志
（4）namenode在内存中对数据进行增删改查
2）第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
（2）Secondary NameNode请求执行checkpoint。
（3）namenode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint
（7）拷贝fsimage.chkpoint到namenode
（8）namenode将fsimage.chkpoint重新命名成fsimage
3）chkpoint检查时间参数设置
（1）通常情况下，SecondaryNameNode每隔一小时执行一次。
在hadoop的配置文件下/opt/module/hadoop-2.8.4/etc/confs路径下[hdfs-default.xml]
|
<property> <name>dfs.namenode.checkpoint.period</name> <value>3600</value> </property> |
（2）一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。
|
<property> <name>dfs.namenode.checkpoint.txns</name> <value>1000000</value> <description>操作动作次数</description> </property>
<property> <name>dfs.namenode.checkpoint.check.period</name> <value>60</value> <description> 1分钟检查一次操作次数</description> </property> |
2.镜像文件和编辑日志文件
1）概念
namenode被格式化之后，将在/opt/module/hadoop-2.8.4/data/dfs/name/current目录中产生如下文件,注只能在NameNode所在的节点才能找到此文件
可以执行find . -name edits* 来查找文件
|
edits_0000000000000000000 fsimage_0000000000000000000.md5 seen_txid VERSION |
（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。
（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。
（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字
（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。
2）oiv查看fsimage文件
（1）查看oiv和oev命令
[jareny@bigdata111 current]$ hdfs
oiv apply the offline fsimage viewer to an fsimage
oev apply the offline edits viewer to an edits file
（2）基本语法
hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径
（3）案例实操
[jareny@bigdata111 current]$ pwd
/opt/module/hadoop-2.8.4/data/dfs/name/current
[jareny@bigdata111 current]$ hdfs oiv -p XML -i fsimage_0000000000000000316 -o /opt/fsimage.xml
[jareny@bigdata111 current]$ cat /opt/module/hadoop-2.8.4/fsimage.xml
将显示的xml文件内容拷贝到IDEA中创建的xml文件中，并格式化。
3）oev查看edits文件
（1）基本语法
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
-p –processor <arg> 指定转换类型: binary (二进制格式), xml (默认，XML格式),stats
-i –inputFile <arg> 输入edits文件，如果是xml后缀，表示XML格式，其他表示二进制
-o –outputFile <arg> 输出文件，如果存在，则会覆盖
（2）案例实操
[jareny@bigdata111 current]$ hdfs oev -p XML -i edits_0000000000000000135-0000000000000000135 -o /opt/module/hadoop-2.8.4/edits.xml -p stats
[jareny@bigdata111 current]$ cat /opt/module/hadoop-2.8.4/edits.xml
每个RECORD记录了一次操作，比如图中的
OP_ADD代表添加文件操作、OP_MKDIR代表创建目录操作。里面还记录了
文件路径（PATH）
修改时间（MTIME）
添加时间（ATIME）
客户端名称（CLIENT_NAME）
客户端地址（CLIENT_MACHINE）
权限（PERMISSION_STATUS）等非常有用的信息
将显示的xml文件内容拷贝到IDEA中创建的xml文件中，并格式化。
3.滚动编辑日志
正常情况HDFS文件系统有更新操作时，就会滚动编辑日志。也可以用命令强制滚动编辑日志。
1）滚动编辑日志（前提必须启动集群）
[jareny@bigdata111 current]$ hdfs dfsadmin -rollEdits
举例：原文件名edits_inprogress_0000000000000000321
执行以下命令后
[root@bigdata111 current]# hdfs dfsadmin -rollEdits
Successfully rolled edit logs.
New segment starts at txid 323
edits_inprogress_0000000000000000321 => edits_inprogress_0000000000000000323
2）镜像文件什么时候产生
Namenode启动时加载镜像文件和编辑日志
4 .namenode版本号
1）查看namenode版本号
在/opt/module/hadoop-2.8.4/data/dfs/name/current这个目录下查看VERSION
namespaceID=1778616660
clusterID=CID-bc165781-d10a-46b2-9b6f-3beb1d988fe0
cTime=1552918200296
storageType=NAME_NODE
blockpoolID=BP-274621862-192.168.1.111-1552918200296
layoutVersion=-63
2）namenode版本号具体解释
（1） namespaceID在HDFS上，会有多个Namenode，所以不同Namenode的namespaceID是不同的，分别管理一组blockpoolID。
（2）clusterID集群id，全局唯一
（3）cTime属性标记了namenode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。
（4）storageType属性说明该存储目录包含的是namenode的数据结构。
（5）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。
（6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。
（7）storageID (存储ID)：是DataNode的ID,不唯一
5. SecondaryNameNode目录结构
Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。
在/opt/module/hadoop-2.8.4/data/dfs/namesecondary/current这个目录中查看SecondaryNameNode目录结构。
|
edits_0000000000000000001-0000000000000000002 fsimage_0000000000000000002 fsimage_0000000000000000002.md5 VERSION |
SecondaryNameNode的namesecondary/current目录和主namenode的current目录的布局相同。
好处：在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
方法一：将SecondaryNameNode中数据拷贝到namenode存储数据的目录；
方法二：使用-importCheckpoint选项启动namenode守护进程，从而将SecondaryNameNode中数据拷贝到namenode目录中。
1）案例实操（一）：
模拟namenode故障，并采用方法一，恢复namenode数据
（1）kill -9 namenode进程
（2）删除namenode存储的数据（/opt/module/hadoop-2.8.4/data/dfs/name）
rm -rf /opt/module/hadoop-2.8.4/data/dfs/name/*
注：此时hadoop-daemon.sh stop namenode关闭NN,
然后hadoop-daemon.sh start namenode重启NN,发现50070页面启动不了
（3）拷贝SecondaryNameNode中数据到原namenode存储数据目录
cp -r /opt/module/hadoop-2.8.4/data/dfs/namesecondary/* /opt/module/hadoop-2.8.4/data/dfs/name/
（4）重新启动namenode
sbin/hadoop-daemon.sh start namenode
2）案例实操（二）：
模拟namenode故障，并采用方法二，恢复namenode数据
（0）修改hdfs-site.xml中的配置，value的单位是秒，默认3600，即1小时，仅配置一台即可
|
<property> <name>dfs.namenode.checkpoint.period</name> <value>120</value> </property>
<property> <name>dfs.namenode.name.dir</name> <value>/opt/module/hadoop-2.8.4/data/dfs/name</value> </property> |
（1）kill -9 namenode进程
（2）删除namenode存储的数据（/opt/module/hadoop-2.8.4/data/dfs/name）
rm -rf /opt/module/hadoop-2.8.4/data/dfs/name/*
（3）如果SecondaryNameNode不和Namenode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到Namenode存储数据的平级目录。
|
[jareny@bigdata111 dfs]$ pwd /opt/module/hadoop-2.8.4/data/dfs [jareny@bigdata111 dfs]$ ls data name namesecondary |
（4）导入检查点数据（等待一会ctrl+c结束掉）
bin/hdfs namenode -importCheckpoint
（5）启动namenode
sbin/hadoop-daemon.sh start namenode
（6）如果提示文件锁了，可以删除in_use.lock
rm -rf /opt/module/hadoop-2.8.4/data/dfs/namesecondary/in_use.lock
6.集群安全模式操作
1）概述
Namenode启动时，首先将映像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。此时，namenode开始监听datanode请求。但是此刻，namenode运行在安全模式，即namenode的文件系统对于客户端来说是只读的。
系统中的数据块的位置并不是由namenode维护的，而是以块列表的形式存储在datanode中。在系统的正常操作期间，namenode会在内存中保留所有块位置的映射信息。在安全模式下，各个datanode会向namenode发送最新的块列表信息，namenode了解到足够多的块位置信息之后，即可高效运行文件系统。
如果满足“最小副本条件”，namenode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以namenode不会进入安全模式。
2）基本语法
集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。
（1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）
（2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）
（3）bin/hdfs dfsadmin -safemode leave （功能描述：离开安全模式状态）
（4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）
3）案例
模拟等待安全模式
1）先进入安全模式
bin/hdfs dfsadmin -safemode enter
2）执行下面的脚本
编辑一个脚本(注：必须已设置环境变量，要不就写绝对路径)
|
#!bin/bash hdfs dfsadmin -safemode wait hadoop fs -put /opt/BBB / |
3）再打开一个窗口，执行
bin/hdfs dfsadmin -safemode leave
7.Namenode多目录配置
1）namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。
2）具体配置如下：
hdfs-site.xml
|
<property> <name>dfs.namenode.name.dir</name> <value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value> </property> |
https://blog.csdn.net/qq_39657909/article/details/85553525 |
|
实验总结： 思考1：如果在非Namenode节点、进行格式化(hdfs namenode -format) 是否和在NN节点上同样会生成name1和name2目录呢？ 答：只要配置了以上得配置，在该节点下同样会生成name1和name2 具体解释： 格式化做了哪些事情？ 在NameNode节点上，有两个最重要的路径，分别被用来存储元数据信息和操作日志，而这两个路径来自于配置文件，它们对应的属性分别是dfs.name.dir和dfs.name.edits.dir，同时，它们默认的路径均是/tmp/hadoop/dfs/name。格式化时，NameNode会清空两个目录下的所有文件，之后，格式化会在目录dfs.name.dir下创建文件 hadoop.tmp.dir 这个配置，会让dfs.name.dir和dfs.name.edits.dir会让两个目录的文件生成在一个目录里
思考2：非NN上如果生成了name1和name2，那么他和NN上生成得有没有差别？ 答：有区别、NN节点上会产生新得edits_XXX，非NN不会fsimage会更新，而非NN不会，只会产生一个仅初始化得到得fsimage，不会生成edits,更不会发生日志滚动。 |
3.2.3 DataNode 的作用
作用DataNode 负责管理用户的文件数据块，每一个数据块都可以在多个datanode上存储多个副本。
1.NameNode & DataNode工作机制
1）一个数据块在datanode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。
2）DataNode启动后向namenode注册，通过后，周期性（1小时）的向namenode上报所有的块信息。
3）心跳是每3秒一次，心跳返回结果带有namenode给该datanode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个datanode的心跳，则认为该节点不可用。
4）集群运行中可以安全加入和退出一些机器
2.数据完整性
1）当DataNode读取block的时候，它会计算checksum校验和
2）如果计算后的checksum，与block创建时值不一样，说明block已经损坏。
3）client读取其他DataNode上的block.
4）datanode在其文件创建后周期验证checksum校验和
3.掉线时限参数设置
datanode进程死亡或者网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判定为死亡，要经过一段时间，这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout，则超时时长的计算公式为：
timeout = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval。
而默认的dfs.namenode.heartbeat.recheck-interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。
需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。
|
<property> <name>dfs.namenode.heartbeat.recheck-interval</name> <value>300000</value> </property> <property> <name> dfs.heartbeat.interval </name> <value>3</value> </property> |
4.DataNode的目录结构
和namenode不同的是，datanode的存储目录是初始阶段自动创建的，不需要额外格式化。
1）在/opt/module/hadoop-2.8.4/data/dfs/data/current这个目录下查看版本号
[jareny@bigdata111 current]$ cat VERSION
storageID=DS-1b998a1d-71a3-43d5-82dc-c0ff3294921b
clusterID=CID-1f2bf8d1-5ad2-4202-af1c-6713ab381175
cTime=0
datanodeUuid=970b2daf-63b8-4e17-a514-d81741392165
storageType=DATA_NODE
layoutVersion=-56
2）具体解释
（1）storageID：存储id号
（2）clusterID集群id，全局唯一
（3）cTime属性标记了datanode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。
（4）datanodeUuid：datanode的唯一识别码
（5）storageType：存储类型
（6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。
3）在/opt/module/hadoop-2.8.4/data/dfs/data/current/BP-97847618-192.168.10.102-1493726072779/current这个目录下查看该数据块的版本号
[jareny@bigdata111 current]$ cat VERSION
#Mon May 08 16:30:19 CST 2017
namespaceID=1933630176
cTime=0
blockpoolID=BP-97847618-192.168.10.102-1493726072779
layoutVersion=-56
4）具体解释
（1）namespaceID：是datanode首次访问namenode的时候从namenode处获取的storageID对每个datanode来说是唯一的（但对于单个datanode中所有存储目录来说则是相同的），namenode可用这个属性来区分不同datanode。
（2）cTime属性标记了datanode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。
（3）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。
（4）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。
5.Datanode多目录配置
1）datanode也可以配置成多个目录，每个目录存储的数据不一样。即：数据不是副本。
2）具体配置如下：
hdfs-site.xml
|
<property> <name>dfs.datanode.data.dir</name> <value>file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2</value> </property> |
3.3 HDFS 优缺点
3.1.1HDFS优点
1.支持海量数据的存储：HDFS存储的文件可以支持TB和PB级别的数据。
2.检测和快速应对硬件故障：在集群环境中，硬件故障是常见性问题，HDFS能够通过心跳机制来检测故障和自动恢复文件。
3.流式数据访问：HDFS不能做到低延迟的数据访问，但是HDFS的吞吐量大，适用于处理离线数据，不适合处理实时数据。HDFS的数据处理规模比较大，应用一次需要大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据库。主要的是数据的吞吐量，而不是访问速度。
4.简化的一致性模型：一个文件存储在HDFS上后，HDFS对文件的切块，文件的存储，节点进行管理，适合一次写入，多次读取的场景。因为存储在HDFS上的文件都是超大文件，hadoop1.X默认是64M。
5.高容错性：数据自动保存多个副本，副本丢失后自动恢复。可构建在廉价的机器上，实现线性扩展。当集群增加新节点之后，namenode也可以感知，将数据分发和备份到相应的节点上。
6.商用硬件：HDFS是设计运行在廉价硬件的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
3.1.2 HDFS缺点
1.不能做到低延迟数据访问：由于HDFS针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟数据访问，不适合HDFS。对于低延迟的访问需求，HBase是更好的选择。
2.不适合大量的小文件存储 ：由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。
3.不适合修改文件：对于上传到HDFS上的文件，不支持修改文件。Hadoop2.0虽然支持了文件的追加功能，但是还是不建议对HDFS上的文件进行修改。因为效率低下。HDFS适合一次写入，然后多次读取的场景。
4.不适合结构化数据：HDFS适合存储半结构化和非结构化数据，若有严格的结构化数据存储场景，也可以考虑采用Hbase的方案。
5.不支持用户的并行写：同一时间内，只能有一个用户执行写操作。
3. 3 HDFS应用场景
HDFS 提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序，以下是一些常用的应用场景。
1.数据密集型并行计算：数据量极大，但是计算相对简单的并行处理，如大规模Web信息搜索；
2.计算密集型并行计算：数据量相对不是很大，但是计算较为复杂的并行计算，如3D建模与渲染、气象预报和科学计算；
3.数据密集与计算密集混合型的并行计算，如3D电影的渲染。
HDFS在使用过程中有以下限制：
4.HDFS不适合大量小文件的存储，因NameNode将文件系统的元数据存放在内存中，因此存储的文件数目受限于NameNode的内存大小；
5.HDFS适用于高吞吐量，而不适合低时间延迟的访问；
6.流式读取的方式，不适合多用户写入一个文件（一个文件同时只能被一个客户端写），以及任意位置写入（不支持随机写）；
7.HDFS更加适合写入一次，读取多次的应用场景
3.4 HDFS 写入文件步骤
1.文件写入步骤
1）客户端向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。
2）namenode返回是否可以上传。
3）客户端请求第一个 block上传到哪几个datanode服务器上。
4）namenode返回3个datanode节点，分别为dn1、dn2、dn3。
5）客户端请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成
6）dn1、dn2、dn3逐级应答客户端
7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答
8）当一个block传输完成之后，客户端再次请求namenode上传第二个block的服务器。（重复执行3-7步）
2.网络拓扑概念
在本地网络中，两个节点被称为“彼此近邻”是什么意思？在海量数据处理中，其主要限制因素是节点之间数据的传输速率——带宽很稀缺。这里的想法是将两个节点间的带宽作为距离的衡量标准。
节点距离：两个节点到达最近的共同祖先的距离总和。
例如，假设有数据中心d1机架r1中的节点n1。该节点可以表示为/d1/r1/n1。利用这种标记，这里给出四种距离描述。
Distance(/d1/r1/n1, /d1/r1/n1)=0（同一节点上的进程）
Distance(/d1/r1/n1, /d1/r1/n2)=2（同一机架上的不同节点）
Distance(/d1/r1/n1, /d1/r3/n2)=4（同一数据中心不同机架上的节点）
Distance(/d1/r1/n1, /d2/r4/n2)=6（不同数据中心的节点）
大家算一算每两个节点之间的距离。
3.机架感知（副本节点选择）
1）官方ip地址：
http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/RackAwareness.html
http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#Data_Replication
2）低版本Hadoop副本节点选择
第一个副本在client所处的节点上。如果客户端在集群外，随机选一个。
第二个副本和第一个副本位于不相同机架的随机节点上。
第三个副本和第二个副本位于相同机架，节点随机。
3）Hadoop2.7.2副本节点选择
第一个副本在client所处的节点上。如果客户端在集群外，随机选一个。
第二个副本和第一个副本位于相同机架，随机节点。
第三个副本位于不同机架，随机节点。
3.5 HDFS 读取文件步骤
1）客户端向namenode请求下载文件，namenode通过查询元数据，找到文件块所在的datanode地址。
2）挑选一台datanode（就近原则，然后随机）服务器，请求读取数据。
3）datanode开始传输数据给客户端（从磁盘里面读取数据放入流，以packet为单位来做校验）。
4）客户端以packet为单位接收，先在本地缓存，然后写入目标文件。
3.5 HDFS 项目实战
3.5.1 项目1文件上传和下载
1.文件上传
|
@Test public void putFileToHDFS() throws Exception{ // 1 创建配置信息对象 // new Configuration();的时候，它就会去加载jar包中的hdfs-default.xml // 然后再加载classpath下的hdfs-site.xml Configuration configuration = new Configuration();
// 2 设置参数 // 参数优先级： 1、客户端代码中设置的值 2、classpath下的用户自定义配置文件 3、然后是服务器的默认配置 configuration.set("dfs.replication", "2");
FileSystem fs = FileSystem.get(new URI("hdfs://bigdata111:9000"),configuration, "itstar");
// 3 创建要上传文件所在的本地路径 Path src = new Path("e:/hello.txt");
// 4 创建要上传到hdfs的目标路径 Path dst = new Path("hdfs://bigdata111:9000/user/itstar/hello.txt");
// 5 拷贝文件 fs.copyFromLocalFile(src, dst); fs.close(); } |
- 文件下载
|
@Test public void getFileFromHDFS() throws Exception{
// 1 创建配置信息对象 Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://bigdata111:9000"),configuration, "itstar");
// fs.copyToLocalFile(new Path("hdfs://bigdata111:9000/user/itstar/hello.txt"), new Path("d:/hello.txt")); // boolean delSrc 指是否将原文件删除 // Path src 指要下载的文件路径 // Path dst 指将文件下载到的路径 // boolean useRawLocalFileSystem 是否开启文件效验 // 2 下载文件 fs.copyToLocalFile(false, new Path("hdfs://bigdata111:9000/user/itstar/hello.txt"), new Path("e:/hellocopy.txt"), true); fs.close(); } |
3.5.2 通过IO流操作HDFS
1.HDFS文件上传
|
@Test public void putFileToHDFS() throws Exception{ // 1 创建配置信息对象 Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://bigdata111:9000"),configuration, "itstar");
// 2 创建输入流 FileInputStream inStream = new FileInputStream(new File("e:/hello.txt"));
// 3 获取输出路径 String putFileName = "hdfs://bigdata111:9000/user/itstar/hello1.txt"; Path writePath = new Path(putFileName);
// 4 创建输出流 FSDataOutputStream outStream = fs.create(writePath);
// 5 流对接 try{ IOUtils.copyBytes(inStream, outStream, 4096, false); }catch(Exception e){ e.printStackTrace(); }finally{ IOUtils.closeStream(inStream); IOUtils.closeStream(outStream); } } |
2.HDFS文件下载
|
@Test public void getFileToHDFS() throws Exception{ // 1 创建配置信息对象 Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://bigdata111:9000"),configuration, "itstar");
// 2 获取读取文件路径 String filename = "hdfs://bigdata111:9000/user/itstar/hello1.txt";
// 3 创建读取path Path readPath = new Path(filename);
// 4 创建输入流 FSDataInputStream inStream = fs.open(readPath);
// 5 流对接输出到控制台 try{ IOUtils.copyBytes(inStream, System.out, 4096, false); }catch(Exception e){ e.printStackTrace(); }finally{ IOUtils.closeStream(inStream); } } |
3.5.3 项目3 HDFS 底层原理RPC
3.6 HDFS 的Web页面
