A Practical Approach to Balancing Correctness, Latency, and Cost in MassiveScale, Unbounded, OutofOrder Data Processing
这篇论文的副标题很长，说明几点:
1. 这篇文章的主要工作是，Balancing Correctness, Latency, and Cost，故它仍然不能突破CAP定理，仍然是在做tradeoff
2. Unbounded, OutofOrder，针对的对象是无限的，乱序的数据，尤其是乱序的数据，这个点在之前的model无法得到较好的处理
并且这篇论文讨论的是，抽象的计算模型和算子，类似mapreduce的论文，设计和实现并不是它的重点
要解决的问题
简单说，
对于batch，latency太长，而且只能针对bounded数据
所以现在的主流是Streaming，但是Streaming在保证latency的时候，如何保证Correctness，或Completeness
答案是，根据CAP定理，是不可能的
那么当前的方案就是balancing，balancing的方式大致就是backfill
无论是Lamda， 还是linkedin的kappa，还是这篇文章的思路可以是说都是backfill的一种表现形式，所以这篇paper的题目也是Practical Approach
即它通过设计做的比之前的方案更精细一些，尤其对于windows的场景，更通用一些
提出的方法
用文章的话说，从概念上看，他的contribution为，
1. Allows for the calculation of event-time ordered results, windowed by features of the data themselves, over an unbounded, unordered data source, with correctness, latency, and cost tunable across a broad spectrum of combinations.
首先，在对无限，无序数据的处理上，尤其是基于event-time的windowed聚合计算，达到latency和correctness的balancing
2. Decomposes pipeline implementation across four related dimensions, providing clarity, composability, and exibility:
What results are being computed.
Where in event time they are being computed.
When in processing time they are materialized.
How earlier results relate to later refinements.
对于流式计算，简单的one-by-one无状态模式，没啥好说的
这篇论文要解决复杂的有状态模式，比如典型的就是基于windowed的聚合操作
这篇文章把这类操作抽象成4个阶段，
what，你要算什么
where，在什么范围内聚合，globe的？在某个时间window中？
when，什么时候输出实时统计结果
how，如何修正修正前面输出的结果
这样你把这4个问题解决了，ok，这个问题也就解了，这篇文章后续就是来回答这4个问题
3. Separates the logical notion of data processing from the underlying physical implementation, allowing the choice of batch, micro-batch, or streaming engine to become one of simply correctness, latency, and cost.
这篇文章提出的模型是独立于物理实现的，可以适用于batch，micro-batch，或streaming，这个是对lamda架构的优化，不用写两份代码了
但注意，这里说抽象模型可以独立于物理实现，但并不是说用一个物理engine可以解决所有问题
Scalable implementations of the above atop the MillWheel streaming engine and the FlumeJava batchengine, with an external reimplementation for Google Cloud Dataflow
作者也是基于两个engine，MillWheel streaming engine and the FlumeJava batchengine，来扩展实现了Dataflow
具体的来说，这篇文章的贡献是提出3个模型，
A windowing model which supports unaligned event-time windows, and a simple API for their creation and use (Section 2.2).解决Where问题
A triggering model that binds the output times of results to runtime characteristics of the pipeline, with a powerful and exible declarative API for describing desired triggering semantics (Section 2.3). 解决when问题
An incremental processing model that integrates retractions and updates into the windowing and triggering models described above (Section 2.3). 解决how问题
概念
为了能理解这3个模型，先理清一些概念
Unbounded/Bounded vs Streaming/Batch
一句话，Streaming/Batch往往表示execution engine，而unbounded/bounded表示数据的infinite/ finite
Windowing
统计窗口，对于unbounded data，只能基于windowing做处理
windowing有如下3种，
前两种很简单，Sessions Windowing，这个比较新鲜，这个是在google实践中很重要的一种windowing形式
Session，即当连续出现key1时形成session windowing窗口，没有key1出现是就不存在窗口，典型应用异常检测，当出现持续异常时就是session windowing，没有异常是不需要统计
Time Domains
时间域，分为两种，
Event Time, which is the time at which the event itself actually occurred，发生时间
Processing Time, which is the time at which an event is observed at any given point during processing within the pipeline，处理时间
显然处理时间一定是晚于发生时间的，我们可以用下面的watermark图来visualize他们的skew关系
我们可以用heuristically established的方式来build这个图形，用于监控系统的状况
DATAFLOW MODEL
In this section, we will de ne the formal model for the system and explain why its semantics are general enough to subsume the standard batch, micro-batch, and streaming models, as well as the hybrid streaming and batch semantics of the Lambda Architecture.
Core Primitives
dataflow提供两种基本原语，分别对应于无状态和有状态
ParDo for generic parallel processing. Each input element to be processed (which itself may be a nite collection) is provided to a user-defined function (called a DoFn in Dataflow), which can yield zero or more output elements per input.
基本的无状态原语
可以等同于flatMap，和map的不同是，可以输出0到多个结果
GroupByKey for key-grouping (key; value) pairs.
有状态的原语
Windowing
现在开始介绍windowing模型，这要解决的where问题，即在infinite的数据流中，我们要处理哪部分数据
首先，dataflow将window信息放入tuple内，
所以dataflow的tuple是4元组，(key; value; event time; window)
同时，支持两种windows操作，
AssignWindows，
可以看到通过AssignWindows，可以将原始数据，转换为带windowing信息的数据
在例子给出的case下，一条raw数据会产生两条带windowing信息的数据
这样做的好处就将，where信息固化在原始数据中了，你不用再在代码里面记着
问题是，这样可能会带来数据膨胀，如果Sliding（60m，1m），岂不是一条raw tuple，要产生60条带windowing信息的tuple
WindowMerging，
这个过程，可以用来消除前面带来的数据膨胀，
这个过程还是比较清晰的
Triggers & Incremental Processing
开始解决when和how的问题
核心问题，我们面对的时候无序的数据，那么我们怎么知道，这个windowing里面的数据已经到全了，可以emit产生结果了？
是不是可以依赖我们上面给出的watermark图来预估，是可以的，但这个方案不完善；会有too fast和too slow问题
too fast，即，通过watermark你是无法保证100%数据完整性的，因为watermark是启发式生成的
too slow，即，latency问题，watermark反映的是大部分数据到全的时间点，必然不会有好的latency
所以可见，这个方案挺废的，即保证不了一致性，也保证不了latency
那么回到那个问题，我们怎么知道什么时候该emit结果了？
答案是，你无法准确知道
所以这边的思路和lamda是一致的，先输出实时数据满足latency需要，并且用batch数据来backfill，修正数据的正确性
这就是这里提到的trigger和增量更新模型，
trigger模型解决when的问题，你可以定义各种不同的trigger，已满足你对latency和correctness的balancing的需求
增量模型解决how的问题，即如何修正数据的正确性，这里分为3种，
Discarding: Upon triggering, window contents are discarded, and later results bear no relation to previous results.
trigger触发时，会丢弃当前window的数据，这样要求various trigger fires to be independent，比如说sum操作
这样的好处，减小mem的负担；问题是，会产生碎片化数据，需要后续再次combine和merge
Accumulating: Upon triggering, window contents are left intact in persistent state, and later results become a refinement of previous results.
trigger触发时，会保留当前window的数据，后续可以继续refine数据
这样的场景，适用于downstream consumer支持overwrites操作，比如数据库
这样的问题就是，当数据量比较大的时候，你无法在mem里面保留长时间数据，那么需要写入存储，那么backfill可能需要offline来完成
Accumulating & Retracting: 比上面那种多了retracting
这个只是用于不同的场景，比如downstream consumer是在做sum统计，那么必须先把上次的减去，才能加上这次的数据
Examples
对于下面的input，
Batch Model
Batch的方式，等所有数据都来全了，计算一遍解决，问题就是latency高达接近10分钟 （对于最早的数据）
基于windowing的batch方式，和普通batch区别，增加windows聚合的结果
Micro-Batch Model
和batch比，兼顾latency
incremental的方式不同，下面是discarding，看看区别
基于windowing的micro-batch，
基于流的Windowing Model
采用watermark的trigger，
这个的问题上面说过，
too fast，9在依据watermark触发时，还没到
too late, 7的数据要等到8到达的时候才能输出，
在watermark trigger的基础上增加micro-batch trigger，这样的好处还是提高latency，
基于Session Windowing Model
