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

本文作者：魚跟貓

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

本文為雲棲社區原創內容，未經允許不得轉載。

推薦閱讀：

相關文章