阿里巴巴電商搜索推薦實時數倉演進之路

簡介： 自建實時數倉到底難在哪裏？實時數倉應該怎麼建？阿里巴巴搜索團隊告訴您答案

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

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天的數據，在面對計算同比、環比等需求時，就須要讀取離線數據與實時數據進行關聯計算，這樣產品/運營在看上層報表展示時就能直觀看到今年實時數據和去年同期的對比表現。

1. 實時數倉架構

==========

基於上訴典型實時數倉訴求，咱們抽象出了以下圖所示的典型實時數倉架構。
實時採集的業務日誌通過實時計算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提供高併發的數據實時寫入和實時查詢。

1. 基於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，知足業務高併發實時更新需求。

1. 將來展望

========

咱們但願將來基於Hologres引擎持續改進現有的實時數倉，主要的方向主要有：

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

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

原文連接本文爲阿里雲原創內容，未經容許不得轉載。