HDFS详解

附件: HDFS简介.pdf (2010-12-1 22:58:56, 516.37 K)
该附件被下载次数 5

【二】HDFS和KFS 比较
两者都是GFS的开源实现，而HDFS 是Hadoop 的子项目，用Java实现，为Hadoop上层应用提供高吞吐量的可扩展的大文件存储服务。
Kosmos filesystem（KFS） is a high performance distributed filesystem for web-scale applications such as, storing log data, Map/Reduce data etc. It builds upon ideas from Google‘s well known Google Filesystem project. 用C++实现
-------------------------------------------------------------------------------------------
本区整理如下，欢迎下载学习：

附件: HDFS和KFS的比较.pdf (2010-12-1 23:04:26, 414.23 K)
该附件被下载次数 3

【三】HDFS的缺点及改进策略
HDFS是一个不错的分布式文件系统，它有很多的优点，但也存在有一些缺点。目前而言，它在以下几个方面就效率不佳：
低延时访问
HDFS 不太适合于那些要求低延时（数十毫秒）访问的应用程序，因为HDFS是设计用于大吞吐量数据的，这是以一定延时为代价的。HDFS是单Master的，所 有的对文件的请求都要经过它，当请求多时，肯定会有延时。当前，对于那些有低延时要求的应用程序，HBase是一个更好的选择。现在HBase的版本是 0.20，相对于以前的版本，在性能上有了很大的提升，它的口号就是goes real time。
使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。
大量小文件
因 为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件 夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万 的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理 10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个 Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
要想让HDFS能处理好小文件，有不少方法：
1、利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。
2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。
3、多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。
附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。
多用户写，任意文件修改
目 前Hadoop只支持单用户写，不支持并发多用户写。可以使用Append操作在文件的末尾添加数据，但不支持在文件的任意位置进行修改。这些特性可能会 在将来的版本中加入，但是这些特性的加入将会降低Hadoop的效率，就拿GFS来说吧，这篇文章里就说了google自己的人都用着Multiple Writers很不爽。
利用Chubby、ZooKeeper之类的分布式协调服务来解决一致性问题。
本文转载自：http://www.cnblogs.com/wycg1984/archive/2010/03/20/1690281.html

-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
【四】Hadoop HDFS配置
环境:
Jdk1.6
Hadoop-2.20.1
Fuse-2.8.1
Jdk1.6下载地址
hadoop-2.20.1下载地址http://www.apache.org/dyn/closer.cgi/hadoop/core/
Fuse-2.8.1下载地址http://sourceforge.net/projects/fuse/files/fuse-2.X/
NameNode 192.168.1.11 Centos 5.3 hostname master-dfs
JobTracker 192.168.1.11 (这个也可单独配置一台)
DataNode 192.168.1.12 Centos 5.3 hostname:data-dfs
Client  192.168.1.13 Centos 5.3 hostname:client-dfs
先决条件
配置ssh自动登陆，详细见http://hadoop.apache.org/common/docs/r0.20.0/quickstart.html
-------------------------------------------------------------------------------------------
安装步骤本区为您整理如下，欢迎下载：

附件: Hadoop HDFS配置.pdf (2010-12-1 23:15:32, 202.61 K)
该附件被下载次数 2

