一、vivo 實時計算業(yè)務現(xiàn)狀

2022年，vivo互聯(lián)網(wǎng)在網(wǎng)用戶總數(shù)達到2.8億，多款互聯(lián)網(wǎng)應用的日活超過了千萬甚至突破了1億，為了向用戶提供優(yōu)質(zhì)的內(nèi)容和服務，我們需要對如此大規(guī)模的用戶所產(chǎn)生的海量數(shù)據(jù)進行實時處理，幫助我們進行運營決策、精準推薦、提升終端用戶體驗，同時通過提升我們的商業(yè)化能力為廣告主提供更加優(yōu)質(zhì)的廣告服務。

近幾年，大數(shù)據(jù)實時計算技術和公司的實時數(shù)據(jù)業(yè)務都在飛速發(fā)展，截止到今年8月，vivo實時計算每日處理數(shù)據(jù)量達到5PB，有效任務數(shù)超過4000，目前已接入98個項目，從趨勢上來看，每年都有超過100%的規(guī)模增長，如此大的業(yè)務規(guī)模和業(yè)務增速給我們實時計算團隊帶來的非常大的挑戰(zhàn)。首先，我們要確保業(yè)務的穩(wěn)定，高速增長的數(shù)據(jù)、復雜的業(yè)務場景和系統(tǒng)架構(gòu)需要我們自底向上的全方位的穩(wěn)定性建設；為了幫助用戶快速落地業(yè)務，我們需要降低開發(fā)門檻，提供良好的易用性和覆蓋各種場景的功能特性，業(yè)務的高效接入和運維能帶來長期的降本收益。同時，大規(guī)模的數(shù)據(jù)和計算我們也希望能夠以盡可能低的成本去運行，這就需要我們提供高效的存儲、計算能力，并且對于許多關鍵業(yè)務，實時計算時效性保障的要求也非常高。在復雜的數(shù)據(jù)環(huán)境中要保障數(shù)據(jù)安全需要有非常良好的且具有前瞻性的設計，優(yōu)秀的安全能力需要能夠提前防范可能的風險。

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

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

從我們大數(shù)據(jù)平臺的體系架構(gòu)上來看，我們通過匯聚層能力收集整個vivo互聯(lián)網(wǎng)的埋點、服務器日志，通過計算、存儲、分析等能力從海量數(shù)據(jù)中挖掘出業(yè)務價值。實時計算作為平臺的核心能力之一，它同時滿足了大規(guī)模數(shù)據(jù)計算和高時效計算的需求，我們通過實時計算平臺來承載和向業(yè)務提供這方面的能力。

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

2.1 基礎服務建設

我們自研的實時平臺后端架構(gòu)包括兩個核心服務：

• SubmissionServer：負責作業(yè)的提交，以及跟資源管理系統(tǒng)的交互，具備高可用、高可擴展能力，支持多版本Flink和多種任務類型。
• ControlServer：負責任務運行狀態(tài)的維護，我們定義了9種任務狀態(tài)，通過一個內(nèi)置狀態(tài)機進行實時的狀態(tài)維護，狀態(tài)的更新延遲在秒級。

基礎服務還包括統(tǒng)一的元數(shù)據(jù)服務和實時的監(jiān)控告警服務。這兩個部分做一下簡單介紹。

我們使用HiveMetaStore作為元數(shù)據(jù)基礎服務，基于TIDB的擴展能力，當前元數(shù)據(jù)實體規(guī)模已達到億級，通過對MetaStore服務的優(yōu)化，大分區(qū)表操作性能提升了10倍，目前已接入Spark、Hive、Flink、Presto等引擎，同時，統(tǒng)一的權限控制、數(shù)據(jù)分類分級、數(shù)據(jù)血緣、元數(shù)據(jù)變更記錄等能力也為數(shù)據(jù)治理提供了良好的基礎。

