开发者学堂课程【分布式计算入门：阿里计算核心技术概述】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/375/detail/4707
阿里计算核心技术概述
目录：
一、核心技术
二、数据收集
三、Shuffle机制
四、流运算的计算
五、分布式挑战
六、服务化诉求
七、增量计算语义
八、Batch
九、消息机制
一、核心技术
如下图所示，整个系统分成角色叫 jobmaster ，负责 job 整个的控制命令和生命周期，数据从源头读进来，有 source 节点，经过中间的处理节点 worker ，由整个 coordinator 负责消息机制以及运行时源信息的定义，用户可以全局统计源信息， coordinator 负责收集和计算这些源信息，供 jobmaster 判断，节点与节点之间的数据通路，抽象为shuffle ，它来决定节点与节点之间如何形式来通讯， output 负责计算结果与下游存储进行对接。整个 source 和 output 都采用了插件机制，源头可以对接任何外部系统，只需上传相应的插件，编写相应的插件即可。
二、数据收集
在介绍流运算系统的时候不可能避免的将会与外部系统进行整合，比如数据源和结果数据，介绍到数据源的时候就不可避免的要提到数据是怎么收集起来的，有两种方法，一种是拉的方法，一种是系统接收推的方法。
1、拉：
（1）消息队列例如 Kafka。
（2）其他存储 Hbase、HDFS 等系统。
（3）Source 节点主动的 pull 数据，借助这些源头以及持久化的数据，实现整个系统的故障恢复，也就是这些消息源头必须满足流运算系统对它的要求和约束，必须提供类似于游标这样的功能，以供整个系统的容错恢复，就涉及第三方服务系统的授权，因为数据系统边界并没有在整个流运算系统里面，作为一个云产品，它需要做系统授权。
2、推：
需要实现 Http 处理模块。整个系统需要实现 Http 插入接口，外部系统只需 push 过来，这种方法对外部数据源无依赖，系统持久化，数据的恢复容错完全由流运算系统内部来支持。
3、输出的方法：
（1）订阅：
结果数据写入消息队列，业务方订阅。
它将消息队列读出的队列存储进自己的在线系统或其他存储系统，那么订阅的 output 基本与外部系统结偶。
（2）服务：
系统直接提供在线数据服务、涉及第三方服务系统授权。
三、Shuffle机制
1、Pull：
Reduce 收到 jab 发来的控制命令，也就是告诉它整个 mab 结束并且告诉它相应的文件地址，从发起 pull 的命令，它会从相应的节点属于它的文件块全部给拖下来。
2、Push：
上游节点直接推送到下游节点，父节点需要知道子节点的部署和分布情况。
四、流运算的计算
流运算是长进程模式，它不像离线计算，这批数据计算完，这个进程会被返回到 rm 重新调度，以供其他任务复用。
1、Longlive：
不同的调度方式，不同的消费机制。
2、容错：
任务跟踪机制。
3、有状态计算：
中间状态的存储方式；容错。
五、分布式挑战
1、扩展能力
（1）集群规模的上限是多少？
比如一万台单集群所要能达到的每个节点每个资源的利用率应该在60%以上，否则就没有意义。
（2）计算作业是否可以线性增加？
随着集群规模扩大，作业量可不可以线性扩展。
2、数据倾斜问题
（1）用户可以重新定义等价的DAG来避免数据倾斜（牺牲性能）。
分布式计算的系统是受最慢的节点所影响，如果剧烈的数据倾斜将会导致整个计算的负载不均衡，所以最慢的节点会拖慢整个计算任务的延时。
（2）严重的倾斜带来超时/雪崩。
假设在一个集群，网络的io已经成为瓶颈，数据倾斜会带来少数的节点的计算超时，jobmaster会以为这些节点发生问题，它将会重播更多的数据用来容错，下发更多的数据，将会更加加剧整个网络的拥塞，进而加剧整个节点的超时，这个情况不断的恶化，最终导致整个集群的负载，所以在一个系统中或者一个工业级的产品中，设置反压机制，流控机制是至关重要的。
（3）数据动态的变化，实时调整。
六、服务化诉求
1、数据高可靠
数据中间状态的可靠性。
2、服务可用性
（1）集群扩容、系统代码升级时是否需要停止服务。
因为用户每时每刻都在使用这些服务，不可能因为集群的扩容、系统代码的升级而暂停用户的服务。
（2）单节点故障是否会导致整体服务的不可用。
3、通用需求
多租户管理：授权鉴权，资源隔离、计量计费、安全体系、运维体系等，这些都是对系统的核心要求。
七、增量计算语义
MRM 是一个计算模型，第一个M作为 local 的计算，R作为本批内数据的 aggregate 计算，第二个M作为跨批数据全局状态的聚合操作。
如图所示，每一列，就是每一个批次的数据都是一个独立的批量计算，merge 操作是将前后两个批次，不同的批次之间去做合并的操作。
假设刚开始的状态是0，第一次的merge以后是7，第二次就是5和7再 merge，oldvalue 就是状态，merge 是跨批操作，从一列看 map 和 reduce 是一个无状态的操作，它可以通过这一批数据重新计算 reduce 的结果，但是 merge 依赖本次 reduce 的结果和上次的 oldvalue 。
八、Batch
系统跟踪数据/时效性处理的最小单位，一个可以scale的概念，两个极端：退化为全量计算、一条数据。
简单的介绍case：
stream t1 = select sellerid, sum(money) as totalRealtimePay from pay group by sellerid;
按照卖家ID实时统计，卖家的实时成交情况。
stream t2 = select count(sellerid) from t1
group by totalRealtimePay /10;
按照每十块钱为一个档，来统计直方图。
假设目前sellerid为11的卖家初始化0元；第0档没卖家；第一档目前为10个卖家；第七档目前有53位卖家。
九、消息机制
流处理系统的重点和核心
1、消息框架分为三部分：
消息分发，接收，处理
在实践里，将整个 shuffle 独立剥离出来，当作一个 shuffle 的 framework ，进而抽象出来变成一个 shuffle 的 service 。
2、异常情况的处理：
程序 crash、容错、网络问题。
3、解决消息“丢失”的问题
整个计算系统分为两类：
（1）消息源头重发
优点：无故障情况下运行特别流畅。
缺点：DAG 大，加剧网络拥堵错误恢复时间较长。
（2）节点内部重放
优点；错误恢复迅速“雪崩”情况缓解。
缺点：每一步都要落地。
注意：流运算系统是一个有状态的计算，实现的模式是系统自动在源头重发和每一节重发两者之间做出动态自动选择。DAG 部分源头重发，部分父亲节点重发，系统可以做到动态的平衡，而每一级的消息持久化，不引入外部系统，而是利用了有状态计算的特性。
