【譯】用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」取一個固定值）。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。