我們基于Flink的CEP能力構(gòu)建了一套秒級延遲、支持動態(tài)規(guī)則配置的監(jiān)控告警系統(tǒng)，同時從基礎設施、基礎服務、實時任務和業(yè)務多個維度構(gòu)建了全方位的監(jiān)控體系。以上這三個方面構(gòu)成了我們的基礎服務?；A服務都具備高可用特性，但是要保障業(yè)務穩(wěn)定，還需要關注整個系統(tǒng)以及在系統(tǒng)上運行的業(yè)務數(shù)據(jù)鏈路，這里最重要的有兩個方面：大數(shù)據(jù)組件服務的穩(wěn)定性和任務本身的穩(wěn)定性。

2.2 穩(wěn)定性建設

我們使用HDFS作為狀態(tài)的持久存儲和業(yè)務數(shù)據(jù)落地的存儲，隨著存儲規(guī)模和讀寫量的增長，我們遇到了DataNode的StaleNode問題、低版本HDFS流式寫無法恢復問題和越來越嚴重的小文件問題，為此我們通過平滑升級HDFS到3版本、優(yōu)化Flink Sink性能和基于Spark3建設小文件合并服務來解決這些問題。

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

另外，F(xiàn)link任務的高可用依賴于Zookeeper，為了避免ZK leader切換對實時作業(yè)的影響，我們對1.10和1.13版本的Flink進行了容忍度增強，對更低版本的任務做了版本升級，也根據(jù)社區(qū)經(jīng)驗優(yōu)化了Flink HA部分的功能，以及加強了對ZK的全面監(jiān)控和治理，保障了ZK的穩(wěn)定性。

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

在內(nèi)容實時推薦場景，產(chǎn)生自在線預估服務的用戶特征快照需要與用戶實時數(shù)據(jù)進行拼接，由于數(shù)據(jù)量巨大在做Join時需要一個大緩存，相比于原來采用Redis作為緩存的方案，F(xiàn)link的RocksDB狀態(tài)后端是一個更合適的方案，但是在狀態(tài)大小達到TB級別時，任務穩(wěn)定性很難保障。我們基于對RocksDB內(nèi)存模型的深刻理解，擴展原生監(jiān)控指標，升級RocksDB版本，建設了狀態(tài)治理相關能力，把任務穩(wěn)定性提升到了生產(chǎn)可用級別。在多個業(yè)務場景上線后，樣本和模型的時效性和穩(wěn)定性得到保障，推薦效果得到很大提升。

后續(xù)我們規(guī)劃通過增加讀緩存和優(yōu)化前綴匹配策略進一步提升RocksDB狀態(tài)后端的性能。

我們一直在思考如何進一步提升業(yè)務的穩(wěn)定性，相對于任務的穩(wěn)定性我們的用戶更加關心他們所需要的數(shù)據(jù)是否準時、數(shù)據(jù)質(zhì)量是否符合預期，而任務的穩(wěn)定不完全等同于時效和質(zhì)量。在時效這個維度我們定義了數(shù)據(jù)準時率的SLI指標，這對我們有兩方面的指引：更自動化和精細化的故障分級保障和流計算的彈性能力的建設。其中前者正在建設中，后者也在我們的規(guī)劃之中。

2.3 易用性建設

從實時作業(yè)開發(fā)角度，我們提供了功能完善、體驗良好的FlinkSQL開發(fā)環(huán)境。相比于社區(qū)版本Flink，我們對SQL能力進行了擴展，比如更加可控的窗口計算觸發(fā)功能，兼容性更強的DDL功能，更加方便的流表創(chuàng)建功能，我們對Format、Connector、UDF都做了一些擴展和優(yōu)化，適用于更多業(yè)務場景，提升了性能；同時我們建設了運行于Standalone集群的SQL調(diào)試能力，具備數(shù)據(jù)抽樣、上傳、DAG圖展示、調(diào)試結(jié)果實時展示等功能。經(jīng)過一年的建設，新增SQL運行任務占比從5%提升到了60%。

