摘要：2019雲棲大會大資料 & AI專場，阿里巴巴資深技術專家王峰帶來“Ververica Platform-阿里巴巴全新Flink企業版揭秘”的演講。本文主要從Ververica由來開始談起，著重講了Ververica Platform的四個核心外掛App Manager、Libra Service、Stream Ledger、Gemini，以及阿里巴巴實時計算雲原生版本相關特性及典型應用場景。

以下是精彩影片內容整理：

隨著人工智慧時代的降臨，資料量的爆發，在典型的大資料業務場景下資料業務最通用的做法是：選用批處理的技術處理全量資料，採用流式計算處理實時增量資料。2017年基於Flink開發的實時計算產品正式服務於阿里巴巴集團內部，並從搜尋和推薦兩大場景開始應用。目前阿里巴巴及下屬所有子公司，都採用實時計算產品來處理所有的實時業務。

Ververica 是如何誕生的？

眾所周知，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 介紹

Ververica Platform是阿里巴巴推出的全新企業版，它仍然堅持以Apache Flink 的社群版本為核心，同時能夠相容各種企業級外掛，在整個基於Flink的實時計算解決方案上對應用性、穩定性、效能、可運維性等方面提供企業級的增值服務。

首先，Ververica Platform是一個企業級的開放軟體，支援客戶將其部署在生產環境中，對接已有的周邊生態系統如日誌、Metrics、儲存等。最初在設計Ververica Platform時就將其定位為完全雲原生的方案，系統元件和核心元件都以支援微服務方式部署到Kubernetes上，使用者可以非常方便的將Ververica Platform和自己的線上服務或其他資料服務做雲原生的混布。

Ververica Platform 計算引擎

Ververica Platform使用Apache Flink作為其核心的計算引擎，保證和社群的完全相容。上圖為Apache Flink最新演進的架構圖。Apache Flink的本質是一款有狀態的流式計算引擎，可以連線各種各樣的儲存，透過ETL計算、資料分析等將資料結果匯入到另外的儲存中。作為流式計算，Flink的時效性非常好，可以在高吞吐量的同時達到亞秒級延時。Flink不僅能夠連線訊息佇列等無限資料流的資料來源，也可以連線檔案系統、資料庫表、KV儲存等有限的資料集，所以Flink也在基於流式計算的優勢上逐漸朝著批流融合的方向發展，有希望成為一種新的批流合一的全能計算引擎。

所以Ververica Platform將會依賴社群的力量，採用Flink社群的主流版本作為核心，所有的增值服務、各種最佳化都會透過嵌入的方式來實現，為使用者提供一個開放透明的計算引擎。以下將詳細介紹Ververica Platform的核心外掛。

Ververica Platform – App Manager

Ververica Platform在應用上的企業級外掛叫APP Manager，是管理Flink全生命週期的工具。Flink作為計算引擎，在易用性方面可以採用多種最佳化來幫助使用者更高效地使用Flink系統。比如，整個Job生命週期的管理，從Job的開發、配置，到提交上線、停止重啟等基本的運維功能可以透過APP Manager封裝出一套完整的工具鏈來完成，同時提供包括日誌的採集收集、執行Metrics的收集展現等功能，方便使用者對任務進行debug。此外，企業級安全也是非常重要的feature，尤其是企業應用時存在多租戶部署的需求，因此APP Manager也提供了Rollbase許可權管理、OpenID授權系統。同時，我們非常注重開放性和被整合的能力，所以APP Manager還提供了完善的API，使使用者能非常方便的將Ververica Platform企業級軟體整合到自己已有的大資料平臺之中。

Ververica Platform – Libra Service

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。

Ververica Platform – Stream Ledger

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是一個輕量的分散式事務處理方案，也是為金融級場景提供的分散式事務處理能力的解決方案。

Ververica Platform – Gemini

最後一個外掛是狀態儲存外掛。在流式計算中，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產品能夠應用於哪些場景，幫助使用者解決哪些問題想必是大家非常關心的，以下將詳述。

應用場景1 - 實時數倉

