一、vivo 實(shí)時(shí)計(jì)算業(yè)務(wù)現(xiàn)狀

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

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

(資料圖片僅供參考)

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

二、實(shí)時(shí)計(jì)算平臺(tái)建設(shè)實(shí)踐

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

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

2.1 基礎(chǔ)服務(wù)建設(shè)

我們自研的實(shí)時(shí)平臺(tái)后端架構(gòu)包括兩個(gè)核心服務(wù)：

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

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

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

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

2.2 穩(wěn)定性建設(shè)

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

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

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

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

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

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

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

2.3 易用性建設(shè)

從實(shí)時(shí)作業(yè)開發(fā)角度，

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

從實(shí)時(shí)作業(yè)運(yùn)維角度，

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

2.4 效率提升

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

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

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

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

2.5 安全能力建設(shè)

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

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

前面有提到，基于實(shí)時(shí)計(jì)算平臺(tái)，公司的多個(gè)中臺(tái)團(tuán)隊(duì)建設(shè)了五大中臺(tái)能力，覆蓋了各種各樣的實(shí)時(shí)場景，這里就跟大家簡單分享下其中兩個(gè)典型場景。

三、應(yīng)用場景簡介3.1 實(shí)時(shí)數(shù)倉

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

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

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

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

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

四、探索與展望

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

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

任務(wù)級(jí)別的彈性能力，我們打算緊跟Flink社區(qū)，探索其AutoScaling特性的應(yīng)用。集群級(jí)別的彈性能力，我們會(huì)采用vivo容器團(tuán)隊(duì)提供的在離線混部能力來實(shí)現(xiàn)。

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

關(guān)鍵詞： 實(shí)時(shí)計(jì)算 實(shí)時(shí)數(shù)據(jù) 我們需要 數(shù)據(jù)服務(wù) 大規(guī)模的