Apache Flink，流計算？不僅僅是流計算！

阿里妹導讀：2018年12月下旬，由阿里巴巴集團主辦的Flink Forward China在北京國家會議中心舉行。Flink Forward是由Apache軟體基金會授權的全球範圍內的Flink技術大會，2015年開始在德國柏林舉辦，今年第一次進入中國。

今天，計算平臺事業部的資深技術專家莫問，將帶領我們重溫這場大資料技術的饕餮盛宴，感受Apache Flink 作為下一代大資料計算引擎的繁榮生態。

Flink Forward China 大會邀請到了來自阿里巴巴、騰訊、華為、滴滴、美團點評、位元組跳動、愛奇藝、去哪兒、Uber、DellEMC、DA（Flink 創始公司）等國內外知名企業以及Apache軟體基金會的嘉賓為大家分享了Apache Flink的成長曆程、應用場景和發展趨勢。

Flink Forward China 2018 嘉賓PPT及演講視訊：

https://github.com/flink-china/flink-forward-china-2018

參與有道，如何更“好”地貢獻 Apache 專案

上午大會由Apache軟體基金會的祕書長Craig Russell開場，Craig首先分享了Apache開源之道，以及開源社群的精神和體制，然後以Apache Flink專案的成長經歷為背景，向大家介紹瞭如何建立以及管理一個Apache開源專案，如何為Apache開源專案做貢獻，並跟隨開源專案一起成長和收穫。

 

 

通過Craig的分享，我們也更詳細地瞭解到了Apache Flink的發展經歷。Flink早期起源於德國柏林工業大學的一個研究專案Stratosphere，並於2014年4月捐獻給Apache軟體基金會，同時重新定位品牌為Flink，經過8個月孵化期，在2014年12月成功從Apache軟體基金會畢業，成為Apache頂級專案，從此開始在大資料領域航行。經過最近4年的持續快速發展，Apache Flink社群已經培養出了42名Committer和19名PMC Member，不斷加入的新鮮血液為Apache Flink社群持續貢獻程式碼，並推動社群健康快速的發展。

 

 

雲上計算普惠科技

 

在Craig分享後，阿里巴巴集團副總裁、搜尋事業部與計算平臺事業部負責人周靖人進行了主題演講。靖人首先向大家介紹了阿里巴巴大資料雲上計算的現狀和趨勢，讓大家看到了阿里巴巴大資料業務場景的超大規模，以及未來更大的挑戰。

 

 

為了更好地支援阿里巴巴未來大資料的發展，阿里大資料發展策略一方面要進一步提升計算力和智慧化，增強企業級服務能力。同時也要加強技術的生態化建設，大力支援並推動開源技術社群的發展，相容行業生態標準，發展生態夥伴聯盟，推動生態建設。

目前阿里巴巴已經參與貢獻230+開源專案，具備8000+合作伙伴和2000+ ISV，雲上生態也已經突破1000,000開發人員。在大資料領域，阿里巴巴最近幾年對Apache Flink社群進行了持續大力的投入，貢獻超過15w行程式碼，主導建立了Flink China中文社群，加速Flink在國內的生態建設，並於今年開始在北京、杭州、上海、深圳等地多次組織Flink Meetup，促進國內Flink技術人員更方便的分享交流。

 

 

靖人在分享的最後宣佈了阿里巴巴內部Flink版本（Blink）將於2019年1月正式開源，本次開源內部版本的目標主要是希望讓廣大Flink使用者能提前享受到阿里巴巴對Flink的改進和貢獻。阿里巴巴同時會盡快將Blink中對Flink的各項改進和優化貢獻給Flink社群，堅持對Apache Flink一個社群的擁抱和支援。

 

 

Apache Flink，如何重新定義計算？

在靖人宣佈阿里巴巴開源內部Flink版本（Blink）後，阿里巴巴集團研究員蔣曉偉分享了Apache Flink在阿里巴巴內部的成長路線以及技術演進之路。

 

