【译】用SQL统一全部：一种有效的、语法惯用的流和表管理方法

如今尚未一个统一的流式SQL语法标准，各家都在作本身的。本文在一些业界应用的基础上提出了一个统一SQL语法的建议。Spark一样存在这个问题，社区版本在流式SQL上迟迟没有动做。EMR Spark在今年上半年提供了本身设计版本的流式SQL支持，也会在后续的更新中吸取和支持这些优秀的设计建议。

原文：https://blog.acolyer.org/2019/07/03/one-sql-to-rule-them-all/

资料：One SQL to rule them all: an efficient and syntactically idiomatic approach to management of streams and tables Begoli et al., SIGMOD’19

在数据处理方面，彷佛最终都会回归到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”取一个固定值）。

原文连接 本文为云栖社区原创内容，未经容许不得转载。