1)數(shù)據(jù)采集

服務(wù)器日志或者App日志通過Flume收集埋點(diǎn)日志，數(shù)據(jù)同時(shí)分發(fā)到離線存儲(chǔ)S3和實(shí)時(shí)存儲(chǔ)kafka;線上業(yè)務(wù)數(shù)據(jù)庫通過Canal實(shí)時(shí)采集MySQL binlog等信息。

2)數(shù)據(jù)存儲(chǔ)加工

離線數(shù)據(jù)處理：利用Hive/Spark高可擴(kuò)展的批處理能力承擔(dān)所有的離線數(shù)倉的ETL和數(shù)據(jù)模型加工的工作。

實(shí)時(shí)數(shù)據(jù)處理：Flink完成實(shí)時(shí)側(cè)數(shù)據(jù)的ETL(包括維度豐富，雙流Join，實(shí)時(shí)匯總);離線表通過調(diào)度平臺(tái)同步到ClickHouse/DorisDB，F(xiàn)link實(shí)現(xiàn)了ClickHouse和DorisDB的sink connector，落地到DorisDB或ClickHouse。

3)數(shù)據(jù)共享

數(shù)據(jù)共享層的主要提供對(duì)外服務(wù)的底層數(shù)據(jù)存儲(chǔ),離線或者實(shí)時(shí)的數(shù)據(jù)寫入相關(guān)的數(shù)據(jù)庫組件中，面向多種服務(wù)，不同場(chǎng)景提供查詢能力。

數(shù)據(jù)共享層主要有TiDB/Hbase/ClickHouse/DorisDB。通過DorisDB和ClickHouse提供的高速OLAP查詢能力，在應(yīng)用側(cè)承接了報(bào)表平臺(tái)，提供即席分析的平臺(tái)，對(duì)開發(fā)側(cè)提供數(shù)據(jù)接口，以及實(shí)現(xiàn)多個(gè)數(shù)據(jù)產(chǎn)品(比如流量分析平臺(tái)，用戶標(biāo)簽平臺(tái))。

4)應(yīng)用層

應(yīng)用層主要為面向管理和運(yùn)營人員的報(bào)表，具有并發(fā)、延遲、需求更新頻繁等要求，面向數(shù)據(jù)分析師的即席查詢，要求支持復(fù)雜sql處理、海量數(shù)據(jù)查詢等能力。

2、各OLAP分析工具選型比較

1)Clickhouse：

優(yōu)點(diǎn)：

·很強(qiáng)的單表查詢性能，適合基于大寬表的靈活即席查詢。

·包含豐富的MergeTree Family，支持預(yù)聚合。

·非常適合大規(guī)模日志明細(xì)數(shù)據(jù)寫入分析。

缺點(diǎn)：

·不支持真正的刪除與更新。

·Join方式不是很友好。

·并發(fā)能力比較低。

·MergeTree合并不完全。

2)DorisDB：

優(yōu)點(diǎn)：

·單表查詢和多表查詢性能都很強(qiáng)，可以同時(shí)較好支持寬表查詢場(chǎng)景和復(fù)雜多表查詢。

支持高并發(fā)查詢。

·支持實(shí)時(shí)數(shù)據(jù)微批ETL處理。

·流式和批量數(shù)據(jù)寫入都能都比較強(qiáng)。

·兼容MySQL協(xié)議和標(biāo)準(zhǔn)SQL。

缺點(diǎn)：

·周邊生態(tài)比較不完善。

·部分SQL語法不支持。

3)TiDB/TiFlash：

優(yōu)點(diǎn)：

·支持更新/刪除。

·兼顧了OLTP的需求。

·支持Flink ExactlyOnce語意，支持冪等。

缺點(diǎn)：

·查詢性能弱，無法較好支持OLAP查詢場(chǎng)景。

·不支持實(shí)時(shí)預(yù)聚合。

·TiFlash暫時(shí)不支持所有的SQL寫法以及函數(shù)。

三、DorisDB在廣告數(shù)據(jù)中心的應(yīng)用實(shí)踐

1、業(yè)務(wù)場(chǎng)景概述

廣告業(yè)務(wù)的核心數(shù)據(jù)有兩大塊：一個(gè)是廣告的曝光點(diǎn)擊流，即所有廣告單元的展點(diǎn)銷信息;第二個(gè)是廣告效果歸因數(shù)據(jù)，比如說在小紅書站內(nèi)的訂單轉(zhuǎn)化，相關(guān)表單提交，筆記的點(diǎn)贊、收藏、加關(guān)注等參與程度。

