分享嘉賓：張照亮 阿里巴巴 高級技術專家
編輯整理：鄭銀秋
出品平臺：DataFunTalk
導讀： 今天分享的內容是阿里搜索推薦數(shù)據(jù)平臺研發(fā)團隊在實時數(shù)倉的一些探索，圍繞著團隊在數(shù)倉上基于Flink + Hologres的演進過程及最佳實踐。 01
業(yè)務背景
阿里巴巴電商搜索推薦實時數(shù)據(jù)倉庫承載了阿里巴巴集團淘寶、淘寶特價版、餓了么等多個電商業(yè)務的實時數(shù)倉場景，提供了包括實時大屏、實時報表、實時算法訓練、實時A/B實驗看板等多種數(shù)據(jù)應用支持。
1. 數(shù) 據(jù)的價值
我們認為數(shù)據(jù)處于阿里巴巴搜索推薦的大腦位置，這體現(xiàn)在算法迭代、產(chǎn)品運營和老板決策等多個方面。那么數(shù)據(jù)是怎樣在搜索推薦業(yè)務場景中流轉的呢？首先是信息采集，用戶在使用手機淘寶的搜索和推薦功能時，會觸發(fā)到服務端上的埋點信息；接下來會經(jīng)過離線和實時的ETL加工，再裝載到產(chǎn)品引擎里面；然后我們會基于引擎來構建分析系統(tǒng)，幫助算法、產(chǎn)品做分析決策；形成一次決策之后，會有一些新的內容上線，用戶可以看到算法模型產(chǎn)出的一些業(yè)務形態(tài)；這樣就產(chǎn)生了一輪新的數(shù)據(jù)采集、加工、裝載和分析的過程。這樣一來就可以利用數(shù)據(jù)形成一個完整的業(yè)務鏈路，其中每個環(huán)節(jié)都非常重要。
2. 搜索推薦典型場景 實時數(shù)據(jù)在電商搜索推薦中有多種不同的應用場景，如實時分析、算法應用和精細化人群運營等。
① 實時分析和算法應用場景 在實時分析和算法應用場景中，我們利用實時數(shù)據(jù)倉庫搭建分析報表、實時大屏、訓練算法模型以及打造其他類型的數(shù)據(jù)產(chǎn)品。實時數(shù)據(jù)的需求搜索推薦場景下主要有以下特點：
② 精細化人群運營場景 在電商運營中，經(jīng)常會有針對不同人群采用不同運營策略的需求。傳統(tǒng)方式使用離線數(shù)據(jù)對人群進行活動投放，但一般需要到第二天才能看到前一日的活動運營效果。為了更高效地觀測、提升運營效果，實時的人群投放、人群畫像成為必不可少的需求。 實時數(shù)倉將會把實時數(shù)據(jù)以實時大屏、實時報表的形式，為活動運營提供實時的人群行為效果數(shù)據(jù)，如不同地區(qū)、不同年齡段人群的實時UV、實時成交額等。此外，還需要將實時數(shù)據(jù)與離線數(shù)據(jù)進行關聯(lián)對比計算，提供實時的環(huán)比、同比數(shù)據(jù)。 02
典型實時數(shù)倉訴求
綜合以上背景，在實時數(shù)倉建設的過程中，我們總結了以下幾類典型的實時數(shù)倉訴求： 1. 分組橫截面 例如分行業(yè)指標展示，通常是在SQL中用group by進行查詢； 2. 多維過濾 場景過濾、用戶過濾、商品過濾、商家過濾等，通常使用array字段進行屬性值的過濾； 3. 聚合 基于明細數(shù)據(jù)聚合計算實時指標，如SUM、COUNT_DISTINCT計算等； 4. A/B Test 通過解析日志埋點中的分桶字段，計算測試桶與基準桶之間的實時Gap數(shù)據(jù)； 5. 指定Key 在排查問題或觀測核心商家指標時，經(jīng)常需要指定商家ID、商品ID查詢實時指標，需要基于明細實時表中的id字段過濾后進行聚合計算； 6. 流批一體 由于實時數(shù)倉僅保留最近2天的數(shù)據(jù)，在面對計算同比、環(huán)比等需求時，就需要讀取離線數(shù)據(jù)與實時數(shù)據(jù)進行關聯(lián)計算，這樣產(chǎn)品/運營在看上層報表展現(xiàn)時就能直觀看到今年實時數(shù)據(jù)和去年同期的對比表現(xiàn)。 03
實時數(shù)倉架構
基于上訴典型實時數(shù)倉訴求，我們抽象出了如下圖所示的典型實時數(shù)倉架構。
實時采集的業(yè)務日志經(jīng)過實時計算Flink清洗過濾，將結果寫到OLAP引擎里面，OLAP引擎既要支持多維的交互式查詢、還要支持KV查詢和流批一體查詢，來滿足我們各種各樣的業(yè)務訴求，同時OLAP引擎還需要對接上層構建的各種業(yè)務應用，提供在線服務。 基于這個典型的實時架構，下面則是我們搜索推薦場景下的實時架構演進過程。
1. 實時數(shù)倉架構 1.0版 首先是實時數(shù)倉架構1.0版，如下圖所示，這個版本主要是由3個板塊組成：
數(shù)據(jù)采集 在數(shù)據(jù)采集層，我們將上游實時采集的數(shù)據(jù)分為用戶行為日志和商品維表、商家維表、用戶維表等，為什么會有維表呢？因為每個業(yè)務在埋點時不會將所有信息全部埋在日志里面，如果所有信息都由用戶行為日志承載，靈活性將會特別差，所以維表在業(yè)務上擔任信息擴展的角色。 采集的用戶行為日志將會實時寫入實時計算Flink，用戶維表、商品維表等維表數(shù)據(jù)統(tǒng)一歸檔至MaxCompute中，在初步計算后將會通過數(shù)據(jù)同步工具（DataX）同步至批處理引擎中。
數(shù)據(jù)處理 在數(shù)據(jù)處理層中，流處理部分，由Flink對實時寫入的用戶行為日志數(shù)據(jù)做初步處理，具體的處理包括數(shù)據(jù)解析、清洗、過濾、關聯(lián)維表等。 批處理部分，為了在數(shù)據(jù)查詢和服務中根據(jù)屬性查詢、篩選數(shù)據(jù)，需要在Flink作業(yè)中將用戶的實時行為和維表做關聯(lián)計算，這就需要批處理系統(tǒng)能夠支持高QPS查詢，當時搜索業(yè)務的單表QPS最高達6500萬，經(jīng)過多方調研，選擇了HBase作為維表的批處理引擎。 Flink作業(yè)中基于用戶ID、商品ID、商家ID等關聯(lián)HBase維表中的屬性數(shù)據(jù)，輸出一張包含多個維度列的實時寬表，再輸出到OLAP引擎。為了簡化Flink實時作業(yè)，降低實時計算的壓力，我們沒有在Flink中使用窗口函數(shù)做指標的聚合工作，只是對實時日志簡單過濾、關聯(lián)后直接輸明細數(shù)據(jù)到下游，這就要求下游引擎需要提既要支持KV查詢、OLAP多維交互式查詢，還要支持流批一體查詢。
數(shù)據(jù)查詢和服務 在第一版架構中我們使用的是Lightning引擎來承載Flink輸出的實時明細數(shù)據(jù)，并基于Lightning實現(xiàn)查詢流批一體，再對上層應用提供統(tǒng)一的實時數(shù)據(jù)查詢服務。 但是Lightning的局限性也是非常明顯的：第一是查詢方式是非SQL類型不夠友好，若是寫SQL需要二次封裝。第二是Lightning采用的是公共集群，多用戶資源不隔離，當需要查詢大量數(shù)據(jù)時，容易出現(xiàn)性能波動和資源排隊等問題，使得查詢耗時較久，在實際業(yè)務場景使用中有一定的限制。
2. 實時數(shù)倉架構 2.0版
基于Lightning的限制，我們希望能找到一款替代產(chǎn)品，它的能力要在Lightning之上，支撐OLAP的交互式查詢以及高QPS的維表校驗查詢。于是在2.0版的實時數(shù)倉架構中，我們開始接入Hologres。 最開始，我們只是用Hologres替代Lightning提供KV、OLAP查詢能力，解決了Lightning所帶來的局限性。這樣的架構看起來很好，但因為還需要經(jīng)過HBase存儲維表，隨著數(shù)據(jù)量的增長，數(shù)據(jù)導入至HBase的時間也越長，實際上浪費了大量資源，并且隨著線上服務實時性要求增加，HBase的弊端也越來越明顯。 而Hologres的核心能力之一是加速離線數(shù)據(jù)，尤其是針對MaxCompute的數(shù)據(jù)，在底層與其資源打通，能加速查詢。所以我們就萌生了將Hologres替代HBase的想法，以Hologres為統(tǒng)一的存儲，數(shù)據(jù)也無需再導入導出，保證了一份數(shù)據(jù)一份存儲。 于是，最終的實時數(shù)倉架構2.0版如下：
-
數(shù)據(jù)處理階段直接將用戶維表、商品維表、商家維表以行存模式存儲到Hologres中，以此替代Hbase存儲。Flink中的作業(yè)可以直接讀取Hologres的維表，與行為日志進行關聯(lián)。
-
在數(shù)據(jù)查詢和服務階段，我們將Flink處理輸出的實時明細數(shù)據(jù)統(tǒng)一存儲至Hologres，由Hologres提供高并發(fā)的數(shù)據(jù)實時寫入和實時查詢。
04
基于Hologres的最佳實踐
實時數(shù)倉2.0版本因為Hologres的接入，既精簡了架構，節(jié)約了資源，也真正實現(xiàn)了流批一體。這個架構也一直使用至今，下面是Hologres基于此架構在搜索推薦具體多個業(yè)務場景中的最佳實踐。
1. 行存最佳實踐 Hologres支持行存和列存兩種存儲模式，行存對于key-value查詢場景比較友好，適合基于primary key的點查和 scan，可以將行存模式的表看作是一張類似于Hbase的表，用不同的表存儲不同實體的維度信息。在Flink實時作業(yè)中可以高效地從Hologres行存表中讀取維表數(shù)據(jù)，與實時流中的實體進行關聯(lián)。
2. 列存最佳實踐 Hologres中默認表的存儲模式是列存，列存對于OLAP場景較為友好，適合各種復雜查詢。 基于Hologres的列存模式，我們搭建了搜索、推薦業(yè)務的實時數(shù)據(jù)查詢看板，在實時看板上可以支持數(shù)十個不同維度的實時篩選過濾。 在最高峰值每秒寫入條數(shù)（RPS）超過500萬的同時仍然可以秒級查詢多個維度篩選下的聚合指標結果。 同時Hologres表支持設置表數(shù)據(jù)TTL的屬性，一般我們將一張實時表的生命周期設置為48小時，超過48小時的數(shù)據(jù)會被自動刪除，在實時看板中支持用戶對最近兩天內的實時數(shù)據(jù)進行查詢，避免了不必要的資源浪費。
3. 流批一體最佳實踐 Hologres不僅支持基于實時明細的數(shù)據(jù)的即席分析查詢，也支持直接加速查詢MaxCompute離線表，因此我們利用這一特性，實現(xiàn)流批一體的查詢（實時離線聯(lián)邦分析）。
在天貓大促活動中，我們利用Hologres的聯(lián)邦分析能力搭建了核心商家的目標完成率、去年同期對比看板，為運營算法決策提供了有效的數(shù)據(jù)支撐。 其中目標完成率看板開發(fā)借助實時離線聯(lián)邦分析變得更為簡單，即通過Hologres實時查詢大促當天的指標，并用實時表的當天指標除以離線表中設定的目標指標，從而讓運營能夠看到實時更新的核心商家當天目標的完成情況。 去年同期對比實時看板的計算邏輯也是類似的，可以在SQL中將實時表與去年的離線表JOIN后進行關鍵指標的同比計算。 所有的計算都可以在Hologres中完成，通過SQL表達計算邏輯即可，無需額外的數(shù)據(jù)開發(fā)工作，一份數(shù)據(jù)一套代碼，降低開發(fā)運維難度，真正實現(xiàn)流批一體。
4. 高并發(fā)實時Update 在一些場景下，我們不僅需要向OLAP引擎實時增量寫入數(shù)據(jù)，還需要對寫入的數(shù)據(jù)進行更新操作（update）。 例如，在訂單成交歸因時，F(xiàn)link實時作業(yè)會將訂單提交數(shù)據(jù)流與進度點擊數(shù)據(jù)流進行雙流JOIN，并且在還需要取訂單提交前的最后一次點擊事件進行關聯(lián)。當有多條點擊事件先后到達時，我們就需要更新訂單歸因明細數(shù)據(jù)，此時需要利用Hologres的update支持，通過數(shù)據(jù)的主鍵更新原有數(shù)據(jù)，保證成交歸因的數(shù)據(jù)準確性。在實踐中Hologres的update寫入峰值能達50W，滿足業(yè)務高并發(fā)實時更新需求。 05
未來展望
我們希望未來基于Hologres引擎持續(xù)改進現(xiàn)有的實時數(shù)倉，主要的方向主要有：
1. 實時表JOIN Hologres現(xiàn)階段支持百億級表與億級表之間的JOIN，秒級查詢響應?；谶@個特性，期望將原本需要在數(shù)據(jù)處理階段由Flink實時作業(yè)完成的維表關聯(lián)工作，可以改為在查詢Hologres階段實時JOIN計算。例如表1是明細數(shù)據(jù)表，表2是用戶維表，在查詢階段的JOIN可以通過篩選用戶維表，然后與明細數(shù)據(jù)表關聯(lián)，達到篩選過濾數(shù)據(jù)的目的。這樣的改進將帶來幾個好處：
-
減少Hologres中的數(shù)據(jù)存儲量，避免實時表中存儲大量的數(shù)據(jù)冗余（如：同一個商品ID的數(shù)據(jù)會重復存儲）；
-
提升實時數(shù)據(jù)中維度屬性的時效性，在查詢階段實時JOIN維表數(shù)據(jù)后進行計算，可以使得我們在通過維度篩選數(shù)據(jù)的時候，始終用的是最新的維度屬性。
2. 持久化存儲 我們未來將探索如何將常用維度的實時數(shù)據(jù)，利用Hologres的計算和存儲能力，將計算結果持久化存儲。 嘉賓介紹：
張照亮
阿里巴巴 | 高級技術專家
張照亮，阿里花名"士恒"，阿里巴巴搜索事業(yè)部高級技術專家，目前主要負責搜推大數(shù)據(jù)解決方案迭代演進和部分業(yè)務側數(shù)據(jù)產(chǎn)品架構設計和研發(fā)工作。
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
