作者：vivo 網際網路實時計算團隊- Chen Tao

本文根據「2022 vivo開發者大會"現場演講內容整理而成。

vivo 實時計算平臺是 vivo 實時團隊基於 Apache Flink 計算引擎自研的覆蓋實時流資料接入、開發、部署、運維和運營全流程的一站式資料建設與治理平臺。

一、vivo 實時計算業務現狀

2022年，vivo網際網路在網使用者總數達到2.8億，多款網際網路應用的日活超過了千萬甚至突破了1億，為了向用戶提供優質的內容和服務，我們需要對如此大規模的使用者所產生的海量資料進行實時處理，幫助我們進行運營決策、精準推薦、提升終端使用者體驗，同時通過提升我們的商業化能力為廣告主提供更加優質的廣告服務。

 近幾年，巨量資料實時計算技術和公司的實時資料業務都在飛速發展，截止到今年8月，vivo實時計算每日處理資料量達到5PB，有效任務數超過4000，目前已接入98個專案，從趨勢上來看，每年都有超過100%的規模增長，如此大的業務規模和業務增速給我們實時計算團隊帶來的非常大的挑戰。首先，我們要確保業務的穩定，高速增長的資料、複雜的業務場景和系統架構需要我們自底向上的全方位的穩定性建設；為了幫助使用者快速落地業務，我們需要降低開發門檻，提供良好的易用性和覆蓋各種場景的功能特性，業務的高效接入和運維能帶來長期的降本收益。同時，大規模的資料和計算我們也希望能夠以儘可能低的成本去執行，這就需要我們提供高效的儲存、計算能力，並且對於許多關鍵業務，實時計算時效性保障的要求也非常高。在複雜的資料環境中要保障資料安全需要有非常良好的且具有前瞻性的設計，優秀的安全能力需要能夠提前防範可能的風險。

 我們從2019年下半年啟動了實時計算平臺的建設，2020年關注在穩定性建設，初步上線了SQL能力，2021年引入了Flink 1.13版本並啟動了容器化建設，2022年主要關注在效率提升，包括流批一體、任務診斷等，到目前為止，我們平臺已初步具備了一些能力，所以今天我代表我們團隊簡單給大家介紹一下我們的平臺建設實踐。

二、實時計算平臺建設實踐

從我們巨量資料平臺的體系架構上來看，我們通過匯聚層能力收集整個vivo網際網路的埋點、伺服器紀錄檔，通過計算、儲存、分析等能力從海量資料中挖掘出業務價值。實時計算作為平臺的核心能力之一，它同時滿足了大規模資料計算和高時效計算的需求，我們通過實時計算平臺來承載和向業務提供這方面的能力。

vivo實時計算平臺是基於Apache Flink計算引擎自研的覆蓋實時流資料接入、開發、部署、運維和運營全流程的一站式資料建設與治理平臺。接下來我會從基礎服務建設、穩定性建設、易用性建設、效率提升和安全能力建設五個方面來介紹我們團隊的建設思路和實踐過程。

2.1 基礎服務建設

 我們自研的實時平臺後端架構包括兩個核心服務：

• SubmissionServer：負責作業的提交，以及跟資源管理系統的互動，具備高可用、高可延伸能力，支援多版本Flink和多種任務型別。

• ControlServer：負責任務執行狀態的維護，我們定義了9種任務狀態，通過一個內建狀態機進行實時的狀態維護，狀態的更新延遲在秒級。

基礎服務還包括統一的後設資料服務和實時的監控告警服務。這兩個部分做一下簡單介紹。

我們使用HiveMetaStore作為後設資料基礎服務，基於TIDB的擴充套件能力，當前後設資料實體規模已達到億級，通過對MetaStore服務的優化，大分割區表操作效能提升了10倍，目前已接入Spark、Hive、Flink、Presto等引擎，同時，統一的許可權控制、資料分類分級、資料血緣、後設資料變更記錄等能力也為資料治理提供了良好的基礎。

