新手提问..帮扶正一下..看理解的对不对..

####################大结构层面########################
个人理解:
mr2跟yarn在逻辑上是互相独立的两个东西..互不影响..但互为合作...

yarn可以理解为 是一个定制版的容器.侧重于资源调度+管理.仅是jvm内的 Container.....docker侧重于资源服务打包..
而我们用hadoop在yarn上跑mr2..其实只是在yarn上封了一层...逻辑层面上是分开的...跟yarn是不牵扯的..只所以这么暧昧..是因为
1 都是用java搞的一套...(Mesos C++写的,docker 用go..)
2 YARN是从MapReduce中演化而来的,所以只能是一步一步解偶...

新框架(mr2)支持第三方(非Yarn架构) MapReduce 开发框架以支持如 SmartTalk/DGSG 等,注意通常情况下这个配置的值都设置为 Yarn,如果没有配置这项,那么提交的 Yarn job 只会运行在 locale 模式,而不是分布式模式。


而spark on yarn..应该是在yarn 的接口层..为spark实现了对接实现...而不需要spark自己来做资源管理


######################mr逻辑######################
个人理解就是:
1 client端完成split后.将运行job所需要的资源文件复制到HDFS上(包括MapReduce程序打包的JAR文件、配置文件和客户端计算所得的输入划分信息),注意:这里就相当于将job分开为task的雏形..这里还没有task的概念..只是将一个大job切成了很多个小job(split)..跟我们日常用的gearman/rabbitmq之类的里的队列里的message差不多...等着worker去消费..
2 资源调度master.去拿这些split..根据资源情况分配最合适的位置及机器来执行map任务.注意:资源调度master会.不断收到 slave的心跳.内容包括slave当前的状态..任务情况..同时会回给slave不同的信息..就单个map task而言...
    a 从hdfs读入数据到mem buffer处理..
    b 将处理的结果以kv的方式组成list..注意此时是key有续的..
    c 当map task内容较长 mem buffer装不下时..会spill到硬盘..注意 1 此时会combiner 2 此mem buffer是读写不互斥的.
    d 但最终一个map task只会有一个输出..会将spill出的多个磁盘文件merge成一个文件..注意此时会重复sort/combiner
    e 最终生成一个key/value输出文件..同时通知 资源调度master..map task完成.
3 当 资源调度master 收到slave的reduce类型心跳..若有完成的map task..则将map task的结果信息(包括目录位置名称等..)..返回给reduce 节点..
4 就单个reduce而言..Reducer在真正运行之前,所有的时间都是在拉取数据,做merge,且不断重复地在做。
    a Copy过程,简单地拉取数据。通过HTTP方式请求map task结果所在的node获取map task的输出文件。
    b Merge阶段。与map类似..不断的sort/combiner
    c Reducer的输出文件。不断地merge后,最后会生成一个“最终文件”。注意:最后一次合并的结果并没有写入磁盘,而是直接输入到reduce函数。



俺新手..这两天学习了一下.你看俺理解的对不对..不对的地方还莫要见笑。。

fish - Hadooper

赞同来自: hexuan1922 跃爷 鬼King2号

理解的挺好,大致是对的,不过有些细节,我觉得有些不妥。 1.

yarn可以理解为 是一个定制版的容器.侧重于资源调度+管理.仅是jvm内的 Container

Yarn中的“资源”概念确实是个抽象层的配置,但yarn的resource并不是仅仅的jvm的container,它也是借助于Linux本身的CGroup进行资源隔离和管理。   2.

d 但最终一个map task只会有一个输出..会将spill出的多个磁盘文件merge成一个文件..注意此时会重复sort/combiner

map task的输出数量与reduce数量相同,当有m个reduce时会最终生成m个中间文件。   3.

c Reducer的输出文件。不断地merge后,最后会生成一个“最终文件”。注意:最后一次合并的结果并没有写入磁盘,而是直接输入到reduce函数。

reduce的输入最后确实会合并成一个文件。但这个“最终文件”的不会全部直接读入reduce内存。因为这个“最终文件”可能非常巨大,采用全部入内存的方式在实际场景中可能会不适合。reduce以迭代器的方式不断从“最终文件”将内容一块块读入内存,这也是为何reduce方法的最后一个参数是Iterator,而不是List的原因(如果是全在内存中,用List岂不是更方便?)。

mengmeng - 大数据工程师

赞同来自: hexuan1922

不错

hexuan1922

赞同来自: fish

再次感谢...@fish..根据你的建议...mr逻辑部分..又整理了一下...   2 资源调度master.去拿这些split..根据资源情况分配最合适的位置及机器来执行map任务.注意:资源调度master会.不断收到 slave的心跳.内容包括slave当前的状态..任务情况..同时会回给slave不同的信息..就单个map task而言...     a 从hdfs读入数据到mem buffer处理..     b 就单行数据而言..是一个key/value对..当前的“key”应该交由哪个reduce去做呢,是需要现在决定的,默认为key hash对reduce个数取模.mr框架也提供Partitioner接口..用便用户自定义规则..(Partitioner)     c 将map的处理结果以kv的方式组成list..注意此时是key有续的..(sort)     d 当map task内容较长 mem buffer装不下时..会spill到硬盘..(combiner)注意 1 此时会combiner 2 此mem buffer是读写不互斥的.     e 随着maptask spill出来的文件越多..会将spill出的多个磁盘文件merge成一个文件..(merge)注意此时会重复sort/combiner     f 最终生成一/多个key/value输出文件(输出数量与reduce数量相同,当有m个reduce时会最终生成m个中间文件。)..同时通知 资源调度master..map task完成.  

hexuan1922

赞同来自:

再追问一个问题.. 假如在wordcount例子中..未设定setCombinerClass.且只有一个reduce节点.那 单个maptask spill出来的单个文件格式应该是<ERROR,1>,<WARNING,1>,<WARNING,1>.....这样一个Key-Value序列.. 当merge 在硬盘上的多个spill文件时: 1 会形成<ERROR, <1,1,.....>>,<WARNING,<1,1,...>>这样一个仍然是Key-Value的 序列,1、1、。。。分别表示第1、2、。。。个spill文件中ERROR的列表??? 2 会形成<ERROR, <14,36,.....>>,<WARNING,<27,45,...>>这样一个仍然是Key-Value的 序列,14、36、。。。分别表示第1、2、。。。个spill文件中ERROR的统计次数, 输出会是那一个?? @fish @mengmeng   我猜会是第一个..变成一个列表...如果是1的话...那再追问几个 1 只有setCombinerClass了..才会按setCombinerClass的逻辑combine?? 2 merge只做同key合为list...不做任何其它逻辑??... 3 有没有像setCombinerClass一样自定义这个setMergeClass吗??  

hexuan1922

赞同来自:

赞一个...   再追问: 还是上边的场景..如果设定setCombinerClass.且只有一个reduce节点.那 单个maptask spill出来的单个文件格式可能是<ERROR,15>,<WARNING,21>,<INFO,33>.....这样一个Key-Value序列.. 当merge 在硬盘上的多个spill文件时: 会形成<ERROR, <15,36,.....>>,<WARNING,<21,45,...>>,<INFO,<33,65,...>>这样一个仍然是Key-Value的 序列,15、36、。。。分别表示第1、2、。。。个spill文件中ERROR的统计次数 还此时会不会有 Combiner ???

要回复问题请先登录注册