开发者学堂课程【分布式计算入门：流式计算概述】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/375/detail/4709
流式计算概述（二）
内容介绍
一、增量计算和流式计算的特点
一、增量计算和流式计算的特点
1.数据特点→流/ delta
流：由业务产生的有向无界的数据流
不可控性（到达时机、相关数据顺序、数据质量、数据规模）
不同的数据通路，到达的时机完全不可控。
比如说我们要计算五分钟的一个滑窗，12：00~12:05的固定窗口，但是由于某些不可控原因，最近这个数据通路他上报的数据12点的数据，有可能在12:30才上报。那么这个数据怎么进行有效的、实时的和保证正确性的计算？因为这个12点的数据12:30才来。
如果要把这个固定窗口五分钟的计算是 willdefine，所以你就必须得等到12:30乃至更久。所以它的整个的实时性完全不可控，要处理这样子的问题，将会引入流式计算或者增量计算一个非常重要的特性，当然现在也在业界不同流派有争议，就是引入 updated 语句。
大家都知道计算是具备确定性，也就是说这个结果，比如说输出这个一个计算结果五分钟的固定窗口，那输出的这个数一定是确定是，也就是说它不可再被更改。
那么在这种场景下，不被更改就意味着延时。因为不知道不同的通路，它的数据到底到达时机在什么时候？所以必须得等一个时间，那么这就会大大造成整个的计算实效性是不可控。
引入 update 语句，等于也就是说我之前可以将12：00~12:05的固定窗口的计算值输出。当12点~12.5的是真实的数据在12:30来的时候，可以将这个值补偿进去，将原来的那个值进行 update 。
update 语句：对系统后续的设计、容错及语义方面产生极大的影响。
大家可以想一下传统的离线计算或者批量计算，那么我在11月12号的凌晨，技术人员是可以预估出前面的流量，做出一些系统扩容和任务配置扩容的一些决定。但是实时或者流失的计算，这个系统的洪峰，从用户端在两秒内就到达了计算系统。是完全没有机会去做对规模进行反应，所以这对我们计算的整个弹性对规模，对现行扩展性提出了比离线计算和批量计算更高的要求。
体系缺失（数据源的治理、数据质量的治理）
传统的离线计算和批量计算，它的相关的数据仓库的质量体系已经构筑的比较完善和完备。那么在生命这个新的应用场景下，无论是数据源的治理还是数据质量的治理，其实这个体系都是相对非常缺失，包括阿里巴巴内部，也在构建整个的数据治理体系，它不仅仅是计算的问题。那么基于对计算的时效性和数据的时效性的要求，整个增量或者流式计算系统，它的容错方案、它的体系结构和它的结果输出的方式都与传统的离线计算和增量提成方式完全不同。这给我们提供了非常大的发展空间和挑战。
时效性要求（容错方案、体系结构、结果输出）
对整个计算的处理的数据力度，有更高的要求。
2.处理粒度最小
流式计算系统或者增量计算系统，它的处理粒度相对比较小。比如说可能每次只处理几条数据，甚至可以一条数据。当然也可以上亿条数据。
对整个系统架构具有决定性影响。
3.处理算子对状态的影响不同
像有些计算它是无状态的计算，有些是有状态的计算。有些处理算子甚至对数据进入的顺序有要求。
4.输出要求
那么他对输出不同的业务场景也有不同要求，有些业务场景要求数据输出具有一致性，也就是说假设有两个区，一个计算任务bucount。那么不同的 key 可能会被分配到不同的计算机类。假设我们在计算双十一期间，不同店铺的实时成交情况。假设一个数据通路或者处理节点有问题，那么不同的店铺，比如说有些店铺的处理节点是ready的，仍然是 ok 的，他会一直往前计算，比如说到凌晨1点。而有些店铺因为他那个数据通路有问题，或者计算节点有问题可能到12:50。然后后面我们又有一个计算就是排序,很明显存在的一个问题就是店铺 a 和店铺b排了序，但是其实他们是在不同维度上、不同时间粒度上进行排序。
可能店铺 a 是到1点截止的数据，店铺b只是到12:50。那么很明显这个计算就是可比性就是 ready 是 OK 的。所以在这样的业务场景下，他要求你的输出具有一致性。而对有些业务场景下，它对输出的连贯性有要求，对一致性没有要求。
比如分控场景，那么有些数据通路宕机了。那没有宕机的将仍然可以计算，不能因为一个点的宕机影响到整体输出，就不能继续。所以大家可以看到，即便在流式计算和增量计算系统内部不同业务场景对它也有不一样的要求。
5.计算特点
时效性 高
质量 准
容错 稳
多样性 多
具有对实时性要求比较高，对质量的把控要求也是非常精准，对容错的要求要求快速恢复、比较稳定的恢复。对流式计算的场景细分，业务场景仍然要求有非常大的多样性，比如说连贯性，一致性。
6.多样性
精确、只多不少、丢的 sla
有些业务是要求数据一条都不能错，有些是业务要求可以多一点但是不能少，比如业务具备的一些幂等性，例如搜索，他本身具有一个逻辑的字段，所以多输出，实际上后面的业务逻辑是可以的。
有些业务场景要求你丢的数据的数量，还是要有 sla 的保证。所以这其实在要求进行设计增量计算和流式计算系统提出了很高的灵活性的要求。
