关于Hadoop分布式计算:多个Map分布在不同节点上执行

1 背景&问题

    学习Hadoop已经快一年了,也是似懂非懂的样子。由于项目的原因,再次启动Hadoop,一直以为这个很简单就能够实现多个机器一起完成一个任务,其实并不然。在实验过程中,发现Map的数量并不能通过设置“mapreduce.job.maps"来改变,这方面的资料也有很多。而且最大问题是,只有当输入文件分块达到8时才会出现7个分布在一个节点上,另外一个分布在另一个节点上。这个是与资源申请有关“Containers”(具体可以参考牛人“董的博客”),每个节点最多能容纳8个Containers(可以通过web查看),大致解释是一个Job对应一个Containers,然后每个Map也是。但是输入文件分块多,导致map数量变多,这样消耗的时间会更多。怎么才能做到多个Map比较均匀分布在不同的机器上呢?


2 解决过程

    第一章中,已经描述了,只有分块很多时,才能分布在不同节点上,但这并不是有效的方法。于是抱着尝试的心态“如果有多个Job呢,每个Job分成3个Map(用3个输入文件),能不能达到并行的效果”。今天,做了几个实验,猜对了,比如:6000条记录放在一个文本里,只有一个Map执行;如果将6000行纪录分割成6部分,两个Job分别处理3个小文件。同时执行这两任务,第一个测试耗时:10185s,第二个测试耗时:7572s。下图是将6000条记录分成3个Job每个Job对应4个小文件(当作四个splits),执行3个Job任务如下:


每个节点上均分配了4个Map任务,另外3个是ApplicationMaster,这里不讨论。

2.1 201610
    发现上述方法治标不治本,于是又查找资料,只需修改yarn-site.xml配置文件即可,关于这些参数说明,网上资源还是很多,这里先不多说了,后续。

<property>
	<name>yarn.scheduler.minimum-allocation-mb</name>
	<value>256<alue>
</property>

<property>
	<name>yarn.nodemanager.resource.memory-mb</name>
	<value>4096</value>
</property>


    一个节点上运行的任务数目主要由两个因素决定,一个是NodeManager可使用的资源总量,一个是单个任务的资源需求量,比如一个NodeManager上可用资源为8 GB内存,8 cpu,单个任务资源需求量为1 GB内存,1cpu,则该节点最多运行8个任务。NodeManager上可用资源是由管理员在配置文件yarn-site.xml中配置的,相关参数如下:
    yarn.nodemanager.resource.memory-mb:总的可用物理内存量,默认是8096
    yarn.nodemanager.resource.cpu-vcores:总的可用CPU数目,默认是8
对于任务的相关参数如下:
    yarn.scheduler.minimum-allocation-mb:最小可申请内存量,默认是1024
    yarn.scheduler.minimum-allocation-vcores:最小可申请CPU数,默认是1
    yarn.scheduler.maximum-allocation-mb:最大可申请内存量,默认是8096
    yarn.scheduler.maximum-allocation-vcores:最大可申请CPU数,默认是4

