基礎(chǔ)數(shù)據(jù)是公司大數(shù)據(jù)應(yīng)用的關(guān)鍵底座，價(jià)值挖掘的基石，內(nèi)容包括：大數(shù)據(jù)集成，數(shù)據(jù)計(jì)算，架構(gòu)容災(zāi)等幾個(gè)主要方面。建設(shè)的目標(biāo)包括：確保基礎(chǔ)數(shù)據(jù)及時(shí)準(zhǔn)確、計(jì)算性能好、資源成本消耗低、架構(gòu)容災(zāi)能力強(qiáng)、研發(fā)效率高，這也是基礎(chǔ)數(shù)據(jù)工作的核心能力。

一、基礎(chǔ)數(shù)據(jù)發(fā)展與挑戰(zhàn)

1.1 vivo 早期的基礎(chǔ)數(shù)據(jù)架構(gòu)

為了滿足業(yè)務(wù)發(fā)展，0-1構(gòu)建基礎(chǔ)數(shù)據(jù)的基礎(chǔ)框架，數(shù)據(jù)來(lái)源主要是日志，通過(guò)實(shí)時(shí)采集，緩存到Kafka，按小時(shí)離線轉(zhuǎn)存到ODS表，日處理數(shù)據(jù)量在百億級(jí)，整個(gè)數(shù)據(jù)鏈路簡(jiǎn)潔高效，但是，隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)增長(zhǎng)，用戶的訴求多樣化，該基礎(chǔ)數(shù)據(jù)架構(gòu)逐漸面臨諸多挑戰(zhàn)。

1.2 vivo 業(yè)發(fā)展帶來(lái)挑戰(zhàn)

一是：數(shù)據(jù)規(guī)模增長(zhǎng)，日增記錄數(shù)從百億到萬(wàn)億級(jí)，日增存儲(chǔ)量從GB級(jí)到PB級(jí)，實(shí)時(shí)并發(fā)QPS量級(jí)達(dá)到數(shù)據(jù)百萬(wàn)。

二是：計(jì)算場(chǎng)景增加，從離線計(jì)算擴(kuò)展到準(zhǔn)實(shí)時(shí)，實(shí)時(shí)，甚至流批一體計(jì)算場(chǎng)景。

三是：性能要求提高，實(shí)時(shí)計(jì)算端到端延時(shí)，需要從小時(shí)到秒級(jí)；離線計(jì)算單小時(shí)數(shù)據(jù)量級(jí)從GB達(dá)到10TB+，業(yè)務(wù)發(fā)展速度超過(guò)了技術(shù)架構(gòu)迭代速度，必然給技術(shù)帶來(lái)更大的挑戰(zhàn)。

1.3 技術(shù)挑戰(zhàn)

首先是單個(gè)Topic數(shù)據(jù)量每天數(shù)百億，多個(gè)消費(fèi)組同時(shí)消費(fèi)，重復(fù)消費(fèi)導(dǎo)致計(jì)算和存儲(chǔ)資源浪費(fèi)；Kafka集群穩(wěn)定性越來(lái)越差。

數(shù)據(jù)量的增加，數(shù)據(jù)采集和ETL計(jì)算時(shí)延越來(lái)越長(zhǎng)，無(wú)法滿足鏈路秒級(jí)時(shí)延，每小時(shí)超過(guò)10TB的離線處理時(shí)間超過(guò)2～3小時(shí)。

考慮存儲(chǔ)成本的原因，Kafka生命周期配置有限，長(zhǎng)時(shí)間的故障會(huì)導(dǎo)致數(shù)據(jù)丟失。

由于計(jì)算性能和吞吐有限，需要不斷增加資源，運(yùn)維值班的壓力日益增長(zhǎng)，每月有超過(guò)20天都有起夜的情況。

當(dāng)然，除了技術(shù)挑戰(zhàn)，還有面臨用戶的挑戰(zhàn)。

1.4 用戶訴求

