簡介： 本文將會為您分享天貓國際如何通過Hologres實現(xiàn)計算、存儲、服務(wù)統(tǒng)一的實時交互式分析。
作者：景聞 阿里巴巴數(shù)據(jù)技術(shù)及產(chǎn)品部數(shù)據(jù)技術(shù)專家
一.業(yè)務(wù)背景
天貓國際營銷活動分析實時排行榜是在大促中幫助業(yè)務(wù)快速的分析商家或者品牌的交易和流量的數(shù)據(jù)情況，給下一步大促的銷售目標，流量蓄水等等做出運營決策；尤其是在活動當天當發(fā)現(xiàn)行業(yè)的問題之后，僅僅靠子行業(yè)的拆分不足以確定具體的問題，也不一定有具體的業(yè)務(wù)抓手，所以需要有到商家、品牌和商品粒度的數(shù)據(jù)來快速定位問題。
二.原技術(shù)方案
原始技術(shù)方案的架構(gòu)如下圖所示，可以看到是非常典型的Lambda架構(gòu)，實時和離線分別是兩套系統(tǒng)，離線數(shù)據(jù)通過MaxCompute（原MaxCompute）輕度匯總同步至MySQL，實時增量數(shù)據(jù)通過Blink清洗后同步至HBase，最后在數(shù)據(jù)服務(wù)里面以View的形式將實時和離線數(shù)據(jù)合并，提供對外服務(wù)。
整個架構(gòu)在實際業(yè)務(wù)執(zhí)行中會有非常多的痛點，典型的有以下幾個：
1）ADS層模型任務(wù)多
流計算和批處理任務(wù)都分別需要開發(fā)基于商品，賣家，品牌粒度的滿足應(yīng)用層的三個ADS模型數(shù)據(jù)，三個數(shù)據(jù)同步任務(wù)，分別需要創(chuàng)建三個oneservice服務(wù)，滿足三個數(shù)據(jù)模塊應(yīng)用。
2）計算過程數(shù)據(jù)膨脹
在營銷活動分析的場景下，看數(shù)據(jù)都是基于天貓國際業(yè)務(wù)類型和行業(yè)為大前提，因此通常在離線和實時的計算任務(wù)中，我們都是并行同時計算好不同的bu類型和所有的行業(yè)粒度的數(shù)據(jù)，這就導(dǎo)致了計算的過程中的數(shù)據(jù)的大量膨脹。
3）流批分離
當前產(chǎn)品上根據(jù)時間進行選擇讀取實時數(shù)據(jù)還是離線數(shù)據(jù)，三天之內(nèi)的數(shù)據(jù)通過實時任務(wù)計算的數(shù)據(jù)，三天前的歷史數(shù)據(jù)是通過批處理任務(wù)計算的離線數(shù)據(jù)，存在兩套任務(wù)同時運行，增加了運維的復(fù)雜性。
4）產(chǎn)品搭建邏輯復(fù)雜
每一個產(chǎn)品展示的報表模塊都需要通過實時數(shù)據(jù)提供的os接口和離線數(shù)據(jù)提供的os來進行，產(chǎn)品搭建的工作量比較大，通過時間來判斷什么時候來讀取離線os的數(shù)據(jù)，什么時候來讀取實時os的數(shù)據(jù)，邏輯比較繁雜。
三.架構(gòu)升級思考策略
思考：為了提升研發(fā)效率和產(chǎn)品搭建的效率，我們只需要開發(fā)到DWD層的明細數(shù)據(jù)，明細數(shù)據(jù)只需要存儲葉子類目，在交互式分層層面按需去關(guān)聯(lián)行業(yè)維表，來提供對外隨機的查詢服務(wù)，從而節(jié)省了構(gòu)建ADS層的多個模型數(shù)據(jù)以及數(shù)據(jù)服務(wù)接口的時間，在產(chǎn)品搭建上基于一個數(shù)據(jù)接口就能滿足多個不同的應(yīng)用場景的數(shù)據(jù)服務(wù)，提升產(chǎn)品搭建層面的效率，降低了產(chǎn)品搭建時的邏輯代碼的復(fù)雜性。
策略：我們希望能夠有一款產(chǎn)品，能統(tǒng)一計算寫入任務(wù)，做到流批統(tǒng)一，對外提供自由的交互式查詢服務(wù)。
四.產(chǎn)品技術(shù)選型
在產(chǎn)品技術(shù)選型之前，需要先梳理業(yè)務(wù)需要用到的表以及數(shù)據(jù)量，選取幾張最具代表性的表用于驗證實際業(yè)務(wù)場景中產(chǎn)品技術(shù)可行性，以及驗證關(guān)鍵指標性能問，包括查詢QPS、寫入TPS等。主要選取的表以及數(shù)據(jù)量如下：
（1） 交易明細數(shù)據(jù)表
| buyer_id + item_id +order_id |
| 20191111 | 4800W |
| 20200618 | 600W |
| 20200721 | 300W |
（2）流量IPV明細數(shù)據(jù)表
| visitor_id + item_id |
| 20191111 | 2.1億 |
| 20200618 | 7000W |
| 20200721 | 2600W |
在技術(shù)選型方面，我們鎖定了兩款產(chǎn)品，一款是AnalyticDB for MySQL，一款是Hologres。ADB是阿里云數(shù)據(jù)庫事業(yè)部團隊提供的云原生數(shù)據(jù)倉庫AnalyticDB MySQL版，是阿里巴巴自主研發(fā)的海量數(shù)據(jù)實時高并發(fā)在線分析云計算服務(wù)。Hologres是阿里云計算平臺事業(yè)部提供的一款全面兼容PostgreSQL協(xié)議并與大數(shù)據(jù)生態(tài)無縫打通的實時交互式分析產(chǎn)品。從實際業(yè)務(wù)場景出發(fā)，兩者的主要區(qū)別有以下幾點：
1）與MaxCompute的打通性
Hologres：與MaxCompute打通，可以直接通過外部表讀取MaxCompute數(shù)據(jù)進行查詢分析，無需存儲就能查詢。
ADB：能加速查詢MaxCompute，提供復(fù)雜交互式分析、實時混合數(shù)據(jù)倉庫等多種場景。
2）成本方面
從我們每年ADB和Hologres的的單價上對比，Hologres成本相比ADB略微低。
3）靈活度
均能滿足OLAP場景，Hologres兼容兼容PostgreSQL生態(tài)，ADB堅兼容MySQL協(xié)議，均能滿足實時和離線批量的數(shù)據(jù)導(dǎo)入和分析。
4）性能
以下是Hologers的測試性能，數(shù)據(jù)量和大小均以MaxCompute的存儲格式為準，沒有進行一些特殊的索引和優(yōu)化處理。
| 數(shù)據(jù)量 | 測試項 | 響應(yīng)時間
| 4600W(20.64GB) | SUM | 2.7s
| 2300W(5.04GB) | SUM | 1.1s
| 4600W(20.64GB) | COUNT | 2.5s
| 2300W(5.04GB) | COUNT | 1.0s
| 4600W(5.04GB) | COUNT(distinct) | 2.8s
| 2300W(5.04GB) | COUNT(distinct) | 1.6s
| 4600W(20.64GB) | AVG | 1.7s
| 2300W(5.04GB) | AVG | 0.9s
| 4600W(20.64GB) | ROW_NUMBER | 2.6s
| 2300W(5.04GB) | AVG | 2.2s
結(jié)論：綜合很多種種因素，我們最終選擇Hologres作為交互式分析的查詢引擎
五.技術(shù)架構(gòu)升級
使用Hologres后的架構(gòu)如下圖所示。
技術(shù)架構(gòu)升級后，主要有以下幾個優(yōu)勢：
1. 計算統(tǒng)一
商品和賣家以及品牌粒度頁面的數(shù)據(jù)統(tǒng)一通過一個實時計算任務(wù)來統(tǒng)一計算，計算過程中不關(guān)聯(lián)行業(yè)和業(yè)務(wù)BU類型的維表，在交互式分析端按需統(tǒng)一通過商品ID和葉子類目ID進行關(guān)聯(lián)維表查詢。提升了研發(fā)的效率和降低了運維的難度，也沒有做到計算任務(wù)的膨脹，節(jié)省了計算資源。
2. 存儲統(tǒng)一
統(tǒng)一通過Hologres的內(nèi)部分區(qū)表的形式存儲實時寫入的交易和流量明細數(shù)據(jù)，提供的統(tǒng)一的數(shù)據(jù)管理和維護，將存儲統(tǒng)一即可實現(xiàn)同庫間的任意交互式分析查詢服務(wù)。
3. 服務(wù)統(tǒng)一
商品和賣家以及品牌粒度的頁面均可以通過一份通用的具有占位符的FBI的數(shù)據(jù)集來實現(xiàn)，通過FBI的報表模式實現(xiàn)數(shù)據(jù)可視化，提升了產(chǎn)品搭建的效率。
六.Hologres實戰(zhàn)
下面將會講述Hologres在實時排行榜中的具體實踐過程：
1.建表模型設(shè)計
首先第一個是表設(shè)計，合理的表設(shè)計能夠大大提升查詢效率，尤其是當數(shù)據(jù)量變大的時候，相關(guān)索引的選擇和配置對性能優(yōu)化有著非常大的作用。所以在Hologres中創(chuàng)建表之前，一定要想清楚表的使用場景，查詢邏輯。
在該方案中，由于需要涉及到交易的明細數(shù)據(jù)按照商品,賣家，品牌粒度匯總和流量數(shù)據(jù)進行join，同時還需要按照行業(yè)以及bu類型進行檢索，主要用到的表DDL如下：
sql
CREATE TABLE IF NOT EXISTS public.dwd_intl_trd_pay_itm_buyer_ri(
stat_date text not null
,stat_hour text not null
,bu_id text not null
,bu_id_level1 text not null
,bu_id_level2 text not null
,item_id text not null
,item_title text
,item_tier text
,seller_id text
,seller_nick text
,seller_level text
,brand_id text
,brand_name text
,cate_id text not null
,pay_time text
,buyer_id text not null
,div_idx_actual_total_fee float8
,is_wap text
,is_jhs text
,biz_order_id text not null
,buy_amount int8
,PRIMARY KEY (stat_date,stat_hour,item_id,buyer_id,biz_order_id)
)
PARTITION BY LIST(stat_date);
CALL SET_TABLE_PROPERTY('public.dwd_intl_trd_pay_itm_buyer_ri', 'orientation', 'column');
CALL set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'storage_format', 'segment');
CALL set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'segment_key', 'stat_date,stat_hour,bu_id,bu_id_level1,bu_id_level2,cate_id');
call set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'distribution_key', 'stat_date,stat_hour');
CALL set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'shard_count’, ‘30');
CREATE TABLE IF NOT EXISTS public.dwd_intl_log_ipv_itm_visitor_ri(
stat_date text not null
,stat_hour text not null
,bu_id text not null
,bu_id_level1 text not null
,bu_id_level2 text not null
,item_id text not null
,item_title text
,seller_id text
,seller_nick text
,brand_id text
,brand_name text
,cate_id text not null
,visitor_id text not null
,ipv int8
,PRIMARY KEY (stat_date,stat_hour,item_id,visitor_id)
)
PARTITION BY LIST(stat_date);
CALL SET_TABLE_PROPERTY('public.dwd_intl_log_ipv_itm_visitor_ri', 'orientation', 'column');
CALL set_table_property('public.dwd_intl_log_ipv_itm_visitor_ri', 'storage_format', 'segment');
CALL set_table_property('public.dwd_intl_log_ipv_itm_visitor_ri', 'segment_key', 'stat_date,stat_hour,bu_id,bu_id_level1,bu_id_level2,cate_id');
call set_table_property('public.dwd_intl_log_ipv_itm_visitor_ri', 'distribution_key', 'stat_date,stat_hour');
CALL set_table_property('public.dwd_intl_log_ipv_itm_visitor_ri', 'shard_count', ‘50');
同時借助Hologres的表屬性設(shè)置，根據(jù)業(yè)務(wù)場景針對性優(yōu)化，主要有以下幾點：
（1）基礎(chǔ)屬性的設(shè)置
distribution_key
指定分布列，數(shù)據(jù)將按照指定列，shuffle到各個shard
set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'distribution_key', 'stat_date,stat_hour,brand_id,seller_id');
clustering_key
指定一些列作為聚簇索引
set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri‘, 'clustering_key‘，'stat_date,stat_hour,cate_id');
segement_key
文件索引，數(shù)據(jù)按該索引劃分文件，可以通過segement_key快速索引到某一文件
set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'segment_key', 'stat_date,stat_hour,bu_id,bu_id_level1,bu_id_level2,cate_id');
（2）高級屬性的設(shè)置
設(shè)置合理的TableGroup
Table Group非常關(guān)鍵的作用就是做local join，從而大大提升join效率，尤其是多表和比較大數(shù)據(jù)量join的時候
call set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'colocate_with', 'public.dwd_intl_log_ipv_itm_visitor_ri');
設(shè)置Shard_count
數(shù)據(jù)量：7億/230GB的數(shù)據(jù)量，設(shè)置在2Kcore左右，交易30和流量50
實例資源：1個shard至少需要1個core來負責計算
寫入性能：根據(jù)交易和流量的RPS來指定
Join需求：有奪標join的查詢case時，需要考慮TableGroup
sql
CALL set_table_property('public.dwd_intl_trd_pay_itm_buyer_ri', 'shard_count', '30');
CALL set_table_property('public.dwd_intl_log_ipv_itm_visitor_ri', 'shard_count', '30');
通過一系列的優(yōu)化，在實際業(yè)務(wù)場景中達到的優(yōu)化效果如下：
1）用戶增加五端通模塊從90s-->8s
2）淘寶直播模塊查詢從9s-->2s
3）當前實時查詢1.8s
2.Hologres與實時Blink的融合
當前流計算任務(wù)的開發(fā)是基于dataphin平臺上采用BlinkSql進行的，這個平臺讓實時任務(wù)的開發(fā)變得相當?shù)娜菀祝@里主要記錄下當Hologres作為實時任務(wù)的sink的時候的一些需要注意的點：
1）sink表創(chuàng)建
- 在實時任務(wù)開發(fā)的時候，任務(wù)的sink operator需要寫到Hologres的時候，需要在dataphin平臺上創(chuàng)建源表，這個表需要同Hologres中的表字段和類型都要保持一致，否則就會出現(xiàn)寫入成功，完全查詢不出來數(shù)據(jù)的情況發(fā)生。
2）分區(qū)路由設(shè)置
- 當Hologres中的表是分區(qū)表的時候，實時任務(wù)是寫父表，數(shù)據(jù)會根據(jù)分區(qū)字段進行數(shù)據(jù)的路由動態(tài)寫入子表中(就是分區(qū)表)，但是這個子表需要提前創(chuàng)建好，否則實時任務(wù)會Failouver。分區(qū)子表的創(chuàng)建一般是通過dataworks的離線調(diào)度進行創(chuàng)建，天/周/月的創(chuàng)建都行。
- dataphin設(shè)置：set tovsbi.dwd_intl_log_ipv_itm_visitor_ri.partitionRouter='true'
- sdp原生的設(shè)置：創(chuàng)建sink表的時候，在with后面添加 partitionRouter = 'true'
3）數(shù)據(jù)寫入策略
- 對于Hologres中有設(shè)置主鍵的表，這個時候需要考慮實時任務(wù)寫入Hologres的數(shù)據(jù)寫入策略。insertOrUpdate這個屬性進行控制，Holo導(dǎo)入時默認會丟棄掉重復(fù)的pk，配置為true將開啟Update功能
- dataphin設(shè)置：set tovsbi.dwd_intl_log_ipv_itm_visitor_ri.insertOrUpdate='true'
- sdp原生的設(shè)置：創(chuàng)建sink表的時候，在with后面添加 insertOrUpdate
3.數(shù)據(jù)可視化展現(xiàn)
Hologres兼容PostgreSQL生態(tài)，提供JDBC/ODBC Driver，因此可以直接對接BI工具實現(xiàn)可視化展現(xiàn)，在實際業(yè)務(wù)中，主要用到數(shù)據(jù)服務(wù)（阿里內(nèi)部叫oneservice）和FBI（阿里集團內(nèi)的一款可視化報表工具）。
1）數(shù)據(jù)服務(wù)
在數(shù)據(jù)中臺的數(shù)據(jù)建設(shè)和數(shù)據(jù)服務(wù)的鏈路上，我們常常需要按照生產(chǎn)者和消費者的模式一樣，通過oneservice將我們開發(fā)好的持久化的數(shù)據(jù)提供的統(tǒng)一的數(shù)服務(wù)。最初原生的方案設(shè)計是按照如下鏈路[1]進行的
但是在實際過程中，由于oneservice對于交互分析這樣的場景支持的很弱，尤其是涉及到查詢邏輯涉及到j(luò)oin的實時，就會出現(xiàn)timeout以及一些其他的問題。其次oneservice將查詢query下推到Hologres查詢的時候，oneservice很多的pg生態(tài)的語法都不支持。最終我們通過上圖的鏈路[2]也就是通過FBI內(nèi)置的Postgresql引擎來直接連Hologres實現(xiàn)數(shù)據(jù)查詢服務(wù)的。
2）FBI可視化
數(shù)據(jù)集動態(tài)配置
FBI層面通過創(chuàng)建數(shù)據(jù)集，將商品，賣家，品牌的三個頁面統(tǒng)一分析，力爭通過一個數(shù)據(jù)集來動態(tài)實現(xiàn)查詢服務(wù)，這里需要涉及到數(shù)據(jù)集中應(yīng)用到的占位符和基于vilocity語法來實現(xiàn)動態(tài)的配置。
Python
from dwd_intl_trd_pay_itm_buyer_ri
where
stat_date = '${bizdate:20200722}'
#if ((! ${bu_level_two} ) and (${bu_level_one} == "111"))
and bu_id = '${bu_level_one}'
#elseif ((! ${bu_level_two} ) and (${bu_level_one} != "111"))
and bu_id_level2 = '${bu_level_two}'
#elseif (( ${bu_level_two} ) and (${bu_level_one} == "111"))
and bu_id = '${bu_level_one}'
#elseif (( ${bu_level_two} ) and (${bu_level_one} != "111"))
and bu_id_level1 = '${bu_level_one}'
#else
and bu_id_level1 = '${bu_level_one}'
#end
group by
'${dims}'
頁面布局設(shè)計
FBI的頁面布局設(shè)計這個比較簡單，直接通過報表的模式展示即可，但是需要同營銷活動分析的級聯(lián)模式保持一致，尤其是涉及到行級關(guān)聯(lián)的一些地方還是需要一些技巧和設(shè)置的，否則初始化的性能不太好。最終的頁面和查詢?nèi)缦拢?/p>
七.業(yè)務(wù)價值
總結(jié)來說，使用Hologres之后，除了上面講訴的做到了計算、存儲、服務(wù)統(tǒng)一的優(yōu)勢之外，從業(yè)務(wù)上來說還有以下幾個突出價值：
1.提升數(shù)據(jù)分析效率
將公共層的明細數(shù)據(jù)存入Hologres，提供給業(yè)務(wù)方能夠進行隨意交互式分析，相比于以前的cube模型的需要關(guān)聯(lián)多個模型的取數(shù)方式，極大的提升了數(shù)據(jù)分析的效率。
2.節(jié)省數(shù)據(jù)回刷資源
整個公共層明細數(shù)據(jù)在行業(yè)的維度只包含葉子類目數(shù)據(jù)，在每年的行業(yè)類目調(diào)整中，不會因為類目維表的變更，導(dǎo)致進行回刷數(shù)據(jù)，極大的節(jié)省了回刷的數(shù)據(jù)資源。
八.未來規(guī)劃
1.節(jié)省存儲空間
由于需要看歷史數(shù)據(jù)，所以需要保存最近400天的數(shù)據(jù)，明細數(shù)據(jù)太過于龐大，因此需要將歷史數(shù)據(jù)進行匯總，有成交的商品是27W X 400 = 1億+(大促會比較大) 降低存儲壓力，同時也會同Hologres技術(shù)團隊一起引入高壓縮比的存儲格式。
2.繼續(xù)優(yōu)化當前技術(shù)
當前通過Hologres的交互式分析技術(shù)和FBI的可視化工具能夠做到查詢均在3s左右，但還是有很多的一些可以化的細節(jié)的地方，比如查詢的優(yōu)化，F(xiàn)BI可視化工具搭建以及使用的一些小問題上，需要結(jié)合Hologres技術(shù)團隊，F(xiàn)BI的技術(shù)團隊一起來共建，反哺技術(shù)鏈的建設(shè)更加完善。
3.數(shù)據(jù)回刷方案
當前的技術(shù)方案不存在因為行業(yè)的頻繁調(diào)整而帶來的大量歷史數(shù)據(jù)回刷的問題，但是如果存在一些邏輯的調(diào)整或者一些不可控的因素導(dǎo)致需要回刷歷史數(shù)據(jù)，因此需要設(shè)計實時的數(shù)據(jù)回刷方案。
4.復(fù)用到更多交互式分析場景
由于當前的Hologres中存儲的大量的交易和流量的IPV明細數(shù)據(jù)，因此在很多的數(shù)據(jù)看板，數(shù)據(jù)分析中都存在可以直接復(fù)用當前數(shù)據(jù)，直接在數(shù)據(jù)集上進行自由的交互式分析，提升數(shù)據(jù)研發(fā)，數(shù)據(jù)分析，產(chǎn)品搭建等研發(fā)效率。
文章鏈接>>https://developer.aliyun.com/article/776646?spm=a2c6h.12873581.0.0.4bcb56813ayX86&groupCode=ai
