HelloWorld

HDFS，即Hadoop Distributed File System，为Hadoop的分布式文件系统。其实除了HDFS外，hadoop还支持其它类型的文件系统，比如FTP、本地文件系统等，而这些文件系统都扩展自抽象基础类FileSystem，该抽象类类提供了丰富的方法用于对文件系统进行操作，比如创建目录、删除文件、重命名等。无论使用的是HDFS还是本地文件系统，或者其它所支持的文件系统，推荐在

RPC是Hadoop的基础组件，提供分布式环境下的对象调用功能。之前用了三天时间分析与测试RPC，目的是想弄清楚它的整个运行机制。       概括的说，RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获

在《Hadoop-2.4.1源码分析--HDFS HeartBeat(心跳检测)之BPServiceActor工作线程运行流程》上、下两篇中，我们介绍了BPServiceActor工作线程的工作流程，即DN周期性发送心跳给NN的大致流程为：        1、连接NN并且完成两次握手。第一次握手获取命名空间信息并验证、设置；第二次握手完成DN的注册。        2、调用sendHear

在《Hadoop-2.4.1源码分析--HDFS HeartBeat(心跳检测)之DataNode端数据块增量汇报》中，介绍了在DN中调用NN的代理实例bpNamenode的blockReceivedAndDeleted()方法，由它负责向NamNode发送RPC请求，根据我们之前讲的RPC原理，可以得知在NN端必定也有一个blockReceivedAndDeleted()方法，执行具体的RPC请

原因是各子节点时间不同步！！！使用命令：ntpdate cn.pool.ntp.org进行时间同步！若报错为：ntpdate[3779]: the NTP socket is in use, exiting。原因是系统ntpd服务器正在运行中，可以通过 ps aux | grep ntpd 查看，如果还是要手动同步时间，就必须先停止该服务。可以使用命令 service ntpd s

hadoop2.0已经发布了稳定版本了，增加了很多特性，比如HDFS HA、YARN等。最新的hadoop-2.4.1又增加了YARN HA。本次安装基于hadoop-2.4.1。       注意：apache提供的hadoop-2.4.1的安装包是在32位操作系统编译的，因为hadoop依赖一些C++的本地库，所以如果在64位的操作上安装hadoop-2.4.1就需要重新在64操作系统

元数据备份目录项主要涉及的场景：1、NameNode启示时，从元数据备份目录中检查最新的fsimage和edits，读取到内存合并，然后将fsimage写回到指定的备份目录，并且重置edits2、元数据更新时，NameNode将日志写入edits3、做cheakpoint时，namenode将checkpoint好的fsimage写回，并重新配置edits1、nn启动加载元

在上一篇文章《Hadoop源码分析--FileSystem的创建过程》中(阅读地址-----------------------------------------------------http://blog.youkuaiyun.com/u010010428/article/details/51378378)，我们分析了HDFS的DistributedFileSystem对象的创建过程，之后就可以按照HD

首先，在自己写的MR程序中通过org.apache.hadoop.mapreduce.Job来创建Job。配置好之后通过waitForCompletion()方法来提交Job。Hadoop版本是2.4.1。       进入waitForCompletion()方法，在判断状态state可以提交Job后，执行submit()方法。monitorAndPrintJob()方法

在《Hadoop源码分析--HDFS HeartBeat(心跳检测)之BPServiceActor工作线程运行流程(上)》这篇文章中，我们介绍了BPServiceActor线程的工作大体流程，至于具体的细节部分，只是讲到了完成与NameNode的连接并进行两次握手的connectToNNAndHandshake()方法，还有一个offerService()方法，用于向NameNode发送心跳，并且

在《Hadoop源码分析--HDFS HeartBeat(心跳检测)整体结构》一文中，我们了解到HDFS心跳相关的BlockPoolManager、BPOfferService、BPServiceActor三者之间的关系，并且知道最终HDFS的心跳是通过BPServiceActor线程实现的。那么，这个BPServiceActor线程到底是如何工作的呢？本文，我们将继续HDFS心跳分析之BPSer

在上篇文章《Hadoop源码分析--HDFS HeartBeat(心跳检测)整体结构》中，详细了解了HDFS中关于心跳的整体结构，知道了BlockPoolManager、BPOfferService和BPServiceActor三者之间的关系。接下来，我们就开始研究HDFS心跳汇报之数据结构初始化。        首先，在DataNode节点启动时所必须执行的startDataNode()

HDFS全称是Hadoop Distribute FileSystem，即Hadoop分布式文件系统，有主从节点之分。在HDFS中，主节点是名字节点NameNode，它负责存储整个HDFS中文件元数据信息，保存了名字节点第一关系和名字节点第二关系。名字节点第一关系是文件与数据块的对应关系，在HDFS正常运行期间，保存在NameNode内存和FSImage文件中，并且在NameNode启动时就由FS

最近一段时间都在读HDFS关于Heartbeat(心跳检测)的源码，读的过程中忽然想到了以前在项目中用到的、为Nginx做HA的Keepalived，当时并没有注意，现在发现二者很相像，但细想又有许多的不同，所以梳理了一下，总结如下：To Be Continued 。。。

在上一篇文章《Hadoop源码分析--MapReduce作业(job)提交源码跟踪》中，我介绍了Job的提交过程源码，介绍的最后一个方法是submitJobInternal(Jobjob, Cluster cluster)，该方法向系统提交作业（该方法不仅设置mapper数量，还执行了一些其它操作如检查输出格式等），在该方法的第394行，涉及到如下一个方法--writeSplits()，该方法

元数据有三类信息：1、文件和目录自身的属性信息2、记录文件内容存储相关信息3、记录hdfs中所有DataNode的信息INode：文件和目录是文件系统的基本元素，hdfs将其抽象为INode，每一个文件或目录都对应一个唯一的INode，其存储了名字信息、创建时间、修改时间、父目录等信息。INode信息完全位于内存，类FSImage是构建在内存元数据与磁盘元数据文件之间的