• 數(shù)據(jù)安全方面：數(shù)據(jù)加密，計(jì)算｜需要解密｜和鑒權(quán)，確保數(shù)據(jù)的安全合規(guī)
• 帶寬成本方面：數(shù)據(jù)壓縮，計(jì)算｜需要解壓縮｜和拆分，降低傳輸?shù)膸挸杀?/span>
• 存儲(chǔ)成本方面：數(shù)據(jù)輸出，需要支持｜不同壓縮格式，以降低存儲(chǔ)成本
• 使用便捷方面：需要擴(kuò)充｜基礎(chǔ)數(shù)據(jù)｜公共維度，避免下游重復(fù)計(jì)算
• 使用門檻方面：實(shí)時(shí)和離線數(shù)據(jù)｜需要滿足SQL化查詢，降低用戶使用門檻

圖片

二、vivo 基礎(chǔ)數(shù)據(jù)架構(gòu)應(yīng)用實(shí)踐

2.1 整體架構(gòu)

基于業(yè)務(wù)發(fā)展，構(gòu)建多機(jī)房多集群，雙活容災(zāi)鏈路基礎(chǔ)架構(gòu)，全面支持多種周期(秒級(jí)/分鐘/小時(shí)/天等)數(shù)據(jù)計(jì)算場(chǎng)景。

相比較歷史架構(gòu)，我們新增了離線采集鏈路，直接從源端拷貝LOG日志，緩存到HDFS目錄，再解析入庫(kù)寫ODS表，與原實(shí)時(shí)鏈路互備，可實(shí)現(xiàn)鏈路故障容災(zāi)切換，同時(shí)，實(shí)時(shí)計(jì)算增加分揀層，收斂消費(fèi)，支持多組件的配置化輸出，為了確保數(shù)據(jù)及時(shí)和準(zhǔn)確性，構(gòu)建了完善的數(shù)據(jù)校驗(yàn)和監(jiān)控體系。

顯然，當(dāng)前的架構(gòu)有點(diǎn)類似Lambda架構(gòu)，可能會(huì)有以下幾個(gè)疑問(wèn)：

• 實(shí)時(shí)和離線鏈路會(huì)出現(xiàn)存儲(chǔ)和計(jì)算冗余，浪費(fèi)資源多；
• 實(shí)時(shí)和離線計(jì)算會(huì)存在數(shù)據(jù)一致性問(wèn)題，運(yùn)維成本大；
• 現(xiàn)在都發(fā)展到流批/湖倉(cāng)一體計(jì)算，此架構(gòu)不夠先進(jìn)。

大數(shù)據(jù)計(jì)算架構(gòu)，滿足公司和業(yè)務(wù)發(fā)展，才是最好的，過(guò)于追求先進(jìn)，又或者太過(guò)落后，都不利于公司和業(yè)務(wù)的發(fā)展，基礎(chǔ)數(shù)據(jù)，重點(diǎn)是穩(wěn)定高可用，通過(guò)持續(xù)的優(yōu)化和迭代，將資源浪費(fèi)問(wèn)題，數(shù)據(jù)一致性問(wèn)題和性能問(wèn)題解決，構(gòu)建一種雙活容災(zāi)全新架構(gòu)，才是我們初衷。

結(jié)合業(yè)務(wù)發(fā)展和使用調(diào)研，發(fā)現(xiàn)批計(jì)算場(chǎng)景遠(yuǎn)多于實(shí)時(shí)計(jì)算場(chǎng)景，并且有以下特點(diǎn)：

1. 因Kafka的存儲(chǔ)與HDFS存儲(chǔ)比較，成本高，如果將萬(wàn)億級(jí)數(shù)據(jù)全部緩存Kafka，存儲(chǔ)成本巨大。
2. 實(shí)時(shí)應(yīng)用場(chǎng)景占比很少，約20%,海量數(shù)據(jù)消費(fèi)資源持續(xù)空跑，導(dǎo)致大量計(jì)算資源浪費(fèi)。
3. Kafka數(shù)據(jù)使用門檻高，不能直接SQL查詢，理解和使用的效率太低。
4. 離線重跑頻繁，Kafka消費(fèi)重置offset操作不方便，運(yùn)維難度較大。
5. 流批/湖倉(cāng)一體架構(gòu)成熟度有限，技術(shù)挑戰(zhàn)難度較大，穩(wěn)定性存在挑戰(zhàn)。
6. 基礎(chǔ)數(shù)據(jù)的雙鏈路一致性問(wèn)題、資源冗余問(wèn)題、性能問(wèn)題，通過(guò)架構(gòu)調(diào)整是可以解決的。