我們基於Flink的CEP能力構建了一套秒級延遲、支援動態規則設定的監控告警系統，同時從基礎設施、基礎服務、實時任務和業務多個維度構建了全方位的監控體系。以上這三個方面構成了我們的基礎服務。基礎服務都具備高可用特性，但是要保障業務穩定，還需要關注整個系統以及在系統上執行的業務資料鏈路，這裡最重要的有兩個方面：巨量資料元件服務的穩定性和任務本身的穩定性。

2.2 穩定性建設

我們使用HDFS作為狀態的持久儲存和業務資料落地的儲存，隨著儲存規模和讀寫量的增長，我們遇到了DataNode的StaleNode問題、低版本HDFS流式寫無法恢復問題和越來越嚴重的小檔案問題，為此我們通過平滑升級HDFS到3版本、優化Flink Sink效能和基於Spark3建設小檔案合併服務來解決這些問題。

Kafka是主要的流儲存元件，但是在叢集運維上存在一些痛點，比如擴縮容和節點硬體故障會導致資源不均衡和消費生產的異常，Kafka團隊建設了流量均衡和動態限流能力，顯著提升了Kafka服務的穩定性，同時我們也提升了Flink對Kafka Broker重啟的容忍度，能夠有效減少Broker故障對執行任務帶來的影響。

另外，Flink任務的高可用依賴於Zookeeper，為了避免ZK leader切換對實時作業的影響，我們對1.10和1.13版本的Flink進行了容忍度增強，對更低版本的任務做了版本升級，也根據社群經驗優化了Flink HA部分的功能，以及加強了對ZK的全面監控和治理，保障了ZK的穩定性。

通過這些對相關元件的優化措施減少了任務異常時間和次數，有效的提升了任務穩定性。接下來介紹一下我們針對某種特定場景的Flink任務穩定性優化實踐。

 在內容實時推薦場景，產生自線上預估服務的使用者特徵快照需要與使用者實時資料進行拼接，由於資料量巨大在做Join時需要一個大快取，相比於原來採用Redis作為快取的方案，Flink的RocksDB狀態後端是一個更合適的方案，但是在狀態大小達到TB級別時，任務穩定性很難保障。我們基於對RocksDB記憶體模型的深刻理解，擴充套件原生監控指標，升級RocksDB版本，建設了狀態治理相關能力，把任務穩定性提升到了生產可用級別。在多個業務場景上線後，樣本和模型的時效性和穩定性得到保障，推薦效果得到很大提升。

後續我們規劃通過增加讀快取和優化字首匹配策略進一步提升RocksDB狀態後端的效能。

 我們一直在思考如何進一步提升業務的穩定性，相對於任務的穩定性我們的使用者更加關心他們所需要的資料是否準時、資料質量是否符合預期，而任務的穩定不完全等同於時效和質量。在時效這個維度我們定義了資料準時率的SLI指標，這對我們有兩方面的指引：更自動化和精細化的故障分級保障和流計算的彈效能力的建設。其中前者正在建設中，後者也在我們的規劃之中。

2.3 易用性建設

 

從實時作業開發角度，

我們提供了功能完善、體驗良好的FlinkSQL開發環境。相比於社群版本Flink，我們對SQL能力進行了擴充套件，比如更加可控的視窗計算觸發功能，相容性更強的DDL功能，更加方便的流表建立功能，我們對Format、Connector、UDF都做了一些擴充套件和優化，適用於更多業務場景，提升了效能；同時我們建設了執行於Standalone叢集的SQL偵錯能力，具備資料抽樣、上傳、DAG圖展示、偵錯結果實時展示等功能。經過一年的建設，新增SQL執行任務佔比從5%提升到了60%。

 

從實時作業運維角度，

我們提供了實時全鏈路的血緣與延遲監控功能。為了實現資料業務，實時計算鏈路往往是很長的，而一個團隊一般只負責其中一段，為了解決鏈路中出現的問題，可能需要上下游多個團隊配合，效率很低。我們作為平臺團隊為使用者提供了一個全域性的視角，這樣可以迅速定位到異常任務節點，非常高效。血緣資料可以實時生成，並且不需要任務的重啟，因此不存在血緣不全的問題。同時，我們也可以輸出端到端全鏈路延遲資料和任務處理延遲資料，幫助我們的使用者做質量監控。

