小紅書是年輕人的生活記錄、分享平臺，用戶可以通過短視頻、圖文等形式記錄生活點滴，分享生活方式。最近幾年，隨著業務類型和用戶體量的爆炸式增長，各類數據分析的需求以及應用系統的數據需求快速出現，例如：商業智能分析，數據應用報表，用戶行為分析、算法策略數據等。

小紅書大數據團隊逐步引入了多種OLAP分析引擎以及自建引擎來更好的滿足需求。當前Flink+Doris和Flink+Clickhouse(自建版)已成為小紅書構建統一實時數據服務的核心技術方案，大大降低了數據鏈路開發復雜性，提升了高并發極速查詢能力。

一、OLAP引擎在小紅書的演進史

第一階段

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

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

第二階段

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

第三階段

業務實時性增強，對查詢性能的要求不斷升高，同時許多數據應用產生。這個階段引入了ClickHouse，用來建設性能更強悍，響應時間更短的數據分析平臺以滿足實時性要求。

第四階段

小紅書大數據團隊進行了實時數倉的整體設計和搭建，同時為統一對各業務團隊提供數據接口而構建了數據服務平臺，外接了多個內部或者To B服務的應用系統。既需要做低延時的復雜查詢，同時對并發量也有很高的要求。這個階段我們又根據場景引入了Doris引擎，以滿足以上各類需求。

第五階段

小紅書大數據團隊在Clickhouse的基礎上自研了Redck引擎。小紅書作為一個內容分享平臺，用戶的行為特征數據分析是最具價值同時也是最具挑戰的，日常存在大量的功能表現、流量漏斗、用戶路徑、實驗分析、屬性分布等分析場景。而這些場景，都對平臺同時具備實時，秒級響應分析萬億行級別數據的能力有著很高的要求?；谶@些實際業務需求，我們利用Clickhouse天然的Mpp特性，加上自主開發的元數據管理，存算分離架構，冷熱數據分層，實時數據寫入等特性，構建了小紅書自己的用戶行為分析平臺，提供高效快速的人群行為分析、實驗分析洞察能力。

二、小紅書數據分析體系架構

1、小紅書OLAP體系現狀

小紅書的整個數據分析體系，由數據采集、數據存儲加工/數據共享和應用層組成。

• 數據采集

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

• 數據存儲加工

離線數據處理：利用Hive/Spark高可擴展的批處理能力承擔所有的離線數倉的ETL和數據模型加工的工作。實時數據處理：Flink完成實時側數據的ETL（包括維度豐富，雙流Join，實時匯總）；離線表通過調度平臺同步到ClickHouse/DorisDB，我們Flink實現了ClickHouse和DorisDB的sink connector，落地到DorisDB或ClickHouse。

• 數據共享

數據共享層的主要提供對外服務的底層數據存儲,離線或者實時的數據寫入相關的數據庫組件中，面向多種服務，不同場景提供查詢能力。數據共享層主要有TiDB/Hbase/ClickHouse/Doris。通過Doris和ClickHouse提供的高速OLAP查詢能力，在應用側承接了報表平臺，提供即席分析的平臺，對開發側提供數據接口，以及實現多個數據產品（比如流量分析平臺，用戶標簽平臺）。

• 應用層

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

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

1）Clickhouse

① 優點

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

② 缺點

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

2）DorisDB

① 優點

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

② 缺點

• 周邊生態比較不完善。
• 部分SQL語法不支持。

3）TiDB/TiFlash

① 優點

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

② 缺點

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

三、DorisDB在廣告數據中心的應用實踐

1、業務場景概述

廣告業務的核心數據有兩大塊：一個是廣告的曝光點擊流，即所有廣告單元的展點銷信息；第二個是廣告效果歸因數據，比如說在小紅書站內的訂單轉化，相關表單提交，筆記的點贊、收藏、加關注等參與程度。基于這些數據，根據不同的業務場景需求，實時匯總出相關業務統計指標，對外提供查詢分析服務。

2、原有解決方案

1）技術架構

在引入Doris引擎之前，是用大量Flink任務進行寫入MySQL/Redis/HDFS/ClickHouse，以達到數據的落地。Flink中核心處理邏輯有幾類：

• 前端用戶廣告展示信息事件流和后端算法推薦流雙流關聯并去重，完善廣告信息。
• 接入反作弊，清除作弊事件。
• 按不同業務場景需求匯總結果寫入不同的數據庫組件中。

2）技術痛點

原有架構主要有以下問題：

• 數據邏輯沒有很好做歸攏合并，維護工作量大，新需求無法快速響應。
• Clickhouse的并發能力不足以及擴容復雜度在可見未來會成為整體廣告系統瓶頸。
• 因為Flink層邏輯散落，由大量小的Flink任務構成，因此導致整個架構無法滿足高可用要求，只要任何一個任務出現問題，都會影響線上業務。

3、基于Flink+Doris的解決方案