圖片

2.2 雙鏈路設(shè)計(jì)

結(jié)合2種用數(shù)場(chǎng)景，將離線和實(shí)時(shí)計(jì)算鏈路，數(shù)據(jù)緩存和計(jì)算分離，減少實(shí)時(shí)存儲(chǔ)和計(jì)算的資源，減少故障風(fēng)險(xiǎn)。

只有實(shí)時(shí)計(jì)算訴求，開(kāi)啟實(shí)時(shí)采集；寫入到Kafka或者Pulsar集群，緩存8-24小時(shí)(可根據(jù)需要調(diào)整)，用于后續(xù)實(shí)時(shí)計(jì)算。

只有離線計(jì)算訴求，開(kāi)啟離線采集；按小時(shí)拷貝到HDFS緩存集群，保存2-7天(可根據(jù)需要調(diào)整)，用于后續(xù)離線計(jì)算。

同時(shí)，數(shù)據(jù)采集端確保實(shí)時(shí)和離線數(shù)據(jù)不冗余，這樣設(shè)計(jì)的好處就是：

• 數(shù)據(jù)緩存 HDFS 比 Kafka 成本更低(降低40%成本)，不容易丟，離線重跑更加便捷；
• 實(shí)時(shí)鏈路出問(wèn)題可立即切換到離線鏈路（定點(diǎn)采集，分鐘級(jí)切換入倉(cāng)），容災(zāi)能力會(huì)更加強(qiáng)大。

隨著業(yè)務(wù)發(fā)展，實(shí)時(shí)場(chǎng)景逐漸增加，切換到實(shí)時(shí)鏈路后，會(huì)與原離線數(shù)據(jù)比較，數(shù)據(jù)不一致性風(fēng)險(xiǎn)更大，為此，我們通過(guò)三個(gè)措施解決，將ETL過(guò)程組件化，標(biāo)準(zhǔn)化，配置化。

一是：開(kāi)發(fā)上線通用組件，離線和實(shí)時(shí)ETL共用

二是：成立ETL｜專屬團(tuán)隊(duì)，統(tǒng)一處理邏輯

三是：構(gòu)建ETL處理平臺(tái)，配置化開(kāi)

這樣，通過(guò)鏈路切換，處理邏輯統(tǒng)一，功能和邏輯一致，既提升了研發(fā)效率，也消除了數(shù)據(jù)不一致風(fēng)險(xiǎn)；而在計(jì)算方面，實(shí)時(shí)和離線計(jì)算集群相互獨(dú)立，實(shí)時(shí)和離線數(shù)據(jù)緩存計(jì)算相互獨(dú)立，互不影響，計(jì)算更加穩(wěn)定。

解決了Kafka存儲(chǔ)成本、雙鏈路數(shù)據(jù)不一致、鏈路容災(zāi)問(wèn)題，接下來(lái)就是計(jì)算性能的問(wèn)題需要解決：

1. 實(shí)時(shí)計(jì)算，存在每天百億級(jí)別的大Topic，多消費(fèi)組重復(fù)消費(fèi)，計(jì)算資源浪費(fèi)。
2. 實(shí)時(shí)計(jì)算，數(shù)據(jù)全鏈路端到端（數(shù)據(jù)生產(chǎn)端到數(shù)據(jù)用端）秒級(jí)延遲訴求無(wú)法滿足。
3. 離線計(jì)算，單次處理數(shù)據(jù)量10TB+，計(jì)算時(shí)間長(zhǎng)超過(guò)2小時(shí)，計(jì)算內(nèi)存配置TB級(jí)，及時(shí)性沒(méi)法保證。
4. 離線計(jì)算，單小時(shí)數(shù)據(jù)量級(jí)不固定，任務(wù)配置的計(jì)算資源是固定的，當(dāng)數(shù)據(jù)量增加時(shí)，常有oom現(xiàn)象，必然，導(dǎo)致值班運(yùn)維壓力就比較大。