3 总结

    后面继续把数据量增多,感觉这样做还可以。因为网上谈这方面基本没有,所以先把思路纪录下来,后面再把实验进行可视化,进一步证明这样做的可行性。

  • 7
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
FourInOne(中文名字“四不像”)是一个四合一分布式计算框架,在写这个框架之前,我也看了老外写的其他开源框架,也对分布式计算进行了长时间的思考,当我们把复杂的hadoop当作一门学科学习时,似乎忘记了我们想解决问题的初衷:我们仅仅是想写个程序把几台甚至更多的机器一起用起来计算,把更多的cpu和内存利用上,来解决我们数量大和计算复杂的问题,当然这个过程中要考虑到分布式的协同和故障处理。如果仅仅是为了实现这个简单的初衷,为什么一切会那么复杂,我觉的自己可以写一个更简单的东西,它不需要过度设计,只需要看上去更酷一点,更小巧一点,功能更强一点。于是我将自己对分布式的理解融入到这个框架中,考虑到底层实现技术的相似性,我将Hadoop,Zookeeper,MQ,分布式缓存四大主要的分布式计算功能合为一个框架内,对复杂的分布式计算应用进行了大量简化和归纳。 首先,对分布式协同方面,它实现了Zookeeper所有的功能,并且做了很多改进,包括简化Zookeeper的树型结构,用domain/node两层结构取代,简化Watch回调多线程等待编程模型,用更直观的容易保证业务逻辑完整性的内容变化事件以及状态轮循取代,Zookeeper只能存储信息不大于1M的内容,FourInOne超过1M的内容会以内存隐射文件存储,增强了它的存储功能,简化了Zookeeper的ACL权限功能,用更为程序员熟悉rw风格取代,简化了Zookeeper的临时节点和序列节点等类型,取代为在创建节点时是否指定保持心跳,心跳断掉时节点会自动删除。FourInOne是高可用的,没有单点问题,可以有任意多个复本,它的复制不是定时而是基于内容变更复制,有更高的性能,FourInOne实现了领导者选举算法(但不是Paxos),在领导者服务器宕机情况下,会自动不延时的将请求切换到备份服务器上,选举出新的领导者进行服务,这个过程中,心跳节点仍然能保持健壮的稳定性,迅速跟新的领导者保持心跳连接。基于FourInOne可以轻松实现分布式配置信息,集群管理,故障节点检测,分布式锁,以及淘宝configserver等等协同功能。 其次, FourInOne可以提供完整的分布式缓存功能。如果对一个中小型的互联网或者企业应用,仅仅利用domain/node进行k/v的存储即可,因为domain/node都是内存操作而且读写锁分离,同时拥有复制备份,完全满足缓存的高性能与可靠性。对于大型互联网应用,高峰访问量上百万的并发读写吞吐量,会超出单台服务器的承受力,FourInOne提供了fa?ade的解决方案去解决大集群的分布式缓存,利用硬件负载均衡路由到一组fa?ade服务器上,fa?ade可以自动为缓存内容生成key,并根据key准确找到散落在背后的缓存集群的具体哪台服务器,当缓存服务器的容量到达限制时,可以自由扩容,不需要成倍扩容,因为fa?ade的算法会登记服务器扩容时间版本,并将key智能的跟这个时间匹配,这样在扩容后还能准确找到之前分配到的服务器。另外,基于FourInOne可以轻松实现web应用的session功能,只需要将生成的key写入客户端cookie即可。 FourInOne对于分布式大数据量并行计算的解决方案不同于复杂的hadoop,它不像hadoop的中间计算结果依赖于hdfs,它使用不同map/reduce的全新设计模式解决问题。FourInOne有“包工头”,“农民工”,“手工仓库”的几个核心概念。“农民工”为一个计算节点,可以部署在多个机器,它由开发者自由实现,计算时,“农民工”到“手工仓库”获取输入资源,再将计算结果放回“手工仓库”返回给“包工头”。“包工头”负责承包一个复杂项目的一部分,可以理解为一个分配任务和调度程序,它由开发者自己实现,开发者可以自由控制调度过程,比如按照“农民工”的数量将源数据切分成多少份,然后远程分配给“农民工”节点进行计算处理,它处理完的中间结果数据不限制保存在hdfs里,而可以自由控制保存在分布式缓存、数据库、分布式文件里。如果需要结果数据的合并,可以新建立一个“包工头”的任务分配进行完成。多个“包工头”之间进行责任链式处理。总的来说,是将大数据的复杂分布式计算,设计为一个链式的多“包工头”环节去处理,每个环节包括利用多台“农民工”机器进行并行计算,无论是拆分计算任务还是合并结果,都可以设计为一个单独的“包工头”环节。这样做的好处是,开发者有更大能力去深入控制并行计算的过程,去保持使用并行计算实现业务逻辑的完整性,而且对各种不同类型的并行计算场景也能灵活处理,不会因为某些特殊场景被map/reduce的框架限制住思维,并且链式的每个环节也方便进行监控过程。 FourInOne也可以当成简单的mq来使用,将domain视为mq队

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值