阿里巴巴從2015年開始調研Flink，並於2016年第一次在搜尋場景中上線Flink，在經過搜尋大資料場景的檢驗後，2017年Flink開始在阿里巴巴集團範圍內支援各項實時計算業務， 到目前為止阿里巴巴基於Flink打造的實時計算平臺，已經支援了包括淘寶、天貓、支付寶、高德、飛豬、優酷、菜鳥、餓了麼等所有阿里巴巴集團下的所有子公司的資料業務，並通過阿里雲向中小企業提供一站式實時計算服務。在2018年的雙11中，阿里實時計算平臺已經實現了峰值每秒17億次，當天萬億級的訊息處理能力。

 

 

Apache Flink目前在阿里巴巴內部最典型的業務場景是實時BI，阿里巴巴內部有著海量的線上交易以及使用者資料，實時看到各個維度的資料統計可以及時地感知並指導阿里巴巴的運營。下圖是一個典型的阿里實時BI流程，阿里的線上服務系統和資料庫會實時產生大量日誌資料並進入訊息佇列，FlinkJob會從訊息佇列中實時讀取處理這些資料，然後將各種統計分析結果實時更新到KV/Table儲存系統中，例如：HBase，終端使用者可以通過Dashboard實時看到各種維度的資料統計分析結果。

 

 

在雙11當天，各種維度的實時資料包表是指導雙11決策的依據，其中最為關鍵的就是全球直播的實時GMV成交額。Flink已經連續兩年支援阿里巴巴雙11實時GMV大屏，一個看似簡單的數字，其背後實際上需要大量Flink計算任務平穩、精準地執行支撐。

 

 

Flink在阿里巴巴另一個典型的應用場景是線上機器學習，傳統的離線機器學習方法需要T+1的分析使用者歷史行為，訓練出模型，當第二天模型上線後就已經是過去式，使用者當前的需求和預期可能已經完全改變。為了給使用者更好的購物消費體驗，阿里巴巴的機器學習系統早已經進化到線上學習時代，例如：當一個使用者在搜尋完一個Query，瀏覽結果頁時，或者點選檢視部分商品時，阿里巴巴的線上學習系統已經可以利用這個間隙瞭解到這個使用者當時的意圖和偏好，並在下次使用者Query時給出更好的排序，並向使用者推薦更合適的商品，這種方式不僅可以進一步提升業務效率，同時也能為使用者帶來更好的產品體驗，尤其是在雙11這種大促場景，使用者的行為時效性都是很短的，只有通過實時線上學習方式，才能做出更加精確的個性化預測和推薦。

 

線上學習系統的優勢在於可以實時收集並處理使用者的行為資料，從而進行實時流式的特徵計算和線上訓練，並將模型的增量更新實時同步回線上系統，形成資料閉環，通過不斷迭代自動優化系統效率和使用者體驗。在阿里的業務規模下，整個線上學習流程將會面對海量的使用者資料規模、和極其複雜的計算挑戰，但在Flink的驅動下，整個流程可以在秒級完成。

 

 

通過以上兩種經典場景可以看出阿里巴巴實時業務場景在各方面的挑戰都很大，直接將Flink社群版本在阿里上線使用是不現實的，因此阿里巴巴實時計算團隊這兩年也對Flink進行了全面的優化、改進和功能擴充套件，其中有些功能和改進已經推回到了Flink社群。

 

在Flink Runtime領域，阿里巴巴貢獻了：

 

全新的分散式系統架構：一方面對Flink的Job排程和資源管理進行了解耦，使得Flink可以原生執行在YARN，K8S之上；另一方面將Flink的Job排程從集中式轉為了分散式，使得Flink叢集規模可以更大的擴充套件。

 

完善的容錯機制：Flink預設在任何task和master失敗後，都會整個Job 重啟，阿里巴巴提出的region-based failover策略以及job manager failover/ha機制，讓Flink可以執行地更加可靠穩定；

 

