作者：蘭乾 阿里巴巴搜索推薦高級開發工程師

一、業務背景

阿里巴巴搜索推薦作為淘系核心流量入口，數據量大，對接的業務場景繁多，且需求變化快，同時對數據的實時性和準確性要求都很高，尤其在各業務方大促KPI完成度監控，並支撐算法迭代即時效果監控加快迭代速度，同時也為算法在線模型提供實時訓練樣本，提升算法效果等方面有著迫切的需求，因此為了滿足這些實時數據的需求，在搭建穩定的數據體系過程中，需要解決許多痛點：

1）數據量大，資源有限下，需做到數據生產基本無延遲，並且查詢秒級內響應；
2）查詢維度繁多，且不固定，隨時可能新增維度，需要豐富的明細數據支撐，且具備高擴展性和靈活性；
3）原始日誌信息有限，需動態補充滿足個性化數據需求；
4）任務、場景多，數據輸出格式需要統一化，降低維護和對接成本；
5）需求迭代快，Blink作業頻繁變更啟停，增加系統不穩定性，需要實現Blink作業變更配置化。

對於實時數據而言，實時性與正確性是最基本的要求，另外鑑於上面提到的痛點和需求，搜索推薦部門結合Blink、交互式查詢引擎Hologres，不斷優化數據研發架構，最終實現了集數據輸出格式化、查詢交互式/個性化、Blink任務模板化以及Blink作業變更配置化等功能為一體的大數據研發架構，如下圖所示：

二、實現原理

2.1 如何實現數據輸出的交互式、個性化、高擴展性

數據輸出的交互式、個性化、高擴展性，我們主要結合了Hologres 行存表和列存表優勢來實現。

要實現數據輸出的交互式、個性化、高擴展性，依賴數據中豐富維度，比如商品、商家、用戶的各種特徵屬性，或者某次用戶行為下的特定場景屬性等，這些維度(屬性)有些是相對固定的基本屬性，比如用戶的城市、年齡、商品的類目等信息，但有些是有業務獨立特徵的個性化屬性，比如特定的一批商品、特定的一些用戶場景等，這些業務上個性化的屬性，隨時都在新增或刪減，並且每個業務查詢的維度是不同的，這樣不僅需要搭建交互式的多維數據分析可視化輸出，還需要能夠靈活支持不同業務場景個性化的數據訴求。

個性化維度(屬性)主要來源於兩個地方，一個是數據採集階段提取的動態化場景信息，如算法分桶信息等；另一個是原始日誌中缺失的個性化信息，例如商品、商家、用戶的個性化特徵，這些個性化的動態特徵最後都按不同的對象屬性存儲到Hologres列存表對應的多值字段中，例如商品、商家、用戶、場景維度信息分別對應Hologres列存表中的多個多值字段：

1）原始日誌動態化場景信息

隨著不同業務的不同變化，每個業務服務端會將新增的業務信息(維度)下發移動客戶端，上報日誌中心， 數據研發工程師對應更改日誌解析配置，搭配Blink作業變更配置化，就可以0代碼發佈實現新增維度的無痕提取與透出，對應的業務產品及算法即可在15分鐘內查詢到該新增維度下的實時數據，例如算法實驗動態分桶效果分析等。

如下表1所示，將用戶vs商品vs商家行為日誌，如曝光、點擊、成交、加購等明細日誌分別存入各自Hologres列存表，幾張Hologres列存表使用同一套schema，其中豐富的多值字段中存放一些從原始日誌中提取的信息以及在Blink中關聯商品(商家、用戶)Hologres行存維表獲取的補充信息，是支持交互式/個性化查詢的核心字段，高可擴展性和靈活性即席多維分析核心字段。

按照 Who+What+When+ Where + How形式對錶schema進行設計，其中How（何事，頻次）按用戶行為是曝光、點擊還是成交加購拆分到不同的表中，行為發生頻次則與Who+What+When+ Where 一同設計到表schema中，如下:

表1 用戶vs商品vs商家行為日誌->Hologres列存表

類型	字段	說明
基礎信息字段	When（時間）: second_timestamp Who（人）: user What（貨）: item,seller Where（場）: channel	人貨場以及事件發生的時間信息
指標字段	How: count,number,amount	人貨在場上行為發生的次數(如成交次數 、商品瀏覽次數)、其他指標(如成交金額、瀏覽時長等)
多值(維度)擴展字段	item_tags,user_tags,bts_tags,algo_tags ,scene_tags,debug_tags	存放一些日誌中提取的信息以及維表關聯獲取的補充信息，是支持交互式/個性化查詢的核心字段，高可擴展性和靈活性即席多維分析核心字段

2）維表關聯提取動態個性化信息

