text: 流计算简介（上篇）
  本文介绍了流计算的概念和技术要素，简单比较了三种主流的流计算框架Structured Streaming（Spark）、Flink和Kafka Streams。
  流计算的概念
  “流”一般是指 源源不断的数据 （Unbounded Data）。
  在理解流计算之前，需要先理解其对立概念—— 批计算 （Batch Computing）。
  流计算不等于实时计算
  那么为什么人们会产生“实时”或“低延迟”的联想呢？
  实时计算是面向低延迟场景产生的一类计算框架，例如早期的Storm（Storm的新版本也在逐渐丰富流计算的语义，如窗口化）： 但在一些场景下这种方式的延迟过高，于是人们引入了实时计算来弥补批计算的不足。
  Lambda体系架构
  基于实时计算与批计算的互补关系，Nathan Marz提出了一种称为Lambda的系统架构，其本质是批计算与实时计算的一种混合架构，如下图所示：
  在Lambda体系下，同一份数据会分别进入批计算子系统（batch sub-system）和实时计算子系统（realtime sub-system）。
  早期的实时计算引擎在实现上存在一致性问题。
  批流结合
  流计算的技术要素
  从本质上看，流计算引擎所做的工作就是：对于源源不断的数据，怎么计算？
  在Beam里，把这些问题概括为What、Where、When、How：
  本文没有讨论第一个问题，即“What”。
  一个流计算应用往往表示成数据源节点、数据输出节点和一些算子构成的有向图，如下图所示：
  发生时间和处理时间
  流计算引擎中的时间一般有两种情况：
  发生时间（Event time）：指某个事件发生的时间，通常由外部系统提供；
  上述两个概念比较容易理解。
  注意这里的讨论基于一个假设，即数据源时钟和流计算系统时钟都是准确的。
  造成这种情况的原因可能是产生数据的数据源或流计算引擎没有可靠的时间同步服务。
  流计算应用的状态和持久化
  下面给出了一些常见的算子状态的例子：
  算子在数据流中查找某种时序模式（Pattern），需要保存保存一段时间原始数据用于匹配；
  算子按分钟/小时/天聚合数据，需要保存一些中间结果；
  算子迭代训练机器学习模型，需要保存当前的模型参数；
  算子在计算时需要参考历史数据，需要保存一些历史数据；
  假设我们想在数据流中查找下面形状的模式： 需要注意的是，算子并非一定有状态（state-full），也可以无状态（state-less)。
  下面我们定义流计算应用的状态。
  下面是按数据对齐的一个示例：
  要支持应用在故障后不必完全重新计算，还需要对状态进行持久化。
  处理模式（Process pattern）
  时间无关（Time-agnostic） 窗口化（Windowing）
  窗口一般有两个要素：
  长度，指窗口在时间上的跨度，比如5分钟；
  基于处理时间的窗口化比较容易理解，比如每隔n分钟，处理过去m分钟积累的数据。
  基于发生时间的窗口化要稍微复杂一些（如上图下部所示）。
  那么可能的时间窗口为
  因为延迟总是存在的，所以一般计算要延后一些。
  那么需要延后多少呢？
  除了上述两种典型窗口化方式以外，还可以有一些自定义的窗口定义方式。
  窗口化处理模式意味着算子一定是有状态的（即state-full），并且状态有有限的生命周期。
  首先，窗口化意味着必须缓存一定数据或计算中间结果，以便在窗口内数据完整抵达后执行计算，所以一定是有状态的。
  最后，有状态的算子并不一定存在窗口化，想想前面提到的迭代训练机器学习模型的例子。
  窗口生命期管理
  基于发生时间的窗口生命期管理要复杂一些。
  由于数据是陆续抵达的，为了计算平均温度就必须缓存两个值，即落在该窗口内的所有温度读数的个数和它们之和，最终可以计算得到平均数：
  是在引擎接收到第一个落在该时间区间内的值的时候 。那么窗口会在什么时刻关闭呢？
  为了描述这种关闭窗口的时间，流计算引擎引入了一个称为 水位线 （Watermark）的概念。
  水位线一旦超过某个时间窗口的最大时间，则可以计算出窗口结果并关闭窗口。
  在一些流计算引擎里，除了水位线外还会有 最大延迟 的概念，即在水位线已经超过窗口最大时间后还需要维持一段时间。
  窗口的计算时机 最终每个窗口只会保留一个计算结果，所以每次计算都涉及到如何更新窗口结果的问题。
  流计算引擎的一致性
  一般来说，针对流数据的计算一致性可以分为三种类型：
  At-most-once：可以理解为“尽力而为”。
  At-least-once：比起At-most-once，这种语义保证每条记录至少会被处理一次，即不会发生数据丢失，但一条记录仍然可能被重复处理多次。
  Exactly-once：这种语义保证记录不会丢失，并且每条记录对状态的影响只能有一次。
  要理解上面的三种语义，首先要清楚这里提到的“丢失”和“重复”特指在流计算系统内部发生的行为，而不是指数据本身存在的问题。
  比如，数据在到达流计算引擎之前可能已经丢了，或数据本身就包含一定的重复率，那这些问题并不在流计算引擎考虑之内。从正确性的角度来看，At-most-once是不可用的，因为它无法保证计算结果是否能反映数据的情况。
  At-least-once确保不会发生数据丢失。
  Exactly-once是一个容易让人产生误解的概念。
  这种误解通常来自两方面：
  误解1：支持Exactly-once语义的流计算引擎对每条记录只处理一次；
  误解2：支持Exactly-once语义只是流计算引擎内部的行为，与外部系统无关
  只有解开上面的两个误解，才能真正理解什么才是Exactly-once。
  我们得到的原始记录可能如下：
  这会引发一个问题——在11:30之前已经计算得到的中间结果是不是丢失了？
  这个问题并不是流计算引擎能独立回答的，因为它无法缓存这些原始数据。
  在计算重新开始时，流计算引擎要求数据源再次从11:20开始消费数据，这样就能与持久化的状态衔接上。
  回到前面提到的两种误解。
  Exactly-once的语义并不是保证每条数据只被处理了一次，而是确保一条数据对最终结果只会影响一次。
  一致性是流计算引擎最重要的属性之一。
  流计算框架比较
  流计算框架介绍小结
  数莓派
  以数为媒，共建工业大数据社区
  来自： leo_qiu的书馆 > 《技术类》 推荐 ： 发原创得奖金，“原创奖励计划”来了！
  请遵守用户 评论公约 类似文章 更多Flink 小贴士 (3): 轻松理解 Watermark
  flink系列-10、flink保证数据的一致性
  干货| 【时间简“识”】3.差分、延迟算子的故事！
  热处理炉温度测量与管理
  阿里 7 亿元收购 Apache Flink 商业公司 DataArtisans
  阿里 7 亿元收购 Apache Flink 商业公司 DataArtisans.Flink在阿里的现状。
  双11背后的黑科技：大数据实时计算如何为你量身定制？
  数据时代，大数据计算已经渗透到了各行各业，业务沉淀数据，数据计算产生新的业务价值，大数据计算正不断地用这种方式推动业务向前发展...【用车】就这一个键 让炎热的车内降温更快
  夏季垂钓，野钓要选择好出钓时间和钓场，这样才能钓好鱼
  安琪冷冻面团改良剂F-99在无发酵 冷冻面团中的应用
  顶级大厨教你如何开锅！