本文介紹了網(wǎng)易郵箱數(shù)倉(cāng)的演進(jìn)過程和期間一些關(guān)鍵的技術(shù)方案引入決策，并闡述了這些決策背后的業(yè)務(wù)需求和技術(shù)考慮因素，以及實(shí)施后的實(shí)際產(chǎn)出成效。最后對(duì)整個(gè)過程進(jìn)行了總結(jié)及后續(xù)展望。

1、概述

到目前為止，網(wǎng)易郵箱數(shù)倉(cāng)的發(fā)展大致經(jīng)歷了三個(gè)階段：

第一個(gè)階段是2020年10月份之前，這時(shí)候我們的數(shù)據(jù)系統(tǒng)的主要任務(wù)是支持郵箱日常的運(yùn)營(yíng)統(tǒng)計(jì)；

第二個(gè)階段大概是2020年11月份到2021年的11月份，這段期間公司嘗試做業(yè)務(wù)的調(diào)整，挖掘新的長(zhǎng)期增長(zhǎng)方向。我們?cè)谶@時(shí)候?qū)︵]箱數(shù)倉(cāng)底層的OLAP引擎和整個(gè)數(shù)據(jù)處理鏈路都進(jìn)行了重構(gòu)，以適應(yīng)業(yè)務(wù)方寬泛的即席數(shù)據(jù)探索需求；

第三個(gè)階段大概是2021年的12月份到現(xiàn)在，我們進(jìn)入了精細(xì)化運(yùn)營(yíng)探索期。這個(gè)時(shí)期我們的主要工作是完善數(shù)倉(cāng)結(jié)構(gòu)，滿足更多、更深入的數(shù)據(jù)應(yīng)用需求。

可以看到，由于每個(gè)時(shí)期面臨的主要問題不同，前兩個(gè)階段切換的主題在于重建基礎(chǔ)設(shè)施，而后兩個(gè)階段切換的主題則是完善上層建筑。

2、初始狀態(tài)

早期的網(wǎng)易郵箱數(shù)倉(cāng)底層是一套完整的Hadoop體系結(jié)構(gòu)，它的組件構(gòu)成比較龐雜。但后期它完成的主要任務(wù)就是從貼源層計(jì)算統(tǒng)計(jì)結(jié)果到應(yīng)用層，用作BI報(bào)表展示。

有一組數(shù)據(jù)能夠反映2020年10月份之前這個(gè)系統(tǒng)的狀態(tài)：整個(gè)集群大概有300個(gè)節(jié)點(diǎn)，存了9P+的數(shù)據(jù)，其中小文件眾多，導(dǎo)致元數(shù)據(jù)條目有6億+，這個(gè)元數(shù)據(jù)規(guī)模讓HDFS的NameNode不堪重負(fù)，2次崩潰。其中第二次崩潰導(dǎo)致郵箱所有的數(shù)據(jù)統(tǒng)計(jì)任務(wù)停了整整1周多的時(shí)間，這也是導(dǎo)致我們下決心后續(xù)對(duì)數(shù)倉(cāng)進(jìn)行升級(jí)改造的直接原因。

然而我們當(dāng)時(shí)只有兩名數(shù)據(jù)開發(fā)人員，并且沒有專職的大數(shù)據(jù)運(yùn)維人員。因此，從資源的角度看，我們實(shí)際上也是沒有條件繼續(xù)支撐這套體系持續(xù)穩(wěn)定運(yùn)轉(zhuǎn)的，一次徹底的底層重構(gòu)勢(shì)在必行。

根據(jù)當(dāng)時(shí)的情況，重構(gòu)方案在技術(shù)層面需要下面考慮三點(diǎn)：

