自己学习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.
对应到这张图片,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自底层设计开始即聚焦于各种可伸缩性问题:表可以很“高”,有数十亿个数据行;也可以很“宽”,有数百万个列;水平分区并在上千个普通商用机节点上自动复制。表的模式是物理存储的直接反映,使系统有可能提高高效的数据结构的序列化、存储和检索。