膜拜！华为内部都在强推的783页大数据处理系统：Hadoop源代码pdf(3)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

第7章NodeManager与任务投运，用户提交的作业为 ResourceManager接受并得到调度运行之后,RM会设法将其投入运行。但是一 个 作 业 (Job 或 App)通常都包含着很多任务,比方说N个MapTask和1个ReduceTask,所以作业的投运终究会分解成许多任务的投运。

第8章MRAppMaster与作业投运，

第9章YARN子系统的计算框架，Hadoop中 YARN 子系统的使命是为用户提供大数据的计算框架。早期的 Hadoop,甚至早期的 YARN 都只提供一种计算框架,那就是 MapReduce。如前所述,MapReduce是一种极简的,然而在很多情况下颇为有效的计算模型和框架。

但是Hadoop的MapReduce框架要求使用者提供用Java语言编写的 Mapper和 Reducer,而 App本身则虽然简单但也要求用Java编写,这又使有些用户感到有点不便,而且 MapReduce这个模式也过于简单和单调。所以 Hadoop后来有了一些新的发展,除 MapReduce外又提供了称为Chain和Stream的计算框架。一来使用户不必非得用Java编程;二来更允许用户利用 Linux上的 Utility工具软件搭建更像“数据流”的结构。本章介绍 YARN 子系统为用户提供的计算框架,当然主要还是传统的 MapReduce框架。

第10章MapReduce框架中的数据流

第11章Hadoop的文件系统HDFS

第12章HDFS的DataNode

第13章DataNode与NameNode的互动，数据节点DataNode在运行中会与三种对端有互动。

第一种是NameNode,如前所述,对于数据块的存储地点,虽然最初是由NameNode分配和指定的,但相关的信息最终来自DataNode的报告。

第二种是用户的App(包括Shell),用户的App可以存在于集群内的任何节点上,不过那是在独立的JVM上,即使与DataNode同在-一个节点上也互相独立;然而真正把数据存储在DataNode上或从DataNode读取数据的却是App(或Shell)。

第三种是集群中别的DataNode,就是说DataNode与DataNode之间也会有通信和互动,这主要来自数据块复份replica的传输和转储。

数据块在HDFS文件系统中的存储是“狡兔三窟”的,一个数据块要分别存储在若干不同的DataNode.上,但是系统并不要求App把–个数据块分别发送给几个DataNode,而只需发送给其中的一个,后面就是DataNode之间的事了。

第14章DataNode间的互动

第15章HDFS的文件访问

第16章Hadoop的容错机制

第17章Hadoop的安全机制

第18章Hadoop的人机界面，供人们直接使用的系统须提供人机交互的手段,或称“人机界面(UserInterface)”即 UI,更确切地说是“Man-MachineInterface”,使人们得以使用和管理这个系统或平台。比

第19章Hadoop的部署和启动，系统的安装部署本来就不是小事,对于大规模的集群就更不用说了。Hadoop 一般都是在集群_上运行,但是要运维人员跑到每一台机器上去部署或启动却是不现实的，得要能在一个集中的控制台节点上完成Hadoop的部署和启动(还有关机)才好,这当然又会使整个过程增加许多技术上的复杂度。既然是在一个集中的控制台节点上部署和启动一个集群,那当然就离不开远程操作,所以Linux的远程操作工具ssh和rsyne就成了整个过程的基石。之所以是ssh和rsync,而不是别的远程操作工具(比方说Telnet),是因为这二者的安全性比较好,通信中采用了较强的加密手段。

第20章Spark的优化与改进

近年来, Hadoop与Spark 之间就像展开了一场你追我赶的竞赛。时至今日，Hadoop和Spark已经成为大数据处理平台的两个“de facto standard”,即“事实标准”。

不过Spark之于Hadoop也并非完全是对立的两种平台或产品,在很大程度上倒是对于Hadoop的补充，而并不完全是作为对于Hadoop的替代。

事实上,Spark虽然也能以“Stand alone"模式独立存在和运行,但是更多地还是利用YARN,在YARN框架上运行。而且Spark也不提供自己的文件系统，大多只是直接利用HDFS。虽然Spark并不要求必须使用HDFS,但是在大规模集群的条件下要实现“数据在哪里,计算就去哪里”这个原则,而且还要容错,实际上也没有太多的选择。

所以从功能上看，Spark的作用只是相当于一个更好的YARN子系统。

Hadoop的不足是明摆着的，总而言之，一是不够灵活、比较死板，就是专门针对MapReduce;二是性能不够好;三是使用不够方便,动不动就得写个Java程序。

那么Spark对此又有些什么样的改进呢?下面就作些介绍和评述,同时也对Hadoop和Spark做个粗泛的比较研究。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！