2. HDFS
总的设计思想:设计目标:提高分布式并发处理数据的效率(提高并发度和移动运算到数据)
分而治之:将大文件、大批量文件,分布式存放在大量独立的服务器上,以便于采取分而治之的方式对海量数据进行运算分析;
重点概念:文件切块,副本存放,元数据,位置查询,数据读写流
2.1 hdfs的shell操作
hadoop fs -操作命令 -参数-ls #显示目录信息
-->hadoop fs -ls hdfs://hadoop-server-00:9000/
这些参数中,所有的hdfs路径都可以简写
-->hadoop fs -ls / 等同于上一条命令的效果
-copyFromLocal #从本地文件系统中拷贝文件到hdfs路径去
-->hadoop fs -copyFromLocal ./jdk.tar.gz /aaa/
-copyToLocal #从hdfs拷贝到本地
-->hadoop fs -copyToLocal /aaa/jdk.tar.gz
-put #等同于copyFromLocal
-get #等同于copyToLocal,就是从hdfs下载文件到本地
-getmerge #合并下载多个文件
--> 比如hdfs的目录 /aaa/下有多个文件:log.1, log.2,log.3,...
hadoop fs -getmerge /aaa/log.* ./log.sum
-moveFromLocal #从本地移动到hdfs
-moveToLocal #从hdfs移动到本地
-cp #从hdfs的一个路径拷贝hdfs的另一个路径
-->hadoop fs -cp /aaa/jdk.tar.gz /bbb/jdk.tar.gz.2
-mv #在hdfs目录中移动文件
-mkdir #在hdfs上创建目录
-->hadoop fs -mkdir -p /aaa/bbb/cc/dd
-rm #删除文件或文件夹
--> hadoop fs -rm -r /aaa/bbb/
-rmdir #删除空目录
-cat ---显示文件内容
-->hadoop fs -cat /hello.txt
--appendToFile ----追加一个文件到已经存在的文件末尾
-->hadoop fs -appendToFile ./hello.txt hdfs://hadoop-server01:9000/hello.txt
可以简写为:
Hadoop fs -appendToFile ./hello.txt /hello.txt
-chgrp
-chmod
-chown
上面三个跟linux中的用法一样
-->hadoop fs -chmod 666 /hello.txt
-count #统计一个指定目录下的文件节点数量
-->hadoop fs -count /aaa/
-createSnapshot
-deleteSnapshot
-renameSnapshot
以上三个用来操作hdfs文件系统目录信息快照
-->hadoop fs -createSnapshot /
-df #统计文件系统的可用空间信息
-du
-->hadoop fs -df -h /
-->hadoop fs -du -s -h /aaa/*
-help #输出这个命令参数手册
-setrep #设置hdfs中文件的副本数量
-->hadoop fs -setrep 3 /aaa/jdk.tar.gz
-stat #显示一个文件或文件夹的元信息
-tail #显示一个文件的末尾
-text #以字符形式打印一个文件的内容
2.2 HDFS的一些concept(概念)和特性
首先,它是一个文件系统,有一个统一的命名空间——目录树, 客户端访问hdfs文件时就是通过指定这个目录树中的路径来进行其次,它是分布式的,由很多服务器联合起来实现功能;
hdfs文件系统会给客户端提供一个统一的抽象目录树, Hdfs中的文件都是分块(block)存储的,块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在hadoop2.x版本中是128M,老版本中是64M
文件的各个block由谁来进行真实的存储呢?----分布在各个datanode服务节点上,而且每一个block都可以存储多个副本(副本数量也可以通过参数设置dfs.replication,默认值是3)
Hdfs中有一个重要的角色:namenode,负责维护整个hdfs文件系统的目录树,以及每一个路径(文件)所对应的block块信息(block的id,及所在的datanode服务器)
hdfs是设计成适应一次写入,多次读出的场景,并不支持文件的修改
(hdfs并不适合用来做网盘应用,因为,不便修改,延迟大,网络开销大,成本太高)
特性:
容量可以线性扩展
数据存储高可靠
分布式运算处理很方便
数据访问延迟较大,不支持数据的修改操作
适合一次写入多次读取的应用场景
2.3 HDFS的java操作
可以随机定位读取位置:DFSInputStream.seek()(1)搭建开发环境(eclipse,hdfs的jar包----hadoop的安装目录的share下)
<dependency>
<groupId>org.apache.hadoop</groupId><artifactId>hadoop-client</artifactId>
<version>2.4.1</version>
</dependency>
建议在linux下进行客户端应用的开发,不会存在兼容性问题。
如果非要在window上做客户端应用开发,需要设置以下环境:
A、在windows的某个目录下解压一个hadoop的安装包
B、将安装包下的lib和bin目录用对应windows版本平台编译的本地库替换
C、在window系统中配置HADOOP_HOME指向你解压的安装包
D、在windows系统的path变量中加入hadoop的bin目录
(2)在java中操作hdfs,首先要获得一个客户端实例
Configuration conf = new Configuration()
FileSystem fs = FileSystem.get(conf)而我们的操作目标是HDFS,所以获取到的fs对象应该是DistributedFileSystem的实例;
get方法是从何处判断具体实例化那种客户端类呢?
----从conf中的一个参数 fs.defaultFS的配置值判断;
如果我们的代码中没有指定并且工程classpath下也没有给定相应的配置,conf中的默认值就来自于hadoop的jar包中的core-default.xml,默认值为: file:///
fs所具备的方法:
2.4 hdfs的工作机制
HDFS集群分为两大角色:NameNode、DataNodeNameNode负责管理整个文件系统的元数据
DataNode 负责管理用户的文件数据块
2.5 namenode工作机制
namenode职责:负责客户端请求的响应
元数据的管理(查询,修改)
---- hdfs元数据是怎么存储的?
A、内存中有一份完整的元数据
B、磁盘有一个“准完整”的元数据镜像
C、当客户端对hdfs中的文件进行新增或者修改操作,响应的记录首先被记入edits这种log日志中,当客户端操作成功后,相应的元数据会更新到内存中
每隔一段时间,会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint)
D、checkpoint操作的触发条件配置参数:
dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率,60秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
#以上两个参数做checkpoint操作时,secondary namenode的本地工作目录
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
dfs.namenode.checkpoint.max-retries=3 #最大重试次数
dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的时间间隔3600秒
dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录
E、namenode和secondary namenode的工作目录存储结构完全相同,所以,当namenode故障退出需要重新恢复时,可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录,以恢复namenode的元数据
F、可以通过hdfs的一个工具来查看edits中的信息
bin/hdfs oev -i edits -o edits.xml
2.6 datanode的工作机制
Datanode工作职责:存储管理用户的文件块数据
定期向namenode汇报自身所持有的block信息(通过心跳信息上报)
上传一个文件,观察文件的block具体的物理存放情况
在每一台datanode机器上的这个目录:
/home/hadoop/app/hadoop-2.4.1/tmp/dfs/data/current/BP-193442119-192.168.2.120-1432457733977/current/finalized