2.4 效率提升

 今年，降本提效是我們的重點工作方向，我們從計算、儲存和資源治理三個方面做了一些工作，取得初步效果。YARN資源管理的粒度較大，而K8s更精細的資源粒度從整體上來看可以有效提升資源利用效率。YARN雖然開啟了cgroups，但是對系統資源的隔離能力仍然較弱，個別異常任務耗盡機器資源可能影響正常執行的任務。因此平臺支援了K8s的資源管理能力，藉助於Flink社群提供的Native K8s特性以及平臺良好的可延伸性，我們當前支援JAR任務的容器化部署，並且通過在開發、運維、資源交付等方面的建設確保了使用者體驗與YARN是一致的。藉助於容器化，我們可以確保開發、測試、線上等環境的一致性，研發效率也得到提升。目前已接入3個業務，明年會比較大規模的應用。

多年以來，巨量資料領域在發展過程中形成了批和流兩套架構並存的現狀，很多時候，業務在落地過程中不得不同時考慮和投入建設兩套鏈路。比如離線數倉和實時數倉獨立建設，資料口徑和計算結果的一致性保障需要付出額外的努力，Hive表不支援資料更新、探查較慢，Kafka資料回溯和查詢困難等問題也一直困擾著資料開發人員。

幸運的是，業界已經探索出來基於資料湖元件在分散式儲存之上構建流批統一儲存的技術，我們根據vivo的業務特點選擇並設計了我們的流批一體方案，目前已經完成基於Hudi的統一儲存引擎、基於Flink的統一入湖、基於HMS的統一後設資料建設，目前業務已經完成試用並開始接入。今年我們主要接入實時業務，明年會有離線業務的接入。這也是我們巨量資料平臺構建湖倉一體很重要的一步。

在長期的實時作業運維過程中，我們積累的大量作業調優和問題解決經驗，隨著運維壓力的增加，我們在思考如何提升運維效率。我們也發現使用者資源佇列用滿的同時，機器的CPU利用率卻處於較低水平，因此我們思考如何減少資源浪費，提升叢集的資源利用效率。資源診斷和異常診斷這兩類問題都是作業優化問題，要優化作業，首先需要掌握作業及其執行環境的資訊，包括執行指標、執行紀錄檔、GC紀錄檔、依賴元件執行狀況、作業系統程序級別資訊，以及作業設定、環境設定等等，然後需要將運維經驗和思路轉化為啟發式演演算法的規則和資料，運用這些資料、演演算法和規則去找到優化的方法。基於這個思路，我們建設了一個診斷服務，具備靈活的資訊收集、規則設定、資料調優功能，能夠在作業啟動或執行時，診斷作業的健康程度，提供一些作業的優化建議給我們的使用者。目前資源診斷能力已經在執行，異常診斷還在建設中。

2.5 安全能力建設

 作為一個基礎的巨量資料服務，安全在我們看來是一個非常重要的命題，因此我們在系統設計之初就考慮了實時資料存取、離線資料讀寫、各個系統與服務之間的安全隔離能力等方面的設計，在實時數倉具備一定規模後，我們又建設了資料分類分級、紀錄檔審計等能力。去年，根據最新的合規要求，離線儲存支援了列級別透明加密，實時資料支援了敏感欄位自動檢測等能力。安全無止境，我們也在對DSMM進行研究解讀，以持續提升巨量資料的安全能力。

以上是我們平臺建設的一些實踐，總結來看，我們基於Flink建設了功能比較完善的實時計算開發和運維能力，業務複雜度越來越高，我們的挑戰還有很多，比如Flink引擎的優化與難點問題的解決、計算效率的進一步提升、流批一體、容器化的大規模應用等，都是我們後續的重點方向。

前面有提到，基於實時計算平臺，公司的多箇中臺團隊建設了五大中臺能力，覆蓋了各種各樣的實時場景，這裡就跟大家簡單分享下其中兩個典型場景。

