小紅書是年輕人的生活記錄、分享平臺，用戶可以通過短視頻、圖文等形式記錄生活點滴，分享生活方式。在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ù)嚴(yán)重影響集群可用性。在Redshift中同時進行ETL任務(wù)的時候，會大量搶占資源，從而影響數(shù)據(jù)分析的效率，導(dǎo)致查詢超時甚至因為集群負(fù)載過大后整個集群崩潰不可用。

　　·沒有良好的存算分離，數(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)

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

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

　　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高可擴展的批處理能力承擔(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。

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

　　4）應(yīng)用層

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

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

　　#FormatImgID_1#

　　1）Clickhouse：

　　優(yōu)點：

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

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

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

　　缺點：

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

　　·Join方式不是很友好。

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

　　·MergeTree合并不完全。

　　2）DorisDB：

　　優(yōu)點：

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

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

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

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

　　·兼容MySQL協(xié)議和標(biāo)準(zhǔn)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)計指標(biāo)，對外提供查詢分析服務(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ù)模型：明細(xì)模型/聚合模型/更新模型。對小紅書廣告業(yè)務(wù)來說，三種數(shù)據(jù)模型各盡其用：

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

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

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

　　數(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é)點問題，當(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ù)和查詢能力。最后，感謝鼎石科技的大力支持，也期望DorisDB作為性能強悍的新一代MPP數(shù)據(jù)庫引領(lǐng)者越來越好!(作者：吳浩亮 小紅書大數(shù)據(jù)團隊，數(shù)據(jù)倉庫架構(gòu)師)