作者：蘭乾 阿裡巴巴搜尋推薦進階開發工程師
一、業務背景
阿裡巴巴搜尋推薦作為淘系核心流量入口，資料量大，對接的業務場景繁多，且需求變化快，同時對資料的實時性和準确性要求都很高，尤其在各業務方大促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。