在1年半以前，个人开始接触hadoop相关的东西，但是那时没有做一些集群来做实验，现在hadoop已经增加了HA相关的特性，商业化的特性越来越足，再重新回过头来学习hadoop相关的生态技术，以增加自己对大数据处理板块的理解，也提高自己对目前IT圈内big data的各种新闻的思辨能力！

一.hadoop中的MapReduce有三大设计目标：

（1）为只需短短几分钟或几个小时就可以完成的作业提供服务；

（2）运行与同一个内部有告诉网络连接的数据中心内；

（3）数据中心内的计算机都是可靠的、定制的硬件。

与set@home项目进行对比，再比对mapreduce的设计目标，探究为何？mapreduce是不是不太适合计算密集型的业务。

二.2.x版本是经过hadoop社区投票决定将0.23的后续版本改为2.x,新增特性包括：

1.YARN（yet another resource negotiator）资源协调管理器

2.HDFS的联邦管理

3.HDFS的高可用，采用secondNameNode机制

secondNameNode的机制，checkpoint 和fsimage、editlog等保证高可用，可靠性大大增加。

三.HDFS

是为高数据吞吐量而设计的，如果考虑到低延迟的应用，可能Hbase比较适合。

小文件，由于NameNode管理文件信息元数据，受限于NN节点内存的大小，所以小文件并不适合hdfs，可以通过cat等操作将小文件拼接。

写的问题，由于是多节点存储，修改文件的代价是巨大的，HDFS不支持随机写，但是可追加。（流的模式，体现的是高吞吐的特点）

NN的容错机制分为两种：

1.NN保存元数据的操作是原子的，在写入本地文件系统的同时，也写入到远程挂载的网络文件系统（NFS）

2.采用secode NameNode，定期编辑日志文件并合并命名空间镜像，以防止编辑日志（editlog文件）过大。这个SNN的CPU性能要ok，因为它需要进行大量的计算来合并操作。辅助的NN的状态总是滞后于NN的，如果主NN宕机，难免会有部分数据丢失，因此second Name Node可以借助于网络的文件系统来恢复丢失的数据。

联邦HDFS

受限于NN节点的硬件，HDFS的横向拓展受到障碍。因此联邦HDFS引入到了2.x的Hadoop：

1.系统通过添加NN节点来实现横向拓展

 2.每个NN管理一个命名空间，比如NN1管理 /usr,NN2管理/data

 3.每个DN节点需要向所有NN节点注册

每个NN维护一个命名空间卷（namespace volume），namespace volume之间彼此独立，互不影响。

导入HDFS工具

Flume 是将大规模流数据导入HDFS的工具，典型应用是收集日志。

Sqoop是将结构化存储数据导入到HDFS，典型应用是将白天生产的数据在晚间导入到Hive数据仓库

distcp复制：两个hadoop集群（相同版本）之间并行复制大量数据。采用mapreduce的方式在两个集群之间复制数据，这里没有reducer。每个文件通过map进行，每个节点map的数量可以通过-m来指定。比如1000G的数据复制，-m 1000，则分配1000个map，每个map复制1G数据。

不相同版本的hadoop RPC是不兼容的。弥补的方式：采用基于只读的http协议HFTP文件系统从源文件系统中读取数据

例子：hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar

可以看到有指定的端口以及hftp协议。使用新出webhdfs协议代理hftp，可以避免兼容性问题。

如果再集群中使用了hdfs proxy，distcp的源或者目标是proxy，则具备了设置防火墙和控制带宽的优点。

保持HDFS的均衡

大量数据复制的时候，考虑集群的均衡很重要。数据块的分布要合理，map的数量要适应集群的规模。1000G的数据，如果是1个map则非常不合适，单节点负担重，系统负载不均衡。如果为了节约资源给其它job，可以考虑用负载均衡器工具来改善集群中块分布的均匀程度。