开发者学堂课程【分布式系统开发调度技术：未来发展方向】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/367/detail/4372
未来发展方向
内容介绍：
一、在线应用与离线任务混跑
二、实时计算
三、更大规模
一、在线应用与离线任务混跑
随着集群规模越来越大，更多的业务需要共享这个集群，业务的种类不一样。
1.在线应用
如网页服务,进程起来之后不会退出，或者输入数据没有明显的起止点。
2.离线处理
如 MapReduce，输入数据是固定的，是一个文件或者是文件中的某一段，当app worker 运行完所需要处理的数据之后会退出。
不同的业务都有共享集群的需求，对分布式调度系统也提出了新的挑战，如何将在线应用与离线任务混跑。
在线应用作为长期运行的服务，对于整个进程，对于网络或者内存的访问的实施性或延迟要求非常高，不希望其它任务占用带宽，或者干扰它的运行，尤其在峰值时对性能的要求。
而离线任务，虽对实时性或延迟没有很高的要求，但是它对于类似磁盘 IO 或网络IO，甚至 CPU 需求非常忙，要求吞吐率足够高，这一点在业界的发展，如 Google，虽然没有开源它的系统，但是在论文里谈到未来的挑战是如何将整个公司内部的在线业务与离线任务并存，最大化的利用集群的物理资源，同时不干扰在线应用对于延迟的要求。
以阿里云的实践来看，目前通过一种超迈的机制来实现在线领取，在阿里集团例子是电商集群，作为电商平台，更多的用户购买是发生在白天期间，到了午间，夜间以后，尤其是凌晨这个时间段，是没有购买行为的，在这个时间段内，整个电商集群的资源利用率非常低，大多数CPU和内存处于休眠状态，那能否将一些其他业务如阿里妈妈，对于用户的点击行为等这些数据的分析，实际上是离线批处理的过程，能否将这些离线批处理的任务在电商集群夜间这一段时间能利用起来。
基本思想就是超迈，即电商集群处于休息的状态情况下，能够在很多在线的进程机器上，往上面调度一些离线的计算，能够将剩余的CPU和内存的计算能力能够利用起来。
这也是未来的趋势，包括在业界，雅虎或者其他云计算的平台，包括亚马逊也在探讨这些话题，如何将闲置的物理资源充分的利用起来，将在线和离线的任务能够统一在一个物理集群中。
二、实时计算
随着大数据的普及，更多的公司会想到如何利用大数据做一些实时的分析，如做商业智能BI的分析。
一个 dba 希望利用大数据能很快的完成一个 SQL 语句的执行，能够在秒级别能看到最后语句执行的结果，这对大规模的分布式系统也提出了要求，就是如何做到实时的计算，如业界一些较优秀的系统，如 STORM 的计算，Spark 系统，都是向着实施计算，如何能最快的完成用户的计算任务的角度去设计和开发的。
以及 flink 等，也是在如何最快的将用户的计算结果拿到同时不造成资源浪费这两个维度综合考虑，提出了些新的计算框架。
主要面临的问题是要追求性能，必然是要减少 mapper 和 reduce 这些进程的拉起和停止是有一定的系统开销，缩小这些系统的开销的同时是当拉进程，如果没有接到任务时，会不会造成资源浪费。这也是未来实时计算发展的框架，要考虑的两个维度，既要做到很快的完成计算，减小系统拉起和停止进程的开销，同时又希望能够做到最大化的利用集群的物理资源。
在这个方面，阿里云的飞天系统开发了一套实时计算框架称为 OnlineJob，它本质上是在线的服务，通过预起一组 Worker 进程作为常驻进程在集群中运行，等待用户从前端发来的计算任务，会立即跑一个语句，通过逻辑 plan 翻译到物理 plan,将这个物理的执行计划很快的发送到已经起来的 Worker 进程上瞬间完成计算。
目前通过测试结果，对于一个在t级别的计算任务可以在s级拿到计算结果。但是将一堆进程预先进行拉起，如果潜在的业务量不大的情况下，这个进程实际上是在消耗物理资源，并没有在做计算，存在一定资源浪费。
所以一个技术能够做到弹性的，动态的增加或减少这个预起的 Worker 进程，通过集群管理员的配置，通过发现这个集群白天的使用量和晚上的使用量的配置，框架知道什么时候该缩减 Worker 的数量，什么时候应该增加 Worker 的数量，做到弹性调节的过程，从而在业务不繁忙时，能够释放集群的资源，而在集群业务量上来时，能够要到资源，并且拉起一组常驻进程来瞬间响应，从而很快的完成用户的计算。
三、更大规模
1.时间维度
随着业务量的增多，更多的业务需要共享集群，原因是不同业务之间对于集群硬件的使用，在时间维度上是不一样的。
如阿里妈妈是一个批处理类型，更多的计算任务量发生在夜间，而电商网站更多的依赖于用户浏览，更多的业务量发生在白天，所以不同的业务或公司，他们业务的特点不一样，决定了对于集群的使用情况，在时间维度上不一样。
2.资源维度
对于有些计算，是内存型，需要大量的生存内存，但没有太多的计算量，而有些业务则是内存需求不多，但对于 CPU 的需求高，当运行时，CPU 负载非常高，所以不同业务在对于资源的维度使用上也存在一定的差异性。所以将这些业务放在一个集群上，最大化程度的利用整个物理资源的计算能力。
由于这方面的原因，更多的需求是能否将更多的业务放在同一集群上，因为如果在物理上隔开，互相补充的效果无法实现。所以更大的规模如何支撑、如何做到资源的调度、更快的资源调度、更大规模的任务调度，这是摆在大数据系统、分布式系统、云计算未来考虑的更长远的课题即支撑起更大规模的集群，更多并发量的任务
