現在還沒有一個統一的流式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”取一個固定值）。