• 開發(fā)效率：因?yàn)殚_發(fā)人員少，而基于MR框架的開發(fā)效率比較低，我們需要一個(gè)使用成本更低、效率更高的開發(fā)平臺(tái)；
• 系統(tǒng)性能：老系統(tǒng)的任務(wù)執(zhí)行效率較低（尤其是邏輯較復(fù)雜的長(zhǎng)周期統(tǒng)計(jì)任務(wù)），新方案應(yīng)該要在大規(guī)模數(shù)據(jù)集下有更好的查詢性能；
• 運(yùn)維效率：因?yàn)槿鄙賹Ｂ毜臄?shù)據(jù)運(yùn)維，我們需要架構(gòu)相對(duì)簡(jiǎn)單，維護(hù)難度相對(duì)低的技術(shù)選型。

另外，在業(yè)務(wù)層面，當(dāng)時(shí)我們的產(chǎn)品和運(yùn)營(yíng)側(cè)都還在新方向探索期，對(duì)業(yè)務(wù)指標(biāo)間的關(guān)聯(lián)性了解不足，沒有形成穩(wěn)定的觀察指標(biāo)體系。具體的癥狀就是這兩個(gè)：

• “不知道要什么”：當(dāng)你問業(yè)務(wù)方：“最想要看哪些指標(biāo)？”，結(jié)果通常都是說不上來，不知道哪些指標(biāo)和用戶、會(huì)員等核心指標(biāo)的提升關(guān)聯(lián)度大；
• “什么都要”：當(dāng)業(yè)務(wù)方提需求的時(shí)候就是：什么都要。各種業(yè)務(wù)過程的不同維度、不同粒度下的指標(biāo)都要看。

如果在這個(gè)時(shí)期就去構(gòu)建完整的多層數(shù)倉(cāng)結(jié)構(gòu)，預(yù)先做好多維度的聚合指標(biāo)，很容易變成無用功，最后要推倒重來。實(shí)際上業(yè)務(wù)側(cè)這時(shí)候最需要的是在明細(xì)事實(shí)數(shù)據(jù)層面的高性能的ad-hoc查詢能力，并且最好更夠支持他們進(jìn)行自助的數(shù)據(jù)探索。

3、數(shù)倉(cāng)1.0

于是經(jīng)過綜合考慮，我們從2020年底到2021年中逐步做了下面幾個(gè)工作：

• 第一個(gè)是將舊Hadoop集群的數(shù)據(jù)進(jìn)行壓縮、清理后，遷移到新搭建的猛犸Hadoop集群（規(guī)模小了很多），成為新數(shù)倉(cāng)的ODS層，向上層提供原始數(shù)據(jù)輸入；
• 第二個(gè)是選型、引入了以數(shù)據(jù)查詢和寫入性能著稱的OLAP引擎ClickHouse（下文簡(jiǎn)稱CK），作為新數(shù)倉(cāng)的DWD層，支持應(yīng)用側(cè)以SQL的形式查詢、挖掘事實(shí)數(shù)據(jù)；
• 第三個(gè)是基于Kafka和Flink搭建了一套新的、支持實(shí)時(shí)數(shù)據(jù)采集的數(shù)據(jù)處理鏈路，為CK輸入清洗后的事實(shí)數(shù)據(jù)。

這套框架搭建完之后帶來下面幾個(gè)方面的好處：

（1）在開發(fā)層面

• 統(tǒng)一用SQL進(jìn)行數(shù)據(jù)需求的開發(fā)，降低了開發(fā)難度，也便于形成統(tǒng)一的開發(fā)規(guī)范；
• 降低了業(yè)務(wù)側(cè)自助查詢的門檻，讓運(yùn)營(yíng)、QA、前后端開發(fā)等職能可以自己實(shí)現(xiàn)數(shù)據(jù)統(tǒng)計(jì)任務(wù)和報(bào)表產(chǎn)出，相當(dāng)于增加了數(shù)據(jù)開發(fā)的人力（這點(diǎn)對(duì)我們來說很重要，它讓我們能夠在人力資源這么緊張的情況下，還能騰出手來，在數(shù)倉(cāng)的外延去補(bǔ)充數(shù)據(jù)中臺(tái)的一些能力）；
• 實(shí)現(xiàn)了高效的數(shù)據(jù)接入流程。