基于這些數(shù)據(jù)，根據(jù)不同的業(yè)務(wù)場(chǎng)景需求，實(shí)時(shí)匯總出相關(guān)業(yè)務(wù)統(tǒng)計(jì)指標(biāo)，對(duì)外提供查詢分析服務(wù)。

2、原有解決方案

1)技術(shù)架構(gòu)

在引入DorisDB之前，是用大量Flink任務(wù)進(jìn)行寫入MySQL/Redis/HDFS/ClickHouse，以達(dá)到數(shù)據(jù)的落地。

Flink中核心處理邏輯有幾類：

·前端用戶廣告展示信息事件流和后端算法推薦流雙流關(guān)聯(lián)并去重，完善廣告信息。

·接入反作弊，清除作弊事件。

·按不同業(yè)務(wù)場(chǎng)景需求匯總結(jié)果寫入不同的數(shù)據(jù)庫組件中。

2)技術(shù)痛點(diǎn)

原有架構(gòu)主要有以下問題：

·數(shù)據(jù)邏輯沒有很好做歸攏合并，維護(hù)工作量大，新需求無法快速響應(yīng)。

·Clickhouse的并發(fā)能力不足以及擴(kuò)容復(fù)雜度在可見未來會(huì)成為整體廣告系統(tǒng)瓶頸。

·因?yàn)镕link層邏輯散落，由大量小的Flink任務(wù)構(gòu)成，因此導(dǎo)致整個(gè)架構(gòu)無法滿足高可用要求，只要任何一個(gè)任務(wù)出現(xiàn)問題，都會(huì)影響線上業(yè)務(wù)。

3、基于DorisDB的解決方案

因此我們希望對(duì)原有體系進(jìn)行優(yōu)化，核心思路是利用一個(gè)OLAP引擎進(jìn)行這一層的統(tǒng)一，對(duì)OLAP引擎的要求是比較高的：

·能支撐大吞吐量的數(shù)據(jù)寫入要求。

·可以支持多維度組合的靈活查詢，TP99在100ms以下。

·有實(shí)時(shí)匯總上卷的能力，提高查詢性能，支持qps達(dá)到上萬的要求。

·通過Binlog實(shí)時(shí)同步MySQL的數(shù)據(jù)，并及時(shí)對(duì)數(shù)據(jù)進(jìn)行封裝。

·比較好的支持多表關(guān)聯(lián)。

經(jīng)過大量調(diào)研，DorisDB比較契合廣告數(shù)據(jù)中心的整體要求。基于DorisDB本身高效的查詢能力，支持高QPS的特性，可以為廣告的算法策略、廣告實(shí)時(shí)計(jì)費(fèi)、廣告平臺(tái)實(shí)時(shí)的數(shù)據(jù)報(bào)告提供一體化服務(wù)。

新架構(gòu)具備以下優(yōu)點(diǎn)：

·結(jié)構(gòu)清晰，F(xiàn)link專注于數(shù)據(jù)的清洗，業(yè)務(wù)邏輯計(jì)算從Flink遷到DorisDB內(nèi)實(shí)現(xiàn)，DorisDB就是數(shù)據(jù)業(yè)務(wù)邏輯的終點(diǎn)。

·可以維護(hù)統(tǒng)一的數(shù)據(jù)口徑，一份數(shù)據(jù)輸入，一套廣告統(tǒng)計(jì)口徑輸出。

·在底層實(shí)現(xiàn)DorisDB主備雙活，更好的支持高QPS場(chǎng)景。

1)數(shù)據(jù)表設(shè)計(jì)

數(shù)據(jù)模型設(shè)計(jì)

DorisDB本身提供三種數(shù)據(jù)模型：明細(xì)模型/聚合模型/更新模型。對(duì)小紅書廣告業(yè)務(wù)來說，三種數(shù)據(jù)模型各盡其用：

·廣告曝光點(diǎn)擊流寫入聚合模型，按照業(yè)務(wù)所需要的維度，如廣告主、廣告類型、創(chuàng)意，廣告單元，搜索詞，地域，用戶屬性等設(shè)計(jì)聚合的所有維度，根據(jù)所需要的指標(biāo)進(jìn)行聚合。

·廣告?zhèn)群蠖擞泻芏嗟木€上MySQL，通過DorisDB更新模型接入MySQL進(jìn)行實(shí)時(shí)的表更新。

·在Hadoop離線數(shù)倉中還定期統(tǒng)計(jì)了一些數(shù)據(jù)報(bào)告同步到DorisDB中，這些數(shù)據(jù)使用了DorisDB的明細(xì)模型。

數(shù)據(jù)分區(qū)/分桶