為了儘可能地支持更多維度、更個性化和可擴展的查詢，若想保留越多的維度特徵信息，數據聚合度越高，特徵信息損失越多，因此，在Blink作業中將【用戶的明細日誌】關聯上Hologres行存表中商品、商家、用戶等對象多種可動態擴展屬性後, 並將屬性作為多值字段直接寫入 Hologres列存表 中，實現任意交叉維度的數據輸出。

使用Hologres行存表，存儲商品、商家、用戶等對象的特徵維度信息，每個對象一張Hologres行存表，如下表格2所示為商品的Hologres行存表部分字段, 商家、用戶表基本邏輯一致：

表2 商品屬性特徵->Hologres行存表

字段	說明
item_id	商品id，行存表主鍵
cate_id等	類目等信息
tags	維度核心字段，商品擴展屬性信息，多值，固定分隔符拆分不同屬性值，對應數據查詢的擴展維度，在blink作業中該字段會合入用戶行為Hologres列存表中對應的多值字段item_tags中，最終輸出到數據報表中的可查詢維度

將海量商品、用戶的特徵信息存入對應的Hologres行存表，並將業務輸入的個性化動態屬性定時寫入Hologres行存表預留字段，幾十億商品的特徵信息僅耗時5分鐘完成數據切換，結合Blink partition join 緩存機制，緩存命中率高達97%，使得千萬級join qps 實際請求Hologres行存表時僅有幾十萬qps，行存表中tags信息通過Blink作業關聯加工後，最終輸出到Hologres列存表，作為查詢維度供交互式分析使用。

2.2 如何實現Blink作業變更配置化

面對層出不窮的需求變化，但考慮到日誌中存在無效信息，並未將日誌中全部信息提取作為可查詢維度，需要根據需求變化變更Blink SQL提取，加上Blink作業頻繁啟停也會增加運維成本，增加業務迭代的人工和時間成本。因此使用MaxCompute(原odps)小表存儲日誌過濾和解析配置，僅需變更配置內容，將新提取的信息自動寫入到Hologres中指定多值字段中，無需變更Blink作業和Hologres表結構，該新增信息就可作為維度任意查詢和輸出。

由於Blink中需要通過發佈及啟停作業才能讀取配置化的信息，繼而完成對實時數據處理的變更，但是搜索推薦所有業務是共用一套Blink作業，且業務頻繁變更，但如果因為個別業務頻繁變動公共Blink作業，對實時數據體系影響較大，又考慮到搜索推薦實時數倉中選擇使用明細數據，因此，在Blink作業中額外關聯ODPS表(_存儲數據解析及過濾配置，由於表極小，可全量緩存在Blink機器上_)，其中數據解析與過濾配置與存儲用戶行為日誌的Hologres列存表schema是一一對應的，獲取到作業所需的解析及過濾配置後，並將上游數據和解析配置同時作為入參輸入到通用的日誌處理UDTF中，並按表格1中用戶vs商品vs商家行為日誌->Hologres列存表的schema格式輸出數據。**這樣僅需變動ODPS表中存儲的解析配置信息，即可無痕將從日誌中額外提取的信息輸出到Hologres列存表中對應的多值字段作為維度可查了。

表3 Blink任務數據解析及過濾配置->ODPS表

2.3 小結

目前搜索推薦大部分作業通過Blink開發產出的是實時明細數據，也就是說並非聚合數據，這樣搭配交互式查詢引擎Hologres，可以自由維度查詢，但對交互式查詢引擎的要求較高; 若維度相對固定，可以做些輕度聚合後，數據輸出到igraph,Hologres,Hbase等存儲與查詢引擎，可節省資源，但擴展性差，且新增維度需要修改Blink任務。

總的來說，基於__海量的明細用戶日誌__，__Hologres__高達幾千萬__QPS__的寫入性能，以及靈活的__多值字段__設計，優秀的全局去重能力__，搭配動態維度無變更接入解決方案，使得__搜索推薦實時大數據在低開發成本、低運維、0溝通情況下，既保證了實時數據的實時性和準確性，又提升數據交互式即席分析的個性化、靈活性和高擴展性。

三、即席多維分析場景實戰

接下來詳細介紹如何通過Hologres和Blink實現1小時內無痕新增分析維度，接入即席多維分析實戰場景中。

 3.1 原始日誌動態化場景信息

例如需要添加實驗桶信息，搜索推薦由於場景複雜，採用的複雜的交叉分桶模式，一次用戶行為對應多個實驗分桶，每時每刻都會有新增的實驗分桶，服務端只需將新增的分桶信息下發客戶端，通過數據採集之後，自動轉換成Hologres列存表特定多值字段如algo_tags的值，該分桶對應實時數據則可即發即查，加快算法迭代週期。

