自己学习hadoop有一段时间了，但总觉得所学习的东西比较碎片化，短时间无法形成一个系统的结构。所以抽空整理一下。
首先，在解决一些疑惑上面，以下博文都给了很大的帮助。
- Hadoop 面试相关，介绍一些基本的概念，很有用；
- HDFS 体系结构，对hdfs的拓展；
- NameNode、DataNode和Client三者之间协作关系及通信方式;
- Hadoop中Namenode单点故障;
- Zookeeper;
- DFSClient;
- 单点故障总结。
下面是用自己的语言作的相关总结。
什么是Hadoop, hadoop 就是一个大数据解决方案。它提供了一套分布式系统基础架构。 核心内容包含hdfs和mapreduce。hadoop2.0以后引入yarn.
-
那hdfs和mapreduce分别又是干什么的呢，hdfs是提供数据存储的，mapreduce是方便数据计算的。
a. hdfs 又对应namenode和datanode. namenode负责保存元数据的基本信息，datanode直接存放数据本身；
b. mapreduce对应jobtracker和tasktracker. jobtracker负责分发任务，tasktracker负责执行具体任务；
c. 所以对应到master/slave架构，namenode和jobtracker就应该对应到master, datanode和tasktracker就应该对应到slave.
Paste_Image.png
对应到这张图片，hadoop集群就大概是这样一个样子。一个集群有一个master，多个slave。一个namenode, 多个datanode。 datanode可以分组，每一组datanode之间有数据备份，一般是有3个数据备份。
那图片中的client又是什么呢，它是Hadoop中的另一个组件，DFSclient。 任何读写请求都要经过DFSClient发起，过程基本是这样，先和namenode建立连接，得到读/写数据的datanode信息。然后再与具体的datanode建立连接，进行读写操作。这个可以参考第6个链接，中间会有一些同步的操作。
既然说道datanode的数据同步，是通过什么东西来管理的呢，这个就是zookeeper的事了。zookeeper基本上能用到各种分布式架构上面实现数据的同步和管理。
hadoop只有一个master,是不是存在单点故障的问题。是的，既然master只有一个，那对应的namenode/jobtracker都存在单点故障问题。好在hadoop2有个secondaryNameNode可以保存一些editlog，必要时可以通过这个来恢复namenode。但是，namenode到secondaryNN是固定时间同步的，当故障发生时，中间或多或少会有数据丢失。况且，secondaryNN的作用并不是NN的备份，而是帮助NN更快的启动。所以，解决单点故障就需要有另一套解决方案。通常，一个NFS来实时同步editlog，再一个备份的NN实时根据editlog构建NN信息。当故障发生时，手动或自动迁移到备份的NN上。
什么是yarn, 其实yarn就是集成其他组件的工具。毕竟hdfs和mapreduce只是基础架构的组件，很多问题不能解决。
hadoop只有一个master,那处理的数据量是不是有限。这个问题是这样，master里只保存元数据的基本信息，所以，建议把小文件都转换成大文件。比如，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
既然hdfs能存储了，那hbase能干什么呢。hdfs只支持随机读。但是HBase可以随机读写。
HBase提供随机读写，来解决Hadoop不能处理的问题。HBase自底层设计开始即聚焦于各种可伸缩性问题：表可以很“高”，有数十亿个数据行；也可以很“宽”，有数百万个列；水平分区并在上千个普通商用机节点上自动复制。表的模式是物理存储的直接反映，使系统有可能提高高效的数据结构的序列化、存储和检索。
