天猫国际通过Hologres进行排行榜的实时交互式分析
簡介：?本文將會為您分享天貓國際如何通過Hologres實(shí)現(xiàn)計(jì)算、存儲、服務(wù)統(tǒng)一的實(shí)時(shí)交互式分析。
作者：景聞 阿里巴巴數(shù)據(jù)技術(shù)及產(chǎn)品部數(shù)據(jù)技術(shù)專家
一.業(yè)務(wù)背景
天貓國際營銷活動分析實(shí)時(shí)排行榜是在大促中幫助業(yè)務(wù)快速的分析商家或者品牌的交易和流量的數(shù)據(jù)情況，給下一步大促的銷售目標(biāo)，流量蓄水等等做出運(yùn)營決策；尤其是在活動當(dāng)天當(dāng)發(fā)現(xiàn)行業(yè)的問題之后，僅僅靠子行業(yè)的拆分不足以確定具體的問題，也不一定有具體的業(yè)務(wù)抓手，所以需要有到商家、品牌和商品粒度的數(shù)據(jù)來快速定位問題。
二.原技術(shù)方案
原始技術(shù)方案的架構(gòu)如下圖所示，可以看到是非常典型的Lambda架構(gòu)，實(shí)時(shí)和離線分別是兩套系統(tǒng)，離線數(shù)據(jù)通過MaxCompute（原MaxCompute）輕度匯總同步至MySQL，實(shí)時(shí)增量數(shù)據(jù)通過Blink清洗后同步至HBase，最后在數(shù)據(jù)服務(wù)里面以View的形式將實(shí)時(shí)和離線數(shù)據(jù)合并，提供對外服務(wù)。
整個(gè)架構(gòu)在實(shí)際業(yè)務(wù)執(zhí)行中會有非常多的痛點(diǎn)，典型的有以下幾個(gè)：
1）ADS層模型任務(wù)多
流計(jì)算和批處理任務(wù)都分別需要開發(fā)基于商品，賣家，品牌粒度的滿足應(yīng)用層的三個(gè)ADS模型數(shù)據(jù)，三個(gè)數(shù)據(jù)同步任務(wù)，分別需要創(chuàng)建三個(gè)oneservice服務(wù)，滿足三個(gè)數(shù)據(jù)模塊應(yīng)用。
2）計(jì)算過程數(shù)據(jù)膨脹
在營銷活動分析的場景下，看數(shù)據(jù)都是基于天貓國際業(yè)務(wù)類型和行業(yè)為大前提，因此通常在離線和實(shí)時(shí)的計(jì)算任務(wù)中，我們都是并行同時(shí)計(jì)算好不同的bu類型和所有的行業(yè)粒度的數(shù)據(jù)，這就導(dǎo)致了計(jì)算的過程中的數(shù)據(jù)的大量膨脹。
3）流批分離
當(dāng)前產(chǎn)品上根據(jù)時(shí)間進(jìn)行選擇讀取實(shí)時(shí)數(shù)據(jù)還是離線數(shù)據(jù)，三天之內(nèi)的數(shù)據(jù)通過實(shí)時(shí)任務(wù)計(jì)算的數(shù)據(jù)，三天前的歷史數(shù)據(jù)是通過批處理任務(wù)計(jì)算的離線數(shù)據(jù)，存在兩套任務(wù)同時(shí)運(yùn)行，增加了運(yùn)維的復(fù)雜性。
4）產(chǎn)品搭建邏輯復(fù)雜
每一個(gè)產(chǎn)品展示的報(bào)表模塊都需要通過實(shí)時(shí)數(shù)據(jù)提供的os接口和離線數(shù)據(jù)提供的os來進(jìn)行，產(chǎn)品搭建的工作量比較大，通過時(shí)間來判斷什么時(shí)候來讀取離線os的數(shù)據(jù)，什么時(shí)候來讀取實(shí)時(shí)os的數(shù)據(jù)，邏輯比較繁雜。
三.架構(gòu)升級思考策略
思考：為了提升研發(fā)效率和產(chǎn)品搭建的效率，我們只需要開發(fā)到DWD層的明細(xì)數(shù)據(jù)，明細(xì)數(shù)據(jù)只需要存儲葉子類目，在交互式分層層面按需去關(guān)聯(lián)行業(yè)維表，來提供對外隨機(jī)的查詢服務(wù)，從而節(jié)省了構(gòu)建ADS層的多個(gè)模型數(shù)據(jù)以及數(shù)據(jù)服務(wù)接口的時(shí)間，在產(chǎn)品搭建上基于一個(gè)數(shù)據(jù)接口就能滿足多個(gè)不同的應(yīng)用場景的數(shù)據(jù)服務(wù)，提升產(chǎn)品搭建層面的效率，降低了產(chǎn)品搭建時(shí)的邏輯代碼的復(fù)雜性。
策略：我們希望能夠有一款產(chǎn)品，能統(tǒng)一計(jì)算寫入任務(wù)，做到流批統(tǒng)一，對外提供自由的交互式查詢服務(wù)。
四.產(chǎn)品技術(shù)選型
在產(chǎn)品技術(shù)選型之前，需要先梳理業(yè)務(wù)需要用到的表以及數(shù)據(jù)量，選取幾張最具代表性的表用于驗(yàn)證實(shí)際業(yè)務(wù)場景中產(chǎn)品技術(shù)可行性，以及驗(yàn)證關(guān)鍵指標(biāo)性能問，包括查詢QPS、寫入TPS等。主要選取的表以及數(shù)據(jù)量如下：
（1） 交易明細(xì)數(shù)據(jù)表
| buyer_id + item_id +order_id | | 20191111 | 4800W | | 20200618 | 600W | | 20200721 | 300W |（2）流量IPV明細(xì)數(shù)據(jù)表
| visitor_id + item_id | | 20191111 | 2.1億 | | 20200618 | 7000W | | 20200721 | 2600W |在技術(shù)選型方面，我們鎖定了兩款產(chǎn)品，一款是AnalyticDB for MySQL，一款是Hologres。ADB是阿里云數(shù)據(jù)庫事業(yè)部團(tuán)隊(duì)提供的云原生數(shù)據(jù)倉庫AnalyticDB MySQL版，是阿里巴巴自主研發(fā)的海量數(shù)據(jù)實(shí)時(shí)高并發(fā)在線分析云計(jì)算服務(wù)。Hologres是阿里云計(jì)算平臺事業(yè)部提供的一款全面兼容PostgreSQL協(xié)議并與大數(shù)據(jù)生態(tài)無縫打通的實(shí)時(shí)交互式分析產(chǎn)品。從實(shí)際業(yè)務(wù)場景出發(fā)，兩者的主要區(qū)別有以下幾點(diǎn)：
1）與MaxCompute的打通性
Hologres：與MaxCompute打通，可以直接通過外部表讀取MaxCompute數(shù)據(jù)進(jìn)行查詢分析，無需存儲就能查詢。
ADB：能加速查詢MaxCompute，提供復(fù)雜交互式分析、實(shí)時(shí)混合數(shù)據(jù)倉庫等多種場景。
2）成本方面
從我們每年ADB和Hologres的的單價(jià)上對比，Hologres成本相比ADB略微低。
3）靈活度
均能滿足OLAP場景，Hologres兼容兼容PostgreSQL生態(tài)，ADB堅(jiān)兼容MySQL協(xié)議，均能滿足實(shí)時(shí)和離線批量的數(shù)據(jù)導(dǎo)入和分析。
4）性能
以下是Hologers的測試性能，數(shù)據(jù)量和大小均以MaxCompute的存儲格式為準(zhǔn)，沒有進(jìn)行一些特殊的索引和優(yōu)化處理。
結(jié)論：綜合很多種種因素，我們最終選擇Hologres作為交互式分析的查詢引擎
五.技術(shù)架構(gòu)升級
使用Hologres后的架構(gòu)如下圖所示。
技術(shù)架構(gòu)升級后，主要有以下幾個(gè)優(yōu)勢：
1. 計(jì)算統(tǒng)一
商品和賣家以及品牌粒度頁面的數(shù)據(jù)統(tǒng)一通過一個(gè)實(shí)時(shí)計(jì)算任務(wù)來統(tǒng)一計(jì)算，計(jì)算過程中不關(guān)聯(lián)行業(yè)和業(yè)務(wù)BU類型的維表，在交互式分析端按需統(tǒng)一通過商品ID和葉子類目ID進(jìn)行關(guān)聯(lián)維表查詢。提升了研發(fā)的效率和降低了運(yùn)維的難度，也沒有做到計(jì)算任務(wù)的膨脹，節(jié)省了計(jì)算資源。
2. 存儲統(tǒng)一
統(tǒng)一通過Hologres的內(nèi)部分區(qū)表的形式存儲實(shí)時(shí)寫入的交易和流量明細(xì)數(shù)據(jù)，提供的統(tǒng)一的數(shù)據(jù)管理和維護(hù)，將存儲統(tǒng)一即可實(shí)現(xiàn)同庫間的任意交互式分析查詢服務(wù)。
3. 服務(wù)統(tǒng)一
商品和賣家以及品牌粒度的頁面均可以通過一份通用的具有占位符的FBI的數(shù)據(jù)集來實(shí)現(xiàn)，通過FBI的報(bào)表模式實(shí)現(xiàn)數(shù)據(jù)可視化，提升了產(chǎn)品搭建的效率。
六.Hologres實(shí)戰(zhàn)
下面將會講述Hologres在實(shí)時(shí)排行榜中的具體實(shí)踐過程：
1.建表模型設(shè)計(jì)
首先第一個(gè)是表設(shè)計(jì)，合理的表設(shè)計(jì)能夠大大提升查詢效率，尤其是當(dāng)數(shù)據(jù)量變大的時(shí)候，相關(guān)索引的選擇和配置對性能優(yōu)化有著非常大的作用。所以在Hologres中創(chuàng)建表之前，一定要想清楚表的使用場景，查詢邏輯。
在該方案中，由于需要涉及到交易的明細(xì)數(shù)據(jù)按照商品,賣家，品牌粒度匯總和流量數(shù)據(jù)進(jìn)行join，同時(shí)還需要按照行業(yè)以及bu類型進(jìn)行檢索，主要用到的表DDL如下：
同時(shí)借助Hologres的表屬性設(shè)置，根據(jù)業(yè)務(wù)場景針對性優(yōu)化，主要有以下幾點(diǎn)：
（1）基礎(chǔ)屬性的設(shè)置
distribution_key
指定分布列，數(shù)據(jù)將按照指定列，shuffle到各個(gè)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的時(shí)候
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
實(shí)例資源：1個(gè)shard至少需要1個(gè)core來負(fù)責(zé)計(jì)算
寫入性能：根據(jù)交易和流量的RPS來指定
Join需求：有奪標(biāo)join的查詢case時(shí)，需要考慮TableGroup
通過一系列的優(yōu)化，在實(shí)際業(yè)務(wù)場景中達(dá)到的優(yōu)化效果如下：
1）用戶增加五端通模塊從90s-->8s
2）淘寶直播模塊查詢從9s-->2s
3）當(dāng)前實(shí)時(shí)查詢1.8s
2.Hologres與實(shí)時(shí)Blink的融合
當(dāng)前流計(jì)算任務(wù)的開發(fā)是基于dataphin平臺上采用BlinkSql進(jìn)行的，這個(gè)平臺讓實(shí)時(shí)任務(wù)的開發(fā)變得相當(dāng)?shù)娜菀?#xff0c;這里主要記錄下當(dāng)Hologres作為實(shí)時(shí)任務(wù)的sink的時(shí)候的一些需要注意的點(diǎn)：
1）sink表創(chuàng)建
- 在實(shí)時(shí)任務(wù)開發(fā)的時(shí)候，任務(wù)的sink operator需要寫到Hologres的時(shí)候，需要在dataphin平臺上創(chuàng)建源表，這個(gè)表需要同Hologres中的表字段和類型都要保持一致，否則就會出現(xiàn)寫入成功，完全查詢不出來數(shù)據(jù)的情況發(fā)生。
2）分區(qū)路由設(shè)置
- 當(dāng)Hologres中的表是分區(qū)表的時(shí)候，實(shí)時(shí)任務(wù)是寫父表，數(shù)據(jù)會根據(jù)分區(qū)字段進(jìn)行數(shù)據(jù)的路由動態(tài)寫入子表中(就是分區(qū)表)，但是這個(gè)子表需要提前創(chuàng)建好，否則實(shí)時(shí)任務(wù)會Failouver。分區(qū)子表的創(chuàng)建一般是通過dataworks的離線調(diào)度進(jìn)行創(chuàng)建，天/周/月的創(chuàng)建都行。
- dataphin設(shè)置：set tovsbi.dwd_intl_log_ipv_itm_visitor_ri.partitionRouter='true'
- sdp原生的設(shè)置：創(chuàng)建sink表的時(shí)候，在with后面添加?partitionRouter?= 'true'
3）數(shù)據(jù)寫入策略
- 對于Hologres中有設(shè)置主鍵的表，這個(gè)時(shí)候需要考慮實(shí)時(shí)任務(wù)寫入Hologres的數(shù)據(jù)寫入策略。insertOrUpdate這個(gè)屬性進(jìn)行控制，Holo導(dǎo)入時(shí)默認(rèn)會丟棄掉重復(fù)的pk，配置為true將開啟Update功能
- dataphin設(shè)置：set tovsbi.dwd_intl_log_ipv_itm_visitor_ri.insertOrUpdate='true'
- sdp原生的設(shè)置：創(chuàng)建sink表的時(shí)候，在with后面添加?insertOrUpdate
3.數(shù)據(jù)可視化展現(xiàn)
Hologres兼容PostgreSQL生態(tài)，提供JDBC/ODBC Driver，因此可以直接對接BI工具實(shí)現(xiàn)可視化展現(xiàn)，在實(shí)際業(yè)務(wù)中，主要用到數(shù)據(jù)服務(wù)（阿里內(nèi)部叫oneservice）和FBI（阿里集團(tuán)內(nèi)的一款可視化報(bào)表工具）。
1）數(shù)據(jù)服務(wù)
在數(shù)據(jù)中臺的數(shù)據(jù)建設(shè)和數(shù)據(jù)服務(wù)的鏈路上，我們常常需要按照生產(chǎn)者和消費(fèi)者的模式一樣，通過oneservice將我們開發(fā)好的持久化的數(shù)據(jù)提供的統(tǒng)一的數(shù)服務(wù)。最初原生的方案設(shè)計(jì)是按照如下鏈路[1]進(jìn)行的
但是在實(shí)際過程中，由于oneservice對于交互分析這樣的場景支持的很弱，尤其是涉及到查詢邏輯涉及到j(luò)oin的實(shí)時(shí)，就會出現(xiàn)timeout以及一些其他的問題。其次oneservice將查詢query下推到Hologres查詢的時(shí)候，oneservice很多的pg生態(tài)的語法都不支持。最終我們通過上圖的鏈路[2]也就是通過FBI內(nèi)置的Postgresql引擎來直接連Hologres實(shí)現(xiàn)數(shù)據(jù)查詢服務(wù)的。
2）FBI可視化
數(shù)據(jù)集動態(tài)配置
FBI層面通過創(chuàng)建數(shù)據(jù)集，將商品，賣家，品牌的三個(gè)頁面統(tǒng)一分析，力爭通過一個(gè)數(shù)據(jù)集來動態(tài)實(shí)現(xiàn)查詢服務(wù)，這里需要涉及到數(shù)據(jù)集中應(yīng)用到的占位符和基于vilocity語法來實(shí)現(xiàn)動態(tài)的配置。
pythonfrom dwd_intl_trd_pay_itm_buyer_riwherestat_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}' #elseand bu_id_level1 = '${bu_level_one}'#endgroup by '${dims}'頁面布局設(shè)計(jì)
FBI的頁面布局設(shè)計(jì)這個(gè)比較簡單，直接通過報(bào)表的模式展示即可，但是需要同營銷活動分析的級聯(lián)模式保持一致，尤其是涉及到行級關(guān)聯(lián)的一些地方還是需要一些技巧和設(shè)置的，否則初始化的性能不太好。最終的頁面和查詢?nèi)缦?#xff1a;
七.業(yè)務(wù)價(jià)值
總結(jié)來說，使用Hologres之后，除了上面講訴的做到了計(jì)算、存儲、服務(wù)統(tǒng)一的優(yōu)勢之外，從業(yè)務(wù)上來說還有以下幾個(gè)突出價(jià)值：
1.提升數(shù)據(jù)分析效率
將公共層的明細(xì)數(shù)據(jù)存入Hologres，提供給業(yè)務(wù)方能夠進(jìn)行隨意交互式分析，相比于以前的cube模型的需要關(guān)聯(lián)多個(gè)模型的取數(shù)方式，極大的提升了數(shù)據(jù)分析的效率。
2.節(jié)省數(shù)據(jù)回刷資源
整個(gè)公共層明細(xì)數(shù)據(jù)在行業(yè)的維度只包含葉子類目數(shù)據(jù)，在每年的行業(yè)類目調(diào)整中，不會因?yàn)轭惸烤S表的變更，導(dǎo)致進(jìn)行回刷數(shù)據(jù)，極大的節(jié)省了回刷的數(shù)據(jù)資源。
八.未來規(guī)劃
1.節(jié)省存儲空間
由于需要看歷史數(shù)據(jù)，所以需要保存最近400天的數(shù)據(jù)，明細(xì)數(shù)據(jù)太過于龐大，因此需要將歷史數(shù)據(jù)進(jìn)行匯總，有成交的商品是27W X 400 = 1億+(大促會比較大) 降低存儲壓力，同時(shí)也會同Hologres技術(shù)團(tuán)隊(duì)一起引入高壓縮比的存儲格式。
2.繼續(xù)優(yōu)化當(dāng)前技術(shù)
當(dāng)前通過Hologres的交互式分析技術(shù)和FBI的可視化工具能夠做到查詢均在3s左右，但還是有很多的一些可以化的細(xì)節(jié)的地方，比如查詢的優(yōu)化，FBI可視化工具搭建以及使用的一些小問題上，需要結(jié)合Hologres技術(shù)團(tuán)隊(duì)，FBI的技術(shù)團(tuán)隊(duì)一起來共建，反哺技術(shù)鏈的建設(shè)更加完善。
3.數(shù)據(jù)回刷方案
當(dāng)前的技術(shù)方案不存在因?yàn)樾袠I(yè)的頻繁調(diào)整而帶來的大量歷史數(shù)據(jù)回刷的問題，但是如果存在一些邏輯的調(diào)整或者一些不可控的因素導(dǎo)致需要回刷歷史數(shù)據(jù)，因此需要設(shè)計(jì)實(shí)時(shí)的數(shù)據(jù)回刷方案。
4.復(fù)用到更多交互式分析場景
由于當(dāng)前的Hologres中存儲的大量的交易和流量的IPV明細(xì)數(shù)據(jù)，因此在很多的數(shù)據(jù)看板，數(shù)據(jù)分析中都存在可以直接復(fù)用當(dāng)前數(shù)據(jù)，直接在數(shù)據(jù)集上進(jìn)行自由的交互式分析，提升數(shù)據(jù)研發(fā)，數(shù)據(jù)分析，產(chǎn)品搭建等研發(fā)效率。
?
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的天猫国际通过Hologres进行排行榜的实时交互式分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里云飞天AI加速器+Serverles
- 下一篇： 智能技术改变淘宝，阿里巴巴首次详解核心商