hadoop 笔记

我们常说的分布式系统，其实就是分布式软件系统，支持分布式处理的软件系统。他是在通信网络互联的多处理机体系结构上执行任务。

 

hadoop是分布式软件系统中文件系统层的软件，他实现了分布式文件系统和部分分布式数据库系统。hadoop中的分布式文件系统hdfs可以实现数据在计算机集群组成的云上，高效的存储和管理。hadoop中的并行编程框架mapreduce可以让用户编写hadoop应用程序。

 

mapreduce应用程序开发是基于mapreduce编程模型，mapreduce编程的原理是：利用输入一个key,value的集合处理后，来输出一个key,value的集合。mapreduce用两个函数表达这儿计算：map和redcue

 

mapreduce处理过程：

从hdfs上读取数据块，由一个个map去处理数据片段，将map任务的输出，按key相同的进行合并（key,value1,value2...）将合并后的结果交给

reduce处理，reduce输出结果文件到hdfs上。

 

分布式文件存储：

 hdfs有一个nameNode(在hadoop2中有两个nameNode)节点和多个dataNode节点组成，一个文件在hdf的底层会分成一个个block，block的默认大小是64M。一个block块会有多个副本（默认有三个），副本会存在不同的dataNode上，以达到容错容灾的目的。nameNode里存储的是文件的源信息（文件权限，拥有者，block块存储在哪台dataNode上等）

 

分布式并行计算：

hadoop中有一个主控的jobTracker和多个taskTracker，主控的jobTracker用于调度和管理其他的taskTracker，TaskTracker负责执行jobTracker分发给他的任务。jobTracker可以运行任意的一台机器上。taskTracker只能运行在dataNode节点上，所以说，dataNode不光是存储文件的节点也是计算节点。jobTracker会把任务分发给空闲的TaskTracker上执行，如果哪个TaskTracker出现故障，任务失败。jobTracker则会把这个任务再分给其他的空闲taskTracker执行

 

本地计算（移动计算而不是移动数据）

数据存储在哪台机器上，就由哪个机器进行计算。这样的好处是可以减少网络io，减少对网络带宽的要求。在hadoop这种分布式集群上，计算节点可以很容易的扩张。数据在不同计算机之间传输，故而网络带宽就成了颈瓶。所以本地计算是一种很有效的节约网络带宽的方法（移动计算比移动数据更经济）

 

任务粒度

把原始文件切成小数据片段，一般来说数据片段的大小要小于或者等于hdfs中block块的大小，这样可以保证一个数据片段是位于一个计算机上的，便于本地计算。n个数据片段由n个map任务执行，注意这n个map任务是分布于n台计算机上，将他们并行处理。reduce的数量可以由用于控制。

 

Mapper和Reduce中全局共享数据

（1）读取hdfs文件

这样可以很直观，缺点是就算是很小的全局数据需要读取hdfs文件，这将会占用网络io,占用系统资源

（2）读取job属性

在task运行的时，可以利用Configuration对象中config.set(name, value);读取job中的属性值，可以将简单的属性封装到配置的作业中，

优点是简单，消耗的资源小，缺点是：对于大的共享资源就没法了

（3）DistributedCache

是为应用提供缓存文件的工具，他可以缓存文本文件，hdfs文件，jar文件，压缩文件

优点是每个job共享文件在启动之后复制一次，可以适合大量的全局文件。缺点是他是只读的

 

shuffle和排序

shuffle就是map端的输出到redcue端的输入整个过程就是shuffle过程。我们为了让reducec端并行处理数据，所以对map的输出 要进行排序和处理。

shuffle的过程可以分为map端和reduce端：

map端shufflle会对map的输出结果进行 划分（pattion），排序(sort),分割（spllit），将划分好的map结果进行排序合并并写到磁盘上，同时按照不同的划分结果发送到对应的reduce上。reduce端会把不同map端送来的相同区域的数据给对应reduceTask去处理。

shuffle过程是mapperReduce的核心过程，shuffle的性能直接影响mapReduce的执行过程（默认shuffle过程并不是最优的，可以根据需求进行定义shuffle过程）

推测式执行

推测式执行就是当做作业启动时，jobTracker会计算整个作业的进度，当发现某一个map执行的速度要慢（cpu负载果高，运行的任务较多等）与整体的平均速度的时候，jobTracker就会重启一个备份的taskTracker去运行这个map. 哪个task先运行完，就kill掉另一个taskMap。

但是这样缺点是，如果是代码的问题，这样另起一个任务并不会有什么效果，反而会增加整个集群的负担（推测式执行要在整个作业都开始之后才会启动，并且只针对运行一段时间之后，执行的速度慢与整个作业），所以可以根据具体的情况而选择开启和关闭推测式执行。

jvm重用

不管是mapTask还是 reduceTask 都是运行在taskTracke节点上的java虚拟机（jvm)，每当taskTracker被分配一个任务，就会在本地启动一个新的java虚拟机。对于有大量零碎文件的map来说，启动那么多的虚拟机显然是不明智，优化有待提升的。如果在很多的时间一个map运行结束，让后续的任务继续重用这个虚拟机就是jvm重用。虽然一个taskTracker节点上可以有多个任务，但是他们都是运行在相互独立的虚拟机上的，taskTracker上的其他任务必须等待，就算是jvm重用也只能是顺序执行

控制jvm重用的属性是mapred.job.reuse.jvm.num.tasks  这个属性上定义了一个TaskTracker运行任务的最大数量，默认为1，可以自定义，为-1则表示没有数量限制

跳过坏环节

mapReduce执行的数据量非常的大，所以用户在编写程序是可能会疏忽或者数据中有坏的记录的存在，所以用户的代码在处理某个记录时可能会崩溃，这时虽然hadoop有处理这种错误的机制，即使再次重复执行也无济于事（ 默认是会重新执行4次），还是会导致整个作业的失败。但是要在庞大的数据量中找到坏的数据也是很困难，很费时的。所以就是当前代码执行时，遇到坏的记录就直接跳过去，然后继续执行（数据量很大的话，有个别错误数据也是可以忍受的）。

当忽略模式启动后，任务失败两次，他就会将错误信息告诉taskTracker，taskTracker就会重新启动一个任务去运行，当再次收到先前任务运行时所遇到的错误信息时，就会直接跳过改记录。忽略模式只适合忽略个别记录数

任务的执行环境

hadoop能够为执行任务的taskTracker提供任务的运行环境，比如map知道处理文件的名称，集群的id等，jobTracker在分配任务给taskTracker时候，会将作业的配置文件发送给taskTracker，taskTracker会将文件保存在本地。我们知道，taskTracker是运行在本地节点单独的jvm上一子进程的方式运行map和reduce,每一个map或者reduce都会启动一个新的jvm，子的jvm会继承父的jvm的执行环境。