本文根據阿裡資深搜尋專家蔣曉偉在首屆阿裡巴巴線上峰會上的分享整理而成。 此次分享的重點是blink計算引擎，它是阿裡巴巴搜尋的流計算和批處理引擎。相比于flink，在上層，blink具有批和流一體化的完備table api，使得其能夠支撐各類業務需求；在底層，blink重新開發了相容flink以及生态的runtime，實作了流處理和批處理完美的統一。
<b>直播視訊：</b>
（點選圖檔檢視視訊）
以下為整理内容。
搜尋文檔的建立和更新
要建立一個搜尋系統，首先需要建立搜尋文檔，具體的建立過程分為三個步驟：第一步，将分散在各地的資料同步到hbase上，資料同步之後，hbase中就包含了建立文檔所需的全部資料；第二步，将hbase中的資料進行彙總，經過業務邏輯的處理後，将産生的需要搜尋的文檔存在結果表當中；第三步，将hbase中的結果表導出到搜尋引擎中，即完成了搜尋文檔的建立。值得注意的是：上述每一步驟都包括全量和增量兩個流程。
<b>物化視圖</b>
結果表可以當做是物化視圖，物化視圖是一種延伸資料，類似于索引。資料庫可以確定物化視圖和其對應的表的一緻性。從物化視圖的觀點出發，可以對全量和增量進行重新解釋，所謂的全量，是相當于索引的建立和重建的流程；而增量則意味着索引的維護。通過物化視圖，僅使用同一句sql語句即可同時解決增量和全量的問題。
<b>流和表的對偶性</b>
要在大資料内實作增量和全量的統一處理，首先我們需要了解幾個概念。
第一個概念是流和表的對偶性。上圖的左半部分是一個流，它包括word和 count兩列，記載了每一詞的出現次數；右邊是一張曆史表，同樣包含word和count兩列，但是word列是具有對應主鍵的。如果利用左邊的流更新右邊的曆史表，就會由原來的五條記錄縮減到三條記錄。通過物化操作，可以把一個流轉化為曆史表；當曆史表存在時，我們可以通過檢視、導出曆史表的修改日志，恢複原來的流。在某種意義上，流和曆史表所包含的資訊量是相同的。流和表的對偶性，意味着我們可以将流計算和批處理結合起來。有一點需要注意的是，這裡表是指動态的表，裡面的内容是不斷修改的。
第二個概念是流的等價性，兩個流當且僅當它們産生相同的正則曆史表時，兩個流等價。如果有兩個流用來更新同一個曆史表，假設在不同的時間點，它們都能得到相同的曆史表，則這兩個流就是等價的。流的等價性給流處理帶來了很大的靈活性，正是這種靈活性使得我們可以在blink中完美地結合流處理和批處理。
什麼是blink？
blink是阿裡巴巴搜尋團隊基于flink開發的計算引擎，其目的是為了支撐阿裡巴巴大規模的計算需求。blink實作了流處理和批處理完美的統一。相比于flink，在上層，blink具有批和流一體化的完備table api，使得其能夠支撐各類業務需求；在底層，blink重新開發了相容flink以及生态的runtime。
<b>blink的table api</b>
blink的table api的設計原則是實作流和批的一體化處理。秉着該原則，blink開發了一系列的功能，包括：
udf/udtf/udagg，使用者可以利用這些函數輕松實作業務邏輯的表達；
雙流join；
aggregation（min、max、avg、sum、count、distinct_count）；
windowing；
retraction撤回機制。
<b>blink的runtime</b>
blink在runtime上也做了很多改進。首先blink實作與yarn的原生态整合；其次對checkpoint和狀态管理進行了優化，使其能夠真正用于生産環境中；同時，blink在容錯性、高可用性、穩定性和可運維性等方面都有很大的改進；此外，blink還支援動态伸縮。
flink on yarn
上圖展示的是flink在yarn上的架構，yarn是hadoop内的排程系統。flink與yarn整合的思路十分簡單：在運作flink之前，首先需要啟動flink叢集，該叢集需要實作配置好；叢集啟用之後，flink叢集就可以接收使用者送出的工作；flink叢集接收到使用者提供的工作之後，通過jobmanger将從yarn處擷取的資源配置設定給不同的job。在每個yarn node上存在一個yarn nodemanager，它用來調用不同的container。該架構存在幾個明顯缺陷：第一，不同的flink job的任務可能會運作在同一flink taskmanager中，即不同job的任務可能運作在同一個程序内，其中一個job的任務失敗可能會殺死整個程序，隔離性較差；第二點，由于flink叢集需要事先配置，一旦資源被flink占用後，yarn就無法再将這些資源配置設定給其他的叢集，這樣就有可能導緻一定程度的資源浪費，同時如果事先配置的資源不足，flink叢集是無法簡單地擴容；第三點，由于管理全部job的flink jobmanager程序運作在一個獨立的container，當job急劇增加時，flink jobmanager就成了整個架構可伸縮性的瓶頸。
<b>blink yarn的原生态整合</b>
在blink yarn的原生态整合中，去掉了單點的jobmanager。當使用者送出job時，yarn resourcemanager會啟用一個job master，兩者一一對應，當job内的task需要資源時，再通過job master向yarn申請資源，實作資源的動态配置設定；同時，不同的job處于不同的container中，確定job之間的隔離。
<b>blink的失敗處理機制</b>
在分布式系統中，失敗是不可避免的。面對機器挂掉、程序崩潰時，如何保證系統的一緻性是一個很大的挑戰。一緻性主要包括至少一次和恰好一次兩個語義。至少一次是說，流來的每個消息能夠保證至少處理一次，不會丢失消息。至少一次相對而言比較容易實作，隻需要記錄哪些消息成功處理過了，即使某個消息處理失敗，也隻需要從最後一條成功處理的消息之後重新開始處理即可。
恰好一次是指處理過的消息與狀态的一緻性。如何實作恰好一次這種邏輯呢？在分布式系統中，我們可以通過chandy-lamport算法實作恰好一次的邏輯。在流的源頭上，當需要做checkpoint時，插入名為barrier的特别消息即可。它的作用是将state 擷取快照之前的消息和之後的消息區分開來。barrier同其他消息一樣，同樣會流入每一個operator中。
<b>blink worker的錯誤恢複</b>
blink worker的錯誤恢複分為兩種情形：第一種是at least once，如果一個節點fail了，我們隻需要重新開機該節點，然後找到影響該節點的源頭，再将源頭進行回放即可，無需重新開機整個job；第二種是exactly once，如果有一個節點fail，我們需要找到該節點的連通圖，将該節點重新開機，然後将連通圖回退到上次checkpoint的位置進行回放即可。
<b>blink master的高可用性</b>
當blink的jobmaster失敗之後，yarn會重新啟動該jobmaster，但是此時jobmaster已經丢失了原來的狀态。為了保證jobmaster不丢失原來的狀态，我們将jobmaster内的代碼寫成了狀态機，每次狀态修改之前都需要log到hdfs；在新的jobmaster啟動之前，通過hdfs的回放得到其原有狀态，進而保障了blink master的高可用性。
<b>blink的動态伸縮</b>
在流計算中，實驗和真正上線使用時是存在偏差的，而且随着業務的增加，流量也會随之改變。通過引入bucket，動态支援blink的伸縮。此外，在blink中，我們添加了多個監控名額，用于觀測job性能。
現狀與計劃
目前blink在阿裡已經實作上千台機器規模的叢集上線，用于支撐搜尋和推薦的核心業務。同時，集團内外對blink表現出了濃厚的興趣，包括uber、facebook等在内的企業都在考慮使用blink。