当前位置: 首页>>hadoop 2.0之YARN>> 阅读正文

YARN/MRv2 MRAppMaster深入剖析—推测执行机制

Category: hadoop 2.0之YARN View: 7,045 Author: Dong
, , ,

  • 评论 (3)
  • 引用通告 (0)
发表评论 发起引用

  • 1楼xxdr 回复

    Post: 2013-04-01 14:10

    您好,请教一下,慢任务的调度执行和失败任务的调度执行,属于容错调度的范畴吗?慢任务和失败任务与“异常”的关系是怎样的?我认为它们很相近但又不一样。现在困惑的是说不出它们具体的区别来。

    [回复]

    Dong 回复:

    hadoop中有三种特殊的任务,failed task,killed task和speculative task,其中,failed task是由于硬件、程序bug等原因异常退出的任务,比如磁盘空间不足等, killed task是Hadoop主动将其杀死的任务,比如一个任务占用过多的内存,为了不影响其他作业的正常运行,Hadoop需将这种恶心的任务杀死,以保证为所有作业提供一个“和谐”的任务执行环境。在同错方面,failed task再次调度时不会在那些曾经失败的节点上运行,而killed task则可能被再次调度到任何一个节点上(包括曾经失败多的节点),因此,如果你目测一个作业的任务运行很慢,你可以使用“bin/hadoop job -fail-task xxx”让这个任务换一个节点重新运行,而不是使用“bin/hadoop job -kill-task xxx”。 speculative task是Hadoop针对那些慢任务(慢任务会拖慢一个作业的完成时间),为他们额外启动一个备份任务,一起处理同一份数据,哪个先执行完,则采用哪个的处理结果,同时将另外一个任务杀死。也就是说,推测执行是Hadoop对慢任务的一种优化机制(实际上就是“空间换时间”的经典优化思想),不属于容错调度范畴。

    [回复]

    xxdr 回复:

    多谢博主的解答!现在还有几个问题请教您:
    1、hadoop中的针对failed task和killed task的处理,我的理解是,在运行过程中,我们可以手动fail或kill掉某个任务。但是在大规模集群的实际运行过程中,这种问题可能经常出现,是否可以称为“异常成为了常态”?那么需要集群自动的failed task和killed task。 我现在的理解是,在hadoop启动的时候,就配置了一个时间阈值,当任务超过该时间阈值还没有响应,则主动failed task和killed task,(但是不明白到底是其中的哪个操作)。
    2、failed task,是在硬件、程序bug等原因主动退出的任务,hadoop是怎样自动的判断哪些task需要failed呢?
    3、speculative task是一种优化机制,为了加速运算;那么failed task和killed task就是为了容错吧?
    4、在异构hadoop集群(或者是大规模集群)下,异常成为了常态,博主认为这种说法科学吗?
    博主,我上面的理解不知道有没有偏差,请指教。

    [回复]

    xxdr 回复:

    博主,不好意思,第3个问题你已经回答了,speculative task属于优化,空间换时间;failed task 和killed task属于容错调度范畴。

    [回复]

    Dong 回复:

    1. 你再好好体会一下killed和failed的去呗,kill是Hadoop将主动任务杀死,这通常是由于Hadoop认为task出现了问题(比如长时间产生输出)或者是恶意的task(task使用超量内存)。而fail是任务自己退出(你的程序退出),比如内存不够,写磁盘失败等,框架并没有将task杀死,是task自己退出的,很多情况下会出现kill和failtask 我在此不细举例,你能想到的异常,hadoop差不多都已经考虑到了。
    2. 你明白了1, 就知道failed task是用户程序自己的行为,程序自己有bug、写磁盘失败,内存溢出等。
    4. 异构集群会有一些问题,但是,如何合理配置槽位,可以大大减少异常任务数目。 即使是同构集群,异常任务也很常见。

    [回复]

    xxdr 回复:

    Thank You!!

    [回复]

  • 2楼xxdr 回复

    Post: 2013-04-02 01:56

    关于慢任务的解决方案,我通过阅读博主的文章,有了初步的认识,感谢哈。。。

    [回复]

  • 3楼Andrew 回复

    Post: 2013-05-29 22:22

    学长,你的博客太强了。
    想请教一下:我想手动调整同一个MR作业中各个任务的container大小,不知能否做到?是通过调整配置参数,重写MRAppMaster,还是?
    例如:Job1 =
    我想实现 task1 <= 250MB, task2 <= 100MB, task3 <= 200MB.

    [回复]

    Dong 回复:

    现在MR仅支持两种container大小,一种是map(所有map task都一样),一种是reduce(所有reduce task都一样),而且是静态配置的,也就是说,作业提交的时候就要确定值,运行过程中不可以修改,如果你想做成动态的,可在现有的MRAppMaster基础上修改,比如可以接收来自客户端的命令,比如动态调整一个container大小的命令等,然后执行相应的操作,同样,对于YARN内核而言,container使用过程中大小不可改变,如果想改变,你需要修改相应代码。

    [回复]

    Andrew 回复:

    多谢多谢!好的,那么我修改下MRAppMaster试试看。
    能不能问句题外话,学长对Hadoop-2了解得这么系统,这些知识是从哪里来的?没搜到其他地方有这么专业的介绍啊。

    [回复]

    Dong 回复:

    自学。

    [回复]

    Andrew 回复:

    想问下学长,在不修改源代码的情况下,如何配置container大小呢?需要用到哪几个参数?

    我设置了-Dmapreduce.map.memory.mb=512,但是log显示分配给container的内存总是1024.请问有可能出了什么问题?

    [回复]

    Dong 回复:

    不应该啊,小伙子。

    [回复]

目前还没有任何Trackbacks和Pingbacks.
发表评论