三、應用場景簡介

3.1 實時數倉

 vivo巨量資料團隊基於vStream平臺建設的實時數倉服務覆蓋了應用分發、內容分發、產品平臺、商業化等多個業務線的報表、行銷、推薦、決策、廣告等多種應用場景。實時數倉沿用了離線數倉的邏輯分層理論，從資料來源經過採集和ETL進入到ODS層，然後經過維度擴充套件、過濾、轉換等操作進入到DWD明細層，然後是輕度聚合層DWS，最後按照主題或業務需求計算出結果指標存入ClickHouse等OLAP引擎成為ADS層，為業務提供資料包表、介面或者資料服務。與離線有所不同的是，實時資料受限於資料達到時間或業務對資料的要求，可能會有層次的裁剪，因此實時數倉也提供了中間層開放的能力。

實時數倉的一部分維度表與離線是共用的，並且為了與離線鏈路保證一致的資料口徑需要將Kafka流表落地到Hive表進行資料的比對，離線與實時的互操作不是很方便，因此，數倉團隊已經開始基於流批一體能力建設準實時的資料鏈路。然後我們看一下，實時計算是如何應用在內容推薦場景的。

3.2 短視訊實時內容推薦

 vivo短視訊是一個很火的應用，為了給到使用者高質量的視訊內容推薦，特別依賴於推薦模型的時效性以及使用者特徵計算的時效性，為了做到實時的模型訓練，需要有實時的樣本資料。因此實時特徵計算和樣本拼接在內容推薦裡面扮演了很重要的角色，vStream平臺提供的TB級別超大狀態任務能力支撐了短視訊以及許多其他應用的實時樣本拼接任務。同時我們也可以看到，在這個方案裡，特徵和樣本都同時存在離線和實時兩條鏈路，這是因為Flink的批計算能力目前還沒有Spark成熟，基於Kafka的實時計算難以做到資料回溯，站在我們巨量資料平臺的角度，一方面我們希望能夠減少重複的計算和儲存，另一方面也希望平臺的使用者能夠不需要重複開發計算和回溯的程式碼。在業界廣泛討論的湖倉一體架構，很重要的一個方面就是為了解決這些問題。在後面的部分，我們會再聊一聊湖倉一體。

實時計算的應用場景有很多，但本質上來說它的目的跟離線計算是一樣的，就是為業務提供資料支援。從前面的介紹可以看到，當前基於Hadoop的巨量資料平臺元件繁多、架構複雜、流批重複、資源效率較低，那麼我們有沒有辦法或者說有沒有希望改變這種現狀呢？我認為是有的，最後分享一下我們對未來的一些探索和展望。

四、探索與展望

 我們知道，業務是彈性的，比如在一天之內總有使用者存取的高峰和低谷，一段時間內總有業務的增長或下降。但是當前，不管是我們的資料計算任務還是YARN叢集的資源分配策略，都不具備彈性，首先，任務分配的資源是固定的，並且，為了儘可能避免計算受到業務波動的影響，離線、實時和線上三種不同型別的計算分別執行在不同的物理叢集。

因此我們需要如下兩種維度的彈效能力：

• 任務級別的彈效能力，我們打算緊跟Flink社群，探索其AutoScaling特性的應用。

• 叢集級別的彈效能力，我們會採用vivo容器團隊提供的在離線混部能力來實現。

 剛剛我們提到了湖倉一體，為什麼需要湖倉一體呢？可以拿BI和AI兩個巨量資料應用領域放在一起來看，流計算、批計算、分析型計算和AI計算及其對應的儲存系統分別解決各自的問題，並且由於發展階段差異，圍繞這四種計算形式建設了大量的平臺系統和業務系統，運營這個複雜龐大的系統資源成本和人力成本都是非常高的。因此大家期望通過統一的儲存抽象、統一的計算抽象、統一的資源抽象和統一的資料管理來建設一個架構內聚、低成本、易於使用的巨量資料系統。大家的期望促進了雲原生、資料湖、新一代計算引擎等技術的發展，這些發展也使得大家的期望更明確更一致。