[[180070]]

阿里巴巴是世界上***的電子商務零售商。 我們在2015年的年銷售額總計3940億美元，超過eBay和亞馬遜之和。阿里巴巴搜索(個性化搜索和推薦平臺)是客戶的關鍵入口，并承載了大部分在線收入，因此搜索基礎架構團隊需要不斷探索新技術來改進產品。

在電子商務網站應用場景中，什么能造就一個強大的搜索引擎?答案就是盡可能的為每個用戶提供實時相關和準確的結果。同樣一個不容忽視的問題就是阿里巴巴的規模，當前很難找到能夠適合我們的技術。

Apache Flink®就是一種這樣的技術，阿里巴巴正在使用基于Flink的系統Blink來為搜索基礎架構的關鍵模塊提供支持，最終為用戶提供相關和準確的搜索結果。在這篇文章中，我將介紹Flink在阿里巴巴搜索中的應用，并介紹我們選擇在搜索基礎架構團隊中使用Flink的原因。

我還將討論如何改進Flink以滿足我們對Blink的獨特需求，以及我們如何與data Artisans和Flink社區合作，將這些更改貢獻給Flink社區。一旦成功地將我們的修改合并到開源項目中，我們會將現有系統從Blink轉移到Apache Flink。

Part 1： Flink在阿里巴巴搜索中的應用

文檔創建

為用戶提供***搜索引擎的***步是創建可供搜索的文檔。在阿里巴巴的應用場景中，文檔是由數百萬個商品列表和相關的商品數據組成。

因為商品數據存儲在許多不同的地方，所以搜索文檔創建也是一個很大的挑戰，搜索基礎架構團隊將商品相關的所有信息匯總在一起并創建完整的搜索文檔。一般來說，整個過程分為3個階段：

1. 將不同來源(例如MySQL，分布式文件系統)的所有商品數據同步到一個HBase集群中。
2. 使用業務邏輯將來自不同表的數據連接在一起，以創建最終的可搜索文檔。這是一個HBase表，我們稱之為'Result'表。
3. 將此HBase表導出為文件作為更新集合。 

這3個階段實際上是在經典的“lambda架構”中的2個不同的pipeline上運行：全量構建pipeline和增量構建pipeline。

• 在全量構建pipeline中，我們需要處理所有數據源，這通常是一個批處理作業。
• 在增量構建pipeline中，我們需要處理在批處理作業完成后發生的更新。例如，賣家可能修改商品價格或商品描述以及庫存量的變化。這些信息需要盡可能快的反饋在搜索結果中。增量構建pipeline通常是一個流式作業。

搜索算法實時A/B測試

我們的工程師會定期測試不同的搜索算法，并且需要盡可能快地評估出效果。現在這種評估每天運行一次，因為想實時分析效果，所以我們使用Blink構建了一個實時A/B測試框架。

在線日志(展示，點擊，交易)由解析器和過濾器收集和處理，然后使用業務邏輯連接在一起。接下來聚合數據，將聚合結果推送到Druid，在Druid內部，我們可以編寫查詢語句并對數據執行復雜的OLAP分析，并查看不同算法的效果。 

在線機器學習

在這部分中Flink有兩個應用場景。首先，我們來討論它在商品特征實時更新中的應用。阿里巴巴搜索排序中使用的一些商品特征包括商品CTR，商品庫存和商品點擊總數。這些數據隨時間而變化，如果可以使用***的數據，我們就能為用戶提供更相關的搜索結果排序。Flink pipeline為我們提供在線特征更新，并大大提高了轉化率。

其次，每年的特定日子(如光棍節)，有些商品折扣力度很大，有時甚至高達50%。因此，用戶行為也會發生很大的變化。交易量巨大，通常比我們在平時看到的高出很多倍。以前訓練的模型在這個場景作用有限，因此我們使用日志和Flink流式作業構建了在線機器學習模型，這個模型會將實時用戶行為數據反饋到系統中。結果在這些不常見但非常重要的營銷節日的轉換率有了很大的提升。 

Part 2： 選擇一個框架來解決問題

選擇Flink應用到搜索基礎架構中，我們在四個方面做過評估。 Flink在四個方面都滿足我們的要求。

• 敏捷： 我們期望能夠為整個(2個pipeline)搜索基礎架構流程維護一套代碼，因此需要一個高級的API來滿足我們的業務邏輯。
• 一致性： 賣方或商品數據庫發生的變化必須反饋在最終搜索結果中，因此搜索基礎架構團隊需要至少處理一次(at-least-once)的語義(對于公司中的一些其他Flink用例，要求正好一次(exactly-once)語義)。
• 低延遲： 當商品庫存量發生變化時，必須盡快在搜索結果中得到體現。例如我們不想給售罄的商品給出很高的搜索排名。
• 成本： 阿里巴巴需要處理大量數據，以我們的集群規模，效率提高可以顯著的降低成本。因此我們需要一個高性能、高吞吐量的框架。