DorisDB提供的數(shù)據(jù)分區(qū)功能，可以很好的提升廣告場(chǎng)景下查詢的性能。例如，廣告?zhèn)炔樵兂Ｒ姷囊环N查詢場(chǎng)景，是查詢過去某一段時(shí)間內(nèi)的數(shù)據(jù)，我們可以在DorisDB中根據(jù)時(shí)間進(jìn)行分區(qū)，過濾掉不必要的分區(qū)數(shù)據(jù)。另外，廣告查詢會(huì)根據(jù)廣告主進(jìn)行篩選，我們將廣告主ID作為排序鍵的最前列，就可以快速定位到廣告主的數(shù)據(jù)，DorisDB還支持按照廣告主ID進(jìn)行Hash分桶，減少整個(gè)查詢的數(shù)據(jù)量進(jìn)行快速定位，這對(duì)高并發(fā)場(chǎng)景也具有非常大的意義，盡量減少了查詢語句所覆蓋的數(shù)據(jù)范圍，提高了并發(fā)能力。

物化視圖

我們利用DorisDB物化視圖能夠?qū)崟r(shí)、批量構(gòu)建，靈活增加刪除以及透明化使用的特性，建立了基于廣告主粒度、基于用戶特征粒度、基于廣告單元粒度、基于具體創(chuàng)意粒度的物化視圖?；谶@些物化視圖，可以極大加速查詢。

2)數(shù)據(jù)導(dǎo)入

實(shí)時(shí)的數(shù)據(jù)導(dǎo)入分為兩種：

·有ETL處理需求的，會(huì)利用Flink進(jìn)行ETL邏輯轉(zhuǎn)化，使用Flink DorisDB Connector寫入DorisDB。

·在實(shí)時(shí)數(shù)倉公共層的，配置Routine Load任務(wù)，將數(shù)據(jù)10s一個(gè)batch寫入DorisDB表中。

離線數(shù)據(jù)報(bào)告導(dǎo)入DorisDB：

·在DorisDB提供的原生的Broker Load基礎(chǔ)上在小紅書數(shù)倉的調(diào)度平臺(tái)上封裝了導(dǎo)數(shù)模版，通過界面化配置的方式，將離線數(shù)倉的表導(dǎo)入到DorisDB中。

3)數(shù)據(jù)查詢

在我們的查詢場(chǎng)景中，廣告主業(yè)務(wù)查詢服務(wù)對(duì)查詢并發(fā)度要求很高。DorisDB采用的是MPP查詢架構(gòu)，底層數(shù)據(jù)按照Range和Hash兩級(jí)分片，非常適合廣告主業(yè)務(wù)的查詢場(chǎng)景。

內(nèi)部做的線上查詢壓測(cè)結(jié)果，每個(gè)FE能到2000左右的QPS，整個(gè)集群能提供上萬的QPS，TP99的查詢?cè)?00毫秒以下。

4)系統(tǒng)運(yùn)維

廣告數(shù)據(jù)中心是非常核心的一個(gè)線上服務(wù)，因此對(duì)高可用及靈活擴(kuò)容能力有非常高的要求。DorisDB支持fe/be多副本，沒有單節(jié)點(diǎn)問題，當(dāng)有節(jié)點(diǎn)故障的時(shí)候也可以保證整個(gè)集群的高可用。另外，DorisDB在大數(shù)據(jù)規(guī)模下可以進(jìn)行在線彈性擴(kuò)展，在擴(kuò)容時(shí)無需下線，不會(huì)影響到在線業(yè)務(wù)，這個(gè)能力也是我們非常需要的。

總結(jié)

小紅書從今年年初開始調(diào)研引入DorisDB，當(dāng)前已經(jīng)有五個(gè)DorisDB集群在穩(wěn)定運(yùn)行中，其中有兩個(gè)開始穩(wěn)定提供線上服務(wù)，三個(gè)還在試運(yùn)行。引入DorisDB后，實(shí)現(xiàn)了數(shù)據(jù)服務(wù)統(tǒng)一化，大大簡(jiǎn)化了實(shí)時(shí)數(shù)據(jù)處理鏈路，同時(shí)也能保障較高的查詢并發(fā)和較低的響應(yīng)延遲要求，之后將用來提升更多業(yè)務(wù)場(chǎng)景的數(shù)據(jù)服務(wù)和查詢能力。最后，感謝鼎石科技的大力支持，也期望DorisDB作為性能強(qiáng)悍的新一代MPP數(shù)據(jù)庫引領(lǐng)者越來越好!(作者：吳浩亮 小紅書大數(shù)據(jù)團(tuán)隊(duì)，數(shù)據(jù)倉庫架構(gòu)師)

songjy