第一個場景是實時數倉，這也是在阿里巴巴內部用得最多的場景，在雲上抽象為如圖的模型，使用者的資料來自於兩處甚至是三處，第一部分來自於ECS日誌，第二部分來自於RDS結構化資料，第三部分來自於IOT的裝置。透過阿里雲的SLS服務或者DataHub資料收集通道來收集使用者資料，實時計算的產品可以實時訂閱到上述資料，用Flink SQL對以上資料進行多維資料分析，產生實時的資料包表。這個過程中，除了有單流的資料處理還有多流資料的join，還可能和HBase、Redis、MySQL等資料庫的資料有結合，其中可以執行復雜的SQL做經典數倉的處理，把數倉處理的結果實時寫到線上的資料庫比如HBase中，都是比較常用的用法。然後透過線上的資料服務在大螢幕中展現，這個場景在淘寶內部是非常經典的場景，雙11的時候可以看到大螢幕上有各種資料的成交、統計、分佈、排名等，最典型的就是GMA交易資料，比如今年1000多億，明年2000多億等等，數字是實時滾動、全球直播的，也是透過這套Flink的架構來實現的。現在對於雲上的很多客戶而言，實時數倉也是一個很大的應用場景。

應用場景2 - 實時風控

第二個實時場景就是實時監控、異常資料的報警等等。這也是現在非常主流的場景之一，其實資料來源和實時數倉很像，基本上還是基於ECS的日誌資料或資料庫中的增量資料表的更新資料、IOT的資料等，工業會產生大量的資料，需要監測裝置資料的異常。與實時數倉不同之處在於實時風控並不是採用SQL來做統計和分析，基本上會採用複雜時間處理，比如Flink CEP或業務方自己定製的風控庫來對實時資料進行監測，這個監測可能基於業務的規則，也可能基於Bigdata on AI的方案。新的研究方向是在異常監測或者風控領域基於模型監控，離線或實時訓練並線上載入這些模型進行實時檢測，能夠實時發現異常的事件，及時進行補救。透過Kafka叢集到線上的報警系統來對接各種業務系統去報警，這也是能夠秒級實時監測各種異常事件做風險控制的方式之一，在整個安防場景、金融場景都是非常常見的解決方案。

應用場景3 - 線上機器學習

第三個場景是成長最快的線上機器學習。線上機器學習是阿里多年的研究方向之一，也是Flink首先應用在阿里巴巴搜尋事業部搜尋推薦業務部場景的原因。線上機器學習是搜尋推薦廣告中非常火的方向，機器學習不僅是離線資料模型來做訓練，甚至能夠形成一個完全的實時化閉環方案，透過使用者在天貓、淘寶上產生的大量的點選、交易，相關資料都會透過日誌系統實時收集，之後傳入實時計算中計算，我們稱之為特徵工程。對使用者的資料如使用者的訂單等做資料清洗，資料特徵的彌補、計算，甚至和離線特徵做一些結合。部分資料，如30天銷量、使用者年齡等資料並非實時變化，是需要長時間的統計得到，我們把實時特徵、離線特徵全部都做了拼接之後就是多維資料的join，最終能夠得出實時樣本。我們透過流式得到實時樣本之後就能夠在後面對接流式來做機器學習的訓練，可以透過PAI等類似的機器學習產品來做實時或者準實時的模型訓練，訓練完之後產生的模型有一套完整的驗證機制，驗證完整的模型Validation之後才能推上線，再用新模型提供個性化的搜尋和推薦，從而驅動使用者產生新的點選，再去進行模型的更新，進而形成一套完整的閉環。這是Bigdata+AI的一個典型場景，從資料處理、資料訓練，再到資料預測、使用者點選形成反饋等，形成完整生產線。這也是Flink做實時計算和線上的流式計算與線上機器學習的訓練形成一套完整閉環的經典方案，這套方案也是淘寶天貓真實的線上搜尋推薦解決方案。

目前我們有很多客戶都在採用這種新的方案來提升他們的點選，尤其是社交媒體類的公司都在嘗試這個新的解決方案。

最後，回到社群，阿里巴巴收購完DataArtisans之後成立了新的企業品牌Ververica，我們希望除了商業化品牌的統一、提供的增值服務之外，還希望能夠繼續擴大社群規模，服務好更多社群的使用者，推動社群繁榮發展。所以阿里巴巴也投入了很大的精力來支援整個 Flink 社群的發展，尤其是在中國，我們已經在北京、上海、深圳等連續辦了非常多的Flnik社群Meetup，包括去年年底舉辦的首屆Flink Forward China大會，今年將繼續舉辦第二屆。去年大會的規模是1000人，今年希望能夠達到2000人，希望中國比較主流的網際網路公司都能參與其中，分享他們對Flink應用的經驗，我們也會聯合Flink創始團隊一起，講Flink的新特性、釋出以及方向上的展示。歡迎更多對Flink有興趣的同學一起來參與大會，交流探討。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。

Ververica Platform-阿里巴巴全新Flink企業版揭秘