2.3 實(shí)時(shí)計(jì)算性能優(yōu)化

增加統(tǒng)一分揀層，通過(guò)Topic一次消費(fèi)，滿足不同業(yè)務(wù)的數(shù)據(jù)要求，避免重復(fù)消費(fèi)，存儲(chǔ)換計(jì)算，降低成本。

為了解決百億級(jí)大Topic=重復(fù)消費(fèi)問(wèn)題，我們構(gòu)建了實(shí)時(shí)分揀層，主要是基于用戶不同訴求，將不同用戶，需要的部分?jǐn)?shù)據(jù)，單獨(dú)分揀到子Topic，提供用戶消費(fèi)，該分揀層，只需要申請(qǐng)一個(gè)消費(fèi)組，一次消費(fèi)，一次處理即可，有效避免重復(fù)消費(fèi)和計(jì)算，這樣，通過(guò)對(duì)大Topic部分?jǐn)?shù)據(jù)的適當(dāng)冗余，以存儲(chǔ)換計(jì)算，可降低資源成本30%以上，同時(shí)，有效確保下游數(shù)據(jù)的一致性。

為了實(shí)現(xiàn)實(shí)時(shí)鏈路秒級(jí)延時(shí)，也遇到了一些困難，  主要介紹下高并發(fā)場(chǎng)景下的Redis批量動(dòng)態(tài)擴(kuò)容問(wèn)題：

在實(shí)時(shí)ETL環(huán)節(jié)，會(huì)存在多個(gè)維表關(guān)聯(lián)，維表緩存Redis，實(shí)時(shí)并發(fā)請(qǐng)求量達(dá)到數(shù)百萬(wàn)，因并發(fā)量持續(xù)增加，在Redis動(dòng)態(tài)批量擴(kuò)容時(shí)，會(huì)因數(shù)據(jù)均衡導(dǎo)致請(qǐng)求延遲，嚴(yán)重時(shí)達(dá)30分，單次擴(kuò)容量機(jī)器越多越嚴(yán)重，這種延時(shí)部分業(yè)務(wù)無(wú)法接受， 我們考慮到=后續(xù)組件容災(zāi)的需要，通過(guò)請(qǐng)求時(shí)延、并發(fā)量、擴(kuò)容影響等幾個(gè)方面的kv組件驗(yàn)證測(cè)試，最終采用了HBase2.0，得益于它毫秒級(jí)的請(qǐng)求延時(shí)，優(yōu)秀的異步請(qǐng)求框架，擴(kuò)容批量復(fù)制region功能，因此，我們將HBase引入到實(shí)時(shí)鏈路中，達(dá)到解決Redis批量擴(kuò)容導(dǎo)致消費(fèi)延時(shí)的問(wèn)題。

對(duì)于動(dòng)態(tài)擴(kuò)容延時(shí)敏感業(yè)務(wù)，優(yōu)先采用HBase緩存維表，Redis作為降級(jí)容災(zāi)組件；對(duì)于動(dòng)態(tài)擴(kuò)容延時(shí)不敏感業(yè)務(wù)，優(yōu)先采用Redis緩存維表，HBase作為降級(jí)容災(zāi)組件。

在實(shí)際應(yīng)用中，還有兩個(gè)小建議：

一是：實(shí)時(shí)任務(wù)重啟時(shí)，瞬間會(huì)產(chǎn)生大量Redis連接請(qǐng)求，Redis服務(wù)器負(fù)載急劇增加，會(huì)存在無(wú)法建立連接直接拋棄的情況，因此，建議在Redis連接代碼中增加重試機(jī)制，或者，連接量比較大時(shí)，可以適當(dāng)分批連接。

二是：Redis組件的單點(diǎn)故障，不管是不是集群部署，難免出現(xiàn)問(wèn)題，以免到時(shí)束手無(wú)策，建議增加額外組件降級(jí)容災(zāi)，我們主要是HBase和Redis并存。

