现在还没有一个统一的流式SQL语法标准，各家都在做自己的。本文在一些业界应用的基础上提出了一个统一SQL语法的建议。Spark同样存在这个问题，社区版本在流式SQL上迟迟没有动作。EMR Spark在今年上半年提供了自己设计版本的流式SQL支持，也会在后续的更新中吸收和支持这些优秀的设计建议。
原文：https://blog.acolyer.org/2019/07/03/one-sql-to-rule-them-all/
在数据处理方面，似乎最终都会回归到SQL上！今天选择的这篇文章作者来自于Apache Beam，Apache Calcite以及Apache Flink的专家们，阐述了他们在构建流式处理SQL接口的经验。最终整理了一些SQL标准的扩展建议。
The thesis of this paper, supported by experience developing large open-source frameworks supporting real-world streaming use cases, is that the SQL language and relational model as-is and with minor non-intrusive extensions, can be very effective for manipulation of streaming data.
这篇文章的论点是，在开发使用大规模开源框架解决现实世界的实际流式场景经验下，SQL语言及关系性模型在当前及非侵入式扩展后，对于流数据的操作非常有效。
文章中很多观点已经在Apache Beam，Apache Calcite以及Apache Flink中实现，或者作为众多选择之一。Streaming SQL已经在阿里巴巴，华为，Lyft，Uber及其他一些公司中应用。下面是一些他们的反馈，为啥做这样的选择：
- 开发和应用成本相对于那些非声明性流处理 API要低得多。
- 比起非标准化的查询语言，熟悉SQL更容易开发应用。
- 常见的窗口聚合及join等处理任务，基于event-time可以更方便的表达及更高效的执行。
- 当应用出错或者服务中断时，可以很方便地使用同一个查询语句对记录存储的数据进行处理。
1. 基本原则
Combined, tables and streams cover the critical spectrum of business operations ranging from strategic decision making supported by historical data to near- and real-time data used in interactive analysis… We believe, based on our experience and nearly two decades of research on streaming SQL extensions, that using the same SQL semantics in a consistent manner is a productive and elegant way to unify these two modalities of data…
总的来说，表和流覆盖了业务运营的关键范围，从历史数据支持的战略决策到交互式分析中使用到的近实时数据。我们相信,基于我们的经验和近 20 年对流式 SQL 扩展的研究,以一致的方式使用相同的 SQL 语义是统一这两种数据模式的高效和优雅方式。
正如作者指出的一样，过去许多年里已经进行了很多前期工作，文章中也借鉴了很多其中大部分。最重要的是，它们是基于使用Apache Flink、Beam以及Calcite所获得的经验教训。
相比于传统的关系性视图，流式应用多了一个Time概念。请注意，在一个用户多次查询中，一个可变的数据表实际上就是一个随时间变化的表，即time-varying relation (TVR)。也就是说，任何一次查询结果，都只是代表了那个时间点的表数据。
A time-varying relation is exactly what the name implies: a relationship whose contents may vary over time… The key insight, stated but under-utilized in prior work, is that streams and tables are two representations for one semantic object.
一个时变表就像它的名字所蕴含的一样：表的数据内容可能随着时间变化而变化。在以前的工作中，指出但未充分利用的观点是，流和表是一个语义对象的两个表示形式。
按照定义，TVR支持所有的关系型操作，即使在涉及时变关系数据的场景中也是如此。所以文中提出的第一个建议实际上就是no-op!所以让我们使用它们，并明确说明SQL是在TVRs上操作的。
我们确实需要做一些扩展来支持event-time。我们尤其需要小心地区分event-time和processing-time。我们还需要理解，事件并不一定是按照事件时间顺序呈现的。
We propose to support event time semantics via two concepts: explicit event timestamps and watermarks. Together, these allow correct event time calculation, such as grouping into intervals (or windows) of event time, to be effectively expressed and carried out without consuming unbounded resources.
我们提出通过两个概念来支持event-time语义：显式的时间时间戳以及watermarks。两相结合，就可以正确地支持event-time计算，例如按时间窗口group，这样可以高效的表达和计算，而无需消耗大量的资源。
Watermark可以追溯至Millwheel, Google Cloud Dataflow，直到Apache Beam and Apache Flink。在处理时间的每一刻，watermark确定了一个时间戳，这个时间戳确定在处理时间上事件完整性的时间界限。
文章第三块讲述了控制关系型数据如何呈现以及何时物化数据行。例如：查询结果是立刻更新来反映任何输入的新数据，还是在一个时间窗口末尾处展示完整的数据更新。
2. 示例
NEXmark(一个流式查询的benckmark) Query7实现了一个监控竞拍中最高价物品的逻辑。每10分钟，查询返回最高的bid及相关的itemid。
下面这张图展示了如何使用Streaming SQL来表达。我没有对业务逻辑做过多的描述，而是对查询本身进了注释。希望这已经足够让你们理解要点了。
输入以下数据：
8：21分查询时，会得到如下TVR：
但如果在8：13分查询时，结果又不一样：
注意，正如目前所表达的，查询返回时间点结果，但是如果我们愿意，我们可以使用物化延迟的方式来改变结果的展示方式。例如“SELECT ... EMIT AFTER WATERMARK;”，查询结果只会在watermark到达了时间窗口末尾时才更新。
所以，在8：16，我们会看到：
然后到了8：21，会看到：
如果希望看到不带watermark的窗口行，但只要得到周期性的局和结果，我们可以使用“SELECT ... EMIT STREAM AFTER DELAY”（这里STREAM表示我们希望流式地展示查询结果）。
3. SQL扩展
希望这能给你带来帮助。目前，该建议包含对标准SQL的7个扩展：
- Watermarked event time column：关系型表中带有watermark的类型为TIMESTAMP的列。watermark由系统进行维护。
- Grouping on event timestamps：当“Group By”字句作用于时间列时，只包含那些key小于时间列定义的watermark的groups。
- Event-time windowing functions：以Tumble和Hop开头，参数包括数据表和时间列描述符，返回一个添加了时间列的数据表。Tumble产生间距相等的不相交窗口，Hop生成同等大小的滑动窗口。
- Stream materialization：“EMIT STREAM”会产生一个按时间变化的结果表，区别于传统的查询结果。新增一个列来指明一个数据行是否是上一行的撤回，该行的日志更新处理时间偏移量以及相对于同一事件时间分组的其他更新的序列号。
- Materialization delay: 当查询带有“EMIT AFTER WATERMARK”修饰语，只有完整的结果行才会物化。
- Periodic materialization: 当查询带有“EMIT AFTER DELAY d”修饰语，查询结果间隔d个周期才会输出出来。
- Combined materialization delay: 当查询带有“EMIT AFTER DELAY d AND AFTER WATERMARK ”修饰语，查询结果间只会在隔d个周期且数据完整的时候才会输出出来。
3.1 Hop示例
3.2 Emit Stream示例
4.经验教训
文章中的第5节列出了从Apache Calcite、Flink和Beam中学到的经验教训，这些经验教训为设计提供了参考。我没有足够时间来一一介绍，下面节点比较吸引我的注意：
- 因为事件时间戳只是常规属性，可以在普通表达式中引用，所以表达式结果可能不会与watermark保持一致，这在查询计划中需要考虑。
- 用户发现很难推断查询中事件时间的最佳使用情况，这可能导致使用不合预期的语义执行计划。
5. 未来工作
对我来说，印象深刻的是用尽量少的改动达到目的。文章中的“future work”部分显示，文中提出的那些扩展还需要进一步完善才行。
例如，我注意到的一点是，SQL标准定义中规定SQL查询中的time是查询的时间点（要么是当前时间，要么是使用“AS OF SYSTEM TIME”指定的时间）。这意味着您还不能在stream尾上表达视图（你可以使用类似“CURRENT_TIME - INTERVAL ‘1’ HOUR”的表达式，但是查询执行时，“CURRENT_TIME”取一个固定值）。
