小紅書(shū)數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)師 @ 吳浩亮：小紅書(shū)引入DorisDB構(gòu)建全新統(tǒng)一的數(shù)據(jù)服務(wù)平臺(tái)

小紅書(shū)是年輕人的生活記錄、分享平臺(tái)，用戶可以通過(guò)短視頻、圖文等形式記錄生活點(diǎn)滴，分享生活方式。在2017年后，隨著業(yè)務(wù)類型和用戶體量的爆炸式增長(zhǎng)，各類數(shù)據(jù)分析的需求以及應(yīng)用系統(tǒng)的數(shù)據(jù)需求快速出現(xiàn)，例如：商業(yè)智能分析，數(shù)據(jù)應(yīng)用報(bào)表，用戶行為分析、算法策略數(shù)據(jù)等。

小紅書(shū)大數(shù)據(jù)團(tuán)隊(duì)逐步引入了多種OLAP分析引擎來(lái)更好的滿足需求。DorisDB采用了全面向量化的計(jì)算技術(shù)，是性能非常強(qiáng)悍的新一代MPP數(shù)據(jù)庫(kù)。通過(guò)引入DorisDB，小紅書(shū)構(gòu)建了全新的統(tǒng)一數(shù)據(jù)服務(wù)平臺(tái)，大大降低了數(shù)據(jù)鏈路開(kāi)發(fā)復(fù)雜性，提升了高并發(fā)極速查詢能力。“  

OLAP引擎在小紅書(shū)的演進(jìn)史第一階段，在2017年之前，數(shù)據(jù)總量還不是特別大，這個(gè)階段使用AWS的Redshift，此時(shí)數(shù)倉(cāng)體系還沒(méi)有完全建立，很多數(shù)據(jù)需求的實(shí)現(xiàn)都是用短平快、煙囪式開(kāi)發(fā)的方式來(lái)滿足。數(shù)據(jù)ETL、數(shù)倉(cāng)模型到最后報(bào)表端展現(xiàn)，在Redshift中一站式完成。但隨著業(yè)務(wù)復(fù)雜度不斷提升，以及數(shù)據(jù)量的快速增長(zhǎng)，這種模式很快遇到了瓶頸。主要有以下問(wèn)題：

• Redshift無(wú)法在不影響線上查詢性能的前提下彈性擴(kuò)展，一旦涉及到擴(kuò)容，就會(huì)涉及到數(shù)據(jù)重分布，從而影響集群的性能以及可用性。
• ETL任務(wù)嚴(yán)重影響集群可用性。在Redshift中同時(shí)進(jìn)行ETL任務(wù)的時(shí)候，會(huì)大量搶占資源，從而影響數(shù)據(jù)分析的效率，導(dǎo)致查詢超時(shí)甚至因?yàn)榧贺?fù)載過(guò)大后整個(gè)集群崩潰不可用。
• 沒(méi)有良好的存算分離，數(shù)據(jù)存儲(chǔ)容量存在瓶頸，無(wú)法滿足隨業(yè)務(wù)而快速增長(zhǎng)的數(shù)據(jù)量存儲(chǔ)需求。

第二階段，隨著數(shù)據(jù)倉(cāng)庫(kù)在Hadoop/Hive體系上搭建和完善，ETL任務(wù)全部轉(zhuǎn)移至Hadoop集群，這個(gè)階段使用Presto完成OLAP分析。Presto天然和Hive共享元數(shù)據(jù)信息，且共同使用物理數(shù)據(jù)存儲(chǔ)，即插即用。大量的對(duì)數(shù)倉(cāng)表的靈活查詢使用Presto完成。

第三階段，業(yè)務(wù)實(shí)時(shí)性增強(qiáng)，對(duì)查詢性能的要求不斷升高，同時(shí)許多數(shù)據(jù)應(yīng)用產(chǎn)生。這個(gè)階段引入了ClickHouse，用來(lái)建設(shè)性能更強(qiáng)悍，響應(yīng)時(shí)間更短的數(shù)據(jù)分析平臺(tái)以滿足實(shí)時(shí)性要求。

第四階段，小紅書(shū)大數(shù)據(jù)團(tuán)隊(duì)進(jìn)行了實(shí)時(shí)數(shù)倉(cāng)的整體設(shè)計(jì)和搭建，同時(shí)為統(tǒng)一對(duì)各業(yè)務(wù)團(tuán)隊(duì)提供數(shù)據(jù)接口而構(gòu)建了數(shù)據(jù)服務(wù)平臺(tái)，外接了多個(gè)內(nèi)部或者To B服務(wù)的應(yīng)用系統(tǒng)。既需要做低延時(shí)的復(fù)雜查詢，同時(shí)對(duì)并發(fā)量也有很高的要求。這個(gè)階段我們又根據(jù)場(chǎng)景引入了DorisDB，以滿足以上各類需求。