大量的效能優化：Flink早期只提供全量Checkpoint機制，這在阿里巴巴大規模State場景下無法正常執行，阿里巴巴提出了增量Checkpoint機制，讓Flink即使在TB級State場景下也可以高效執行；Flink Job經常在內部運算元或者UDF中訪問外部儲存系統，例如：mysql，hbase，redis等，一旦出現個別query被卡住，整個task就被卡住，並通過反壓影響到整個job，阿里巴巴提出了async IO機制，大幅降低了同步IO訪問帶來的影響。 此外，阿里巴巴貢獻了credit-based的全新網路流控機制，使得Flink網路資料傳輸效能得到了顯著提升。

 

在Flink SQL領域，阿里巴巴貢獻了全新的Streaming SQL語義和功能。例如：Agg Retraction，UDX支援，DDL支援和大量的Connector適配。

 

 

在阿里巴巴，我們發現很多經典的業務場景都是同時具備實時流處理和離線批處理兩種需求，而且流處理和批處理中的業務邏輯幾乎是一樣的，但使用者需要開發兩套程式碼，兩套叢集資源部署，導致額外的成本。例如阿里巴巴的商品搜尋索引構建流程，白天需要將商品的更新資訊流式同步到搜尋引擎中，讓使用者可以在搜尋引擎中看到實時的商品資訊，晚上需要將全量的阿里巴巴商品進行批處理構建全量索引，這就是傳統的Lambda架構。

 

 

阿里巴巴的解法是希望提供一套批流融合計算引擎，讓使用者只需開發一套業務程式碼，就可以在實時和離線兩種場景下複用，這也是在2015年阿里巴巴選擇Flink作為未來大資料引擎的初衷。 Flink基於流處理機制實現批流融合相對Spark基於批處理機制實現批流融合的思想更自然，更合理，也更有優勢，因此阿里巴巴在基於Flink支援大量核心實時計算場景的同時，也在不斷改進Flink的架構，使其朝著真正批流融合的統一計算引擎方向前進。

 

在Flink Runtime領域，阿里巴巴提出了全新的Operator Framework/API設計，使其能夠同時適應批流兩種運算元特性；同時在Job排程和網路Shuffle兩種核心機制上，都實現了靈活的外掛化機制，使其能夠適應批流不同場景的需求。

 

在Flink SQL領域，阿里巴巴提出了全新的Query Execution和Optimizer架構，利用高效的二級制資料結構，更加合理的記憶體利用方式，更細粒度的Codegen機制以及更加豐富的優化器策略，使得Streaming 和Batch SQL都有了非常大的效能提升。

 

 

經過大量架構改進和效能優化後，阿里巴巴內部Flink版本（Blink）在批處理上也實現了重大成果突破，在1T，10T和30T的TPC-DS的Benchmark中，Blink的效能資料均明顯超出Spark，並且效能優勢在資料量不斷增加的趨勢下越來越明顯，這也從結果上驗證了Flink基於流做批的架構優勢。

 

 

目前，阿里巴巴的內部Flink版本（Blink）已經開始支援內部批流融合的應用場景，例如阿里巴巴的搜尋推薦演算法平臺，流式和批量的特徵以及訓練流程都已經統一基於Flink在執行。

 

 

蔣曉偉在分享的最後給出了對Flink未來的一些展望，他認為Flink除了批流融合，還有很多新的方向值得去擴充套件，例如：Flink可以進一步加強在機器學習和圖計算生態上的投入，從而在AI浪潮中實現新的突破。

 

此外，Flink天然具備基於事件驅動的處理思想，天然的反壓和流控機制，以及自帶狀態管理和彈性擴縮容的能力，這些優勢都在促使基於Flink構建微服務框架成為一種新的思想和解決方案。

 

 