從實時作業(yè)運維角度，我們提供了實時全鏈路的血緣與延遲監(jiān)控功能。為了實現(xiàn)數(shù)據(jù)業(yè)務，實時計算鏈路往往是很長的，而一個團隊一般只負責其中一段，為了解決鏈路中出現(xiàn)的問題，可能需要上下游多個團隊配合，效率很低。我們作為平臺團隊為用戶提供了一個全局的視角，這樣可以迅速定位到異常任務節(jié)點，非常高效。血緣數(shù)據(jù)可以實時生成，并且不需要任務的重啟，因此不存在血緣不全的問題。同時，我們也可以輸出端到端全鏈路延遲數(shù)據(jù)和任務處理延遲數(shù)據(jù)，幫助我們的用戶做質(zhì)量監(jiān)控。

2.4 效率提升

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

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

幸運的是，業(yè)界已經(jīng)探索出來基于數(shù)據(jù)湖組件在分布式存儲之上構(gòu)建流批統(tǒng)一存儲的技術，我們根據(jù)vivo的業(yè)務特點選擇并設計了我們的流批一體方案，目前已經(jīng)完成基于Hudi的統(tǒng)一存儲引擎、基于Flink的統(tǒng)一入湖、基于HMS的統(tǒng)一元數(shù)據(jù)建設，目前業(yè)務已經(jīng)完成試用并開始接入。今年我們主要接入實時業(yè)務，明年會有離線業(yè)務的接入。這也是我們大數(shù)據(jù)平臺構(gòu)建湖倉一體很重要的一步。

在長期的實時作業(yè)運維過程中，我們積累的大量作業(yè)調(diào)優(yōu)和問題解決經(jīng)驗，隨著運維壓力的增加，我們在思考如何提升運維效率。我們也發(fā)現(xiàn)用戶資源隊列用滿的同時，機器的CPU利用率卻處于較低水平，因此我們思考如何減少資源浪費，提升集群的資源利用效率。資源診斷和異常診斷這兩類問題都是作業(yè)優(yōu)化問題，要優(yōu)化作業(yè)，首先需要掌握作業(yè)及其運行環(huán)境的信息，包括運行指標、運行日志、GC日志、依賴組件運行狀況、操作系統(tǒng)進程級別信息，以及作業(yè)配置、環(huán)境配置等等，然后需要將運維經(jīng)驗和思路轉(zhuǎn)化為啟發(fā)式算法的規(guī)則和數(shù)據(jù)，運用這些數(shù)據(jù)、算法和規(guī)則去找到優(yōu)化的方法?；谶@個思路，我們建設了一個診斷服務，具備靈活的信息收集、規(guī)則配置、數(shù)據(jù)調(diào)優(yōu)功能，能夠在作業(yè)啟動或運行時，診斷作業(yè)的健康程度，提供一些作業(yè)的優(yōu)化建議給我們的用戶。目前資源診斷能力已經(jīng)在運行，異常診斷還在建設中。

2.5 安全能力建設

作為一個基礎的大數(shù)據(jù)服務，安全在我們看來是一個非常重要的命題，因此我們在系統(tǒng)設計之初就考慮了實時數(shù)據(jù)訪問、離線數(shù)據(jù)讀寫、各個系統(tǒng)與服務之間的安全隔離能力等方面的設計，在實時數(shù)倉具備一定規(guī)模后，我們又建設了數(shù)據(jù)分類分級、日志審計等能力。去年，根據(jù)最新的合規(guī)要求，離線存儲支持了列級別透明加密，實時數(shù)據(jù)支持了敏感字段自動檢測等能力。安全無止境，我們也在對DSMM進行研究解讀，以持續(xù)提升大數(shù)據(jù)的安全能力。

