作者：張照亮（士恒）阿裡巴巴搜尋事業部進階技術專家
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的計算和存儲能力，将計算結果持久化存儲。