小紅書(shū)數(shù)據(jù)分析體系架構(gòu)

小紅書(shū)OLAP體系現(xiàn)狀

小紅書(shū)的整個(gè)數(shù)據(jù)分析體系，由數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)加工/數(shù)據(jù)共享和應(yīng)用層組成。

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

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

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

離線數(shù)據(jù)處理：利用Hive/Spark高可擴(kuò)展的批處理能力承擔(dān)所有的離線數(shù)倉(cāng)的ETL和數(shù)據(jù)模型加工的工作。實(shí)時(shí)數(shù)據(jù)處理：Flink完成實(shí)時(shí)側(cè)數(shù)據(jù)的ETL（包括維度豐富，雙流Join，實(shí)時(shí)匯總）；離線表通過(guò)調(diào)度平臺(tái)同步到ClickHouse/DorisDB，F(xiàn)link實(shí)現(xiàn)了ClickHouse和DorisDB的sink connector，落地到DorisDB或ClickHouse。

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

數(shù)據(jù)共享層的主要提供對(duì)外服務(wù)的底層數(shù)據(jù)存儲(chǔ),離線或者實(shí)時(shí)的數(shù)據(jù)寫(xiě)入相關(guān)的數(shù)據(jù)庫(kù)組件中，面向多種服務(wù)，不同場(chǎng)景提供查詢能力。數(shù)據(jù)共享層主要有TiDB/Hbase/ClickHouse/DorisDB。通過(guò)DorisDB和ClickHouse提供的高速OLAP查詢能力，在應(yīng)用側(cè)承接了報(bào)表平臺(tái)，提供即席分析的平臺(tái)，對(duì)開(kāi)發(fā)側(cè)提供數(shù)據(jù)接口，以及實(shí)現(xiàn)多個(gè)數(shù)據(jù)產(chǎn)品（比如流量分析平臺(tái)，用戶標(biāo)簽平臺(tái)）。

應(yīng)用層

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

各OLAP分析工具選型比較

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

• 很強(qiáng)的單表查詢性能，適合基于大寬表的靈活即席查詢。
• 包含豐富的MergeTree Family，支持預(yù)聚合。
• 非常適合大規(guī)模日志明細(xì)數(shù)據(jù)寫(xiě)入分析。

缺點(diǎn)：

• 不支持真正的刪除與更新。
• Join方式不是很友好。
• 并發(fā)能力比較低。
• MergeTree合并不完全。

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

• 單表查詢和多表查詢性能都很強(qiáng)，可以同時(shí)較好支持寬表查詢場(chǎng)景和復(fù)雜多表查詢。
• 支持高并發(fā)查詢。
• 支持實(shí)時(shí)數(shù)據(jù)微批ETL處理。
• 流式和批量數(shù)據(jù)寫(xiě)入都能都比較強(qiáng)。
• 兼容MySQL協(xié)議和標(biāo)準(zhǔn)SQL。

缺點(diǎn)：

• 周邊生態(tài)比較不完善。
• 部分SQL語(yǔ)法不支持。

TiDB/TiFlash：優(yōu)點(diǎn)

• 支持更新/刪除。
• 兼顧了OLTP的需求。
• 支持Flink  ExactlyOnce語(yǔ)意，支持冪等。

缺點(diǎn)

• 查詢性能弱，無(wú)法較好支持OLAP查詢場(chǎng)景。
• 不支持實(shí)時(shí)預(yù)聚合。
• TiFlash暫時(shí)不支持所有的SQL寫(xiě)法以及函數(shù)。

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

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

廣告業(yè)務(wù)的核心數(shù)據(jù)有兩大塊：一個(gè)是廣告的曝光點(diǎn)擊流，即所有廣告單元的展點(diǎn)銷信息；第二個(gè)是廣告效果歸因數(shù)據(jù)，比如說(shuō)在小紅書(shū)站內(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ù)。

原有解決方案

技術(shù)架構(gòu)在引入DorisDB之前，是用大量Flink任務(wù)進(jìn)行寫(xiě)入MySQL/Redis/HDFS/ClickHouse，以達(dá)到數(shù)據(jù)的落地。Flink中核心處理邏輯有幾類：

• 前端用戶廣告展示信息事件流和后端算法推薦流雙流關(guān)聯(lián)并去重，完善廣告信息。
• 接入反作弊，清除作弊事件。
• 按不同業(yè)務(wù)場(chǎng)景需求匯總結(jié)果寫(xiě)入不同的數(shù)據(jù)庫(kù)組件中。

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

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