（2）在業(yè)務(wù)提效層面

• CK具有很高的單表查詢和寫入性能，提升了數(shù)據(jù)需求實(shí)現(xiàn)的效率；
• 依靠強(qiáng)大的基礎(chǔ)性能，CK可以覆蓋從T+1的運(yùn)營(yíng)統(tǒng)計(jì)到準(zhǔn)實(shí)時(shí)的服務(wù)質(zhì)量基線統(tǒng)計(jì)需求。

（3）在運(yùn)維層面

• 盡管CK自身也有在擴(kuò)容等方面的維護(hù)難點(diǎn)，但整體上相比Hadoop技術(shù)棧的組件要少，部署結(jié)構(gòu)相對(duì)簡(jiǎn)單；
• 另外CK在數(shù)據(jù)壓縮后仍能維持較好的查詢性能，有助于我們控制存儲(chǔ)規(guī)模。

在新數(shù)倉(cāng)上線后，我們?nèi)〉昧吮容^顯著的業(yè)務(wù)和技術(shù)成效。比如在業(yè)務(wù)支撐方面，業(yè)務(wù)側(cè)自助取數(shù)占比從0提升到了80%以上，平均取數(shù)時(shí)長(zhǎng)從天級(jí)縮短至分鐘級(jí)，當(dāng)時(shí)的業(yè)務(wù)指標(biāo)覆蓋度也有了質(zhì)的提升；在開發(fā)層面，統(tǒng)計(jì)任務(wù)的開發(fā)效率、數(shù)據(jù)查詢性能和數(shù)據(jù)接入效率都成倍地提升；而在運(yùn)維層面，我們用比之前更少的服務(wù)器資源支撐了更高的數(shù)據(jù)吞吐量，同時(shí)系統(tǒng)可用性還得到了提升。

看上去我們已經(jīng)很好地支撐了當(dāng)時(shí)的業(yè)務(wù)需求，為什么還要繼續(xù)折騰呢？

因?yàn)闃I(yè)務(wù)會(huì)成長(zhǎng)。隨著各項(xiàng)運(yùn)營(yíng)目標(biāo)的推進(jìn)，大家總算是形成了一些相對(duì)穩(wěn)定的業(yè)務(wù)觀察指標(biāo)了，但觀察了一段時(shí)間之后的結(jié)論就是：很多關(guān)鍵業(yè)務(wù)指標(biāo)的增長(zhǎng)都出現(xiàn)了瓶頸。而同時(shí)在降本增效的趨勢(shì)下，運(yùn)營(yíng)觸達(dá)行為的轉(zhuǎn)化率要求也提升了。

實(shí)際上是業(yè)務(wù)增長(zhǎng)現(xiàn)在需要更精細(xì)化的運(yùn)營(yíng)策略了，而這時(shí)候我們的系統(tǒng)能力就逐漸和新的需求演化趨勢(shì)之間產(chǎn)生了一些失配：

• 首先是深挖業(yè)務(wù)增長(zhǎng)因素的多維度分析場(chǎng)景增多了，而CK的Join性能優(yōu)化較弱，或者說對(duì)于業(yè)務(wù)側(cè)同學(xué)和數(shù)據(jù)分析師來說，要寫出高效的關(guān)聯(lián)查詢SQL的門檻比較高，所以應(yīng)用復(fù)雜的維度建模方法的難度較大（如果都打成CK喜歡的大寬表的模式的話，數(shù)據(jù)表的復(fù)用度低，重復(fù)開發(fā)量大，數(shù)據(jù)變更的影響也大）；
• 第二個(gè)是運(yùn)營(yíng)策略越來越依賴用戶、設(shè)備等維度的標(biāo)簽，而標(biāo)簽（尤其是統(tǒng)計(jì)數(shù)值類標(biāo)簽）是容易發(fā)生變更的，而CK對(duì)數(shù)據(jù)熱更新的支持不完善，會(huì)增加標(biāo)簽維護(hù)的成本；
• 第三個(gè)是隨著更多數(shù)據(jù)應(yīng)用的出現(xiàn)，分析查詢的頻次提升了，對(duì)數(shù)倉(cāng)的并發(fā)請(qǐng)求增多，但CK的并發(fā)查詢支撐能力不強(qiáng)。

