作者：張照亮（士恆）阿里巴巴搜索事業部高級技術專家

1. 業務背景

阿里巴巴電商搜索推薦實時數據倉庫承載了阿里巴巴集團淘寶、淘寶特價版、餓了麼等多個電商業務的實時數倉場景，提供了包括實時大屏、實時報表、實時算法訓練、實時A/B實驗看板等多種數據應用支持。

數據的價值

我們認為數據處於阿里巴巴搜索推薦的大腦位置，這體現在算法迭代、產品運營和老闆決策等多個方面。那麼數據是怎樣在搜索推薦業務場景中流轉的呢？首先是信息採集，用戶在使用手機淘寶的搜索和推薦功能時，會觸發到服務端上的埋點信息；接下來會經過離線和實時的ETL加工，再裝載到產品引擎裡面；然後我們會基於引擎來構建分析系統，幫助算法、產品做分析決策；形成一次決策之後，會有一些新的內容上線，用戶可以看到算法模型產出的一些業務形態；這樣就產生了一輪新的數據採集、加工、裝載和分析的過程。這樣一來就可以利用數據形成一個完整的業務鏈路，其中每個環節都非常重要。

搜索推薦典型場景

實時數據在電商搜索推薦中有多種不同的應用場景，如實時分析、算法應用和精細化人群運營等。
1）實時分析和算法應用場景
在實時分析和算法應用場景中，我們利用實時數據倉庫搭建分析報表、實時大屏、訓練算法模型以及打造其他類型的數據產品。實時數據的需求搜索推薦場景下主要有以下特點：

• 數據量大：單日PB級存儲
• 單表總條數：_千億+_
• QPS高：峰值寫入RPS 6500W+
• 峰值查詢QPS：_200+_
• 數據靈活性要求高，分析場景多樣化，固定條件高頻分析、非固定條件多維查詢

2）精細化人群運營場景
在電商運營中，經常會有針對不同人群採用不同運營策略的需求。傳統方式使用離線數據對人群進行活動投放，但一般需要到第二天才能看到前一日的活動運營效果。為了更高效地觀測、提升運營效果，實時的人群投放、人群畫像成為必不可少的需求。
實時數倉將會把實時數據以實時大屏、實時報表的形式，為活動運營提供實時的人群行為效果數據，如不同地區、不同年齡段人群的實時UV、實時成交額等。此外，還需要將實時數據與離線數據進行關聯對比計算，提供實時的環比、同比數據。
因此，在整個精細化人群運營場景中

2.典型實時數倉訴求

綜合以上背景，在實時數倉建設的過程中，我們總結了以下幾類典型的實時數倉訴求：

分組橫截面

例如分行業指標展示，通常是在SQL中用group by進行查詢；

多維過濾

場景過濾、用戶過濾、商品過濾、商家過濾等，通常使用array字段進行屬性值的過濾；

聚合

基於明細數據聚合計算實時指標，如SUM、COUNT_DISTINCT計算等；

A/B Test

通過解析日誌埋點中的分桶字段，計算測試桶與基準桶之間的實時Gap數據；

指定Key

在排查問題或觀測核心商家指標時，經常需要指定商家ID、商品ID查詢實時指標，需要基於明細實時表中的id字段過濾後進行聚合計算；

流批一體

由於實時數倉僅保留最近2天的數據，在面對計算同比、環比等需求時，就需要讀取離線數據與實時數據進行關聯計算，這樣產品/運營在看上層報表展現時就能直觀看到今年實時數據和去年同期的對比表現。

3. 實時數倉架構

基於上訴典型實時數倉訴求，我們抽象出了如下圖所示的典型實時數倉架構。

實時採集的業務日誌經過實時計算Flink清洗過濾，將結果寫到OLAP引擎裡面，OLAP引擎既要支持多維的交互式查詢、還要支持KV查詢和流批一體查詢，來滿足我們各種各樣的業務訴求，同時OLAP引擎還需要對接上層構建的各種業務應用，提供在線服務。
基於這個典型的實時架構，下面則是我們搜索推薦場景下的實時架構演進過程。