一般來說，有兩種方法來將批處理和流式處理統一起來。一種方法是將批處理作為基本出發點，在批處理框架上支持流式處理。這可能不符合真正意義上低延遲，因為用微批量處理(micro-batching)模擬流式處理需要一些固定的開銷。因此，當試圖減少延遲時，開銷的比例也會相應增加。在我們的規模上，為每個微批量處理器調度1000個任務，需要重新建立連接并重新加載狀態。因此在某種程度上，微批處理方法代價太高將變得沒有意義。

Flink從另一個角度來解決這個問題，即將流式處理作為基本出發點，在流式處理框架上支持批量處理，將批處理作為流式處理的一種特殊情況。使用這種方法，不會丟掉我們在批處理模式(批處理模式下流是有限的)下做出的優化，你仍然可以做一些批量處理上的優化。

Part 3： Blink是什么?

Blink是Flink的一個分支版本，我們做了一定的改進以滿足阿里巴巴的一些特定需求。因此，Blink在幾個不同的集群上運行，每個集群有大約1000臺機器，大規模集群的性能對我們來說非常重要。

Blink的改進主要包括兩個方面：

Table API更完整，因此我們可以使用相同的SQL進行批處理和流式處理。

更強大的YARN模式，但仍然100%兼容Flink的API和更廣泛的生態系統。

Table API

我們首先添加了對用戶自定義函數UDF的支持，方便在Flink中實現獨特的業務邏輯。我們還添加了一個流對流的join的功能，由于Flink對于狀態比較好的支持，所以實現起來比較容易。我們添加了幾個聚合函數以及滑動窗口的支持，最有趣的一個是distinct_count。

(編輯注：FLIP-11涵蓋了與上述功能相關的一系列Table API和SQL改進，對該主題感興趣的可以閱讀) 

接下來，我們將介紹運行時改進，可以分為四個不同的類別。

Yarn上的Blink

當我們開始項目時，Flink支持2種集群模式：standalone模式和YARN上的Flink。在YARN模式中，作業不能動態請求和釋放資源，而是需要預先分配所有需要的資源。不同的作業可能共享相同的JVM進程，這有利于資源利用和資源隔離。

Blink中每個作業都有自己的JobMaster，以根據作業需要請求和釋放資源。并且不同的作業不能在同一個Java進程中運行，這將在作業和任務之間得到***隔離。阿里巴巴團隊目前正在與Flink社區合作，將這項工作貢獻給開放源代碼，改進工作在FLIP-6(除了YARN之外還擴展到其他集群管理器)中得到了體現。 

Operator縮放

在生產環境中，我們的客戶端可能需要改變Operator的并行性，但同時他們不想失去當前狀態。當我們開始使用Blink時，Flink不支持在保持狀態的同時改變Operator的并行性。Blink引入了“bucket”的概念作為狀態管理的基本單位。有比任務更多的bucket，并且每個任務將被分配多個bucket。當并行性改變時，我們將重新分配任務的bucket。 使用這種方法，可以改變Operator的并行性并維持狀態。

(編者注：Flink社區同時在Flink 1.2版本中解決了的這個問題 - 該功能在***版本的主分支中可用。Flink的“key groups”概念在很大程度上等同于上面提到的“bucket”，但是實現時使用的數據結構略有不同。更多信息，請在Jira查看FLIR-3755) 

增量Checkpoint

在Flink中，Checkpoint操作分為兩個階段：在本地獲取狀態快照，然后將狀態快照保存到HDFS(或另一個存儲系統)，并且每個快照的整個狀態存儲在HDFS中。我們的狀態數據太大了，這種方法是不可行的，所以Blink只存儲修改的狀態在HDFS中，這能夠大大提高Checkpoint的效率。這種修改使我們能夠在生產環境中使用很大的狀態數據。 

異步I/O

我們的job在生產環境中很大瓶頸在訪問外部存儲器上，如HBase。為了解決這個問題，我們引入了異步I/O，我們將致力于為社區做出貢獻，并在FLIP-12中有詳細描述。

(編輯筆記：data Artisans認為FLIP-12足夠強大，可以在不久的將來在某個時間擁有自己的獨立寫入。所以我們只是簡單地介紹一下這里的想法，如果你想了解更多，可以查看FLIP writeup) 

Part 4： 阿里巴巴的Flink未來計劃是什么?

我們將繼續優化我們的流式job，特別是更好地處理臨時傾斜(temporary skew)和慢節點(slow machines)，同時不會對反壓機制(backpressure)和故障快速恢復造成影響。正如在Flink Forward大會上大家討論的，我們認為Flink作為批處理框架以及流式處理框架有著巨大潛力。我們正在努力利用Flink的批處理能力，希望在幾個月內在生產環境中使用Flink批處理模式。

會議的另一個熱門話題是流式SQL，我們將繼續在Flink中添加更多的SQL支持和Table API的支持。阿里巴巴的業務持續增長，這意味著我們的job會越來越大，確保我們可以擴展到更大的集群變得越來越重要。

非常重要的是，我們期待與社區繼續合作，以便將我們的工作貢獻回開源社區，以便所有Flink用戶都能從我們加入Blink的工作中受益。我們期待著在2017年Flink Forward大會上向您介紹我們的進展情況。