所以我們需要對(duì)系統(tǒng)進(jìn)行進(jìn)一步的能力提升。但從資源、成本以及需求時(shí)效性的角度考慮，去改造CK或者等它升級(jí)提供所需要的能力和特性顯然都不現(xiàn)實(shí)。

為了能夠在不大規(guī)模地改變現(xiàn)有架構(gòu)的前提下，快速地補(bǔ)充缺失的能力，我們考慮新引入一個(gè)能滿足這些能力要求的OLAP引擎，并讓它主要工作在DWM層，用來承載輕度聚合數(shù)據(jù)、標(biāo)簽及其他維表，并支撐業(yè)務(wù)的多維度分析需求。

在這個(gè)新數(shù)倉(cāng)的選型上，我們對(duì)比了業(yè)界多個(gè)優(yōu)秀的OLAP引擎，其中有基于Hadoop生態(tài)的方案，也有采用獨(dú)立研發(fā)的存算系統(tǒng)的方案。最終考慮到StarRocks在與現(xiàn)有系統(tǒng)的整合難度、關(guān)聯(lián)查詢優(yōu)化、數(shù)據(jù)更新支持、并發(fā)查詢能力和運(yùn)維成本等方面的均衡表現(xiàn)，決定選擇它作為新的選型。

StarRocks實(shí)際上是與Doris同源的另外一個(gè)開源分支。這背后其實(shí)還隱含了另外一個(gè)選型因素，就是我們和StarRocks的技術(shù)團(tuán)隊(duì)在很早之前就建立了聯(lián)系，他們也在我們的實(shí)踐過程中提供了很好的技術(shù)支持。

4、數(shù)倉(cāng)2.0

于是從2021年年末起，我們按計(jì)劃引入了StarRocks，并調(diào)整了數(shù)倉(cāng)的邏輯結(jié)構(gòu)，從而又帶來了一系列提升：

（1）在業(yè)務(wù)支撐層面

• 可以支持并發(fā)度比較高的多維度分析查詢需求；
• 以較小的開發(fā)、維護(hù)成本滿足了數(shù)據(jù)應(yīng)用側(cè)的標(biāo)簽查詢需求。

（2）在開發(fā)及架構(gòu)層面

• 我們讓CK和StarRocks工作在了各自擅長(zhǎng)的層次。在數(shù)據(jù)規(guī)模比較大的細(xì)粒度事實(shí)層，數(shù)據(jù)探索依然可以依賴CK的大寬表模式；而在中間層的開發(fā)中我們也能充分利用StarRocks的自動(dòng)聚合、智能物化視圖等這些特性來提升開發(fā)效率；
• 提升通用指標(biāo)的復(fù)用度，減少了重復(fù)開發(fā)；
• 降低了對(duì)明細(xì)層數(shù)據(jù)的查詢壓力。

目前，我們StarRocks中存儲(chǔ)了40多個(gè)標(biāo)簽表，數(shù)據(jù)量達(dá)300多億條，日均數(shù)據(jù)更新7億多次，每天承載的查詢量達(dá)到了千萬(wàn)級(jí)（這里包括了一些在線應(yīng)用的實(shí)時(shí)請(qǐng)求）。