1）實時數倉架構 1.0版

首先是實時數倉架構1.0版，如下圖所示，這個版本主要是由3個板塊組成：
數據採集
在數據採集層，我們將上游實時採集的數據分為用戶行為日誌和商品維表、商家維表、用戶維表等，為什麼會有維表呢？因為每個業務在埋點時不會將所有信息全部埋在日誌裡面，如果所有信息都由用戶行為日誌承載，靈活性將會特別差，所以維表在業務上擔任信息擴展的角色。
採集的用戶行為日誌將會實時寫入實時計算Flink，用戶維表、商品維表等維表數據統一歸檔至MaxCompute中，在初步計算後將會通過數據同步工具（DataX）同步至批處理引擎中。

數據處理
在數據處理層中，流處理部分，由Flink對實時寫入的用戶行為日誌數據做初步處理，具體的處理包括數據解析、清洗、過濾、關聯維表等。
批處理部分，為了在數據查詢和服務中根據屬性查詢、篩選數據，需要在Flink作業中將用戶的實時行為和維表做關聯計算，這就需要批處理系統能夠支持高QPS查詢，當時搜索業務的單表QPS最高達6500萬，經過多方調研，選擇了HBase作為維表的批處理引擎。
Flink作業中基於用戶ID、商品ID、商家ID等關聯HBase維表中的屬性數據，輸出一張包含多個維度列的實時寬表，再輸出到OLAP引擎。為了簡化Flink實時作業，降低實時計算的壓力，我們沒有在Flink中使用窗口函數做指標的聚合工作，只是對實時日誌簡單過濾、關聯後直接輸明細數據到下游，這就要求下游引擎需要提既要支持KV查詢、OLAP多維交互式查詢，還要支持流批一體查詢。

數據查詢和服務
在第一版架構中我們使用的是Lightning引擎來承載Flink輸出的實時明細數據，並基於Lightning實現查詢流批一體，再對上層應用提供統一的實時數據查詢服務。
但是Lightning的侷限性也是非常明顯的：第一是查詢方式是非SQL類型不夠友好，若是寫SQL需要二次封裝。第二是Lightning採用的是公共集群，多用戶資源不隔離，當需要查詢大量數據時，容易出現性能波動和資源排隊等問題，使得查詢耗時較久，在實際業務場景使用中有一定的限制。

2）實時數倉架構 2.0版

基於Lightning的限制，我們希望能找到一款替代產品，它的能力要在Lightning之上，支撐OLAP的交互式查詢以及高QPS的維表校驗查詢。於是在2.0版的實時數倉架構中，我們開始接入Hologres。
最開始，我們只是用Hologres替代Lightning提供KV、OLAP查詢能力，解決了Lightning所帶來的侷限性。這樣的架構看起來很好，但因為還需要經過HBase存儲維表，隨著數據量的增長，數據導入至HBase的時間也越長，實際上浪費了大量資源，並且隨著線上服務實時性要求增加，HBase的弊端也越來越明顯。
而Hologres的核心能力之一是加速離線數據，尤其是針對MaxCompute的數據，在底層與其資源打通，能加速查詢。所以我們就萌生了將Hologres替代HBase的想法，以Hologres為統一的存儲，數據也無需再導入導出，保證了一份數據一份存儲。

於是，最終的實時數倉架構2.0版如下：
數據處理階段直接將用戶維表、商品維表、商家維表以行存模式存儲到Hologres中，以此替代Hbase存儲。Flink中的作業可以直接讀取Hologres的維表，與行為日誌進行關聯。
在數據查詢和服務階段，我們將Flink處理輸出的實時明細數據統一存儲至Hologres，由Hologres提供高併發的數據實時寫入和實時查詢。

4. 基於Hologres的最佳實踐