因此我們希望對原有體系進行優化，核心思路是利用一個OLAP引擎進行這一層的統一， 對OLAP引擎的要求是比較高的：

• 能支撐大吞吐量的數據寫入要求。
• 可以支持多維度組合的靈活查詢，TP99在100ms以下。
• 有實時匯總上卷的能力，提高查詢性能，支持qps達到上萬的要求。
• 通過Binlog實時同步MySQL的數據，并及時對數據進行封裝。
• 比較好的支持多表關聯。

經過大量調研，DorisDB比較契合廣告數據中心的整體要求?；贒orisDB本身高效的查詢能力，支持高QPS的特性，可以為廣告的算法策略、廣告實時計費、廣告平臺實時的數據報告提供一體化服務。新架構具備以下優點：

• 結構清晰，Flink專注于數據的清洗，業務邏輯計算從Flink遷到DorisDB內實現，DorisDB就是數據業務邏輯的終點。
• 可以維護統一的數據口徑，一份數據輸入，一套廣告統計口徑輸出。
• 在底層實現DorisDB主備雙活，更好的支持高QPS場景。

1）數據表設計數據模型設計

DorisDB本身提供三種數據模型：明細模型/聚合模型/更新模型。對小紅書廣告業務來說，三種數據模型各盡其用：

• 廣告曝光點擊流寫入聚合模型，按照業務所需要的維度，如廣告主、廣告類型、創意，廣告單元，搜索詞，地域，用戶屬性等設計聚合的所有維度，根據所需要的指標進行聚合。
• 廣告側后端有很多的線上MySQL，通過DorisDB更新模型接入MySQL進行實時的表更新。
• 在Hadoop離線數倉中還定期統計了一些數據報告同步到DorisDB中，這些數據使用了DorisDB的明細模型。

2）數據分區/分桶

DorisDB提供的數據分區功能，可以很好的提升廣告場景下查詢的性能。例如，廣告側查詢常見的一種查詢場景，是查詢過去某一段時間內的數據，我們可以在DorisDB中根據時間進行分區，過濾掉不必要的分區數據。另外，廣告查詢會根據廣告主進行篩選，我們將廣告主ID作為排序鍵的最前列，就可以快速定位到廣告主的數據，DorisDB還支持按照廣告主ID進行Hash分桶，減少整個查詢的數據量進行快速定位，這對高并發場景也具有非常大的意義，盡量減少了查詢語句所覆蓋的數據范圍，提高了并發能力。

3）物化視圖

我們利用DorisDB物化視圖能夠實時、批量構建，靈活增加刪除以及透明化使用的特性，建立了基于廣告主粒度、基于用戶特征粒度、基于廣告單元粒度、基于具體創意粒度的物化視圖?；谶@些物化視圖，可以極大加速查詢。

4）數據導入

實時的數據導入分為兩種：

• 有ETL處理需求的，會利用Flink進行ETL邏輯轉化，使用Flink DorisDB Connector寫入DorisDB。
• 在實時數倉公共層的，配置Routine Load任務，將數據10s一個batch寫入DorisDB表中。

離線數據報告導入DorisDB：

• 在DorisDB提供的原生的Broker Load基礎上在小紅書數倉的調度平臺上封裝了導數模版，通過界面化配置的方式，將離線數倉的表導入到DorisDB中。

5）數據查詢

在我們的查詢場景中，廣告主業務查詢服務對查詢并發度要求很高。Doris采用的是MPP查詢架構，底層數據按照Range和Hash兩級分片，非常適合廣告主業務的查詢場景。

內部做的線上查詢壓測結果，每個FE能到2000左右的QPS，整個集群能提供上萬的QPS，TP99的查詢在100毫秒以下。

6）系統運維

廣告數據中心是非常核心的一個線上服務，因此對高可用及靈活擴容能力有非常高的要求。Doris引擎本身支持fe/be多副本，沒有單節點問題，當有節點故障的時候也可以保證整個集群的高可用。另外，當前體系結構在大數據規模下可以進行在線彈性擴展，在擴容時無需下線，不會影響到在線業務。

在此基礎上，我們同時建設了主備雙活鏈路，使用consul進行連接管理，一旦出現單條鏈路失效，可以一體化切換所有線上查詢服務，在日常開發新需求上線時，也可以保持備用鏈路上線運行，主備對比校驗，再進行主鏈路升級，做到業務上線對下游無感知。

四、總結

在實時體系構建在Flink+Doris整體框架后，實現了數據服務統一化，大大簡化了實時數據處理鏈路，同時也能保障較高的查詢并發和較低的響應延遲要求，當前已經作為小紅書數據中臺的核心架構，為廣告投放平臺聚光平臺的重構和業務迭代，電商商家端Ark系統和鷹眼系統的迭代和穩定運行提供了底層架構的支撐，之后的將來也會用來提升更多業務場景的數據服務和查詢能力。