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

1、概述

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

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

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

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

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

2、初始狀態(tài)

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

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

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

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

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

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

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

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

3、數(shù)倉1.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在這個新數(shù)倉的選型上，我們對比了業(yè)界多個優(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同源的另外一個開源分支。這背后其實(shí)還隱含了另外一個選型因素，就是我們和StarRocks的技術(shù)團(tuán)隊在很早之前就建立了聯(lián)系，他們也在我們的實(shí)踐過程中提供了很好的技術(shù)支持。

4、數(shù)倉2.0

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

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

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

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

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

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

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

5、總結(jié)

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

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

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

6、展望

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

為此我們計劃做好以下幾件事情：

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

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