赞
踩
最近开始读<< Hadoop:the definitive guide>>,于是打算写点读书笔记,书电子版见网盘,密码v66s。
原书推荐的读书顺序如下图:
这里我们就按从第一章到最后一章的顺序读吧.
MR的思想非常简单,如下图所示:
MapReduce一般用Java实现,故我们需要注意以下的地方:
我们需要注意的以下几点:
map task将它的输出写在本地磁盘,而不是HDFS,因为这些数据都是暂时的,只需要作为输入提供给reduce,并不是最终结果。
此外还需要说明一点,在一些情况下,我们可以实现一个combiner函数,这个函数工作在每一个map之后,将map函数的输出先聚合好,再将其输出到reduce中。这样可以将map输出的中间结果规模减小,减少和reduce通信的规模。
HDFS被设计用于下面三个目的:
综上所述,HDFS不适用于下面的情况:
磁盘有一个Block的概念,它是磁盘读/写数据的最小单位,一般为512bytes。HDFS也有Block的概念,但它的块是一个很大的单元,默认是64MB。像硬盘中的文件系统一样,在HDFS中的文件将会按块大小进行分解,并作为独立的单元进行存储。但和硬盘中的文件系统不一样的是,存储在块中的一个比块小的文件并不会占据一个块大小盘物理空间(HDFS中一个块只存储一个文件的内容)。
HDFS中块之所以这么大主要有两个原因:
HDFS中块的好处:
HDFS中的节点是master-slave的工作模式,因此分为两种: 一个namenode 和多个 datanode。
Namenode负责管理文件系统命名空间,例如维护文件系统的树结构,还有树中所有文件和目录的元数据。这些信息分为两个部分: fsimage和edit log,前者是一个对hdfs文件系统的快照而后者是文件系统的改动序列。此外它知道一个文件的全部块在哪些datanode上。
Datanode则负责存储和读取这些blocks。此外他们还要定期向namenode报告存储的blocks的情况。
由于没有namenode, hdfs就不知道文件的组织结构,因此hadoop1.0中对namenode提供了两个容错机制:
但是这种primary-secondary的备份方式仍然不够好,实际上显然namenode仍然是单点失败的(single point of failure) ,因此如果它失败时从secondary恢复可能需要很久(如半个小时)。在hadoop2.0中提供了新的解决办法,即提供了对HA(high availability)的支持:active-standby namenodes。这种新的容错机制有和上面的相比如下特点:
这里的共享空间除了用NFS储存,hadoop本身还提供了QJM(quorum journal manager),这也是它推荐的方法。QJM使用了paxos协议,因此只要保证过半的存储节点没有失败,就不会导致edit logs丢失。利用了上面新的设计后,standby namenode可以在很多时间内(例如几十秒)接管active namenode的工作,原因是edit logs仍然在内存中,并且standby namenode中有最新的block mapping。
最后,如果standby namenode失败了,则直接从hadoop 集群中冷启动即可。这不会比non-HA的效果更差。
这部分略过,因为网上有很多相关博客,只说一点:
副本的概念对目录是无效的,因为它们的信息都用元数据存储在namenode中。
HDFS读写的过程见下面两张图,十分简单直接,这里不再赘述,有兴趣可以查阅其他博客。
这里简单展示一下hadoop的节点距离和3副本备份策略:
实际上hadoop先把第一个副本存在client所在的那个namenode(如果是外部的client则随机选取一个),然后把第二和第三个副本存在其他机架上的两个不同的node中。至于更多的副本则随机存储。
我们还需要介绍一下一致性模型(coherency model),即文件在读写时的数据可见性。HDFS中,所有block只有在写完后才对用户可见,如果它正在写则是用户不可见的。因此HDFS提供了两个函数来帮助用户:
最后我们在提一个hdfs指令:
hadoop distcp < dir1 > < dir2 >
这是hdsf并行地拷贝文件,往往在大规模数据迁移时很有用。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。