• 數(shù)據(jù)邏輯沒(méi)有很好做歸攏合并，維護(hù)工作量大，新需求無(wú)法快速響應(yīng)。
• Clickhouse的并發(fā)能力不足以及擴(kuò)容復(fù)雜度在可見(jiàn)未來(lái)會(huì)成為整體廣告系統(tǒng)瓶頸。
• 因?yàn)镕link層邏輯散落，由大量小的Flink任務(wù)構(gòu)成，因此導(dǎo)致整個(gè)架構(gòu)無(wú)法滿足高可用要求，只要任何一個(gè)任務(wù)出現(xiàn)問(wèn)題，都會(huì)影響線上業(yè)務(wù)。

基于DorisDB的解決方案

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

• 能支撐大吞吐量的數(shù)據(jù)寫(xiě)入要求。
• 可以支持多維度組合的靈活查詢，TP99在100ms以下。
• 有實(shí)時(shí)匯總上卷的能力，提高查詢性能，支持qps達(dá)到上萬(wàn)的要求。
• 通過(guò)Binlog實(shí)時(shí)同步MySQL的數(shù)據(jù)，并及時(shí)對(duì)數(shù)據(jù)進(jìn)行封裝。
• 比較好的支持多表關(guān)聯(lián)。

經(jīng)過(guò)大量調(diào)研，DorisDB比較契合廣告數(shù)據(jù)中心的整體要求?；贒orisDB本身高效的查詢能力，支持高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)景。

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

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

• 廣告曝光點(diǎn)擊流寫(xiě)入聚合模型，按照業(yè)務(wù)所需要的維度，如廣告主、廣告類型、創(chuàng)意，廣告單元，搜索詞，地域，用戶屬性等設(shè)計(jì)聚合的所有維度，根據(jù)所需要的指標(biāo)進(jìn)行聚合。
• 廣告?zhèn)群蠖擞泻芏嗟木€上MySQL，通過(guò)DorisDB更新模型接入MySQL進(jìn)行實(shí)時(shí)的表更新。
• 在Hadoop離線數(shù)倉(cāng)中還定期統(tǒng)計(jì)了一些數(shù)據(jù)報(bào)告同步到DorisDB中，這些數(shù)據(jù)使用了DorisDB的明細(xì)模型。

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

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

物化視圖

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

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

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

• 有ETL處理需求的，會(huì)利用Flink進(jìn)行ETL邏輯轉(zhuǎn)化，使用Flink DorisDB Connector寫(xiě)入DorisDB。
• 在實(shí)時(shí)數(shù)倉(cāng)公共層的，配置Routine Load任務(wù)，將數(shù)據(jù)10s一個(gè)batch寫(xiě)入DorisDB表中。

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

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

數(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è)集群能提供上萬(wàn)的QPS，TP99的查詢?cè)?00毫秒以下。

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

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

總結(jié)

小紅書(shū)從今年年初開(kāi)始調(diào)研引入DorisDB，當(dāng)前已經(jīng)有五個(gè)DorisDB集群在穩(wěn)定運(yùn)行中，其中有兩個(gè)開(kāi)始穩(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)延遲要求，之后將用來(lái)提升更多業(yè)務(wù)場(chǎng)景的數(shù)據(jù)服務(wù)和查詢能力。

—— 如果覺(jué)得文章還OK，請(qǐng)轉(zhuǎn)發(fā) ——

特別提示：關(guān)注本專欄，別錯(cuò)過(guò)行業(yè)干貨！

PS：本司承接 小紅書(shū) / 淘寶逛逛 / 抖音 / 百度系 / 知乎 / 微博/大眾點(diǎn)評(píng) 等 全網(wǎng)各平臺(tái)推廣；

咨詢微信：139 1053 2512 (同電話)

首席增長(zhǎng)官CGO薦讀：

• 《首席增長(zhǎng)官 – 增長(zhǎng)黑客 Growth Hacker》
• 《小紅書(shū) – 增長(zhǎng)黑客 Growth Hacker》
• 《視頻號(hào) – 增長(zhǎng)黑客 Growth Hacker》

更多精彩，關(guān)注：增長(zhǎng)黑客（GrowthHK.cn）

增長(zhǎng)黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來(lái)達(dá)成各種營(yíng)銷目標(biāo)的新型團(tuán)隊(duì)角色。從單線思維者時(shí)常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實(shí)現(xiàn)低成本甚至零成本帶來(lái)的有效增長(zhǎng)…