2.4 離線計(jì)算性能優(yōu)化

批處理，參考流計(jì)算的原理，采用微批處理模式，解決超過(guò)10TB/小時(shí)的性能問(wèn)題。

前面多次提到的離線計(jì)算，單次處理數(shù)據(jù)量超過(guò)10TB，消耗特別多的資源，數(shù)據(jù)經(jīng)常出現(xiàn)延遲，從圖中可以看出，鏈路處理環(huán)節(jié)比較多，尤其在Join大維表時(shí)，會(huì)產(chǎn)生大量shuffle讀寫，頻繁出現(xiàn)7337端口異常現(xiàn)象（這里的7337是ESS服務(wù)端口），因集群沒(méi)有類似RSS這樣的服務(wù)，即使有，也不一定能抗住這個(gè)量級(jí)的shuffle讀寫，所以，降低shuffle數(shù)量，是我們提升離線計(jì)算性能的關(guān)鍵。

為了降低shuffle數(shù)量，首先想到的就是降低單次處理數(shù)據(jù)量，于是，我們借鑒了流式計(jì)算模型，設(shè)計(jì)了微批計(jì)算架構(gòu)，其原理介紹下：

數(shù)據(jù)采集寫HDFS頻率由小時(shí)改為分鐘級(jí)(如10分鐘)；持續(xù)監(jiān)控緩存目錄，當(dāng)滿足條件時(shí)(比如大小達(dá)到1TB)，自動(dòng)提交Spark批處理任務(wù)；讀取該批次文件，識(shí)別文件處理狀態(tài)，并寫元數(shù)據(jù)，處理完，更新該批次文件狀態(tài)，以此循環(huán)，將小時(shí)處理，調(diào)整為無(wú)固定周期的微批處理；當(dāng)發(fā)現(xiàn)某小時(shí)數(shù)據(jù)處理完成時(shí)，提交hive表分區(qū)（注意：是否處理完我們調(diào)用采集接口，這里不做詳細(xì)描述）。

這種微批計(jì)算架構(gòu)，通過(guò)充分利用時(shí)間和資源，在提升性能和吞吐量的同時(shí)，也提升了資源利用率。至此，我們降低了單次處理的數(shù)據(jù)量，比如：業(yè)務(wù)表單次處理數(shù)據(jù)量從百億下將到10億，但是，join多張大維表時(shí)shuffle量依然很大，耗時(shí)較長(zhǎng)，資源消耗較高，這不是完美的解決方案，還需要在維表和join方式上持續(xù)優(yōu)化。

維表的優(yōu)化，將全局全量維表，修改為多個(gè)業(yè)務(wù)增量維表，降低Join維表數(shù)據(jù)量，以適當(dāng)冗余存儲(chǔ)換Join效率。

因?yàn)榫S表都是公司級(jí)的全量表，數(shù)據(jù)在4～10億左右，且需要關(guān)聯(lián)2到3個(gè)不同維表，關(guān)聯(lián)方式是Sort Merge Join，會(huì)產(chǎn)生shuffle和Sort的開(kāi)銷，效率很低。

圖片

因此，我們做了降低維表量級(jí)，調(diào)整Join模式兩個(gè)優(yōu)化，降維表如下：

首先：基于業(yè)務(wù)表和維表，構(gòu)建業(yè)務(wù)增量維表，維表數(shù)據(jù)量從億級(jí)下降到千萬(wàn)級(jí)；

其次：所有維表都存儲(chǔ)在HBase，增量維表半年重新初始化一次(減少無(wú)效數(shù)據(jù))；

最后：Join時(shí)優(yōu)先使用增量維表，少部分使用全量維表，并且每次計(jì)算都會(huì)更新增量維表。

接下來(lái)，調(diào)整業(yè)務(wù)表和維表的Join方式，首先，來(lái)看下原來(lái)大表關(guān)聯(lián)使用的Sort Merge Join的原理。

