dataflow原文：https://ai.google/research/pubs/pub43864
dateflow模型出现的背景
- 无边界、乱序、大规模的数据越来越普遍
- 数据使用者的复杂需求
- 按事件发生时间顺序进行计算
- 按数据自身的特征进行窗口计算
- 立即得到数据分析的结果
现代数据处理系统演进
- 处理海量数据
- MapReduce,Hadoop,pig,hive,spark
- 流处理Sql上
- sql社区的工作（查询系统，窗口，数据流，时间维度，语义模型）
- 低延时处理
- Spark Streaming，MillWheel，Storm
原因： 数据工作者现在拥有了很多强有力的工具把大规模无序的数据加工成结构化的数据，而结构化的数据拥有远大于原始数据的价值。但是我们仍然认为现存的模型和方法在处理一些常见的场景时有心无力
需求示例
故事
流媒体平台提供商想要通过视频广告，向广告商收费来实现视频内容变现。收费标准按广告收看次数、时长来收费，该提供商支持在在线和离线播放两种方式。
角色及需求
- 流媒体平台提供商
- 想知道每天像广告上收费金额，可以按视频和广告进行统计。
- 可以在历史离线数据上进行离线分析。
- 希望有一个简单且灵活的系统，可以处理分散在全球的数据。
- 广告商
- 想知道视频被观看了多少次，多长时间
- 投放了哪些广告，广告投放在哪些视频里，受众人群分布情况
- 需要付的钱数
- 视频内容提供者
- 想知道视频被观看了多少次，多长时间
- 投放了哪些广告，广告投放在哪些视频里，受众人群分布情况
- 赚到多少钱，及时调整营销策略和报价
现有系统的弊端
时延性问题
批处理系统MapReduce、FlumeJava、Spark shuffle 无法满足时延的要求。因为它需要再处理前数据都要收集为一个批次。
准确性和语义表达性
现有许多提供扩展和容错保证的流处理系统缺乏准确性和语义表达性。
- 不能提供exactly-once语义，影响正确性
- 比如Storm，samza，Plusr
计算窗口问题
- 缺少窗口所需的时间原语
- 比如 Tigon
- 仅仅限制于基于元组和基于事件处理时间的窗口
- 比如： Spark Streaming ,Sonora,Trident
- 提供了基于事件时间的窗口，但依赖排序
- SqlStream
- 提供了基于事件时间的窗口，但事件时间窗口的触发语义被限制
- flink
- 无法有效表达基于sesiion的窗口
- CEDR和trill提供了有用的标记触发语义和增量模型，语义是基于标记的。
缺少高级的编程模型
- MillWheel和Spark Streaming
- CEDR和trill提供了有用的标记触发语义和增量模型，语义是基于标记的。
