白话分布式 之 分布式计算框架——Spark
日期:2018-09-13 17:45:47 / 人气:1701
分布式存储出现是因为单机存储资源有限且难以扩展,分布式计算出现同样是因为单机计算资源有限且难以扩展。存储资源一般指磁盘容量,而计算资源通常指内存和 CPU。
我们引用中科院的定义来详细看一下分布式计算到底是什么:
分布式计算是一种新的计算方式。所谓分布式计算就是在两个或多个软件互相共享信息,这些软件既可以在同一台计算机上运行,也可以在通过网络连接起来的多台计算机上运行。
分布式计算比起其它算法具有以下几个优点:
1、稀有资源可以共享。
2、通过分布式计算可以在多台计算机上平衡计算负载。
3、可以把程序放在最适合运行它的计算机上。
这个定义真的是精辟,不仅指出了分布式计算的内涵,也同样指出了分布式计算的问题。我们分解一下这个定义。
首先我们标注一些关键词:软件,网络,运行,资源,共享,平衡,负载,适合。
我们不看上面的定义,只看这些关键词,便可以勾勒出分布式计算需要的子系统:
1、调度系统:对应关键词 平衡,适合,负载 --> 想要生活的井井有条,最好有人帮你安排好。
2、通信系统:对应关键词 网络,共享 --> 想要沟通一起玩耍,至少有个电话吧。
3、计算系统:对应关键词 软件,资源,运行 --> 想要吃饭,至少有个活厨子吧。
同样,我们可以先列举这些关键词的对立面:网络不可靠,运行出问题,资源不足,共享不畅,分配不平衡,负载过大,不适合 根据这些反向关键词勾勒出分布式系统可能存在的问题:
1、资源调度不合理,导致负载不平衡,不能充分使用集群资源: 对应关键字 资源不足,分配不平衡,负载过大,不适合。
2、计算可靠性不高导致结果错误或者计算失败 : 对应关键字 网络不可靠,运行出问题。
调度问题占了 4 个关键字,占总关键字的 67 %,说明中科院认为调度问题是分布式计算的最关键因素,是的,我们也是这么认为的。所以我们会首先介绍 spark 的调度系统,然后带出其他两个系统,顺便将 spark 解决两个问题的方案带出来。
Spark 框架
Spark 的调度系统从上到下包括 DAGScheduler(Job 级调度器)和TaskScheduler(Task 级调度器)和 SchedulerBackend(调度资源管理器)组成,其关系如下图所示:
为了让大家快速对这个流程有一个直观的认识,我们参照例子解释一下:
学校刚来的校长(DAGScheduler)决定梳理一下学校现状,统计学校男女学生的人数,出一份报表(Job - 输出男女人数报表),决定让秘书先找人按照班级各自统计一下男女人数,每个班产生一个报表,然后让合并男生和女生的数量(两个 Stage - 班级报表,报表合并),校长同时规定了最多派多少组人(Executor - 实际执行工作的环境,对应 Java 虚拟机)去干这件事,每个组最多多少人(Thread - 单个 Executor 中最大的并行工作个体,对应 CPU 核数 - 每个 Thread 只能干单一的活,要不只统计男生数量,要不只统计女生数量)。
秘书拿到指令后,根据班级的数量,班级人数和班级的位置对组进行具体工作的规划(比如说哪组人负责那几个班级最快-离得最近)。
然后秘书到外包公司集团(SchedulerBackend - 专门外包人力的组织)按照规划要人,外包集团会将人力需求分配到各个公司(Worker),如果正好所有人都被派出了,就告诉秘书等一会儿(Spark 程序启动时的 Accept 状态),一旦有人回来了,外包集团就让这个人按照规划去对应的几个班级统计男女人数(Task - 数量等于班级数 * 2 - 因为每个班都要统计男生和女生数量),随着人员逐渐回归,派出的人数也会逐渐跟上规划。
校长会跟踪统计的情况,每当有一个班级的男生或者女生被统计出来了,校长就掏出小本在待办清单上把这个 Task 抹掉,直到所有的都抹掉了,然后去看每个班报表是否都生成了,就认为班级统计(第一个 Stage )完成了,同理,校长也会统计 Stage 数量用来判断 Job 是否完成了。
虽然这个工作使用 Spark 的框架做有点杀鸡用牛刀,但是上面的例子应该会让大家对于其中的概念有一个大概的认识,我们下面再对这些概念给出相对严格的定义。
- Job 指一次 action 操作,Spark 对数据的操作包括 transform 操作和 action 操作,action 操作指有数据输出(无论是输出到文件还是输出到控制台)的操作,spark 是懒的,一段程序只有遇到 action 操作才会真正调度执行。Spark 按照 action 操作对应用进行 Job 切分。
- Stage 一个 Job 会根据 Shuffle 被拆分为多个 Stage 。所谓的 shuffle 就是宽依赖。所谓的宽依赖就是父 RDD 的分区影响了多个 RDD 的分区。
- Task Spark 最小执行单元,一般而言数据每个 partition 对应一个 Task。
- Driver 就是代码中的 SparkContext,整个 Spark 作业启动、调度、监控者。
- Worker 可运行的物理节点。
- Executor 执行 Spark 的处理程序,也就是一个 JVM进程,如果使用 yarn 调度的话则对应 yarn 中的一个 Container。
这些概念的关系在上面的例子中便可以推演出来,官方的图则更加简明一些:
虽然 Spark 有自己的调度机制和调度逻辑,但是也只能实现多个提交的 Job 内做出优化,如果要针对集群资源情况和负载压力做出最佳的分配决策,仅凭 Spark 本身是做不到的。所以在工程应用上,很少会单独部署和使用 Spark ,而是将其与 yarn 结合起来,利用 yarn 资源管理和分配能力给出最优的分配策略。
实际上, MapReduce 和 Storm 也通常会依赖 yarn 的资源管理能力。这也就是上文中第一个问题的答案——不要逞能,专业的事情交给专业的人做。
Spark 的内部通信是非常复杂的,client 与 master 之间, master 与 worker 之间 ,worker 内部之间都有通信,而且整个运作时很快的,资源消耗也是比较大的。所以不会采用阻塞 I/O 的方式在线等待,理所当然的选择了 NIO(发出响应后立刻返回,释放资源,等待回调)模型。实际上,几乎没有哪个大数据在线系统会不采用这种方案。在 1.6 之前,Spark 采用了基于 Actor 模型的 Akka 通信框架,但是因为一些管理和依赖冲突的考虑,在 1.6 以后替换成了 Netty 框架。
Spark 也使用了一系列的超时机制来防止网络异常带来的问题, 通过累加器计数来识别运行时的异常并会使用 Stage 重新提交来解决这些异常。
作者:admin
新闻资讯 News
- 讯宜捷成功签约深圳芯而达05-18
- 讯宜捷成功签约洛阳锐英机械05-18
- 讯宜捷成功签约深圳美达05-18
- 讯宜捷成功签约河南渡渡鸟网络科...05-18
案例展示 Case
- 地跨“半壁江山”06-23
- 【蒙牛清远】设备维护保养系统再...05-18
- 【青木合众】复杂问题简单化就是...05-10
- 【乐山商场】拯救零售服务的商业...05-05
- 【国企中石油】税银综合管理平台...05-15
- 【上田财富】信息化财富管理机构...05-05