先讀取數(shù)據(jù)，基于SortShuffleManager機(jī)制，做內(nèi)存排序，磁盤溢寫，磁盤文件合并等操作，然后，對(duì)每個(gè)分區(qū)的數(shù)據(jù)做排序，最后匹配關(guān)聯(lián)，可以有效解決大數(shù)據(jù)量關(guān)聯(lián),不能全部?jī)?nèi)存Join的痛點(diǎn)。

而我們降低了業(yè)務(wù)表和維表的數(shù)據(jù)量，分區(qū)減少了，shuffle量自然也會(huì)減少，如果再把消耗比較大的分區(qū)排序去掉，就可以大大提升關(guān)聯(lián)性能。

而對(duì)于千萬(wàn)級(jí)維表如果采用廣播方式，可能造成Driver端OOM，畢竟維表還是GB級(jí)別的，所以，采用Shuffle Hash Join方式是最佳方案。

最大的優(yōu)點(diǎn)就是，就是將維表分區(qū)的數(shù)據(jù)加載到內(nèi)存中，并且使用Map結(jié)構(gòu)保存，Join時(shí)，通過(guò)get的方式遍歷，避免排序，簡(jiǎn)單高效。

這樣，通過(guò)降低業(yè)務(wù)表和維表數(shù)據(jù)量，改變Join方式，相比較原來(lái)計(jì)算性能提升60%+，至此，離線計(jì)算性能問(wèn)題得到解決，數(shù)據(jù)產(chǎn)出及時(shí)性也就迎刃而解。

2.5 數(shù)據(jù)完整性

在數(shù)據(jù)采集，實(shí)時(shí)ETL和離線ETL，寫ODS過(guò)程中，如何確保數(shù)據(jù)不丟，不錯(cuò)，保持?jǐn)?shù)據(jù)完整性 ？其挑戰(zhàn)主要有三個(gè)。

1. 數(shù)據(jù)完整如何判定，比如A表數(shù)據(jù)量，下降20%？或者30%，表示不完整？很難統(tǒng)一定義，也是行業(yè)痛點(diǎn)。
2. 出現(xiàn)問(wèn)題，并且是異常，如何快速定位？
3. 不完整的數(shù)據(jù)，給到下游用戶，成千上萬(wàn)的任務(wù)都在使用錯(cuò)誤的數(shù)據(jù)計(jì)算，影響面很大，故障恢復(fù)成本很高。

而這一切的基礎(chǔ)，都需要依賴元數(shù)據(jù)，因此，元數(shù)據(jù)收集成了很關(guān)鍵的工作，必須優(yōu)先設(shè)計(jì)和建設(shè)，這里不展開(kāi)講實(shí)時(shí)元數(shù)據(jù)的收集內(nèi)容。

當(dāng)有了豐富的元數(shù)據(jù)后，利用實(shí)時(shí)元數(shù)據(jù)，我們?cè)阪溌分校黾恿巳龑訉?shí)時(shí)數(shù)據(jù)完整性對(duì)賬校驗(yàn)，它們分別是：

• 數(shù)據(jù)采集，完整性對(duì)賬
• ETL處理，完整性對(duì)賬
• 組件輸出，完整性對(duì)賬

這樣，通過(guò)可視化輸出對(duì)賬結(jié)果，能夠快速定位和發(fā)現(xiàn)問(wèn)題，定位時(shí)長(zhǎng)從天級(jí)別下降到分鐘級(jí)別。

為了準(zhǔn)確識(shí)別數(shù)據(jù)異常波動(dòng)，我們結(jié)合業(yè)務(wù)特征，建設(shè)出了多種完整性校驗(yàn)方法，并構(gòu)建多功能交叉驗(yàn)證體系，應(yīng)用于數(shù)據(jù)校驗(yàn)，主要有以下幾種校驗(yàn)方案：

1. 短周期內(nèi)的同比和環(huán)比
2. 基于歷史趨勢(shì)的算法校驗(yàn)
3. 基于數(shù)據(jù)時(shí)延的偶發(fā)漂移
4. 基于節(jié)假日的數(shù)據(jù)起伏等
5. 基于時(shí)間段的操作特征等