實時數倉2.0版本因為Hologres的接入，既精簡了架構，節約了資源，也真正實現了流批一體。這個架構也一直使用至今，下面是Hologres基於此架構在搜索推薦具體多個業務場景中的最佳實踐。

1）行存最佳實踐

Hologres支持行存和列存兩種存儲模式，行存對於key-value查詢場景比較友好，適合基於primary key的點查和 scan，可以將行存模式的表看作是一張類似於Hbase的表，用不同的表存儲不同實體的維度信息。在Flink實時作業中可以高效地從Hologres行存表中讀取維表數據，與實時流中的實體進行關聯。

2）列存最佳實踐

Hologres中默認表的存儲模式是列存，列存對於OLAP場景較為友好，適合各種複雜查詢。
基於Hologres的列存模式，我們搭建了搜索、推薦業務的實時數據查詢看板，在實時看板上可以支持數十個不同維度的實時篩選過濾。在最高峰值每秒寫入條數（RPS）超過500萬的同時仍然可以秒級查詢多個維度篩選下的聚合指標結果。
同時Hologres表支持設置表數據TTL的屬性，一般我們將一張實時表的生命週期設置為48小時，超過48小時的數據會被自動刪除，在實時看板中支持用戶對最近兩天內的實時數據進行查詢，避免了不必要的資源浪費。

3）流批一體最佳實踐

Hologres不僅支持基於實時明細的數據的即席分析查詢，也支持直接加速查詢MaxCompute離線表，因此我們利用這一特性，實現流批一體的查詢（實時離線聯邦分析）。
在天貓大促活動中，我們利用Hologres的聯邦分析能力搭建了核心商家的目標完成率、去年同期對比看板，為運營算法決策提供了有效的數據支撐。
其中目標完成率看板開發藉助實時離線聯邦分析變得更為簡單，即通過Hologres實時查詢大促當天的指標，並用實時表的當天指標除以離線表中設定的目標指標，從而讓運營能夠看到實時更新的核心商家當天目標的完成情況。
去年同期對比實時看板的計算邏輯也是類似的，可以在SQL中將實時表與去年的離線表JOIN後進行關鍵指標的同比計算。所有的計算都可以在Hologres中完成，通過SQL表達計算邏輯即可，無需額外的數據開發工作，一份數據一套代碼，降低開發運維難度，真正實現流批一體。

4）高併發實時Update

在一些場景下，我們不僅需要向OLAP引擎實時增量寫入數據，還需要對寫入的數據進行更新操作（update）。
例如，在訂單成交歸因時，Flink實時作業會將訂單提交數據流與進度點擊數據流進行雙流JOIN，並且在還需要取訂單提交前的最後一次點擊事件進行關聯。當有多條點擊事件先後到達時，我們就需要更新訂單歸因明細數據，此時需要利用Hologres的update支持，通過數據的主鍵更新原有數據，保證成交歸因的數據準確性。在實踐中Hologres的update寫入峰值能達50W，滿足業務高併發實時更新需求。

5. 未來展望

我們希望未來基於Hologres引擎持續改進現有的實時數倉，主要的方向主要有：

1）實時表JOIN
Hologres現階段支持百億級表與億級表之間的JOIN，秒級查詢響應。基於這個特性，期望將原本需要在數據處理階段由Flink實時作業完成的維表關聯工作，可以改為在查詢Hologres階段實時JOIN計算。例如表1是明細數據表，表2是用戶維表，在查詢階段的JOIN可以通過篩選用戶維表，然後與明細數據表關聯，達到篩選過濾數據的目的。這樣的改進將帶來幾個好處：
1）減少Hologres中的數據存儲量，避免實時表中存儲大量的數據冗餘（如：同一個商品ID的數據會重複存儲）；
2）提升實時數據中維度屬性的時效性，在查詢階段實時JOIN維表數據後進行計算，可以使得我們在通過維度篩選數據的時候，始終是用的最新的維度屬性。

2）持久化存儲
我們未來將探索如何將常用維度的實時數據，利用Hologres的計算和存儲能力，將計算結果持久化存儲。