一、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計算及其對應的存儲系統分別解決各自的問題，并且由于發展階段差異，圍繞這四種計算形式建設了大量的平臺系統和業務系統，運營這個復雜龐大的系統資源成本和人力成本都是非常高的。因此大家期望通過統一的存儲抽象、統一的計算抽象、統一的資源抽象和統一的數據管理來建設一個架構內聚、低成本、易于使用的大數據系統。大家的期望促進了云原生、數據湖、新一代計算引擎等技術的發展，這些發展也使得大家的期望更明確更一致。