分布式文件系统与HDFS

常见的分布式文件系统：GFS、TFS、HDFS
ssh 
hadoop fs -ls hdfs://itcast01:9000
hadoop fs -ls /
hadoop fs -cat /in.log | more //查看命令
hadoop fs -ls -R(递归查询文件） -h(人类可读）
drwxr-xr-x  -  root supergroup
d代表文件类型，目录
rwx，所属用户的权限
r-x，所属组的权限
r-x，其他用户的权限
1，代表是否存储文件，1表示存储
root,代表所属用户
supergroup，代表所属组
hdfs有一些常用的命令
hadoop 
1.google的三大论文花时间看一下！
2.阅读一些hdfs的命令

读块，就近原则！
元数据存储细节：
NameNode Metadata（内存当中）
NameNode(FileName, replicas, block-ids...)
NadeNode:
1.fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
2.edits:日志信息
3.fstime:最后一次checkpoint的时间

以上这些文件是保存在linux的文件系统中

一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。

通透性、容错、分布式文件管理系统很多

lNameNode

lDataNode

lSecondary NameNode

NameNode

是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。接收用户的操作请求

元数据是存储在内存中~

l文件包括：

①fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。

②edits:操作日志文件。

③fstime:保存最近一次checkpoint的时间

l以上这些文件是保存在linux的文件系统中。

工作特点：

lNamenode始终在内存中保存metedata，用于处理“读请求”

l到有“写请求”到来时，namenode会首先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，并且向客户端返回

lHadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。Secondary namenode就是用来合并fsimage和edits文件来更新NameNode的metedata的。

SecondaryNameNode

lHA的一个解决方案。但不支持热备。配置即可。

l执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage.

l默认在安装在NameNode节点上，但这样...不安全！

secondary通知namenode切换edits文件

2.secondary从namenode获得fsimage和edits(通过http)

3.secondary将fsimage载入内存，然后开始合并edits

4.secondary将新的fsimage发回给namenode

5.namenode用新的fsimage替换旧的fsimage

lfs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认3600秒。

lfs.checkpoint.size    规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。

Datanode

l提供真实文件数据的存储服务。

l文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block.

l不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间

lReplication。多复本。默认是三个。