来源：http://www.cnblogs.com/laov/p/3434917.html
Hadoop核心
HDFS(Hadoop Distributed File System) ：Hadoop分布式文件系统。
特点：保存多个副本，且提供容错机制，副本丢失或者宕机自动恢复，默认保存3份。
运行在廉价的机器上
适合大数据处理。多大？越大越好。HDFS会默认将文件分割成block，默认64M为一个block。然后将block按键值对存储在HDFS上，并将键值对映射到内存中。如果小文件太多，那内存的负担会很重。
HDFS也是按照Master和Slave的结构。分为NameNode 、SecondaryNameNode 、DataNode 这几个角色。
NameNode：是Master节点，大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间。
SecondaryNameNode：是小弟，辅助大领导。分担NameNode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
DataNode：Slave节点，奴隶，负责存储client发来的数据块；执行数据块的读写操作。
热备份：b是a的热备份，如果a坏掉，那么b会马上自动运行代替a的工作。
冷备份：b是a的冷备份，如果a坏掉，那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。
fsimage：元数据镜像文件（文件系统的目录树）
edits：元数据的操作日志（针对文件系统做的修改记录）
namenode内存中存储的是：fsimage+sdits
SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量。
工作原理：
写操作：
比如我将要把本地上一百兆的文件A写入HDFS文件系统上，将会发生那些事情呢？？
1.Client将文件按64M分割，分为若干个Block,这里文件被分为量块：Block1为64M,Block2为36M
2.Client向NameNode发生写数据请求：领导，我想要把两个Block共一百M写入HDFS上去,批准否？
3.领导收到请求，想了片刻，你有两个Block，我看看手下有几个奴隶（DataNode），好吧。我来分配下：
Block1：host2,host1,host3
Block2:host7,host8,host4
然后把这些信息反馈给client，批准啦！至于领导怎么分配肯定是有规则的，不是凭空决定的，它的规则我们稍后说。
4.client得到批准以后，就可以安安静静的向奴隶们(DataNode)发数据啦,发生过程是以流式写入的。
流式写入过程：
a. 先将64M的Block1按64K划分，我们把每一个64K称为package
b. client将第一个package发送给host2；（根据领导的信息）
c. host2接收完后，就会将这个package发送给host1，与此同时，client也不会闲着，向host2第二个package呢；
d. host1接收到了host2发来的第一个package后，发送给host3，与此同时接收host2发来的第二个package
以此类推，直到将block1发送完毕。
e. 当Block1真的全部发送完了后，三个奴隶（host2,host1,host3）向领导（NameNode）报告任务完成了。而且【host2】奴隶2（谁叫我排第一个呢）还要和client沟通，我们这交易结束了哦。
f. client虽然把Block1发送出去了，还有二胎Block2呢，也许后面还有N多胎呢！！！
同样的套路，client根据领导的信息，将block2发送给另外的奴隶们（host7，host8，host4）
直到将所有的Block全部写到HDFS上。
最后，我们再来看看这些奴隶手上的数据：
MapReduce: