1)數(shù)據(jù)采集
服務(wù)器日志或者App日志通過Flume收集埋點日志，數(shù)據(jù)同時分發(fā)到離線存儲S3和實時存儲kafka;線上業(yè)務(wù)數(shù)據(jù)庫通過Canal實時采集MySQL binlog等信息。
2)數(shù)據(jù)存儲加工
離線數(shù)據(jù)處理：利用Hive/Spark高可擴展的批處理能力承擔所有的離線數(shù)倉的ETL和數(shù)據(jù)模型加工的工作。
實時數(shù)據(jù)處理：Flink完成實時側(cè)數(shù)據(jù)的ETL(包括維度豐富，雙流Join，實時匯總);離線表通過調(diào)度平臺同步到ClickHouse/DorisDB，F(xiàn)link實現(xiàn)了ClickHouse和DorisDB的sink connector，落地到DorisDB或ClickHouse。
3)數(shù)據(jù)共享
數(shù)據(jù)共享層的主要提供對外服務(wù)的底層數(shù)據(jù)存儲,離線或者實時的數(shù)據(jù)寫入相關(guān)的數(shù)據(jù)庫組件中，面向多種服務(wù)，不同場景提供查詢能力。
數(shù)據(jù)共享層主要有TiDB/Hbase/ClickHouse/DorisDB。通過DorisDB和ClickHouse提供的高速OLAP查詢能力，在應(yīng)用側(cè)承接了報表平臺，提供即席分析的平臺，對開發(fā)側(cè)提供數(shù)據(jù)接口，以及實現(xiàn)多個數(shù)據(jù)產(chǎn)品(比如流量分析平臺，用戶標簽平臺)。
4)應(yīng)用層
應(yīng)用層主要為面向管理和運營人員的報表，具有并發(fā)、延遲、需求更新頻繁等要求，面向數(shù)據(jù)分析師的即席查詢，要求支持復(fù)雜sql處理、海量數(shù)據(jù)查詢等能力。
2、各OLAP分析工具選型比較
1)Clickhouse：
優(yōu)點：
·很強的單表查詢性能，適合基于大寬表的靈活即席查詢。
·包含豐富的MergeTree Family，支持預(yù)聚合。
·非常適合大規(guī)模日志明細數(shù)據(jù)寫入分析。
缺點：
·不支持真正的刪除與更新。
·Join方式不是很友好。
·并發(fā)能力比較低。
·MergeTree合并不完全。
2)DorisDB：
優(yōu)點：
·單表查詢和多表查詢性能都很強，可以同時較好支持寬表查詢場景和復(fù)雜多表查詢。
支持高并發(fā)查詢。
·支持實時數(shù)據(jù)微批ETL處理。
·流式和批量數(shù)據(jù)寫入都能都比較強。
·兼容MySQL協(xié)議和標準SQL。
缺點：
·周邊生態(tài)比較不完善。
·部分SQL語法不支持。
3)TiDB/TiFlash：
優(yōu)點：
·支持更新/刪除。
·兼顧了OLTP的需求。
·支持Flink ExactlyOnce語意，支持冪等。
缺點：
·查詢性能弱，無法較好支持OLAP查詢場景。
·不支持實時預(yù)聚合。
·TiFlash暫時不支持所有的SQL寫法以及函數(shù)。
三、DorisDB在廣告數(shù)據(jù)中心的應(yīng)用實踐
1、業(yè)務(wù)場景概述
廣告業(yè)務(wù)的核心數(shù)據(jù)有兩大塊：一個是廣告的曝光點擊流，即所有廣告單元的展點銷信息;第二個是廣告效果歸因數(shù)據(jù)，比如說在小紅書站內(nèi)的訂單轉(zhuǎn)化，相關(guān)表單提交，筆記的點贊、收藏、加關(guān)注等參與程度。
基于這些數(shù)據(jù)，根據(jù)不同的業(yè)務(wù)場景需求，實時匯總出相關(guān)業(yè)務(wù)統(tǒng)計指標，對外提供查詢分析服務(wù)。
2、原有解決方案
1)技術(shù)架構(gòu)
在引入DorisDB之前，是用大量Flink任務(wù)進行寫入MySQL/Redis/HDFS/ClickHouse，以達到數(shù)據(jù)的落地。
Flink中核心處理邏輯有幾類：
·前端用戶廣告展示信息事件流和后端算法推薦流雙流關(guān)聯(lián)并去重，完善廣告信息。
·接入反作弊，清除作弊事件。
·按不同業(yè)務(wù)場景需求匯總結(jié)果寫入不同的數(shù)據(jù)庫組件中。
2)技術(shù)痛點
原有架構(gòu)主要有以下問題：
·數(shù)據(jù)邏輯沒有很好做歸攏合并，維護工作量大，新需求無法快速響應(yīng)。
·Clickhouse的并發(fā)能力不足以及擴容復(fù)雜度在可見未來會成為整體廣告系統(tǒng)瓶頸。
·因為Flink層邏輯散落，由大量小的Flink任務(wù)構(gòu)成，因此導(dǎo)致整個架構(gòu)無法滿足高可用要求，只要任何一個任務(wù)出現(xiàn)問題，都會影響線上業(yè)務(wù)。
3、基于DorisDB的解決方案
因此我們希望對原有體系進行優(yōu)化，核心思路是利用一個OLAP引擎進行這一層的統(tǒng)一，對OLAP引擎的要求是比較高的：
·能支撐大吞吐量的數(shù)據(jù)寫入要求。
·可以支持多維度組合的靈活查詢，TP99在100ms以下。
·有實時匯總上卷的能力，提高查詢性能，支持qps達到上萬的要求。
·通過Binlog實時同步MySQL的數(shù)據(jù)，并及時對數(shù)據(jù)進行封裝。
·比較好的支持多表關(guān)聯(lián)。
經(jīng)過大量調(diào)研，DorisDB比較契合廣告數(shù)據(jù)中心的整體要求。基于DorisDB本身高效的查詢能力，支持高QPS的特性，可以為廣告的算法策略、廣告實時計費、廣告平臺實時的數(shù)據(jù)報告提供一體化服務(wù)。
新架構(gòu)具備以下優(yōu)點：
·結(jié)構(gòu)清晰，F(xiàn)link專注于數(shù)據(jù)的清洗，業(yè)務(wù)邏輯計算從Flink遷到DorisDB內(nèi)實現(xiàn)，DorisDB就是數(shù)據(jù)業(yè)務(wù)邏輯的終點。
·可以維護統(tǒng)一的數(shù)據(jù)口徑，一份數(shù)據(jù)輸入，一套廣告統(tǒng)計口徑輸出。
·在底層實現(xiàn)DorisDB主備雙活，更好的支持高QPS場景。
1)數(shù)據(jù)表設(shè)計
數(shù)據(jù)模型設(shè)計
DorisDB本身提供三種數(shù)據(jù)模型：明細模型/聚合模型/更新模型。對小紅書廣告業(yè)務(wù)來說，三種數(shù)據(jù)模型各盡其用：
·廣告曝光點擊流寫入聚合模型，按照業(yè)務(wù)所需要的維度，如廣告主、廣告類型、創(chuàng)意，廣告單元，搜索詞，地域，用戶屬性等設(shè)計聚合的所有維度，根據(jù)所需要的指標進行聚合。
·廣告?zhèn)群蠖擞泻芏嗟木€上MySQL，通過DorisDB更新模型接入MySQL進行實時的表更新。
·在Hadoop離線數(shù)倉中還定期統(tǒng)計了一些數(shù)據(jù)報告同步到DorisDB中，這些數(shù)據(jù)使用了DorisDB的明細模型。
數(shù)據(jù)分區(qū)/分桶
DorisDB提供的數(shù)據(jù)分區(qū)功能，可以很好的提升廣告場景下查詢的性能。例如，廣告?zhèn)炔樵兂Ｒ姷囊环N查詢場景，是查詢過去某一段時間內(nèi)的數(shù)據(jù)，我們可以在DorisDB中根據(jù)時間進行分區(qū)，過濾掉不必要的分區(qū)數(shù)據(jù)。另外，廣告查詢會根據(jù)廣告主進行篩選，我們將廣告主ID作為排序鍵的最前列，就可以快速定位到廣告主的數(shù)據(jù)，DorisDB還支持按照廣告主ID進行Hash分桶，減少整個查詢的數(shù)據(jù)量進行快速定位，這對高并發(fā)場景也具有非常大的意義，盡量減少了查詢語句所覆蓋的數(shù)據(jù)范圍，提高了并發(fā)能力。
物化視圖
我們利用DorisDB物化視圖能夠?qū)崟r、批量構(gòu)建，靈活增加刪除以及透明化使用的特性，建立了基于廣告主粒度、基于用戶特征粒度、基于廣告單元粒度、基于具體創(chuàng)意粒度的物化視圖?；谶@些物化視圖，可以極大加速查詢。
2)數(shù)據(jù)導(dǎo)入
實時的數(shù)據(jù)導(dǎo)入分為兩種：
·有ETL處理需求的，會利用Flink進行ETL邏輯轉(zhuǎn)化，使用Flink DorisDB Connector寫入DorisDB。
·在實時數(shù)倉公共層的，配置Routine Load任務(wù)，將數(shù)據(jù)10s一個batch寫入DorisDB表中。
離線數(shù)據(jù)報告導(dǎo)入DorisDB：
·在DorisDB提供的原生的Broker Load基礎(chǔ)上在小紅書數(shù)倉的調(diào)度平臺上封裝了導(dǎo)數(shù)模版，通過界面化配置的方式，將離線數(shù)倉的表導(dǎo)入到DorisDB中。
3)數(shù)據(jù)查詢
在我們的查詢場景中，廣告主業(yè)務(wù)查詢服務(wù)對查詢并發(fā)度要求很高。DorisDB采用的是MPP查詢架構(gòu)，底層數(shù)據(jù)按照Range和Hash兩級分片，非常適合廣告主業(yè)務(wù)的查詢場景。
內(nèi)部做的線上查詢壓測結(jié)果，每個FE能到2000左右的QPS，整個集群能提供上萬的QPS，TP99的查詢在100毫秒以下。
4)系統(tǒng)運維
廣告數(shù)據(jù)中心是非常核心的一個線上服務(wù)，因此對高可用及靈活擴容能力有非常高的要求。DorisDB支持fe/be多副本，沒有單節(jié)點問題，當有節(jié)點故障的時候也可以保證整個集群的高可用。另外，DorisDB在大數(shù)據(jù)規(guī)模下可以進行在線彈性擴展，在擴容時無需下線，不會影響到在線業(yè)務(wù)，這個能力也是我們非常需要的。
總結(jié)
小紅書從今年年初開始調(diào)研引入DorisDB，當前已經(jīng)有五個DorisDB集群在穩(wěn)定運行中，其中有兩個開始穩(wěn)定提供線上服務(wù)，三個還在試運行。引入DorisDB后，實現(xiàn)了數(shù)據(jù)服務(wù)統(tǒng)一化，大大簡化了實時數(shù)據(jù)處理鏈路，同時也能保障較高的查詢并發(fā)和較低的響應(yīng)延遲要求，之后將用來提升更多業(yè)務(wù)場景的數(shù)據(jù)服務(wù)和查詢能力。最后，感謝鼎石科技的大力支持，也期望DorisDB作為性能強悍的新一代MPP數(shù)據(jù)庫引領(lǐng)者越來越好!(作者：吳浩亮 小紅書大數(shù)據(jù)團隊，數(shù)據(jù)倉庫架構(gòu)師)