在業(yè)務(wù)成效方面，一些特定的用戶標(biāo)簽讓定向引流觸達(dá)活動(dòng)的點(diǎn)擊率平均提升了90%以上；基于數(shù)倉(cāng)中間層的取數(shù)系統(tǒng)和畫像系統(tǒng)上線以來，累計(jì)節(jié)省了約10人月的數(shù)據(jù)開發(fā)人力投入；同時(shí)標(biāo)簽庫(kù)也支撐了風(fēng)控因子庫(kù)和個(gè)性化反垃圾模型的構(gòu)建。

5、總結(jié)

如果用一句話來總結(jié)到目前為止的數(shù)倉(cāng)建設(shè)過程，那就是：“雖然起步晚，但幾乎總是在關(guān)鍵的業(yè)務(wù)發(fā)展節(jié)點(diǎn)前補(bǔ)充了與之匹配的能力”。我們從中得到的感觸主要有兩點(diǎn)：

首先是數(shù)據(jù)團(tuán)隊(duì)?wèi)?yīng)該時(shí)刻關(guān)注業(yè)務(wù)的運(yùn)營(yíng)狀態(tài)和數(shù)據(jù)的產(chǎn)出價(jià)值。這是我們跟上業(yè)務(wù)的發(fā)展節(jié)奏甚至推動(dòng)它前進(jìn)的前提，同時(shí)也體現(xiàn)了一種價(jià)值取向：就是技術(shù)團(tuán)隊(duì)的最終產(chǎn)出價(jià)值通常不是技術(shù)本身，我們的技術(shù)活動(dòng)的終極目標(biāo)通常也不是技術(shù)先進(jìn)性，而是讓業(yè)務(wù)在殘酷的市場(chǎng)競(jìng)爭(zhēng)中獲得生存優(yōu)勢(shì)；

其次是數(shù)倉(cāng)建設(shè)無法一蹴而就。因?yàn)闃I(yè)務(wù)需求的演進(jìn)需要一個(gè)過程，而方案的實(shí)施又有各種資源和成本上的限制，所以不可能也沒有必要從一開始就考慮實(shí)現(xiàn)一個(gè)大而全的系統(tǒng)。更好的方式可能是提前預(yù)判需求的演變趨勢(shì)，用來做長(zhǎng)期的建設(shè)規(guī)劃，但按中短期的能力要求循序漸進(jìn)地推進(jìn)。

6、展望

展望未來，郵箱業(yè)務(wù)會(huì)持續(xù)發(fā)展，甚至?xí)L試突破業(yè)務(wù)的領(lǐng)域邊界。預(yù)計(jì)會(huì)有更多針對(duì)特定領(lǐng)域的數(shù)據(jù)應(yīng)用出現(xiàn)。這些應(yīng)用實(shí)際上是把調(diào)用數(shù)倉(cāng)算力的門檻降低了，會(huì)給數(shù)據(jù)支撐工作帶來更大的壓力。

為此我們計(jì)劃做好以下幾件事情：

• 為了保持?jǐn)?shù)倉(cāng)系統(tǒng)的健康度，需要完善數(shù)據(jù)中臺(tái)的數(shù)據(jù)治理能力，尤其是通過數(shù)據(jù)價(jià)值評(píng)估和數(shù)據(jù)生命周期管理，有效地控制數(shù)倉(cāng)的熱存儲(chǔ)中的數(shù)據(jù)規(guī)模；
• 為了在降本增效的前提下應(yīng)對(duì)不斷提升的應(yīng)用算力需求，需要提升數(shù)倉(cāng)系統(tǒng)的資源利用率和彈性伸縮能力，因此考慮引入OLAP引擎層面的存算分離和資源隔離機(jī)制；
• 為了應(yīng)對(duì)業(yè)務(wù)領(lǐng)域拓展可能會(huì)帶來的不同的數(shù)據(jù)分析模式，還需要考慮湖倉(cāng)一體和簡(jiǎn)化、加速數(shù)據(jù)湖分析的方案。

本次的分享就到這里，謝謝大家。