Hadoop源码分析-HDFS

经过近66个工作日的时间，终于搞定了HDFS系统，在我们的项目中，称为Fordim0.1。

为了能够让更多的朋友认识Hadoop在此附上一Google’s Solution --> Open Source Word’s Solution ：
 Google File System – Hadoop Distributed FS
 Map-Reduce – Hadoop Map-Reduce
 Sawzall – Pig, Hive, JAQL
 Big Table – Hadoop HBase,  Cassandra
 Chubby – Zookeeper


关于Hadoop的内部实现流程方案，我想列到下篇日志当中，本篇我只想讲述如何剖析这3万多行的代码。在对Java 应用程序的IO操作的基础上理解Hadoop并不难，关键是掌握程序系统各组件的依懒性，有条理的分析先做什么，后实现什么这样的原则，我的plan是：
1. 系统中存在的case : Master / Slaves / Client 其对应的实现:
Master– NameNode
Slaves–DataNode s
Client –DFSClient

2. 三者之间的通信通过IPC建立，最底层仍然是TCP，底层实现原理暂且不理，通过Hadoop 的RPC机制做出Demo。

3. 认知NameNode后发现该庞然大物犹如人体的大脑，它充当着HDFS的控制器，但尽管有着近似一万行代码的它，我们也无需慌张，现在的工作没有它的份，聪明的朋友就会分析到，就是现在实现这样的控制器，也无法工作，因为人体还没有四肢。Okay, 接下来的任务是

4. 在RPC的基础上定义ClientProtocol / DatanodeProtocol两interface，本质上他们是RMI技术的应用。
ClientProtocol: DFSClient- -> NameNode
Allows clients to ask for DFS services.
DatanodeProtocol: Datanode - -> NameNode
Used by DataNode programs that actually store DFS data blocks.

5. 接口完了，接下来我们定义上面仨。至此，我们的第一阶段顺利完成。

6. 如果前面工作顺利的话，下面我们的工作就是DFSClient 和 Datanode 了，事实上我们通过Hadoop的官方文档便可得知，DFSClient做任何事是必须向NameNode 发出请求，等NameNode处理完请求给予响应后，才允许和Datanode交互。然而此时我们未必要实现它，就当作DFSClient直接向DataNode通信。

7. 前面没有讲到DFSClient与DaatNode的交互方式，是因为他们俩不存在请求与被响应的的策略，因此Hadoop HDFS并未使用RPC来实现他们俩之间的通信，而是直接通过底层的socket 连接Datanode的ServerSocket，以实现数据的传输。

8. 该部分的成功实现，是建立在对chunk / packet / block，以及Java IO操作的理解之上的。那么我们的任务当然是先实现上传，后下载了，原因你知道的。

9. 在完成put操作时，我们发现DataNode存储block的机制（之后的日志会说到，此处会改为链接），这里提醒一下，现在无需实现，简单的流程是，当Datanode收到block时，我们先找本地磁盘的任意地方存放，等get操作完了之后，我们认为DFSClient 与 DataNode暂时是没有什么活要做的，那么之后，我们可以考虑研究DataNode的存储机制然后加上。

10. 前面第二阶段的工作很艰巨，而且是比较重要，这就好似我们创造了人体的四肢一样，那么接下来是更为艰巨的任务NameNode。

11. 该物如何剖析是关系到项目进度以及工作效率最受影响的因素之一，与其茫然的不停双击鼠标，还不如准备笔纸仔细的分析该如何开展工作。在注释与文档的帮助下，找到了一个切入点，首先从DFSClient的session入手，也就是请求的开始直到结束，NameNode直始至终做了哪些工作，跟到最后一步，大脑是如何存储记忆的，渐渐浮出水面，那就是INode。

12. 熟悉Linux OS的朋友应该知道INode的概念，我们知道block 是记录档案内容数据的地区，而INode则是记录该档案的属性，以及该档案存在哪一个block之内的信息。在terminal 中，下达ls –i 命令可以看到indoe的参数值。要想攻破NameNode，INode必须理解。

13. OK, 接下来的任务最为艰巨，那就是我们的FSNamesystem出场，解决了它，NameNode基本上可以说所剩无几，此类有近4500行。在初步分析时，内部线程可以不用看，而工作的重点则是这样的流程interface - > NameNode->FSNamesystem->FSDirectory->INode。

14. 在完成以上流程后，可以研究FSNamesystem中的内部线程，实际上不难看出，Master Server正是使用了它们维持了整个 HDFS 系统的负载平衡。

15. 完成内部线程后，我们便可模拟数据进行测试。最后另用Shell 脚本来封装我们的系统。

以上是我研究Hadoop-HDFS系统的一般流程，其中有些知识点没有列到会在今后的日志中讲到，例如HDFS对外提供的访问接口，除了Shell ，还有web ui 。而它则是使用jetty 实现的。

楼主头像像马云。

不是吧, 我比他帅吧,哈哈, 开玩笑 ..  

开始分享了，支持一下。

呵呵，也谢谢你一直以来的大力帮助。 

楼上, 关于hadoop架构, hadoop.apache.org中的docs里有很多介绍, 完全可以参考.

确实

楼主写的这么好的资料今天才看到，非常感谢楼主无私的分享，也希望越来越多的人开始接触Hadoop。

请问楼主，client客户端怎么配置？我之前上传文件都是把namenode节点当作客户端来用，然后我发现在datanode节点中上传就会出现好多问题，尤其是我修改了hadoop的一些功能到了datanode节点上上传时，那些功能都没用了，请问是怎么回事?

Hadoop#HDFS分为三个组成部分, Client, DN, NN.

前者可以为任意的连网客户机, 后两者建议放到内网集群中。

1. 当你需要put文件到集群时, Client最好放到和DN, NN一样的网段内。
2. 当你仅需要move, delete文件时, Client可以放到任意远程客户机。

那么要想让Client工作, Hadoop-site.xml文件最起码需要配置fs.default.name.
<property>
   <name>fs.default.name</name>
   <value>hdfs://localhost:9000/</value>
           <description>Client和NN同一台机子</description>
</property>

非本机需要把localhost换成NN的IP或者是可以解析的hostname

另外，你说出现了很多问题, 这些问题指哪些, 请仔细分析一下, 如果可以, 请贴出Client端和Namenode端的日志