Flink Table & SQL API--動態表與Redo和Undo

今年4月11日在San Francisco舉辦的Flink Forward 2017會議上，來自Data Artisans公司的Timo Walther介紹了目前Flink社群中關於Table & SQL API的內容與展望。

展望的內容主要介紹了Dynamic Tables Model，即流上的動態表模型。初看到這一概念，我立刻想到了Oracle中的物化檢視，只不過物化檢視重新整理的頻率是有一定週期和間隔的。

而流是無界的且源源不斷的，再加上流上可能出現的亂序以及狀態的增量計算、延遲資料的重新計算等問題，我覺得Flink動態表的實現確實比較前沿。

下面就根據Timo Walther的視訊演講與PPT，對Flink動態表做一下簡單的介紹。

1、什麼是動態表

動態表並不是Flink獨有的一個概念，表本身來講，也不是嚴格意義的靜態的，隨著資料不斷的insert、update、delete等操作，表中的資料也是不斷變化的。同樣的，Flink中的動態表也是隨著時間的移動不斷改變，通常我們基於一個時間範圍來查詢動態表的資料，這樣就是相當於在流上應用window操作。所以，流和動態表之間是可以相互轉化的。

注意：流上的資料不可能像資料庫中表一樣一直儲存著資料，而是隨著時間移動，flink表上的資料不斷的被purge，或者clean-up或設定超時時間，否則狀態太大很容易將記憶體撐爆。

2、流轉換為動態表

有2種模式可以將流轉換為動態表：

1、Append模式--沒有key的概念
2、Update模式--有key的概念

Append模式就是不斷的insert資料，那麼動態表中將包含流上的所有資料，沒有範圍；
Update模式就是不斷的update資料，動態表中只保留流上最新的資料。

例如上圖中，時間從1到9，Append模式擁有所有資料，而Update模式只有每個K最新的資料，相當於對前一條K的更新。

3、動態表的查詢

動態表上的查詢確實很像維護著一個物化檢視，而且這個查詢的結果是不斷更新的。

以上圖為例，分別在時間為8、9、12時，進行3次查詢，查詢每個k包含的數量。
A[t]代表在時間t對錶A進行的查詢。
q(A[t])代表在時間t對錶進行特定的查詢，例如上圖中對每個K進行計數。

首先，q(A[8])時查詢的動態表結果是A包含3條，B包含2條，C包含1條。
其次，q(A[9])時查詢的動態表結果是A包含3條，B包含3條，C包含1條。
最後，q(A[12])時查詢的動態表結果是A包含3條，B包含3條，C包含2條。

這種SQL並沒有限定範圍，即就是我們上面介紹的Append模式，就有點類似於流上word count的例子。下面看一個有範圍的word count的例子。

上圖中，SQL中規定每隔5秒進行一次查詢，視窗型別是翻滾視窗，即每5秒都是一次新的動態表。

首先，q(A[5])時查詢的動態表結果是A包含2條，B包含1條，C包含1條。
其次，q(A[10])時查詢的動態表結果是A包含1條，B包含2條。
最後，q(A[15])時查詢的動態表結果是A包含2條，C包含2條。

值得注意的是，由於是翻滾視窗，之前的結果並沒有累加到下一次結果中，而且要等到5秒的水位線到達後才觸發計算。

由於流上的操作有諸多限制，因此不是任何的查詢都可以應用到動態表上的，原因如下：

1、無界的資料必須設定超時時間或者約束，否則狀態太大。
2、隨著資料不斷的到達，也許僅僅需要觸發一部分的重新計算。
3、查詢要在有界的範圍內進行。

4、動態錶轉換為流

這裡很像資料庫中日誌的技術：

1、Undo:資料被更新，保留以前的資料，例如Oracle中的閃回查詢，就利用undo機制。
2、Redo:資料被更新，重新計算最新的值，即重做。
3、Undo+Redo:既要以前的資料，也要最新的資料。

對於動態表而言，支援2種模式：

1、Redo
2、Undo+Redo

這裡介紹的太抽象了，簡單點說，Redo就是根據key，在key上進行更新操作；而Undo+Redo就是刪除之前的結果，重新計算最新的資料。我們下面看2個例子：

1、Undo+Redo

這裡對結果不斷進行撤回操作，並redo重新計算。

2、Redo

這裡對結果進行基於key的更新操作。

我們知道，流上的操作可以處理亂序和late element，而flink SQL同樣支援，例如我們設定一個一天的視窗查詢，每個30分鐘分鐘觸發一次計算，那麼每次觸發其實就是對之前結果的更新。當然我們可以設定允許的遲到時間，之後再次觸發計算，也可以設定最後的觸發時間。之後，視窗的狀態將被purge。

5、關於Retraction

中文解釋為撤回、撤銷。那麼在流處理中，retraction是什麼意思呢？其實就是對與之前觸發（early trigger）的結果，進行不斷的改善和更新操作。

主要有2個地方需要retraction：

1、基於Key的表上，更新之前的結果
2、session window，後續的觸發導致之前的視窗發生merge

這兩種情況都需要對之前觸發過的計算再次進行計算。

最後，附上3張上半年Flink Forward 2017的照片：

1、歡迎各年齡段的選手：）

2、Club Mate德國軟飲還有中文字畫

3、誰帶過去的日本米酒。。。

參考：

YouTube–Timo Walther - Table & SQL API– unified APIs for batch & stream processing
SlideShare–Timo Walther - Table & SQL API – unified APIs for batch and stream processing