總結蔣曉偉老師的分享，Apache Flink過去雖然在流計算領域已經獲得很大的成功，但Flink並沒有停滯，而是正在不斷在突破自己的邊界，Flink不僅僅是Streaming Engine，也不僅僅是Bigdata Engine，未來更希望努力成為Application Engine。

 

 

流處理即未來

接下來來自DA（Flink創始公司）的CTO - Stephan Ewen也對Flink的發展趨勢給出類似的觀點。Stephan認為“Streaming Takes on Everything”即流處理是一切計算的基礎， Flink一方面需要朝著離線方向發展，實現批流融合大資料計算能力，另一方面也需要朝著更加實時線上方向發展，支援Event-Driven Application。前面已經重點闡述了Flink在批流融合計算方面的進展，接下來我們重點介紹下Flink在Event-Driven Application方向的思路。

 

 

傳統的應用服務架構一般是Online App +Database的架構，Online App負責接收使用者Request，然後進行內部計算，最後將Result返回給使用者，Application的內部狀態資料儲存在Database中；在Flink的event-drivenApplication架構中，可以認為Flink Source接收Request， Sink返回Result，JobGraph進行內部計算，狀態資料都儲存在State中。

 

 

傳統應用服務架構需要自己負責分散式和彈性管理，並由Database負責資料一致性管理；而Flink在這兩方面是存在天然優勢的，因為Flink天然是分散式系統，可以自己管理彈性伸縮，此外Flink內建了狀態管理和exactly once一致性語義，因此基於Flink可以更方便、高效實現Transactional Application。

 

城市級實時計算的力量

在Apache Flink社群大神Stephan Ewen的分享後，來自阿里雲的AI首席科學家閔萬里向大家分享了實時計算在阿里雲智慧城市中發揮的力量，通過分享多個真實應用案例，讓大家對實時技術有了更多的體感和認識。

 

在城市大腦的業務場景中，不僅要能實時處理來自各種感測器收集到的資訊，對現實世界發生的事情進行響應，同時也要對未來將要發生的事情進行預測，例如：接下來那裡可能要發生交通擁堵，從而提前做出干預，這才是更大的價值。整個城市大腦的架構都執行在阿里雲基礎設施之上，Apache Flink承擔了核心實時計算引擎的角色，負責處理各種結構化和非結構化資料。

 

 

在2018年9月的雲棲大會上，阿里雲釋出了杭州城市大腦2.0，覆蓋杭州420平方公里，可以監控到超過150萬輛在途行駛機動車的實況資訊，這個看似簡單的事情在過去是很難做到的，現在我們通過1300多個路口的攝像頭、感測器以及高德App的實時資訊，通過Flink進行三流合一的處理，就可以實時感知到整個城市交通的脈搏資訊，並通過進一步分析可以得出延誤、安全等交通指數，預測感知城市的態勢發展。

 

 

在杭州，城市大腦通過實時分析4000多個交通攝像頭採集的視訊流，可以實時監控路上車輛的異常事件，例如：車輛超速、逆行和擦碰等，並將這些異常事件實時同步到交警指揮中心進行實時報警，目前杭州的交通事件報警已經有95%來自城市大腦自動通報的，這背後都是通過Flink進行各種複雜的計算邏輯實時算出來的。實時計算讓交警處理交通故障的方式從過去的被動等待變成了主動處理，從而大幅提升城市交通的效率，為老百姓帶來實實在在的好處。

 

 

這50%，關乎生死

2018年，城市大腦第一次走出國門，來到馬來西亞吉隆坡，基於實時大資料對交通進行智慧排程，它可以根據救護車的行駛資訊，以及沿途路況資訊，智慧調整紅綠燈，為救護車開闢綠色快速通道，這項技術為救護車節省了近50%的時間到達醫院，這50%的時間可能意味著人的生和死，在這裡技術顯得不再骨感，實時計算的力量也許可以挽救生命。

 

 

