经过近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在此附上一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 实现的。
基于hadoop0.16.x 2009-2-7 23:51
评论
50010是数据通信端口, 50020是RPC调用端口
dfs.datanode.du.reserved可以代替
HADOOP_HOME要一样的
put操作实际上是指DFSClient 与 DataNode建立的Socket连接。因此走的是DN的50010端口。(在传输数据的环节上是和NameNode没有关系的.
没事, 有问题多讨论, 对于我也是个总结的过程。
哦,对,我上面写错了,其实应该是namenode的50010端口,呵呵
put操作实际上是指DFSClient 与 DataNode建立的Socket连接。因此走的是DN的50010端口。(在传输数据的环节上是和NameNode没有关系的.
没事, 有问题多讨论, 对于我也是个总结的过程。
谢谢. 博客中有不少提到hadoop的bug, 如果ithero兄用到, 不防参考一下. 本文实际上更为精确的定义是如何来分析HDFS的代码. 至于云,那就让那些抄概念的说去吧.
DN或者是Client任何一个需要独力一台机子的话, 必须指定fs.default.name 为NN的监听地址。
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端的日志
楼主你上面说的配置文件是在修改的client端的配置文件吗?如果我有一台nn和dn同一网段中的机子,我想让他成为client机子,我是不是应该首先在它上面安装好hadoop,配置好……然后就可以了?nn上还需不需要再配置一下?
另外,为什么要让它们是同一个网段?我需要上传文件的……是不是不同网段的话,hadoop默认存储优先选择同一网段呀?
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端的日志
不是吧, 我比他帅吧,哈哈, 开玩笑 ..
确实
呵呵,也谢谢你一直以来的大力帮助。