摘要:2019雲棲大會大數據 & AI專場,阿里巴巴資深技術專家王峯帶來「Ververica Platform-阿里巴巴全新Flink企業版揭祕」的演講。本文主要從Ververica由來開始談起,着重講了Ververica Platform的四個核心插件App Manager、Libra Service、Stream Ledger、Gemini,以及阿里巴巴實時計算雲原生版本相關特性及典型應用場景。算法
直播回放請點擊數據庫
如下是精彩視頻內容整理:緩存
隨着人工智能時代的降臨,數據量的爆發,在典型的大數據業務場景下數據業務最通用的作法是:選用批處理的技術處理全量數據,採用流式計算處理實時增量數據。2017年基於Flink開發的實時計算產品正式服務於阿里巴巴集團內部,並從搜索和推薦兩大場景開始應用。目前阿里巴巴及下屬全部子公司,都採用實時計算產品來處理全部的實時業務。安全
衆所周知,Apache Flink是業界很是流行的流計算引擎,最先誕生於歐洲,是柏林大學的研究型項目。後來由項目的發起人創辦了DataArtisans公司並根據該研究項目孵化出 Flink,並於2014年將 Flink 捐贈給 Apache基金會。性能優化
同年,阿里巴巴開始關注Flink。因爲搜索有不少業務場景很是依賴大數據和實時數據處理,而Flink在架構設計上,做爲全流式的執行引擎,數據處理效率很是高。因而阿里巴巴內部開始着手研究Flink,並看好Flink將會成爲新一代計算引擎,加速大數據計算的將來發展。數據結構
通過一年努力,阿里內部對Flink的開源版本作了不少深度優化與改進,使其可以適應阿里巴巴超大規模的業務場景,包括搜索、推薦等核心的業務場景。2016年,第一次將Flink推到雙11場景使用,構建了搜索、推薦的全實時鏈路(包括在線學習、模型預測等),造成了一套完整的閉環。2017年,阿里巴巴全線上線了基於Flink實時計算產品,服務於阿里巴巴的搜索、推薦等核心場景以及廣告、數據和全部部門的實時在線業務,好比:阿里巴巴雙11全天各類多維的數據統計,交易額大屏幕的全球直播等所有都是由基於Flink的實時計算產品來支持。架構
在此基礎之上,2018年,咱們首次在阿里雲公有云推出基於Flink的實時計算服務,開始支持各行各業的企業客戶。阿里巴巴對Flink的承認度在逐漸增長,Flink也證實了在實時計算的業務中的巨大潛力。自此,阿里巴巴加大了對Flink的投入並加速推動Flink社區的發展。2019年1月,阿里巴巴收購了DataArtisans並建立了新企業品牌Ververica,以上即爲Flink的企業品牌Ververica的由來。併發
在開源這塊,相信你們都很是瞭解每一個大的開源項目背後都有一個企業品牌,隨着整合的逐步完善,德國的Flink創始團隊與中國阿里巴巴的實時計算團隊也開始密切合做。與此同時,咱們也在持續推進Flink社區的發展。1月初,阿里巴巴將內部維護的Flink分支Blink貢獻給整個Flink開源社區,目前阿里巴巴對Flink社區貢獻的代碼已超過100萬行。而且,兩個團隊密切配合在商業化上進行聯合做戰,推出全新的Flink企業版——Ververica Platform。運維
Ververica Platform的技術架構如何,可以解決哪些應用場景,下面將詳細講解。機器學習
Ververica Platform是阿里巴巴推出的全新企業版,它仍然堅持以Apache Flink 的社區版本爲內核,同時可以兼容各類企業級插件,在整個基於Flink的實時計算解決方案上對應用性、穩定性、性能、可運維性等方面提供企業級的增值服務。
首先,Ververica Platform是一個企業級的開放軟件,支持客戶將其部署在生產環境中,對接已有的周邊生態系統如日誌、Metrics、存儲等。最初在設計Ververica Platform時就將其定位爲徹底雲原生的方案,系統組件和核心組件都以支持微服務方式部署到Kubernetes上,用戶能夠很是方便的將Ververica Platform和本身的在線服務或其餘數據服務作雲原生的混布。
Ververica Platform使用Apache Flink做爲其核心的計算引擎,保證和社區的徹底兼容。上圖爲Apache Flink最新演進的架構圖。Apache Flink的本質是一款有狀態的流式計算引擎,能夠鏈接各類各樣的存儲,經過ETL計算、數據分析等將數據結果導入到另外的存儲中。做爲流式計算,Flink的時效性很是好,能夠在高吞吐量的同時達到亞秒級延時。Flink不只可以鏈接消息隊列等無限數據流的數據源,也能夠鏈接文件系統、數據庫表、KV存儲等有限的數據集,因此Flink也在基於流式計算的優點上逐漸朝着批流融合的方向發展,有但願成爲一種新的批流合一的全能計算引擎。
因此Ververica Platform將會依賴社區的力量,採用Flink社區的主流版本做爲內核,全部的增值服務、各類優化都會經過嵌入的方式來實現,爲用戶提供一個開放透明的計算引擎。如下將詳細介紹Ververica Platform的核心插件。
Ververica Platform在應用上的企業級插件叫APP Manager,是管理Flink全生命週期的工具。Flink做爲計算引擎,在易用性方面能夠採用多種優化來幫助用戶更高效地使用Flink系統。好比,整個Job生命週期的管理,從Job的開發、配置,到提交上線、中止重啓等基本的運維功能能夠經過APP Manager封裝出一套完整的工具鏈來完成,同時提供包括日誌的採集收集、運行Metrics的收集展示等功能,方便用戶對任務進行debug。此外,企業級安全也是很是重要的feature,尤爲是企業應用時存在多租戶部署的需求,所以APP Manager也提供了Rollbase權限管理、OpenID受權系統。同時,咱們很是注重開放性和被集成的能力,因此APP Manager還提供了完善的API,使用戶能很是方便的將Ververica Platform企業級軟件集成到本身已有的大數據平臺之中。
Libra Service是提供智能運維能力的企業級插件。大數據的系統運行中運維是其中的重要部分,尤爲是規模擴大的場景中。常規狀況下運行Flink Job,基本上是開發人員寫完代碼後要配各類各樣的參數,對於Flink的運維人員來說,須要知道這個Job是幹什麼的、支持什麼樣的業務、峯值是什麼狀況、大概的數據規模是什麼樣子,根據本身的經驗進行調整,而且通過屢次迭代後纔可以將一個任務調好。在任務較少的狀況下,還能夠經過運維人員人肉維護,但若是出現上千個Job,甚至阿里巴巴內部上萬個Flink Job的場景,這是Flink社區版本沒法幫助解決的,因此Ververica Platform提供了一套智能運維插件,相似於AI Ops,智能運維插件可以幫助用戶推算出一個Job須要多少個TMs,每一個TM須要配置多少個Slots,每一個TM的JVM參數如何配置以及一個Job的併發度如何配置等。
上圖爲Libra Service的基本設計思路,這是一個很是經典的智能AI Ops設計方案,能夠看到用戶正常經過APP Manager會提交一個Job,Job在Kubernetes集羣啓動以後,Libra Service會監控全部在Kubernetes集羣上面運行的Flink Job,實時採集全部的Metrics,包括Task的Metrics是否延遲、吞吐、buffer等運行信息,Job Manager和Task Manager的GC狀況,JVM各類運行的數據指標等等。至關於自動採集做業的各類指標特徵,利用算法推算出如今的Job運行是否健康。好比部分Job在持續地延遲運行或利用了大量資源但實際上是在空跑等不健康狀態,當Job處於不健康狀態時,經過算法推算出合理的計劃,好比延遲了要擴容,浪費資源可能要縮容,而後通知App Manager去修改整個Job的配置,讓Job重啓適應新的配置來達到穩定高效節省資源的效果,這就是彈性擴縮容插件Libra Service,是智能運維的AI Ops。
Flink提供了很是完整的一致性語義,也支持強一致性的語義,保證數據一條不丟、一條很多,這個是能夠支持計費等金融級很是苛刻的條件,但有一個約束即整個正確性只可以保證單條的記錄,好比2個帳戶要轉帳就保證不了,由於只可以保證對A的操做絕對正確,對B的操做絕對正確,可是對A的10塊錢轉給B,這個完整的事務原生的Flink是沒有辦法保證的。
所以Ververica Platform提供了一套分佈式的跨行跨機器事務解決方案。Stream Ledger是基於Flink Datastream API生態的Library,能夠實現高性能的跨行分佈式事務處理能力,這套Library徹底基於Flink內部API,沒有任何外部依賴,能夠與Datastream API和SQL無縫集成,可以兼容Flink已有的全部讀寫Connectors,因此Steam Ledger是一個輕量的分佈式事務處理方案,也是爲金融級場景提供的分佈式事務處理能力的解決方案。
最後一個插件是狀態存儲插件。在流式計算中,Flink自然支持內置狀態存儲管理,不須要依賴外部的存儲就能夠把實時的數據統計等工做完成。正常作報表統計時都有count、sum、average等參數,這些計數器就是狀態數據,隨着計算量的增長,狀態數據可能會愈來愈大以致於內存可能沒法承擔,因此須要一套內置的狀態存儲來存儲這些狀態。你們都知道在計算系統中,一旦有存儲IO訪問,性能瓶頸則頗有多是在存儲IO上,因此須要優化狀態存儲的訪問。
Flink內置了兩種狀態存儲,一種是基於Java Heap的State Backend狀態存儲插件,另外一種是基於RocksDB的狀態存儲插件。基於Java Heap的性能很是好,由於是徹底基於JVM內存的,而且沒有序列化反序列化。但它的侷限在於Java的方案內存容量會是瓶頸,由於Java對內存的利用率很是低,不如序列化高。通過測試,在物理數據超過幾百兆以後,內存的使用率超過幾個G就不可以擴大數據量了,因此係統很是不穩定。業界不少公司都是在用RocksDB來作,這是很是優秀的開源KV存儲,但由於是基於C++寫的,因此和Flink的集成上還有不少不方便的地方,同時RocksDB也不是爲Flink設計的,因此Flink在不少狀態的數據結構設計上沒有辦法進行優化。咱們但願針對Flink的狀態存儲來作一套本身的存儲插件,能夠提供更強大的功能,同時也兼容社區的協議,因此Gemini應運而生。Gemini是徹底存儲計算分離的設計,它和RocksDB有很大的不一樣,同時它也能夠利用本地SSD作二級緩存來加速訪問,尤爲是在Flink出現故障,一個Task失敗,從新拉起一個進程時,它能夠遠程的從HDFS上直接拉起狀態,下載時間會大幅下降,提高了整個Flink SLB體驗,包括它在設計的時候採用了Java,和Flink系統間的整合也會更好。
這是整個Ververica Platform Gemini Store和RocksDB的Benchmark的性能數據,咱們能夠看到Flink在經常使用的KV state、List state、Map state等性能上都有很是明顯的提高,具體的數據你們能夠自行查看。這個項目也是咱們在整個Ververica Platform作性能優化中效果最明顯的插件。
Ververica Platform是企業級的引擎軟件,可以部署到任何環境中,自然能夠跑在Kubernetes上,因此爲了方便提供實時計算的雲計算服務,讓阿里雲的客戶都可以方便的使用,咱們已經把它適配到阿里雲的雲環境之中,和阿里雲的系統實現了無縫的集成。將Flink的log放到阿里雲的SLS上,能夠利用SLS的log技術查詢搜索Flink的log,因此咱們將Flink Metrics對接到Prometheus生態中。咱們也將Flink Checkpoint存儲的狀態數據對接到阿里雲的OSS上,讓已有的用戶可以複用OSS系統。更重要的一點是整個阿里系統都是雲原生的,Ververica Platform也徹底運行在阿里雲的容器服務平臺之上,所以雲原生也是Ververica Platform的特色之一。若是用戶已經有本身的雲原生集羣或容器服務,能夠嘗試半托管模式,用戶將提供集羣給咱們,咱們就能夠把整個軟件部署到用戶的集羣上,包括已經存在的集羣或新購買的集羣,這種半托管方式可以給用戶提供到此種服務,固然咱們也會提供全託管模式,選擇上比較靈活,這就是目前已經在公測的Ververica Platform雲原生企業版。
Ververica Platform產品可以應用於哪些場景,幫助用戶解決哪些問題想必是你們很是關心的,如下將詳述。
第一個場景是實時數倉,這也是在阿里巴巴內部用得最多的場景,在雲上抽象爲如圖的模型,用戶的數據來自於兩處甚至是三處,第一部分來自於ECS日誌,第二部分來自於RDS結構化數據,第三部分來自於IOT的設備。經過阿里雲的SLS服務或者DataHub數據收集通道來收集用戶數據,實時計算的產品能夠實時訂閱到上述數據,用Flink SQL對以上數據進行多維數據分析,產生實時的數據報表。這個過程當中,除了有單流的數據處理還有多流數據的join,還可能和HBase、Redis、MySQL等數據庫的數據有結合,其中能夠運行復雜的SQL作經典數倉的處理,把數倉處理的結果實時寫到在線的數據庫好比HBase中,都是比較經常使用的用法。而後經過在線的數據服務在大屏幕中展示,這個場景在淘寶內部是很是經典的場景,雙11的時候能夠看到大屏幕上有各類數據的成交、統計、分佈、排名等,最典型的就是GMA交易數據,好比今年1000多億,明年2000多億等等,數字是實時滾動、全球直播的,也是經過這套Flink的架構來實現的。如今對於雲上的不少客戶而言,實時數倉也是一個很大的應用場景。
第二個實時場景就是實時監控、異常數據的報警等等。這也是如今很是主流的場景之一,其實數據源和實時數倉很像,基本上仍是基於ECS的日誌數據或數據庫中的增量數據表的更新數據、IOT的數據等,工業會產生大量的數據,須要監測設備數據的異常。與實時數倉不一樣之處在於實時風控並非採用SQL來作統計和分析,基本上會採用複雜時間處理,好比Flink CEP或業務方本身定製的風控庫來對實時數據進行監測,這個監測可能基於業務的規則,也可能基於Bigdata on AI的方案。新的研究方向是在異常監測或者風控領域基於模型監控,離線或實時訓練並在線加載這些模型進行實時檢測,可以實時發現異常的事件,及時進行補救。經過Kafka集羣到在線的報警系統來對接各類業務系統去報警,這也是可以秒級實時監測各類異常事件作風險控制的方式之一,在整個安防場景、金融場景都是很是常見的解決方案。
第三個場景是成長最快的在線機器學習。在線機器學習是阿里多年的研究方向之一,也是Flink首先應用在阿里巴巴搜索事業部搜索推薦業務部場景的緣由。在線機器學習是搜索推薦廣告中很是火的方向,機器學習不只是離線數據模型來作訓練,甚至可以造成一個徹底的實時化閉環方案,經過用戶在天貓、淘寶上產生的大量的點擊、交易,相關數據都會經過日誌系統實時收集,以後傳入實時計算中計算,咱們稱之爲特徵工程。對用戶的數據如用戶的訂單等作數據清洗,數據特徵的彌補、計算,甚至和離線特徵作一些結合。部分數據,如30天銷量、用戶年齡等數據並不是實時變化,是須要長時間的統計獲得,咱們把實時特徵、離線特徵所有都作了拼接以後就是多維數據的join,最終可以得出實時樣本。咱們經過流式獲得實時樣本以後就可以在後面對接流式來作機器學習的訓練,能夠經過PAI等相似的機器學習產品來作實時或者準實時的模型訓練,訓練完以後產生的模型有一套完整的驗證機制,驗證完整的模型Validation以後才能推上線,再用新模型提供個性化的搜索和推薦,從而驅動用戶產生新的點擊,再去進行模型的更新,進而造成一套完整的閉環。這是Bigdata+AI的一個典型場景,從數據處理、數據訓練,再到數據預測、用戶點擊造成反饋等,造成完整生產線。這也是Flink作實時計算和在線的流式計算與在線機器學習的訓練造成一套完整閉環的經典方案,這套方案也是淘寶天貓真實的在線搜索推薦解決方案。
目前咱們有不少客戶都在採用這種新的方案來提高他們的點擊,尤爲是社交媒體類的公司都在嘗試這個新的解決方案。
最後,回到社區,阿里巴巴收購完DataArtisans以後成立了新的企業品牌Ververica,咱們但願除了商業化品牌的統1、提供的增值服務以外,還但願可以繼續擴大社區規模,服務好更多社區的用戶,推進社區繁榮發展。因此阿里巴巴也投入了很大的精力來支持整個 Flink 社區的發展,尤爲是在中國,咱們已經在北京、上海、深圳等連續辦了很是多的Flnik社區Meetup,包括去年年末舉辦的首屆Flink Forward China大會,今年將繼續舉辦第二屆。去年大會的規模是1000人,今年但願可以達到2000人,但願中國比較主流的互聯網公司都能參與其中,分享他們對Flink應用的經驗,咱們也會聯合Flink創始團隊一塊兒,講Flink的新特性、發佈以及方向上的展現。歡迎更多對Flink有興趣的同窗一塊兒來參與大會,交流探討。
本文爲雲棲社區原創內容,未經容許不得轉載。