vivo 實時計算平臺建設實踐

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

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

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

2.1 基礎服務建設

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

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

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

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

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

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

2.2 穩定性建設

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

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

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

2.3 易用性建設

2.4 效率提升

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

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

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

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

2.5 安全能力建設

3.1 實時數倉

3.2 短影片實時內容推薦

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

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

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

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

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