以上是我們平臺建設的一些實踐，總結(jié)來看，我們基于Flink建設了功能比較完善的實時計算開發(fā)和運維能力，業(yè)務復雜度越來越高，我們的挑戰(zhàn)還有很多，比如Flink引擎的優(yōu)化與難點問題的解決、計算效率的進一步提升、流批一體、容器化的大規(guī)模應用等，都是我們后續(xù)的重點方向。

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

三、應用場景簡介

3.1 實時數(shù)倉

vivo大數(shù)據(jù)團隊基于vStream平臺建設的實時數(shù)倉服務覆蓋了應用分發(fā)、內(nèi)容分發(fā)、產(chǎn)品平臺、商業(yè)化等多個業(yè)務線的報表、營銷、推薦、決策、廣告等多種應用場景。實時數(shù)倉沿用了離線數(shù)倉的邏輯分層理論，從數(shù)據(jù)源經(jīng)過采集和ETL進入到ODS層，然后經(jīng)過維度擴展、過濾、轉(zhuǎn)換等操作進入到DWD明細層，然后是輕度聚合層DWS，最后按照主題或業(yè)務需求計算出結(jié)果指標存入ClickHouse等OLAP引擎成為ADS層，為業(yè)務提供數(shù)據(jù)報表、接口或者數(shù)據(jù)服務。與離線有所不同的是，實時數(shù)據(jù)受限于數(shù)據(jù)達到時間或業(yè)務對數(shù)據(jù)的要求，可能會有層次的裁剪，因此實時數(shù)倉也提供了中間層開放的能力。

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

3.2 短視頻實時內(nèi)容推薦

vivo短視頻是一個很火的應用，為了給到用戶高質(zhì)量的視頻內(nèi)容推薦，特別依賴于推薦模型的時效性以及用戶特征計算的時效性，為了做到實時的模型訓練，需要有實時的樣本數(shù)據(jù)。因此實時特征計算和樣本拼接在內(nèi)容推薦里面扮演了很重要的角色，vStream平臺提供的TB級別超大狀態(tài)任務能力支撐了短視頻以及許多其他應用的實時樣本拼接任務。同時我們也可以看到，在這個方案里，特征和樣本都同時存在離線和實時兩條鏈路，這是因為Flink的批計算能力目前還沒有Spark成熟，基于Kafka的實時計算難以做到數(shù)據(jù)回溯，站在我們大數(shù)據(jù)平臺的角度，一方面我們希望能夠減少重復的計算和存儲，另一方面也希望平臺的用戶能夠不需要重復開發(fā)計算和回溯的代碼。在業(yè)界廣泛討論的湖倉一體架構(gòu)，很重要的一個方面就是為了解決這些問題。在后面的部分，我們會再聊一聊湖倉一體。

實時計算的應用場景有很多，但本質(zhì)上來說它的目的跟離線計算是一樣的，就是為業(yè)務提供數(shù)據(jù)支持。從前面的介紹可以看到，當前基于Hadoop的大數(shù)據(jù)平臺組件繁多、架構(gòu)復雜、流批重復、資源效率較低，那么我們有沒有辦法或者說有沒有希望改變這種現(xiàn)狀呢？我認為是有的，最后分享一下我們對未來的一些探索和展望。

四、探索與展望

我們知道，業(yè)務是彈性的，比如在一天之內(nèi)總有用戶訪問的高峰和低谷，一段時間內(nèi)總有業(yè)務的增長或下降。但是當前，不管是我們的數(shù)據(jù)計算任務還是YARN集群的資源分配策略，都不具備彈性，首先，任務分配的資源是固定的，并且，為了盡可能避免計算受到業(yè)務波動的影響，離線、實時和在線三種不同類型的計算分別運行在不同的物理集群。

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

• 任務級別的彈性能力，我們打算緊跟Flink社區(qū)，探索其AutoScaling特性的應用。
• 集群級別的彈性能力，我們會采用vivo容器團隊提供的在離線混部能力來實現(xiàn)。

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