【五】从HDFS看分布式文件系统的设计需求
分布式文件系统的设计目标大概是这么几个：透明性、并发控制、可伸缩性、容错以及安全需求等。我想试试从这几个角度去观察HDFS的设计和实现，可以更清楚地看出HDFS的应用场景和设计理念。
首先是透明性，如果按照开放分布式处理的标准确定就有8种透明性：访问的透明性、位置的透明性、并发透明性、复制透明性、故障透明性、移动透明性、性能透明性和伸缩透明性。对于分布式文件系统，最重要的是希望能达到5个透明性要求：
（1） 访问的透明性：用户能通过相同的操作来访问本地文件和远程文件资源。HDFS可以做到这一点，如果HDFS设置成本地文件系统，而非分布式，那么读写 分布式HDFS的程序可以不用修改地读写本地文件，要做修改的是配置文件。可见，HDFS提供的访问的透明性是不完全的，毕竟它构建于java之上，不能 像NFS或者AFS那样去修改unix内核，同时将本地文件和远程文件以一致的方式处理。
（2）位置的透明性：使用单一的文件命名空间，在不改 变路径名的前提下，文件或者文件集合可以被重定位。HDFS集群只有一个Namenode来负责文件系 统命名空间的管理，文件的block可以重新分布复制，block可以增加或者减少副本，副本可以跨机架存储，而这一切对客户端都是透明的。
（3）移动的透明性，这一点与位置的透明性类似，HDFS中的文件经常由于节点的失效、增加或者replication因子的改变或者重新均衡等进行着复制或者移动，而客户端和客户端程序并不需要改变什么，Namenode的edits日志文件记录着这些变更。
（4）性能的透明性和伸缩的透明性：HDFS的目标就是构建在大规模廉价机器上的分布式文件系统集群，可伸缩性毋庸置疑，至于性能可以参考它首页上的一些benchmark。
其 次是并发控制，客户端对于文件的读写不应该影响其他客户端对同一个文件的读写。要想实现近似原生文件系统的单个文件拷贝语义，分布式文件系统需要做出复 杂的交互，例如采用时间戳，或者类似回调承诺（类似服务器到客户端的RPC回调，在文件更新的时候；回调有两种状态：有效或者取消。客户端通过检查回调承 诺的状态，来判断服务器上的文件是否被更新过）。HDFS并没有这样做，它的机制非常简单，任何时间都只允许一个写的客户端，文件经创建并写入之后不再改 变，它的模型是 write-one-read-many ， 一次写，多次读。这与它的应用场合是一致，HDFS的文件大小通常是兆至T级的，这些数据不会经常修改，最经常的是被顺序读并处理，随机读很少，因此 HDFS非常适合MapReduce框架或者web crawler应用。HDFS文件的大小也决定了它的客户端不能像某些分布式文件系统那样缓存常用到的几百个文件。
第三，文件复制功能，一个文件 可以表示为其内容在不同位置的多个拷贝。这样做带来了两个好处：访问同个文件时可以从多个服务器中获取从而改善服务的伸缩 性，另外就是提高了容错能力，某个副本损坏了，仍然可以从其他服务器节点获取该文件。HDFS文件的block为了容错都将被备份，根据配置的 replication因子来，默认是3。副本的存放策略也是很有讲究，一个放在本地机架的节点，一个放在同一机架的另一节点，另一个放在其他机架上。这 样可以最大限度地防止因故障导致的副本的丢失。不仅如此，HDFS读文件的时候也将优先选择从同一机架乃至同一数据中心的节点上读取block。
第四，硬件和操作系统的异构性。由于构建在java平台上，HDFS的跨平台能力毋庸置疑，得益于java平台已经封装好的文件IO系统，HDFS可以在不同的操作系统和计算机上实现同样的客户端和服务端程序。
第五，容错能力，在分布式文件系统中，尽量保证文件服务在客户端或者服务端出现问题的时候能正常使用是非常重要的。HDFS的容错能力大概可以分为两个方面：文件系统的容错性以及Hadoop本身的容错能力。文件系统的容错性通过这么几个手段：
（1） 在Namenode和Datanode之间维持心跳检测，当由于网络故障之类的原因，导致Datanode发出的心跳包没有被Namenode正常收 到的时候，Namenode就不会将任何新的IO操作派发给那个Datanode，该Datanode上的数据被认为是无效的，因此Namenode会检 测是否有文件block的副本数目小于设置值，如果小于就自动开始复制新的副本并分发到其他Datanode节点。
（2）检测文件block的完整性，HDFS会记录每个新创建的文件的所有block的校验和。当以后检索这些文件的时候，从某个节点获取block，会首先确认校验和是否一致，如果不一致，会从其他Datanode节点上获取该block的副本。
（3）集群的负载均衡，由于节点的失效或者增加，可能导致数据分布的不均匀，当某个Datanode节点的空闲空间大于一个临界值的时候，HDFS会自动从其他Datanode迁移数据过来。
（4）Namenode 上的fsimage和edits日志文件是HDFS的核心数据结构，如果这些文件损坏了，HDFS将失效。因而， Namenode可以配置成支持维护多 个 FsImage和 Editlog的拷贝。任何对 FsImage或者 Editlog的修改，都将同步到它们的副本上。 它总是选取最近的一致的 FsImage和 Editlog使用。 Namenode在 HDFS是单点存在，如果 Namenode所在的机器错误，手工的干预是必须的。
（5)文件的删除，删除并不是马上从Namenode移出namespace，而是放在/ trash目录随时可恢复，直到超过设置时间才被正式移除。
再说Hadoop本身的容错性，Hadoop支持升级和回滚，当升级Hadoop软件时出现bug或者不兼容现象，可以通过回滚恢复到老的Hadoop版本。
最后一个就是安全性问题，HDFS的安全性是比较弱的，只有简单的与unix文件系统类似的文件许可控制，未来版本会实现类似NFS的kerberos验证系统。
总 结下：HDFS作为通用的分布式文件系统并不适合，它在并发控制、缓存一致性以及小文件读写的效率上是比较弱的。但是它有自己明确的设计目标，那就是支 持大的数据文件（兆至T级），并且这些文件以顺序读为主，以文件读的高吞吐量为目标，并且与MapReduce框架紧密结合。
本文转载自：http://dennis-zane.javaeye.com/blog/228537
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

