课程链接:阿里云大学_分布式系统开发-调度技术
海量数据如何并发处理?
这就是分布式任务调度所要解决的问题
举个栗子:
如何快速的做出大量的热狗?
如果将每一个一个热狗按流程做的话,可见工作量会十分巨大而且效率低下
MapReduce实例
Google的传奇大神Jeff Dean借鉴函数式编程的思想,提出了MapReduce解决方案,其核心思想其实很简单:
- 对任务按需求切分成多个子任务
- 对每一个子任务做mapping映射操作,得到一个中间态结果
- 再对所有的中间态结果进行reduce合并,得到最终结果
我们换个角度理解MapReduce操作:
- 做热狗时,会有多个厨师分别把不同的原材料切好,这一步叫mapping操作,至于切成什么样可不是随便的,这要由问题的解空间决定,比如要做热狗,就要把面包切两半,而不是碾成面包糠,要把黄瓜切成片,而不是切成块
- 还会有一些厨师,按照一定的比例,将处理好的原材料组装成最终的热狗,这一步叫做reducing操作
关于MapReduce,有一个非常经典的案例就是Word Count,接下来通过一张图了解Word Count的流程:
其中Shuffle阶段是在mapping操作结束后,reducing操作开始前进行,它可以将mapping操作的结果进行一个小范围的聚合,可以减轻reduce拉取时的消耗
阿里飞天任务调度系统
飞天系统中,参与任务调度的主要有App Master和App Worker
App Master
- 向Fuxi Master发起资源请求
- 将资源分配结果下发给对应的集群节点上,拉起App Worker进程
- 负责监控Instance运行期间,如果发生故障,如何进行重试
App Worker
- 响应App Master发来的请求
- 进行运算,并将结果写到输出文件上
任务调度系统的技术要点
数据Locality
Instance运行时是要读取数据的,那么最好是让Instance在本地读取数据,因为如果远程读取数据的话,会涉及网络IO,这样会使性能下降,因此我们希望Instance能够多的在本地读取数据。下面举一个栗子
表中是每一个Instance在不同节点上的数据分布情况。为了使Instance尽可能多的在本地读取数据,我们可以这样分配Instance的存储节点
但是,这样还是存在问题,就是node3是空闲的,而node2非常繁忙
那么为了最大化的利用资源,究竟怎么重新分配Instance2和Instance3呢?
一种方法是这样:
这样一来,虽然每个节点都分配了Instance,但是可以发现,Instance3将会多出50%的远程数据读取消耗
如果我们这样分配:
那么,只需要牺牲10%的远程数据读取消耗就可以最大化的利用资源,同时提高效率
因此,不是一味地追求数据的本地化,而要全盘考虑资源的负载是否均衡
数据Shuffle
数据的Shuffle主要就是负责Map和Reduce之间的数据传递,其主要有这样几种模式:
通常,Map的结果需要写入分布式存储系统中去,然后Reduce再从分布式存储系统中拉取数据,因此这其中就涉及到了数据的格式问题,而现有的服务器系统会将数据的格式化封装到Streamline包中,用户只需要根据接口定义数据类型即可
Instance重跑和Backup Instance
错误在分布式系统中是十分常见的,对于不同的错误要有不同的处理方法
例如,当某一个作业进程崩溃,或是某一台机器宕机,那么任务调度系统,会立即将任务切换到另一台机器运行
还有一种情况是,运行并没有问题,但是由于机器硬件的性能退化,导致运行缓慢,那么这样的问题如何处理呢?
阿里云服务器系统提供了一种Backup Instance方法,当遇到这样的问题,App Master会将Instance再发送给另一台机器,两台机器同时运行Instance,谁先运行完毕就取谁的结果
但是这个机制的触发,需要以下条件:
- 运行时间超过其他Instance的平均运行时间
- 数据处理速度低于其他Instance的平均值
- 已完成的Instance比例