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

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

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

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

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

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

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

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

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

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

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

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

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

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

離線數(shù)據(jù)處理：利用Hive/Spark高可擴展的批處理能力承擔(dān)所有的離線數(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。

數(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)品（比如流量分析平臺，用戶標簽平臺）。

應(yīng)用層

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

各OLAP分析工具選型比較

Clickhouse：優(yōu)點：

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

缺點：

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

DorisDB：優(yōu)點：

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

缺點：

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

TiDB/TiFlash：優(yōu)點

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

缺點

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

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

業(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ù)。

原有解決方案

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

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

技術(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ù)。

基于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場景。

數(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)意粒度的物化視圖。基于這些物化視圖，可以極大加速查詢。

數(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中。

數(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毫秒以下。

系統(tǒng)運維

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

總結(jié)

小紅書從今年年初開始調(diào)研引入DorisDB，當(dāng)前已經(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ù)和查詢能力。

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

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

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

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

首席增長官CGO薦讀：

• 《首席增長官 – 增長黑客 Growth Hacker》
• 《小紅書 – 增長黑客 Growth Hacker》
• 《視頻號 – 增長黑客 Growth Hacker》

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

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