【六】利用JavaAPI访问HDFS的文件
本区整理如下，欢迎下载：

附件: 利用JavaAPI访问HDFS的文件.pdf (2010-12-1 23:21:04, 167.35 K)
该附件被下载次数 3

【七】对Hadoop-HDFS性能造成重大影响的杀手-Shell
近 来在测试Hadoop时, 使用NameNode身上的dfshealth.jsp管理页面发现，DataNode在运行的过程中,Last Contact参数时常会超过3。LC（Last Contact）的意思是表明DataNode有多少秒的时间未向NameNode发送心跳包了。然而默认DataNode是3秒发送一次，我们都知 道，NameNode默认以10分钟作为DN的死亡超时时间，那么究竟有哪些因素会导致JSP管理页面LC参数超过3，甚至会达到200以上，这样的情况 对我们的系统的稳定运行究竟有没有影响？
事实上，这现象我观察了好一阵子，影响LC参数增大的原因有下面几种情况：
1.HDFS收到大量删除BLOCK的命令. 请参见：https://issues.apache.org/jira/browse/HDFS-611；
2.HDFS 有大量BLOCK需要report 给NN；
3.组织心跳包的数据；
4.网络环境。
前两种情况LC的值一般不会超过100，对性能不会造成很大影响。 Hadoop-0.22.0 以后版本，Hadoop也有所改进。
那么值的一提的是DN在组织心跳包期间，对FSDatasetInterface 接口进行了相关方法的调用，具体可以参考一下FSDatasetMBean接口中的几个方法：
/** 
  * Returns the total space (in bytes) used by dfs datanode
  * @return  the total space used by dfs datanode
  * @throws IOException
*/  
public long getDfsUsed() throws IOException; 
/**
* Returns total capacity (in bytes) of storage (used and unused)
* @return  total capacity of storage (used and unused)
* @throws IOException
*/ 
public long getCapacity() throws IOException; 
/**
* Returns the amount of free storage space (in bytes)
* @return The amount of free storage space
  * @throws IOException
*/ 
public long getRemaining() throws IOException;
这三个方法意思大家都很明白，它们的实现者分别为DF,DU两个类，它们会不定期的通过Shell类的runComamnd方法来执行系统命令，以获取当前目录的 df, du 值。
然而在执行的过程当中有趣的事情发生了，笔者有13个分区，一共存有14万多个BLOCK，
Df 和du 平均每次执行的时间都会超过两秒，戏剧性的是DU 和DF最高的一次在执行某分区目录的命令时，居然用了180秒以上。（Shell#runCommand方法中, 从ProcessBuilder 实例化到process.start() 执行时间）。
难 道是分区目录下的BLOCK数量过多导致运行缓慢么，在linux 系统里执行DF DU相同的命令结果都是以毫秒时间结束。那问题显然出在了ProcessBuilder， 居了解，该类由JVM通过Linux 内核来fork 子进程，子进程当然会完全继承父进程的所有内存句柄，jstack看到JVM此时线程状态大部分处于WAITING， 这个过程经过测试确实会影响DFSClient写入超时，或关闭流出错（下篇会说到， 作为长久Running 的DFSClient， 应该做好流的关闭工作，0.21-trunk中流的关闭仍然存有安全隐患。） 最后我折腾过从32位机子一路换到64位的机子，但问题依然存在。
最后只好再次对HDFS开刀，重构了DU,DF 以及自己的IOStat , Uptime类，通过Linux系统来执行，把结果输出到临时文件中，然后由Hadoop来读取。 LC的问题不再发生。

本文转载自：http://dongyajun.javaeye.com/blog/627905
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
【八】HDFS+MapReduce+Hive+HBase十分钟快速入门
本文的目的是让一个从未接触Hadoop的人，在很短的时间内快速上手，掌握编译、安装和简单的使用。
-------------------------------------------------------------------------------------------
文章相对比较长，本区进行了相关整理排版，欢迎下载：

附件: HDFS+MapReduce+Hive+HBase十分钟快速入门.pdf (2010-12-1 23:33:00, 516.81 K)
该附件被下载次数 2

附件: HDFS中两种random read比较.pdf (2010-12-1 23:43:53, 235.71 K)
该附件被下载次数 2

附件: Hadoop分布式文件系统：架构和设计要点.pdf (2010-12-1 23:43:53, 459.80 K)
该附件被下载次数 2

-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------

转自：http://www.cnblogs.com/chinacloud/archive/2010/12/03/1895369.html

本文转自夏雪冬日博客园博客，原文链接：http://www.cnblogs.com/heyonggang/archive/2012/12/22/2829219.html，如需转载请自行联系原作者