标签：put 内容 set ros 读写 笔记 失效 拷贝 其他
官方文档：
http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
大神的翻译：
http://blog.csdn.net/guxch/article/details/18356215
我菜就抄抄补补就行了~
以下引用 http://blog.csdn.net/guxch/article/details/18356215，总结部分是自己写的~
hdfs是一个分布式的文件系统，是为存储支持海量而生。特点：
这一段扯了一堆犊子却没说清楚什么是流式数据访问
海量数据存储
运行在HDFS之上的应用有大数据集。HDFS上一个典型文件的大小为数个GB到数个TB，因而，HDFS已为大数据文件做了优化，它应该聚合数据传输带宽，并能在单一集群部署数百个节点。在单一实例下，它应该支持数百万文件。运行在HDFS之上的应用有大数据集。HDFS上一个典型文件的大小为数个GB到数个TB，因而，HDFS已为大数据文件做了优化，它应该聚合数据传输带宽，并能在单一集群部署数百个节点。在单一实例下，它应该支持数百万文件。
简单耦合模型
HDFS应用需要“一次写多次读”这样一个访问文件模式。一个文件一旦被创建，写入和关闭，都不需要修改。这个假设简化了数据的一致性，使数据可以大容量吞吐。一个Map/Reduce应用和一个web爬虫应用特别适合于这种场合。
移动计算比移动数据动“便宜”
如果应用程序所操作的数据就在附近，那么这种应用的计算效能要高得多，特别是当数据集很大的时刻。这减少了网络拥塞，增加了系统的整体效率。这要求将计算放置到数据存储的附近，而不是将数据移动到计算程序处。HDFS为应用程序提供了将它们移动到数据存储位置的接口
Portability Across Heterogeneous Hardware and Software Platforms 异构硬件和软件平台的可移植性
HDFS被设计成很容易地从一个平台迁移到另一个平台，这个特性有利于将HDFS作为一个可选择的，大规模应用的平台而被广泛应用。
总结，说了这么多，只需要计算hdfs是分布式的文件系统就行了。
HDFS有一个master/slave(主/从)架构。一个HDFS集群有一个单一的NameNode，这是一个管理文件系统命名空间和规定客户端如何访问文件的主服务器。另外，集群由若干DataNode，通常每个节点一个，管理这个节点上的存储。HDFS暴露出一个文件系统命名空间，允许用户数据存储在其中。在内部，一个文件被分割成一个或多个块，这些块被存储到若干DataNode上。NameNode维护文件系统命名空间，例如打开、关闭、重命名文件和目录，它也决定着数据块到DataNode的映射。客户端对文件系统的请求（读/写）由DataNode负责处理。在NameNode的指令下，DataNode也负责数据块的创建、删除和复制。HDFS有一个master/slave(主/从)架构。一个HDFS集群有一个单一的NameNode，这是一个管理文件系统命名空间和规定客户端如何访问文件的主服务器。另外，集群由若干DataNode，通常每个节点一个，管理这个节点上的存储。HDFS暴露出一个文件系统命名空间，允许用户数据存储在其中。在内部，一个文件被分割成一个或多个块，这些块被存储到若干DataNode上。NameNode维护文件系统命名空间，例如打开、关闭、重命名文件和目录，它也决定着数据块到DataNode的映射。客户端对文件系统的请求（读/写）由DataNode负责处理。在NameNode的指令下，DataNode也负责数据块的创建、删除和复制。
NamaNode和DataNode被设计成可以运行在日常通用的机器上，这些机器通常运行GNU/Linux操作系统。HDFS用Java编写，任何支持Java的机器都能运行NameNode或DataNode。采用高可移植Java语言意味着HDFS可以部署到各种类型的机器。一个典型的部署中，有一台特别的机器，上面仅运行NameNode，集群中其他的机器，每一台运行一个DataNode的实例。这个架构不排除在一台机器上运行多个DataNode，但现实中很少见。
集群中仅有一个NameNode极大地简化了系统的架构。NameNode是所有HDFS元数据的存储者和管理者，而用户数据决不会流入到NameNode上。NamaNode和DataNode被设计成可以运行在日常通用的机器上，这些机器通常运行GNU/Linux操作系统。HDFS用Java编写，任何支持Java的机器都能运行NameNode或DataNode。采用高可移植Java语言意味着HDFS可以部署到各种类型的机器。一个典型的部署中，有一台特别的机器，上面仅运行NameNode，集群中其他的机器，每一台运行一个DataNode的实例。这个架构不排除在一台机器上运行多个DataNode，但现实中很少见。
集群中仅有一个NameNode极大地简化了系统的架构。NameNode是所有HDFS元数据的存储者和管理者，而用户数据决不会流入到NameNode上。
[========]
以上也是引用大神的翻译，简单总结一下：
1.namenode是负责HDFS中元数据与集群管理的。包括：文件的创建、重命名、删除、位置移动、与客户端交互、文件与数据块映射、指定文件存储位置、监控集群数据块缺失、管理datanode数据块复制与恢复等，但不负责文件的读写、存储。namenode与datanode通过心跳来交流信息。
2.datanode 负责实际的数据块的读写、块状态检测等
3.namenode中的元数据分为两块，一块是hdfs文件系统，即文件的相关信息(位置、对应的数据块等)，另一块是blockmap，即datanode上数据块信息
HDFS支持传统的层次结构文件组织方式。用户或应用程序可以在目录中创建目录和存储文件。文件系统命名空间的层次结构类似于其他文件系统，可以创建和删除文件，将文件从一个目录移动到另一个目录，或者重命名文件。HDFS不支持硬链接或软链接。但是，HDFS架构并不排除实现这些特性。
NameNode维护文件系统命名空间。任何对文件系统命名空间或者它的属性的修改都被NameNode所记录。应用程序可以指定一个文件的复制份数，一个文件拥有的拷贝数叫做该文件的复制因数，此信息由NameNode保存。
[========]
总结：当成linux文件系统来用就好！不支持链接而已
HDFS被设计用来可靠地在一个大集群中跨机器地存储巨大文件，它将每个文件保存为连续的块，除最后一个块之外，一个文件中所有块的大小相同，为容错性，文件块被复制。文件块大小与复制因数是每个文件的配置参数。应用程序可以为每个文件指定复制份数，这个复制因数可以在文件创建时指定，也可以在以后改变。HDFS中的文件都是“写一次”的方式，并且在任何时刻，严格只有一个写入者。
NameNode决定如何复制文件块。它周期性地从集群中每一个DataNode接收心跳和块报告。接收到心跳表示这个DataNode还在正常工作，而块报告则包含着这个DataNode上所有文件块的列表。
复制块的放置对HDFS的性能和可靠性至关重要。优化的复制块放置方法是HDFS不同于其他分布式文件系统的地方，这个特性需要大量的经验与调试。复制块的机架自适应策略就是为了提高数据的可靠性、可用性和节省网络带宽。目前复制块放置的实现策略仅是这个方向上的一个初步努力的结果。这个策略的短期目标是验证它在实际生产系统的情况，了解它更多的状况，为测试和研究更复杂的策略建立基础。
集群上运行的大容量HDFS实例通常有许多机架。不同机架上的两个节点之间的通信需要通过通信设备，大部分情况下，同一机架上两台机器之间的网络带宽大于不同机架上两台机器之间的带宽。
NameNode决定着每个DataNode所属的机架id，这个过程在“Hadoop Rack Awareness”中有一个描述。一个简单但不太优化的方法是将复制块放置到不同的机架上，当某个机架故障时，数据也不会丢失，并且读数据时可以利用多个机架的带宽，这种将复制块均匀分布到不同机架的策略在发生部件故障时很容易做到负荷平衡，但是这个策略增加了写成本，因为写时，数据块需要在不同机架之间传输数据。
通常情况下，当复制因数是3时，HDFS的放置策略是一个数据块放置到本地机架的一个节点，另一份数据块放置到本地机架的另一个节点，最后一份数据块放置到不同机架的一个节点。这个策略减少了机架之间的通信而极大提高了写性能。机架发生故障的可能性远小于节点，这个策略并不影响数据的可靠性和可用性，但是，在读数据时，它确实降低了整体带宽，因为数据块仅放置在两个而不是三个机架上，这种策略下，一个文件的复制块没有在机架之间均匀分布，三分之一的复制块在一个节点上；三分之二的复制块在一个机架上，另三分之一的复制块均匀分布在另外的机架上。这个策略提高了写性能，没有降低数据可靠性或读性能。
这儿描述的目前缺省的复制块放置策略还在不断改进中。
[========]
总结：
1.hdfs上的数据块保存多个副本，一般是三个，这样可以提高文件的可用性，不容易因为机器故障导致文件不可用。
2.块的放置策略是，在客户端所在节点上先放一个块，在同机架不同节点上再放一个块，然后在不同机架上的节点上再放一个。这样可以优化写入和网络开销。
3.通过为datanode配置机架，那么namenode可以实现2中的功能。默认只有一个default机架。
为减少全局的带宽和读延迟，HDFS尝试从离要求读的客户端最近的地方读取复制块，如果读者节点与复制块节点在同一机架上，则这个复制块优先用来满足读请求，如果HDFS集群有多个数据中心，则优先使用本地数据中心中的复制块，而不是远方的数据块。
启动时，NameNode进入一个特别的状态，叫做“安全模式”。在安全模式下，不会发生数据块的复制。NameNode接收各DataNode的心跳和数据块信息。数据块信息包含了DataNode上所有的数据块列表。每个数据块都有一个特定的最小的复制份数，如果数据块的复制份数满足这个最小值要求，NameNode就认为这个数据块已被安全复制。当NameNode检查了某一百分比（可配置）的复制块，再加额外的30秒之后，NameNode就退出安全模式，它接着看看是否还有复制块的份数少于规定值，然后将这些块复制到其他DataNode上。
HDFS命名空间存储在NameNode上。NameNode采用一个叫EditLog的事务日志来持久性记录每一个发生在文件系统metadata上的变化。例如，在HDFS上创建一个新文件会使NameNode向EditLog插入一条记录，同样，改变一个文件的复制因数也将在EditLog中插入一条记录。NameNode采用宿主操作系统的一个本地文件来保存EditLog。整个文件系统命名空间，包括数据块与文件的对应，文件系统的属性，存储在一个叫fsimage的文件中，这个文件也保存在NameNode的本地文件系统中。
NameNode将整个文件系统命名空间和文件块映射表保持在内存中，它们被设计成紧凑形式，因此，即使NameNode有4GB的RAM，也能支持很大数量的文件和目录。当NameNode启动时，它从磁盘上读取FsImage和EditLog，将EditLog中的事务应用于内存中的FsImage，然后更新磁盘上的FsImage，形成一个新版本。旧版本的EditLog就可以被截断了，因为事务应用到FsImage中，并且被保存了。这个过程叫做一个检查点。在目前的实现中，只有在NameNode启动后才能产生检查点。在不久的将来，会支持周期性检查点，这个工作目前正在进行中。
DataNode将HDFS的数据存储在本地文件系统中，DataNode并不知道HDFS文件，它只是将HDFS不连续的文件数据块存储在本地文件系统。DataNode不会将所有文件都创建在一个目录中，相反，它采用启发式方面来决定每个目录下最佳的文件数目，在合适的时候创建子目录。将所有文件创建在同一目录下不是最佳的方法，这是因为本地文件系统可能不高效地支持单一目录下有巨大的文件数目。当DataNode启动后，它扫描本地文件系统，产生一个所有HDFS数据块与本地文件对应的列表，然后将其发给NameNode，这个列表叫做Blockreport。
[========]
总结：
1.hdfs的元数据被持久化成两部分：fsimage 和 editlog。 fsimage相当于数据库的增量备份,editlog相当于数据库事务日志，将fsimage和editlog合起来就是完全的数据。
2.namenode启动后，将editlog和fsimage合并成完整的元数据并加载到内存中，并将合并后的写入新的fsimage中，这叫做一个checkpoint。然后，hdfs上的修改被写入新的editlog然后修改内存的hdfs映像。注意：内在中的映像是完整的hdfs元数据。
3.backupnode会定时(默认1小时)从namenode拿editlog，然后合并本地的fsimage，然后将合并后的fsimage发送到namenode上。
3.为了保证元数据的安全，一般使用HA技术或者，将fsimage和editlog写入到多个不同的驱动器上。
所有HDFS的通讯协议建立在TCP/IP协议之上，客户端与NameNode通过一个配置的TCP端口建立连接，它们之间的协议叫ClientProtocol，DataNode与NameNode之间采用DataNodeProtocol通讯。一个RPC抽象层包裹了ClientProtocol和DataNodeProtocol。从设计上讲，NameNode从不发起RPC，而只应答由客户端或DataNode发起的RPC请求。
即使发生故障时，HDFS也能存储数据，这是HDFS的基本目标。有三种常见的故障类型：NameNode故障、DataNode故障和网络故障。
每个DataNode周期性地向NameNode发送心跳。网络故障可能使一部分DataNode失去与NameNode的联系。NameNode通过心跳丢失来发现这种情况，它将最近没有发送心跳的DataNode标记为“dead”，并且不再向其发送新的IO指令。任何注册在“dead”DataNode上的数据都不在可用。DataNode的“dead”状态可以使一些数据块的复制因数低于设定值，NameNode就不断地检查哪些数据块需要复制，并在需要时发起复制过程。再复制可能因为如下原因而发生：一个DataNode不可用，一个复制块损坏，DataNode上一个磁盘发生损坏，或者文件的复制因数增加了。
HDFS的架构与数据再平衡的方案是适应的。如果一个DataNode的磁盘空间低于某个阈值，一种再平衡方案要将数据从这个DataNode自动地移动到另一个。当对某一文件的请求突然有巨大增加时，一种再平衡方案要动态地创建额外的复制块并再分配其他数据块。这些类型的数据再平衡方案目前还没用实现。
从DataNode中获取的数据块在到达时损坏了，这是有可能发生的，因为存在存储设备瑕疵、网络故障或软件bug。HDFS客户端软件实现验证HDFS文件的校验和。当客户端创建了一个HDFS文件，它计算文件每个数据块的校验和，并将校验和存储在HDFS同一命名空间下的另一个隐藏文件中。当客户端软件接收到文件内容，通过与此文件相关联的校验和文件，它验证数据块的校验和。如果不匹配，客户端软件可以选择从另一个DataNode接收相同的数据块。
FsImage和EditLog是HDFS的中心数据结构，它们的损坏将使HDFS实例不能工作，因此，NameNode可以被配置支持多个FsImage和EditLog拷贝，任何对FsImage或EditLog的更新都将同步到每一个拷贝中。这种同步地更新FsImage和EditLog的多个拷贝可能会降低NameNode每秒可处理的事务数目，但是，这种降低是可接受的，因为即使对数据十分敏感的HDFS应用，它们对元数据不会敏感。当NameNode启动时，它选择最新的具有一致性的FsImage和EditLog拷贝来使用。
快照支持保存某一特定时刻的数据。快照的一个使用场合是将损坏的HDFS实例回滚到以前已知好的时间点。
注：可以对文件或者目录做快照
HDFS被设计成支持非常大的文件。适合于HDFS的应用程序就是那些使用大数据集的应用，这些应用一次写入数据，一次或多次读取数据，并且满足流式读取的速度。HDFS支持这种文件一次写多次读的特性。HDFS中一个典型的数据块是64MB，因此，HDFS中的文件被分割成64MB的块，如果可能，每一块放在不同的DataNode上。
用户创建一个文件的请求并不会立刻传递给NameNode，实际上，开始时，HDFS客户端会将文件数据缓存在本地临时文件中。应用程序的写操作会透明地再定向到这个临时文件，当这个本地临时文件积累到足够HDFS块大小时，客户端与NameNode通讯，NameNode将文件名插入到文件系统层次目录中，并分配一个数据块给它，NameNode于是回应客户端，给出DataNode和目的数据块的标识，接着客户端将临时文件中的数据更新到指定的DataNode，当文件被关闭时，本地临时文件中剩下的、没有更新的数据被传递到DataNode，客户端告诉NameNode说这个文件关闭了，在这个时候，NameNode才将文件创建的操作持久化保存（提交事务）。如果文件关闭之前NameNode失效了，文件就丢失了。
以上的方案是经过仔细考虑HDFS上的应用程序而得出的，这些应用程序需要流式写文件，如果用户不经过客户端缓存而直接写一个远程文件，网络速度和拥塞情况将极大地影响吞吐量，这个方案不是没有先例，早期的分布式文件系统，例如AFS，就利用客户端缓存来提高性能。POSIX已放松了对数据上传更高性能的要求。
当用户向一个HDFS文件写数据时，数据先被写入本地的临时文件中，这已在上面解释过了。假设HDFS文件的复制因数为3，当本地文件积累满一个数据块时，客户端从NameNode得到一个DataNode的列表，这个列表就是放置该数据块的DataNode。于是，客户端将数据更新到第一个DataNode，第一个DataNode开始接收数据，接收到后（以较小的数据块，4KB），将这个小数据块保存到本地，然后将其传输给列表中的第二个DataNode，第二个DataNode也以相同的方式操作，将其传递给第三个DataNode，最后，第三个NataNode将数据写入本地存储位置。这样，类似于管道，一个DataNode一边从前一个DataNode接收数据，一边将其传递给后一个DataNode。
从应用程序可以有多种办法访问HDFS。HDFS原生地提供了一个JAVA API来访问文件系统，还有一个对这个JAVA API的C包装。另外，也可以用一个HTTP浏览器来浏览HDFS中的文件。目前，通过WebDAV协议来浏览HDFS的工作正在进行中。
HDFS将用户数据组织成文件和目录这样一种形式。它提供了一个叫“FSshell”的命令行接口，允许用户与HDFS数据交换。这个命令行的句法类似于用户已经熟悉的其他命令行工具（例如bash,csh），以下是一些命令行和与之对应动作的例子。
| Action | Command |
|---|---|
| Create a directory named /foodir | bin/hadoop dfs -mkdir /foodir |
| Remove a directory named /foodir | bin/hadoop dfs -rmr /foodir |
| View the contents of a file named /foodir/myfile.txt | bin/hadoop dfs -cat /foodir/myfile.txt |
FS shell的目标是给需要脚本语言与存储数据交互的应用程序。
DFSAdmin命令集是用来管理HDFS集群的，这些命令仅被HDFS管理员使用。下面是是一些命令和与之对应动作的例子。
| Action | Command |
|---|---|
| Put the cluster in Safemode | bin/hadoop dfsadmin -safemode enter |
| Generate a list of DataNodes | bin/hadoop dfsadmin -report |
| Recommission or decommission DataNode(s) | bin/hadoop dfsadmin -refreshNodes |
典型的HDFS安装配置了一个web服务器，采用配置的TCP端口来浏览HDFS命名空间。这个功能允许用户可以用web浏览器来浏览HDFS命名空间并查看文件的内容。
(以下是自己翻译~)
如果开启了回收站功能，那么通过fs shell删除的文件先被放到回收站中(不知道通过API删除的会不会这样)，只在文件在回收站中就可以被恢复。回收站的默认位置是(/user/
$ hadoop fs -mkdir -p delete/test1
$ hadoop fs -mkdir -p delete/test2
$ hadoop fs -ls delete/
Found 2 items
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2
删除到回收站
$ hadoop fs -rm -r delete/test1
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current
删除时不进入回收站
$ hadoop fs -rm -r -skipTrash delete/test2
Deleted delete/test2
查看回收站
$ hadoop fs -ls .Trash/Current/user/hadoop/delete/
Found 1 itemsdrwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1当一个文件的复制因数变小时，NameNode选择能被删除的过量的复制块。这个信息随下一次的DataNode的心跳而传递给DataNode，DataNode接着删除对应的块和释放对应的空间，再一次说明，调用setReplication完成的时刻与集群中出现对应的剩余空间的时刻之间相比，可能有一个滞后。
注：对于已经存在于hdfs上的文件，修改dfs.replication后不会降低或者增加复制因子。必须通过fs shell hadoop dfs -setrep来修改已经存在的文件的复本数。如
hadoop dfs -setrep -w 3 -R /user/hadoop/dir1将复制因子修改为3.
本节的东西实在太多，所以十分感觉感谢http://blog.csdn.net/guxch/article/details/18356215!
标签：put 内容 set ros 读写 笔记 失效 拷贝 其他
原文地址：http://www.cnblogs.com/skyrim/p/7455289.html