在工業生產IOT場景中，大量裝置的感測器都收集了海量的指標資料，這些資訊過去都被暫存2個月後丟棄了，唯一的用途就是在出現生產故障時拿來分析用，在有了大資料實時計算能力後，這些指標都可以被實時監控起來，作為及時調控生產流程的依據。協鑫光伏是全球最大的光伏切片企業，阿里雲利用實時裝置監控，幫助其提高了1%的良品率，每年可以增加上億元的收入。

 

 

滴滴實時計算平臺架構與實踐

Keynote最後一位嘉賓是來自滴滴出行的研究員羅李，大家都知道滴滴出行是一個實時出行平臺和交易引擎，它的資料和場景天然是實時的，各種網約車服務產生的資料都需要實時處理和分析。

 

 

滴滴的實時業務場景主要包括實時風控、實時發券、實時異常檢測，實時交易、服務和工單監控，以及實時乘客、司機和訂單特徵處理等。

 

滴滴實時計算平臺發展已經經歷了三個階段，第一階段是各個業務方自建小叢集，造成叢集和資源碎片化問題；第二階段由公司統一建立了大叢集，提供統一的平臺化服務，降低了叢集資源和維護成本；第三階段是通過Flink SQL方式提供平臺化服務，通過SQL語言優勢進一步降低業務開發成本，提升開發效率。

 

滴滴現階段基於Apache Flink引擎建設的實時計算平臺以開源的Hadoop技術體系作為平臺底座，並通過DataStream, SQL和CEP三種API向滴滴內部業務提供實時計算服務，同時在平臺層也已經具備相對完善的WebIDE、資料血緣管理、監控報警和多組合隔離等機制。

 

 

在滴滴實時業務的快速發展推動下，其實時計算叢集已經達到千臺規模，每天執行2000+流計算任務，可以處理PB級的資料。

 

滴滴在搭建Flink實時計算平臺的過程中，在內部也對Flink做了一些改進，例如在 Stream SQL領域擴充套件了DDL，豐富了 UDF，支援了TTL的雙流Join和維表Join等；在CEP領域，增加了更多運算元支援和規則動態修改能力等，其中部分優化已經推回了社群。

 

 

最後，羅李介紹了滴滴實時計算平臺的未來規劃，主要方向在於進一步推廣Stream SQL提升業務開發效率，推動CEP在更多業務場景落地，同時完成公司內部原有Spark Streaming向Flink的遷移，併發力IOT領域。

 

在下午的幾個分會場中，來自阿里巴巴、騰訊、華為、滴滴、美團點評、位元組跳動、愛奇藝、去哪兒、Uber、EMC、DA（Flink 創始公司）的多位嘉賓和講師都圍繞Flink技術生態和應用場景進行了分享和交流。從分享的內容上可以看出，BAT三家中阿里巴巴和騰訊都已經完全擁抱了Flink；美團、滴滴和位元組跳動（TMD）三家新興網際網路企業在實時計算場景也都已經以Flink作為主流技術方向開始建設，滴滴在Keynote上分享已經令人印象深刻，美團的實時計算叢集也已經突破4000臺規模，位元組跳動（頭條和抖音的母公司）的Flink生產叢集規模更是超過了1w臺的驚人規模 。

 

 

由此可見Apache Flink的技術理念已經在業界得到了大量認可，基於Flink的實時計算解決方案開始在國內佔據主流趨勢。下一步Flink需要一方面繼續完善流計算能力，爭取在IOT等更多場景落地，與此同時進一步加強在批流融合能力上的全面突破，並完善在機器學習和AI生態上的建設，以及在event-driven的application和微服務場景上進行更長遠的探索。

我們期待與你一起共建更好的Apache Flink。

你可能還喜歡

點選下方圖片即可閱讀

首次公開！《阿里計算機視覺技術精選》揭祕前沿落地案例

周博通 | 阿里開源首個 DL 框架、4000臺伺服器真實資料集；明年1月開源Blink

萬字長文揭祕：阿里如何實現海量資料實時分析？

關注「阿里技術」

把握前沿技術脈搏