网站设计的要求,商城网站建设需要注意什么,彼亿营销,电子商务网站开发课程教案现在还没有一个统一的流式SQL语法标准#xff0c;各家都在做自己的。本文在一些业界应用的基础上提出了一个统一SQL语法的建议。Spark同样存在这个问题#xff0c;社区版本在流式SQL上迟迟没有动作。EMR Spark在今年上半年提供了自己设计版本的流式SQL支持#xff0c;也会在…现在还没有一个统一的流式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 BeamApache 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 BeamApache Calcite以及Apache Flink中实现或者作为众多选择之一。Streaming SQL已经在阿里巴巴华为LyftUber及其他一些公司中应用。下面是一些他们的反馈为啥做这样的选择
开发和应用成本相对于那些非声明性流处理 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来表达。我没有对业务逻辑做过多的描述而是对查询本身进了注释。希望这已经足够让你们理解要点了。 输入以下数据 821分查询时会得到如下TVR
但如果在813分查询时结果又不一样
注意正如目前所表达的查询返回时间点结果但是如果我们愿意我们可以使用物化延迟的方式来改变结果的展示方式。例如“SELECT ... EMIT AFTER WATERMARK;”查询结果只会在watermark到达了时间窗口末尾时才更新。
所以在816我们会看到
然后到了821会看到
如果希望看到不带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”取一个固定值。
原文链接 本文为云栖社区原创内容未经允许不得转载。