為減輕存儲和計算壓力，僅從原始日誌中提取核心維度放入Hologres列存表多值字段，因此對於特定業務，新增的個性化場景信息，可以通過變更ODPS表中存放的數據解析配置，即可無痕將新增的個性化場景信息轉換成維度添加到Hologres列存表對應多值字段中，例如在推薦中新增的紅包業務，且需要將對應的紅包信息轉換成查詢維度，在推薦僅維護一套Blink作業和Hologres表的情況下，基於統一的日誌規範，無需任何變更，自動在推薦實時數倉中新增了紅包場景數據，另外紅包業務中攜帶的紅包信息，則需要在ODPS表中解析配置裡新加相應的提取邏輯，比如設置成將日誌中紅包唯一識別碼的值放置到Hologres列存表的scene_tags字段中，則該紅包識別碼即可作為維度供業務查詢分析使用，監控紅包曝光等實時效果。

 3.2 維表關聯提取動態個性化信息

面對海量的實時數據，如何快速精準地獲取、監控我想要的數據呢？這就需要給數據帶上所需的維度或特徵信息，簡單來說主要有以下幾點：

1）原始數據日誌在大部分情況下，缺失商品類目、行業，用戶地域等基本屬性；
2）除了使用通用的類目、行業等基本信息，還需要監控某些特定的商品、某些核心的商家、某些特殊的人群下的數據情況，是需要有對應的個性化屬性的。
3）如果不關聯上基本屬性或個性化屬性維度信息，就沒辦法直接過濾查詢獲取到對應維度下的數據，需要額外關聯並二次加工才可獲取，無法靈活查詢，做不到任意個性化維度的交互式查詢。

總結來說，不同業務場景對實時數據都會有不同的需求，需要監控或使用各種基本屬性和個性化屬性維度下實時數據，但如何滿足各種各樣個性化的實時數據需求呢？
如下圖所示，搭建了維度特徵管理平臺Seahummer，支持商品、商家、用戶等對象的標籤特徵管理，根據業務方配置的個性化屬性，比如賣家分層、用戶分層，以及各種自定義的業務屬性等，關聯到對應的商品/商家/用戶上，最終產出對應MaxCompute(odps)維表，並導入Hologres行存表中，在Blink流作業裡，關聯對應Hologres行存表即可獲取相應的基本屬性和個性化屬性，並標記到Hologres列存表實時數據上輸出，這些屬性最終以多值字段的形式存儲在Hologres列存表中，作為查詢維度呈現在可視化報表。

維度的增減，無需更改Blink作業，整體維度變更鏈路最慢小時內完成維表數據切換，目前業務方已能通過seahummer平臺自助打標後，在通天塔數據門戶（阿里巴巴內部的一款分析軟件）中自助即席多維分析，涵蓋1000+自定義維度信息，無需開發同學額外支持，解放人力，減少溝通成本。

1）對象——商品、商家、用戶
2）標籤數據來源——odps、excel
3）基本屬性——商品/商家名稱、類目、行業、BC類型，用戶地域等
4）個性化屬性——指定商品池、特殊人群、商家等
5）與Blink實時流作業打通——Blink流任務關聯Hologres維表即可獲取相應的基本屬性和個性化屬性

例如算法新上線了分桶實驗，需要對特定商品或人群採取特定的算法策略，只需要對這些商品或用戶通過維度特徵管理平臺Seahummer錄入，對應標籤則自動流入到相應商品或用戶的Hologres行存表中的tags字段，並轉換成了用戶行為Hologres列存表中的item_tags或user_tags多值字段中，最後以自定義、可擴展查詢維度的形式透出在可視化報表中；上述紅包業務例子中，需要對重點目標人群傾斜部分曝光流量，這時候同理將重點目標人群打上標識，即可監控目標與非目標人群曝光流量對比，適時調整算法策略，完成業務目標。

四、業務價值

4.1自定義交互式即席多維查詢

依託Hologres強大的多維分析能力，以及高併發、無延遲實時寫入和全局去重能力，其中全局去重能力解決了在Blink作業異常情況下數據去重問題，保障了數據一致性。在日常及大促期間，承接了搜索推薦海量流量數據，支持搜索推薦算法AB實驗實時效果分析，除了有對應的實時數據多維交互式可視化報表以外，還提供了實時數據服務，支持算法在線調用，自動調整算法策略，此外生產的實時數據流，還在Blink中用於算法實時模型訓練，加快了算法迭代週期，達到任意查詢維度結果秒級響應。

在支持算法AB實驗即時查詢分析的同時，還支持商家、商品、用戶等對象各類屬性及標籤多維度下的自由查詢，比如用戶年齡、城市等級分層等，以及通過維表或流量日誌接入的可擴展的自定義標籤及維度，極大地擴展了不同算法、產品、運營、分析師角色即時分析的自由度和靈活性。

4.2某特定業務實時大屏

依託Hologres的多維分析能力，還可以針對某些特定獨立業務搭建實時監控大屏，比如在該業務促銷活動期間，監控對應的成交和KPI完成度，以及分析當前業務觸達及消費的人群特徵分佈，用於即時調整運營策略，完成KPI。