最近開學學習blink了。flink+alibaba=bilink。看到一次比較精彩的分享，非常適合新手。
轉載如下：
------------------------------------
輕鬆掌握阿里Blink SQL關鍵技術及實現原理
內容來源：2018 年 6 月 15 日，阿里巴巴高級技術專家孫金城（金竹）在“阿里雲流計算杭州峯會”進行《Blink SQL關鍵技術及實現原理》演講分享。IT 大咖說（微信id：itdakashuo）作爲獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：2852 | 8分鐘閱讀
獲取嘉賓演講視頻及PPT：suo.im/4ZZ9PO
摘要
本次演講主要介紹Blink SQL的幾個關鍵技術，以及實現原理，並通過兩個實例來闡述具體的功能效果。
六個特點和背景介紹
Blink架構
Blink作爲一個純流式的計算平臺，具備秒級甚至毫秒級的延時，能夠快速容錯，比如在某個計算節點掛掉的時候可以快速恢復。它還支持動態擴容，針對流計算場景做了大量優化，具備高吞吐和高資源利用率的極致性能，同時解決了非常明顯的數據亂序的問題，並且支持大數據量的流計算請求。
Blink特點
什麼是BlinkSQL
BlinkSQL是在FlinkSQL基礎上新增了大量的豐富功能和性能優化。SQL作爲聲明式的可優化的語言具備很大的優勢，Blink的SQL查詢優化器會對用戶SQL進行優化，制定最優的執行計劃以獲取高性能。同時SQL易於理解，用它編寫的業務邏輯清晰明瞭。
雖然SQL被更多的用於批處理，但是在流計算場景下同樣也適用。從處理的數據集合來看，流處理的數據是無窮的，而批處理面對的是有限集合。從內部處理邏輯來看，批處理是單次作業，流處理的運作持續不斷，並且會對歷史數據進行修正。
上圖展示的是一個攜帶時間戳和用戶名的點擊事件流，我們先對這些事件流進行流式統計，同時在最後的流事件上觸發批計算。流計算中每接收一個數據都會觸發一個結果，可以看到最後的事件無論是在流還是批上計算結果都是6。這說明只要SQL語句和數據源相同，流和批的計算結果就不會存在差異。相同的SQL在流和批這兩種模式下，語義相同，最終結果就會一致。
五個概念和一個實現
流表對偶性
流表對偶性是指流錶轉換信息無損，具有對偶性。
傳統數據庫表有兩個最明顯的特徵schema和data，流同樣也有schema和data，另外還有一個重要屬性time，隨着時間的推移數據會不斷涌入流中。
上圖中在對一個用戶名關係表進行DML操作，每insert一條語句後會觸發一個統計查詢，按user維度分組做count統計。圖中插入第一條數據後，輸入的是（mary , 1），接着再插入數據就會輸出（Bob , 2）、（mary , 1），在進行操作的時候雖然沒有顯示的涉及到時間，但是其實都隱含了一個操作時間，從本質上講，傳統數據庫表中也有time屬性。
這樣的話單就屬性來看數據庫表和流式就是一樣的，我們可以把一個具體的表可以看做是流上某一時間切片的數據。
動態表
隨着時間變化不斷變化的表可以稱之爲動態表，這個概念不適用於傳統數據庫表。因爲傳統數據庫有着事務控制，在執行查詢的那一刻表的內容不會有變化，所以是靜態表。而流上的數據即使在查詢的時候也還是在變化，數據進行回放的時候，可以Replay成一張動態表，而動態表的changelog又形成了流。
持續查詢 & 增量計算
持續查詢是流計算特有的，不斷更新結果，執行運行的查詢。它是保證低延遲和數據更新的基礎。
增量計算是一種可以提高流計算性能的計算實現，流上的每一條數據都會利用上一條計算結果進行聚合和統計計算。
Early Emit & Retraction
Early Emit是爲了保證流計算的低延時需求，將計算結果儘早的流到下游。由於流計算的結果會隨着時間改變，因此即使上游的計算結果在發出的那一刻是正確的，但是隨後又會產生新的結果，這樣下游當初接收的數據就是陳舊的。Retraction解決的就是這一問題，爲了保障流計算語義正確性，將Early Emit的計算結果撤回併發出正確的計算結果。
雙流JOIN實現
對於雙流join，由於流上的流速不一定相同，有可能會出現查詢的時候數據不存在，後續才出現數據的情況。上圖是Blink的join方案，將左邊的數據存儲在一個state中，並且對右邊的state做join查詢。同理右邊的數據處理也是一樣，先存儲在一個state中，然後join查詢另一個state。
這樣的流程存在一個問題，即在join另一邊的state時可能沒有數據，傳統數據庫的做法是將它留空，而流上的數據會實時變化，此刻沒有join數據不代表下一刻還沒有。這就需要利用Retraction機制，在正確數據到來的時候撤回之前的空數據並重新填入新數據，如上圖所示。
總結
這裏我們對這5個概念做下總結。首先有了流表對偶性，流錶轉換纔有理論支撐，流表才能互轉；有了動態表的概念，SQL才能作用於流上，才能進行持續查詢；有了持續查詢的概念，才能真正解釋流式SQL計算永不結束，結果永遠在更新；增量計算配合查詢和引擎優化，纔有了Blink的高性能；Early Emit和Retraction，一個使用Blink有了無限逼近秒級毫秒級的低延時，一個保證了流式語義的正確性。
兩個案例和總結
案例1 - 無key熱點
對於有多區塊的數據源，每個區塊都會由對應的節點來處理。理想情況下每個節點的處理量相同，負載是均衡的，但是實際場景下可能會出現不均衡處理的情況，比如某個節點無法處理所負載的量，對此我們要將該節點無法處理的部分分配給其他節點。
Blink爲此提供了Dynamic Rebalance，它會感知下游節點的壓力情況，進而將繁忙的節點處理不過來的數據分發給空閒節點。需要注意的是目前的這種情況是無key節點，這意味着數據在哪個節點處理都可以。
案例2 - keyed熱點
Keyed就是對數據按key分組，相同的key必須到同一個節點上。這時候雖然框架也能感知到反壓，但是不可以使用反壓機制再分配節點上的數據。
這時候要用到Local-Global Aggregation，數據熱點優化的另一個方案，也是由系統內部的查詢優化器來完成，讓用戶無感知。它會先將每個節點的數據在本地進行Local Agg聚合，圖中不同的顏色表示不同的key，他們在本地會做局部的聚合，這樣原先上游的4條記錄就變成的1條，很大程度上減輕了下游節點的壓力。
總結
Blink SQL擁有標準的語義，完全支持標準的ANSI SQL，同時有豐富的功能，比如UDF、JOIN、雙流JOIN等。有更優的性能，在ANSI SQL的各個語法功能基礎上做了大量的性能優化。提供了一站式平臺，集開發、測試、部署、監控、升級於一體，讓用戶專注於自己的業務。