#01
網(wǎng)易郵箱業(yè)務(wù)背景 1網(wǎng)易郵箱發(fā)展史網(wǎng)易郵箱作為國(guó)內(nèi)互聯(lián)網(wǎng)行業(yè)一個(gè)活化石級(jí)別的業(yè)務(wù)，從誕生到現(xiàn)在已經(jīng)進(jìn)入第二十五個(gè)年頭：
網(wǎng)易郵箱見(jiàn)證了國(guó)內(nèi)互聯(lián)網(wǎng)行業(yè)從誕生到發(fā)展以及壯大的整個(gè)過(guò)程，相應(yīng)的數(shù)據(jù)處理架構(gòu)也發(fā)生了一系列變化：
2005年至2017年：基于 Hadoop 生態(tài)構(gòu)建的大數(shù)據(jù)架構(gòu)。
2018年到2020年：基于 Flink + ClickHouse 自研的批流合一的大數(shù)據(jù)平臺(tái)。
2021年至今：基于StarRocks構(gòu)建的極速統(tǒng)一的大數(shù)據(jù)平臺(tái)。
2郵箱數(shù)據(jù)應(yīng)用場(chǎng)景業(yè)務(wù)日志數(shù)據(jù)存儲(chǔ)：所有業(yè)務(wù)日志都要求永久冷備存儲(chǔ)，同時(shí)在一些關(guān)鍵的業(yè)務(wù)上面，要求至少有半年以上的熱點(diǎn)數(shù)據(jù)的熱備存儲(chǔ)。不同的數(shù)據(jù)分別存儲(chǔ)，離線數(shù)據(jù)存儲(chǔ)到 HDFS ，實(shí)時(shí)數(shù)據(jù)存儲(chǔ)到 ClickHouse。業(yè)務(wù)可用性保障：網(wǎng)易郵箱作為一個(gè)通信性質(zhì)的業(yè)務(wù)，它的核心收發(fā)信鏈路以及用戶登錄驗(yàn)證機(jī)制對(duì)可用性要求非常高。核心指標(biāo)統(tǒng)計(jì)：包括用戶的活躍度，用戶新增/流失/挽回等轉(zhuǎn)化率，APP的安裝率， Webmail 的登錄等數(shù)據(jù)，會(huì)生成數(shù)據(jù)報(bào)表進(jìn)行數(shù)據(jù)展現(xiàn)。運(yùn)營(yíng)策略指引：包括直郵、推送等的轉(zhuǎn)化率的分析，以及引流用戶的留存率等方面的一些數(shù)據(jù)統(tǒng)計(jì)。反垃圾與風(fēng)控：郵箱需要具備反垃圾的能力以及風(fēng)控的能力，會(huì)對(duì)用戶的敏感行為做出判斷，通過(guò)數(shù)據(jù)的反饋來(lái)進(jìn)行捕捉，同時(shí)制定反垃圾策略。業(yè)務(wù)產(chǎn)品優(yōu)化：郵箱的數(shù)據(jù)產(chǎn)品會(huì)支持一些業(yè)務(wù)的優(yōu)化，包括對(duì)一些新業(yè)務(wù)的用戶使用數(shù)據(jù)的采集分析，以及諸如用戶支付和訂閱情況的分析等。3數(shù)據(jù)規(guī)模與業(yè)務(wù)現(xiàn)狀服務(wù)器方面。包括一些實(shí)體機(jī)和云上的一些虛機(jī)，總的算力超過(guò)1萬(wàn)核，服務(wù)器分布在華北和華東等各個(gè) IDC 機(jī)房。數(shù)據(jù)比較分散，匯總處理的難度較高。用戶量方面。網(wǎng)易郵箱存量的注冊(cè)用戶達(dá)到10億級(jí)別，同時(shí)每天還在新增巨大的新注冊(cè)用戶量。存量和增量巨大，風(fēng)控的壓力較大。數(shù)據(jù)量方面。冷備的歷史壓縮數(shù)據(jù)已經(jīng)達(dá)到PB級(jí)別，同時(shí)每天新增的數(shù)據(jù)量也很大，內(nèi)外網(wǎng)的數(shù)據(jù)流量峰值達(dá)到每秒上G的級(jí)別。資源吃緊，維護(hù)成本高。業(yè)務(wù)線方面。核心的收發(fā)信數(shù)據(jù)鏈路和登錄服務(wù)的可用性要求都是 SLA 達(dá)到 99.99%，同時(shí)每天都有超過(guò)1000個(gè)的離線數(shù)據(jù)處理任務(wù)，實(shí)時(shí)數(shù)據(jù)處理要求7×24小時(shí)無(wú)間斷運(yùn)行，下游支撐超過(guò)1萬(wàn)個(gè)數(shù)據(jù)服務(wù)。業(yè)務(wù)模型復(fù)雜，服務(wù)精度、可用性要求高。
#02
OLAP 引擎演進(jìn)與選型 1OLAP 平臺(tái)演進(jìn)網(wǎng)易郵箱作為國(guó)內(nèi)互聯(lián)網(wǎng)行業(yè)里面最早接觸大數(shù)據(jù)領(lǐng)域的互聯(lián)網(wǎng)廠商之一，從05年就開(kāi)始接觸 Hadoop 架構(gòu)作為大數(shù)據(jù)處理平臺(tái)。當(dāng)時(shí)主要功能是數(shù)據(jù)的存儲(chǔ)和采集，使用 MapReduce 進(jìn)行數(shù)據(jù)處理，使用 Hive 和 HBase 進(jìn)行離線和實(shí)時(shí)數(shù)據(jù)查詢?nèi)蝿?wù)，數(shù)據(jù)輸出使用 Oracle 的 BI 系統(tǒng)實(shí)現(xiàn)。隨著技術(shù)的不斷發(fā)展，到18年逐漸過(guò)渡到基于 Flink + Kafka + ClickHouse 以及網(wǎng)易杭研自研的猛犸平臺(tái)組建的一個(gè)批流合一的數(shù)據(jù)平臺(tái)。ClickHouse 作為 ODS 基礎(chǔ)數(shù)倉(cāng)，主要用來(lái)支持實(shí)時(shí)性的查詢?nèi)蝿?wù)，猛犸平臺(tái)主要負(fù)責(zé)任務(wù)的編排和調(diào)度，自研的數(shù)據(jù)報(bào)表系統(tǒng)進(jìn)行數(shù)據(jù)的呈現(xiàn)。隨著業(yè)務(wù)深入的發(fā)展，現(xiàn)有的架構(gòu)在一些特殊的場(chǎng)合或需求下，有些力不從心。包括一些跨表的或者復(fù)雜度較高的查詢，以及一些高并發(fā)的場(chǎng)景，還有一些大數(shù)據(jù)的熱點(diǎn)更新的場(chǎng)景，現(xiàn)有的架構(gòu)都沒(méi)有辦法做到滿意。網(wǎng)易郵箱從21年開(kāi)始引入了 StarRocks，作為下一代數(shù)據(jù)引擎架構(gòu)，解決高并發(fā)查詢輸出，復(fù)雜事務(wù)跨表查詢，數(shù)據(jù)熱更新支持等問(wèn)題。2為什么引入 StarRocks網(wǎng)易郵箱為什么會(huì)引入 StarRocks，這要從業(yè)務(wù)痛點(diǎn)說(shuō)起。首先，從資源方面來(lái)說(shuō)，網(wǎng)易郵箱因?yàn)橛脩袅亢蛿?shù)據(jù)量都非常大，資源顯得有些不足，造成 Kafka 和 ClickHouse，以及運(yùn)算機(jī)器本身等，經(jīng)常會(huì)出現(xiàn)一些因?yàn)閴毫^(guò)大而產(chǎn)生的報(bào)警，影響數(shù)據(jù)業(yè)務(wù)的開(kāi)展和數(shù)據(jù)處理任務(wù)的開(kāi)發(fā)。其次，因?yàn)楝F(xiàn)有架構(gòu)里面會(huì)同時(shí)存在多個(gè)數(shù)據(jù)平臺(tái)，每個(gè)平臺(tái)都要相應(yīng)的運(yùn)維人員介入，造成運(yùn)維成本和采購(gòu)費(fèi)用居高不下。再次，在數(shù)據(jù)需求方面，當(dāng)前的架構(gòu)與一些業(yè)務(wù)需求不匹配，主要體現(xiàn)在包括離線實(shí)時(shí)，和一些高并發(fā)以及跨表的查詢，都沒(méi)有一勞永逸的方案。同時(shí)，作為移動(dòng)互聯(lián)網(wǎng)的一個(gè)永恒不變的矛盾，產(chǎn)品對(duì)于數(shù)據(jù)需求的緊迫性，當(dāng)前的架構(gòu)沒(méi)有辦法很好的快速支持。另外，在數(shù)據(jù)開(kāi)發(fā)方面，由于郵箱的一些歷史原因，一些比較老舊的基礎(chǔ)服務(wù)的日志，開(kāi)發(fā)的時(shí)候并沒(méi)有考慮到數(shù)據(jù)統(tǒng)計(jì)方面的需求，這些日志的格式參差不齊，對(duì)數(shù)據(jù)清洗以及下游的數(shù)據(jù)存儲(chǔ)的技術(shù)迭代有一定影響。最后，系統(tǒng)的一些鏈路經(jīng)過(guò)多年的迭代之后有些臃腫，而數(shù)據(jù)需求經(jīng)常變化多端，導(dǎo)致開(kāi)發(fā)人員的人力資源不是很夠，造成開(kāi)發(fā)難度的增大。因?yàn)樯鲜鰡?wèn)題，我們迫切需要一個(gè)性能強(qiáng)悍、上手容易、部署簡(jiǎn)單、使用方便、適配性高、安全穩(wěn)定的 OLAP 系統(tǒng)，而 StarRocks 剛好能滿足我們的需求，這是我們?yōu)槭裁匆?StarRocks 的根本原因。3OLAP 指標(biāo)維度對(duì)比我們對(duì)比了國(guó)內(nèi)外一些比較常見(jiàn)的 OLAP 系統(tǒng)，包括 StarRocks、ClickHouse、Impala 以及最基礎(chǔ)的 Kylin。下圖是我們的對(duì)比結(jié)果。我們對(duì)比的維度包括底層技術(shù)、查詢性能、維護(hù)難度、場(chǎng)景適配、兼容易用、安全穩(wěn)定和擴(kuò)展伸縮7個(gè)維度。ClickHouse 作為當(dāng)前比較流行的 OLAP 系統(tǒng)，我們重點(diǎn)分析一下它跟 StarRocks 的一些區(qū)別。底層技術(shù)方面， StarRocks 與 ClickHouse 都是基于 MPP 架構(gòu)實(shí)現(xiàn)。查詢性能方面，StarRocks 的性能在單表查詢上表現(xiàn)良好，多表聯(lián)合查詢方面比 ClickHouse 更有優(yōu)勢(shì)。維護(hù)難度方面，StarRocks 沒(méi)有三方依賴，可以開(kāi)箱即用，而 ClickHouse 的維護(hù)難度在業(yè)界是出了名的高。場(chǎng)景適配方面，我們當(dāng)前的實(shí)際應(yīng)用是實(shí)時(shí)數(shù)倉(cāng)，存儲(chǔ)海量的流水?dāng)?shù)據(jù)。StarRocks 提供了若干種數(shù)據(jù)模型，可以覆蓋大部分的業(yè)務(wù)場(chǎng)景。兼容易用方面，兩者的表現(xiàn)差不多。ClickHouse 支持 HTTP 接口，StarRocks 的優(yōu)勢(shì)則體現(xiàn)在提供多種 IO 的支持，以及對(duì)于 MySQL 協(xié)議的兼容。安全穩(wěn)定方面，分區(qū)分桶和多副本架構(gòu)兩者都支持，最大區(qū)別是 ClickHouse 的分布式高可用是基于ZooKeeper 實(shí)現(xiàn)的。我們?cè)趯?shí)際應(yīng)用中發(fā)現(xiàn)，在高負(fù)載的情況下，ZooKeeper 的表現(xiàn)是比較差的，經(jīng)常出現(xiàn)一些諸如復(fù)制失敗、數(shù)據(jù)丟失的情況。StarRocks 則是基于自研的 BDBJE 來(lái)實(shí)現(xiàn)，在我們的實(shí)際應(yīng)用過(guò)程中并沒(méi)有發(fā)現(xiàn)它出現(xiàn)類似 ClickHouse 那樣的數(shù)據(jù)異常的問(wèn)題。擴(kuò)展伸縮方面， StarRocks 的優(yōu)勢(shì)主要體現(xiàn)在它可以對(duì)每一個(gè)分區(qū)來(lái)靈活的定制它的數(shù)據(jù)擴(kuò)容的方案，同時(shí)它在擴(kuò)容之后，可以自動(dòng)實(shí)現(xiàn)數(shù)據(jù)均衡，相對(duì)來(lái)說(shuō) ClickHouse 則需要人工介入來(lái)處理。經(jīng)過(guò)以上7大方面的對(duì)比， StarRocks 在各方面的均衡表現(xiàn)，都非常適合作為網(wǎng)易郵箱的下一代 OLAP 系統(tǒng)的選型。
#03
系統(tǒng)架構(gòu)1系統(tǒng)架構(gòu)描述下圖左邊就是網(wǎng)易郵箱大數(shù)據(jù)處理系統(tǒng)的系統(tǒng)結(jié)構(gòu)圖，從左到右，從下到上可以分為5個(gè)層次。
左下角是數(shù)據(jù)采集層，它主要的任務(wù)就是將分布在各個(gè)服務(wù)器上的日志數(shù)據(jù)，通過(guò) Flume 采集匯總到數(shù)據(jù)處理層，按照不同的類型諸如離線的或者是實(shí)時(shí)的分別存儲(chǔ)到對(duì)應(yīng)的存儲(chǔ)介質(zhì)上。再上一層是數(shù)據(jù)加工層，對(duì)應(yīng)不同的數(shù)據(jù)類型，離線數(shù)據(jù)使用 MapReduce 任務(wù)處理，實(shí)時(shí)數(shù)據(jù)使用 Flink 任務(wù)處理，然后把數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)存儲(chǔ)層。再往上是數(shù)據(jù)存儲(chǔ)層，最原始的沒(méi)有經(jīng)過(guò)任何加工的 ODS 數(shù)據(jù)會(huì)存儲(chǔ)到 HDFS 上，經(jīng)過(guò)一定的清洗形成的結(jié)構(gòu)化數(shù)據(jù)會(huì)放到 ClickHouse 的實(shí)時(shí)數(shù)倉(cāng)里面。從21年開(kāi)始，數(shù)據(jù)存儲(chǔ)層引入了 StarRocks 把 ClickHouse 實(shí)時(shí)數(shù)倉(cāng)上的基礎(chǔ)數(shù)據(jù)進(jìn)行聚合提煉，以應(yīng)對(duì)更深層更復(fù)雜的查詢，和一些實(shí)時(shí)性的查詢。在數(shù)據(jù)存儲(chǔ)層上面就是數(shù)據(jù)應(yīng)用層了，應(yīng)用層主要包括了數(shù)據(jù)大盤報(bào)表的輸出，以及給下游業(yè)務(wù)提供的實(shí)時(shí)查詢的業(yè)務(wù)接口。右面綠色部分是數(shù)據(jù)治理框架，包括數(shù)據(jù)鏈路的監(jiān)控，實(shí)時(shí)和離線任務(wù)的配套 Sloth，以及 Azkaban 的模型，還有我們出于對(duì)數(shù)據(jù)血緣方面的考慮，自己研發(fā)的一套任務(wù)執(zhí)行框架，以及對(duì)應(yīng)的 Kibana 和 Promethues 的數(shù)據(jù)監(jiān)控系統(tǒng)。這5大部分共同組成了一個(gè)完整的大數(shù)據(jù)處理架構(gòu)。2StarRocks 使用場(chǎng)景StarRocks 在網(wǎng)易郵箱的實(shí)際業(yè)務(wù)中的使用場(chǎng)景，可以分為4個(gè)類型：
下圖中的3是我們生產(chǎn)環(huán)境中的一個(gè) StarRocks 集群，包括三臺(tái)物理機(jī)。
圖中的1是一個(gè)跨表查詢的結(jié)果，在若干個(gè)數(shù)據(jù)規(guī)模超過(guò)億級(jí)的大表上進(jìn)行一個(gè)聯(lián)合查詢，大概兩分鐘左右能夠產(chǎn)生結(jié)果，這是比較強(qiáng)悍的一個(gè)跨表查詢，解決掉了我們以往的比較頭痛的問(wèn)題。
#04
應(yīng)用案例1用戶登錄處理鏈路
左邊是數(shù)據(jù)鏈路的一個(gè)示意圖，用戶登錄的行為數(shù)據(jù)，經(jīng)過(guò) Kafka 以及 Flink 的實(shí)時(shí)處理之后，存儲(chǔ)到 StarRocks 數(shù)倉(cāng)，然后同時(shí)支持下游4個(gè)不同的數(shù)據(jù)需求。
數(shù)據(jù)的落盤存儲(chǔ)。
基于存儲(chǔ)之后的數(shù)據(jù)，在 T+1 的時(shí)間窗口進(jìn)行數(shù)據(jù)的統(tǒng)計(jì)，最終生成 OKR 指標(biāo)，輸出到下游的數(shù)據(jù)報(bào)表系統(tǒng)。
實(shí)時(shí)的用戶登錄，我們要求進(jìn)行一些監(jiān)控，來(lái)保證用戶的敏感行為能夠自動(dòng)聚合疊加，到達(dá)一定閾值之后，觸發(fā)一些風(fēng)控處理。
針對(duì)需要實(shí)時(shí)查詢的數(shù)據(jù)，提供一個(gè)查詢接口，供下游業(yè)務(wù)調(diào)用。
左上角的圖是網(wǎng)易郵箱比較常見(jiàn)的推廣活動(dòng)的節(jié)點(diǎn)鏈路的示意圖，它包括6個(gè)數(shù)據(jù)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都會(huì)按照用戶的操作行為，將數(shù)據(jù)反饋到后臺(tái)的數(shù)倉(cāng)里面。
我們的任務(wù)就是根據(jù)這些反饋的素材數(shù)據(jù)，建立如右圖這樣的漏斗模型，方便產(chǎn)品和推廣人員直觀的分析出推廣鏈路里面的短板是哪個(gè)環(huán)節(jié)，用戶在每個(gè)環(huán)節(jié)里流失的具體原因是什么。在模型的建立過(guò)程中充分利用了 StarRocks 的跨表查詢的能力，能夠根據(jù)用戶ID以及一些時(shí)間參數(shù)，對(duì)6個(gè)不同節(jié)點(diǎn)上反饋的數(shù)據(jù)進(jìn)行串聯(lián)，最終生成大寬表來(lái)支持模型的建立。#05
未來(lái)展望1StarRocks 的優(yōu)勢(shì)和展望StarRocks 的優(yōu)勢(shì)包括開(kāi)箱即用、投入較少、功能強(qiáng)大、覆蓋的場(chǎng)景多、架構(gòu)先進(jìn)簡(jiǎn)潔、迭代迅速、支持到位等。這里重點(diǎn)說(shuō)一下我們的展望。首先，網(wǎng)易郵箱作為一個(gè)歷史比較久的業(yè)務(wù)，有大量的數(shù)據(jù)存儲(chǔ)在一些比較老舊的數(shù)據(jù)架構(gòu)里面，如何快速并且低成本的將這些數(shù)據(jù)遷移到 StarRocks 平臺(tái)上，同時(shí)能夠保證遷移過(guò)程中數(shù)據(jù)的安全穩(wěn)定，并且不影響正常的數(shù)據(jù)鏈路，很希望能夠看到 StarRocks 有相應(yīng)的支持。其次，對(duì)于像AI算法之類的數(shù)據(jù)挖掘的需求，也希望看到 StarRocks 的支持。再者，網(wǎng)易郵件里面存儲(chǔ)了很多圖片文件視頻等非結(jié)構(gòu)化的內(nèi)容，如果要把它們?nèi)窟w移到 StarRocks 存儲(chǔ)系統(tǒng)里面來(lái)，也希望能有一個(gè)類似數(shù)據(jù)湖的解決方案。最后，在可視化工具方面，也希望能夠看到 StarRocks 的有力支持。
