Flink China 上海站Meetup 小小小總結

氛圍

這是我第一次參加工業界自發組織的技術類線下meetup，因為場地設置在一個咖啡館裡，整體比較舒適輕鬆，topic明確，規模小。發現組織活動為了準時開始好像都喜歡「假裝」把開始時間提前一個小時告知大家。一共五小場分享，每個半小時左右，每場結束chair會限制提問個數，還會發起一次紅包，最後一個領到的人獎勵一個訂製包包 中間有一次茶歇(提拉米蘇和華夫餅還闊以），滿意的是只聽到過一次手機響，演講過程中也沒人隨意走動，大家都很自覺維持分享者與聽眾之間的交流狀態。

活動主要議題

巴真 阿里 《Flink：構建下一代大數據處理引擎》

a. 3V數據趨勢，但是Velocity還是棘手，每秒處理472 Millon個事件，要求sub-second級的延遲，Hadoop與Spark可以解決volume和variety的問題，storm與Flink可以解決volume和velocity的問題，但是3v相結合是challenge的

b. 計算趨勢是 計算碎片化，計算越來越貼近終端，就近選擇數據站處理，未必都要傳輸到雲端；模型多樣化

c. 用戶趨勢，在阿里人人都是數據分析師，BI工程師轉型為AI工程師

d. 分享了3個典型案例，阿里/滴滴/知乎

e. 阿里的思考，計算類型雖多，但是核心模型批處理佔大頭，剩下的OLAP和流佔小頭；批處理99%都是sql，而流處理99%都是nosql；需要統一計算引擎，統一抽象方式，提供unified sql，統一BI和AI引擎

f. 如何構建下一代大數據處理引擎，從完備性和易用性兩個維度，分析各類計算平台、雲產品、開源軟體的優缺點，並主要分析了不選擇Spark的三大問題(實際覆蓋的計算模型不完整+穩定性未解決+中文社區、資料匱乏，沒有有效組織)

g. 阿里基於Flink創造了Blink，從scalability&complexity兩個維度，優化了很多方面

王新春 唯品會 《Flink在唯品會的實踐》

a. 先介紹唯品會的實時平台現狀，計算平台以Storm與Spark佔據大頭，Flink分量較低，核心業務包括實時推薦引擎、內部大促看板、實時數據清洗、互聯網金融、安全風控、比價，等等

b. Flink的應用場景有大促實時看板，處理的數據量大，統計維度多

c. 從Storm遷移到Flink，穩定性可靠性提升，資源消耗也降低了2/3，比如計算狀態原來Storm是需要和Redis頻繁通過網路RPC交互，大促式單獨的redis集群會壓滿

d. 基於Kubernates管理實時和AI平台，統計計算資源，獨立容器組件有各自的ip

e. 目前還在做的，統一數據源UDM架構 (關於這點有位思科的engineer提問到，他們在做的智慧城市經常面臨不同scheme的數據源)

劉康 攜程 《基於Flink的實時特徵平台》

a. 先介紹了攜程原來的實時特徵作業開發運維的痛點，根據性能metrics選擇Storm或Spark，平均作業耗時3-5填，大部分需要用到消息隊列作數據源，但是消息是非結構化數據、無統一數據字典；根據業務需求設計計算邏輯；實時處理不能滿足數據需求的情況下，還要開發單獨的離線作業和融合邏輯；校驗和糾錯沒有形成最佳實踐，實際效果還是依賴個人能力，等等，這些都是improve的目標

b. 平台目前還是標準的lambda架構，KV系統選用Aerospake存儲離線特徵，也是流處理數據源的一部分

c. 介紹了為什麼要轉用Flink，毫秒級的延遲/ABS的容錯機制/SQL的支持度

d. 使用Flink的案例，以及遇到的問題，比如會話窗口用途廣，可以用於推薦召回、用戶召回等，相比之下原先設計方案中需要使用分散式鎖做進程間的並發控制，較為複雜；比如窗口的offset需要小於窗口大小，且不能用於時區適配，等等

e. 介紹了使用Flink之後平台的效果，上線周期從原來的3-5天降低到小時級；闡述了未來的規劃，模型訓練平台-特稱平台-模型部署服務

易偉平 餓了么 《Flink在餓了么的應用與實踐》

a. 介紹了餓了么的平台架構實現，數據源有應用的日誌、DRC、Flume/Hangout等，以Kafka作為消息中間件，計算平台Storm、Spark和Flink都有用，Storm佔據2/3，Spark佔據1/3，Flink目前用的比較少，存儲backend涉及到redis、mysql、kafka等

b. 目前的數據現狀是每天60TB的量，集群規模為400個節點

c. 介紹了三個計算平台各自的優缺點，以及內部應用場景；單獨介紹了一致性語義問題，認為目前exactly-once=at-least-once+冪等操作(emmm，我發現分享了很多基礎知識)

d. 因為餓了么現在是阿里系了嘛，所以，未來Flink的參與度要提高

大沙 阿里 《Flink計算的現狀與未來：融入Flink生態 參與開源開發》

a.總結流計算六大核心技術，即低延遲/快速容錯/通用API/易用/彈性/高性能，各自都有貢獻社區，譬如大規模高並發部署優化、容錯方面的增量式checkpoint/優化柵欄對齊、主導制定Flink SQL語義/完善Flink SQL功能，實現了聚合、連接、窗口操作，跑通全部的TPC-H查詢，等等

b. 流和批的統一是大勢所趨，本質區別在於何時把處理結果反饋給用戶，批可以看作是流處理的一種特例，如果可以用SQL統一流和批的計算，可以減少很多工作，比如原來開發者需要自己將SQL轉化為流式拓撲，比如SQL的optimizer都是現有的，不再需要根據業務來手動優化，而是根據設計好的cost model( StateIO-cost plays a big role on plan choosing)

c. 阿里的Blink實現了SQL Enginee架構，提交同樣的SQL查詢，根據設置的處理模式，批還是流，生成輸出同樣的結果

d. Flink未來的應用場景主要包括流批的統一計算，人工智慧、機器學習，物聯網領域，實時BI，規則引擎

e. Flink的生態可能不及Spark，德國的團隊可能更focus技術本身，需求驅動作用不強，相反Spark是用戶需要什麼，他們就提供什麼

f. 如何融入開源社區，參與開源開發，學會review他人的code很重要

Slide鏈接：https://1drv.ms/f/s!At--zp96qv_FhqFESREoXNrW8GHfgw

Flink Forward China大會

約12月21日北京，求組隊~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！