將這些驗(yàn)證方案，交叉疊加應(yīng)用到，不同的表和Topic，可以明顯提升異常發(fā)現(xiàn)的準(zhǔn)確率,實(shí)際從85%提升到99%，如果出現(xiàn)異常告警，也會(huì)自動(dòng)阻斷下游任務(wù)，這樣會(huì)大大降低對(duì)下游用戶的影響。

三、vivo 基礎(chǔ)數(shù)據(jù)架構(gòu)總結(jié)展望

3.1 架構(gòu)實(shí)踐總結(jié)

基礎(chǔ)數(shù)據(jù)架構(gòu)應(yīng)用諸多實(shí)踐，沒(méi)有全部詳細(xì)描述，有關(guān)業(yè)務(wù)痛點(diǎn)，用戶訴求，研發(fā)幸福感經(jīng)過(guò)長(zhǎng)期的建設(shè)，也取得了一些進(jìn)步。

1. 基礎(chǔ)數(shù)據(jù)架構(gòu)，從單鏈路升級(jí)到流批存算分離雙活架構(gòu)，多機(jī)房/集群/組件容災(zāi)，基礎(chǔ)數(shù)據(jù)鏈路高可用。
2. 實(shí)時(shí)計(jì)算，避免重復(fù)消費(fèi)，數(shù)據(jù)按需分揀，構(gòu)建低延時(shí)的計(jì)算架構(gòu)，滿足數(shù)百萬(wàn)并發(fā)處理請(qǐng)求。
3. 離線計(jì)算，任務(wù)化整為零，數(shù)據(jù)分拆減量，計(jì)算降低過(guò)程開(kāi)銷，存儲(chǔ)換性能，整體性能提升60%。
4. 數(shù)據(jù)及時(shí)性，整體架構(gòu)升級(jí)改造，數(shù)據(jù)處理量級(jí)從百億級(jí)到數(shù)萬(wàn)億級(jí)，SLA及時(shí)率穩(wěn)定保持在99.9%。
5. 數(shù)據(jù)完整性，三層級(jí)實(shí)時(shí)對(duì)賬，多功能數(shù)據(jù)校驗(yàn)，準(zhǔn)確的監(jiān)控告警，SLA完整性穩(wěn)定99.9995%。
6. 值班運(yùn)維，得益于高可用架構(gòu)和鏈路，高性能計(jì)算，起夜值班天數(shù)從月均20+下降到月均5天以內(nèi)。

而數(shù)據(jù)壓縮，數(shù)據(jù)安全，數(shù)據(jù)易用性，便捷性，在過(guò)程中都有涉及，只是沒(méi)有詳細(xì)講述。

3.2 架構(gòu)迭代規(guī)劃

打造更敏捷高效，低成本的湖倉(cāng)一體大數(shù)據(jù)計(jì)算架構(gòu)。

• 離線采集，重點(diǎn)解決源端宕機(jī)數(shù)據(jù)丟失問(wèn)題，因?yàn)楫?dāng)前部分?jǐn)?shù)據(jù)離線采集，端側(cè)服務(wù)器宕機(jī)，可能會(huì)有數(shù)據(jù)丟失風(fēng)險(xiǎn)。
• 離線計(jì)算，重點(diǎn)解決Shuffle問(wèn)題，從ESS切到RSS，實(shí)現(xiàn)Shuffle數(shù)據(jù)的存儲(chǔ)和計(jì)算分離，解決ESS服務(wù)的性能問(wèn)題。
• 實(shí)時(shí)運(yùn)維，提升異常發(fā)現(xiàn)和處理的智能化水平，重點(diǎn)是實(shí)時(shí)元數(shù)據(jù)的捕獲與歸因分析，解決實(shí)時(shí)運(yùn)維中定位難，處理時(shí)間要求短的問(wèn)題。
• 實(shí)時(shí)計(jì)算，將聯(lián)合相關(guān)團(tuán)隊(duì)，構(gòu)建更敏捷高效，低成本的，湖倉(cāng)一體化大數(shù)據(jù)計(jì)算架構(gòu)。