簡(jiǎn)介：?本文主要介紹如何通過(guò) MaxCompute 進(jìn)行海量人群的標(biāo)簽加工，通過(guò) Hologres 進(jìn)行分析建模，從而支持大規(guī)模人群復(fù)雜圈選場(chǎng)景下的交互式體驗(yàn)，以及基于API的數(shù)據(jù)服務(wù)最佳實(shí)踐。

本文作者 劉一鳴 阿里云智能 高級(jí)產(chǎn)品專家

人群圈選系統(tǒng)基本邏輯架構(gòu)

人群圈選并不是一個(gè)新業(yè)務(wù)， 幾乎所有的互聯(lián)網(wǎng)公司都在做，因?yàn)檫@是一個(gè)基本營(yíng)銷場(chǎng)景，選定的人群要發(fā)代金券，要導(dǎo)入流量，要做針對(duì)性促銷，要選擇合適的人群，那怎么做這件事情呢？實(shí)際上要通過(guò)人群的行為特征，采購(gòu)特性，關(guān)注特征，興趣特性，甚至是教育程度等等，把人群劃分成不同的組。通過(guò)劃分人群組，在有限的營(yíng)銷預(yù)算里面，將資源投放給轉(zhuǎn)化率或點(diǎn)擊率最高的人群。

基本的業(yè)務(wù)架構(gòu)邏輯如下圖，自下而上。首先是標(biāo)簽加工引擎，主要以離線加工為主。在標(biāo)簽加工引擎內(nèi)，會(huì)對(duì)用戶歷史的采購(gòu)行為、訪問(wèn)行為、關(guān)注行為等等做很多標(biāo)簽，可以統(tǒng)計(jì)出來(lái)，哪些人對(duì)哪些商品關(guān)注過(guò)多少次，點(diǎn)擊過(guò)多少次，留意過(guò)多少次等等，會(huì)有很多統(tǒng)計(jì)性的屬性在里面。這些標(biāo)簽會(huì)導(dǎo)入到在線畫像服務(wù)引擎內(nèi)，服務(wù)引擎是給運(yùn)營(yíng)人員，廣告主進(jìn)行交互式的查詢，因?yàn)橐鶕?jù)用戶行為特征，篩選出最關(guān)注的用戶群體。這個(gè)用戶群體可能是30天內(nèi)關(guān)注某些商品但是沒有買的群體，或者是相關(guān)的上下游產(chǎn)品，通過(guò)行為特征篩選出來(lái)。篩選過(guò)程是一個(gè)高度交互過(guò)程，因?yàn)橐粋€(gè)人的行為特征是非常復(fù)雜的。所以需要頻繁的選擇某個(gè)條件，去掉某個(gè)條件，條件和條件之間可能會(huì)做合并、去重的操作等等。直到把人群大小限定到預(yù)算可支持的范圍內(nèi)，比如我們要投遞給1萬(wàn)個(gè)人廣告，那要通過(guò)各種限定條件把這1萬(wàn)個(gè)人找出來(lái)。找出來(lái)還不能做直接投遞，還需要對(duì)人群做更細(xì)粒度的分析，通過(guò)歷史數(shù)據(jù)行為分析這1萬(wàn)個(gè)人是不是想要的目標(biāo)人群。之后會(huì)把目標(biāo)群體以投遞包的形式，導(dǎo)出給投遞系統(tǒng)。這是一個(gè)基本業(yè)務(wù)邏輯。

那這個(gè)業(yè)務(wù)需求的背后技術(shù)要求是什么呢？

典型人群業(yè)務(wù)版塊的核心是洞察分析，洞察分析一般的場(chǎng)景是，要支撐幾萬(wàn)個(gè)不同的廣告主，他們會(huì)在平臺(tái)上自由選擇更感興趣的人群，每個(gè)廣告主對(duì)人群的訴求是不一樣的，某些人關(guān)注的購(gòu)買力，有些關(guān)注的是收藏行為。每天數(shù)萬(wàn)廣告主發(fā)出數(shù)百萬(wàn)次的查詢請(qǐng)求，構(gòu)建數(shù)萬(wàn)次各種人群包，各個(gè)系統(tǒng)的計(jì)算復(fù)雜度是要求非常高的。這里的核心訴求包含幾個(gè)點(diǎn)，毫秒級(jí)洞察，因?yàn)樗械牟樵兿Ｍ墙换ナ降?#xff0c;需要在界面上每一次互動(dòng)，每一次下拉菜單，每一次選擇，每一次條件組合，都希望看到一個(gè)互動(dòng)結(jié)果，整個(gè)人群是變大還是變小，目標(biāo)人群是不是跟期望的相似。這一點(diǎn)對(duì)性能要求是非常大的。同時(shí)提醒大家，數(shù)據(jù)一定要脫敏處理，保護(hù)好用戶的個(gè)人隱私，所有的分析都是建立在合規(guī)數(shù)據(jù)基礎(chǔ)之上的分析。

人群圈選系統(tǒng)服務(wù)引擎核心訴求

規(guī)模數(shù)據(jù)上的交互式分析性能

數(shù)萬(wàn)廣告主提交數(shù)百萬(wàn)次的數(shù)據(jù)查詢，需要毫秒級(jí)的響應(yīng)，查的快是必須的。這個(gè)快加了一個(gè)限定詞，是規(guī)模數(shù)據(jù)。百萬(wàn)級(jí)不算規(guī)模，行為日志是非常大的，希望是百億級(jí)別以上，依舊有一個(gè)很好的交互式分析能力，能夠在秒級(jí)響應(yīng)。

靈活篩選能力

用戶的篩選行為多種多樣，等值比較、數(shù)值大小范圍比較、時(shí)間范圍比較等。各種各樣的篩選條件能夠靈活組合，表達(dá)這些篩選結(jié)果就體現(xiàn)出來(lái)計(jì)算引擎的能力。

高吞吐更新能力

用戶標(biāo)簽并不是靜態(tài)的，當(dāng)前一切實(shí)時(shí)化，一切在線化，所有的行為數(shù)據(jù)變化，都希望能夠?qū)崟r(shí)觸發(fā)，實(shí)時(shí)反饋下一時(shí)刻的系統(tǒng)決策。比如最新收藏夾里放了什么商品，這種行為能不能成為在線畫像的一部分。所以對(duì)高實(shí)時(shí)的吞吐能力要求會(huì)很高。

從計(jì)算層面來(lái)講，可以分成下圖幾種計(jì)算模式。

標(biāo)簽過(guò)濾分為等值過(guò)濾，可以用Equal/In/Between，這些過(guò)濾可以在百億級(jí)別上進(jìn)行操作。操作之后的結(jié)果集，要做很多的交差并集，舉個(gè)常見例子，一個(gè)用戶既關(guān)注了競(jìng)品品牌也關(guān)注了本公司商品，卻沒有買，這里面其實(shí)有并的關(guān)系，有差的關(guān)系，有交的關(guān)系。所以這些人群關(guān)系之間要組合，有很高的交差并集計(jì)算。最后還有很強(qiáng)的精確去重的需求，因?yàn)樽罱K要把計(jì)算結(jié)果，變成一個(gè)唯一定位用戶的ID，這個(gè)ID會(huì)用來(lái)做廣告的投遞。那這些需求，在引擎層面上就是數(shù)據(jù)讀取效率怎么樣，如果用行存讀取是不是會(huì)出現(xiàn)IO放大的問(wèn)題，數(shù)據(jù)按行去存，真正過(guò)濾是按照某一列過(guò)濾，但是IO讀取，會(huì)把整行讀取，會(huì)出現(xiàn)IO放大問(wèn)題。列存還會(huì)有索引問(wèn)題、過(guò)濾效果問(wèn)題。計(jì)算算子上表連接時(shí)是Hash JOIN方式還是用Nest Loop JOIN方式。精確去重的效果如何。這些都是對(duì)計(jì)算引擎效率上有很高的要求。所以本質(zhì)上是要解決高效數(shù)據(jù)存儲(chǔ)與過(guò)濾、關(guān)系運(yùn)算內(nèi)存/CPU消耗、精確去重內(nèi)存/CPU消耗問(wèn)題。

這里就有很多不同的解決優(yōu)化思路，是用更多的內(nèi)存還是CPU。行業(yè)內(nèi)大致的思路有兩種。

一種是通過(guò)預(yù)結(jié)算思路，有Kylin/Druid這樣的技術(shù)。這些技術(shù)可以在一些預(yù)定義的維度上，進(jìn)行一次提前的預(yù)加工。預(yù)加工后，數(shù)據(jù)集會(huì)在本質(zhì)上進(jìn)行減少。比如要找一個(gè)用戶群體，關(guān)注了第一個(gè)商品卻沒有關(guān)注第二個(gè)商品。每一個(gè)結(jié)果集都可以用bitmap數(shù)組來(lái)表達(dá)，數(shù)組之間做交差并集效率是非常高的。預(yù)計(jì)算技術(shù)實(shí)際上是把精確去重和交差并集上計(jì)算是有很大好處的。但缺陷也比較明顯，最大的缺陷就是不靈活，同時(shí)完整SQL表達(dá)能力也比較弱。另一種是屬于MPP分布式數(shù)據(jù)庫(kù)技術(shù)，一些通過(guò)列存、分布式、索引方式提供更好的查詢性能。

所以真正落地一套人群篩選方案時(shí)，一般不是只選擇一個(gè)方案。因?yàn)椴还苁穷A(yù)計(jì)算方案還是MPP方案都有一些本質(zhì)的缺陷。

那市場(chǎng)上哪些技術(shù)更適合做存儲(chǔ)和查詢呢？

第一類技術(shù)，大家都比較熟悉的事務(wù)數(shù)據(jù)庫(kù)。事務(wù)數(shù)據(jù)庫(kù)是行存儲(chǔ)，對(duì)單行數(shù)據(jù)寫入存儲(chǔ)效率是非常高的，用來(lái)做查詢，做過(guò)濾統(tǒng)計(jì)，在千萬(wàn)級(jí)以上會(huì)發(fā)現(xiàn)消耗資源是非常大的。所以一般不會(huì)拿TP系統(tǒng)直接做分析操作。

第二類系統(tǒng)，AP系統(tǒng)，是我們常見OLAP系統(tǒng)。這一類系統(tǒng)針對(duì)大規(guī)模數(shù)據(jù)掃描場(chǎng)景做了優(yōu)化，包括利用分布式技術(shù)，列存技術(shù)，壓縮技術(shù)、索引的技術(shù)等等。這類技術(shù)查的都很快，但本質(zhì)缺陷是大部分系統(tǒng)更新上做的不太友好，因?yàn)閿?shù)據(jù)查的快，所以數(shù)據(jù)該緊湊緊湊，該壓縮壓縮，所以在更新能力上弱一些。還有一類系統(tǒng)，在大數(shù)據(jù)分析也常見，我們把它叫Serving系統(tǒng)，支持在線業(yè)務(wù)的一類系統(tǒng)，這類系統(tǒng)查的是足夠快，但犧牲的其實(shí)是查詢的靈活性。比如，文檔數(shù)據(jù)庫(kù)、KeyValue系統(tǒng)查詢方式有很大的局限，只能按照它的key去查詢。這樣靈活性減少了，但是性能上無(wú)限放大，因?yàn)榭梢詸M向擴(kuò)展，因?yàn)閗ey相對(duì)來(lái)說(shuō)訪問(wèn)效率是最高的，而且更新效率也非常高，按照key更新，可以替換整條記錄。我們過(guò)去就不得不針對(duì)不同場(chǎng)景，把數(shù)據(jù)拆分到TP、AP、Serving，數(shù)據(jù)在幾個(gè)系統(tǒng)之間來(lái)回傳遞。讓我們對(duì)整個(gè)系統(tǒng)的依賴度變的更高，只要數(shù)據(jù)有一次依賴，就會(huì)產(chǎn)生一次數(shù)據(jù)不一致，產(chǎn)生數(shù)據(jù)不一致就意味著數(shù)據(jù)的修正，數(shù)據(jù)的開發(fā)成本變的更高。所以大家都會(huì)在很多領(lǐng)域做創(chuàng)新，第一類創(chuàng)新是在TP和AP領(lǐng)域里做一個(gè)混合負(fù)載能力。嘗試通過(guò)一個(gè)技術(shù)把這兩個(gè)場(chǎng)景解決掉。有支持事務(wù)，又能支持分析，也希望未來(lái)有一天這個(gè)系統(tǒng)真正很好的落地。這類系統(tǒng)也有一定的局限，要支持事務(wù)操作，各種分布式鎖開銷還是必不可少的。這類系統(tǒng)因?yàn)榫邆淞艘恍┠芰?#xff0c;所以在整個(gè)并發(fā)和性能上，開銷是比較大的，所以有一定的性能瓶頸。

在下圖左側(cè)部分也是可以做一些創(chuàng)新的，左側(cè)的創(chuàng)新會(huì)發(fā)現(xiàn)最大的問(wèn)題是不支持事務(wù)。把事務(wù)能力弱化，不需要那么多事務(wù)，希望查的足夠快，更新的足夠快。所以這個(gè)地方是有可能做技術(shù)創(chuàng)新，這個(gè)技術(shù)既具備很好的靈活的分析能力，也具備很好的數(shù)據(jù)寫入能力，有具備完整的SQL表達(dá)能力。所以左側(cè)的交集部分的技術(shù)，很適合剛才提到的三點(diǎn)技術(shù)要求。這就是今天要分享的產(chǎn)品Hologres。

Hologres=向量化SQL引擎 + 靈活的多維分析+高吞吐實(shí)時(shí)更新

Hologres，一站式實(shí)時(shí)數(shù)倉(cāng)，提供實(shí)時(shí)分析（OLAP）與在線服務(wù)（點(diǎn)查）兩種能力，與MaxCompute無(wú)縫打通，實(shí)現(xiàn)一套架構(gòu)，多種負(fù)載（OLAP、在線服務(wù)、交互式分析）共存，減少數(shù)據(jù)孤島，避免數(shù)據(jù)割裂，簡(jiǎn)化鏈路，提升用戶體驗(yàn)。

統(tǒng)一存儲(chǔ)

• 一份數(shù)據(jù)支持多種負(fù)載 (OLAP、在線服務(wù)、MaxCompute交互式分析)，減少數(shù)據(jù)割裂
• 數(shù)據(jù)無(wú)孤島，無(wú)頻繁數(shù)據(jù)導(dǎo)入導(dǎo)出，提高數(shù)據(jù)開發(fā)效率、簡(jiǎn)化鏈路

統(tǒng)一接口

• 接口兼容開源Postgres協(xié)議，支持主流開發(fā)和BI工具，無(wú)需應(yīng)用層重寫，生態(tài)開放
• 統(tǒng)一用SQL描述多種場(chǎng)景，提高數(shù)據(jù)應(yīng)用開發(fā)效率
• 統(tǒng)一數(shù)據(jù)模型，通過(guò)“表”來(lái)描述數(shù)倉(cāng)模型，語(yǔ)義一致

實(shí)時(shí)離線一體

• 支持實(shí)時(shí)寫入、實(shí)時(shí)更新、寫入即可查，原生集成Flink
• 與MaxCompute存儲(chǔ)無(wú)縫打通，透明加速，無(wú)需數(shù)據(jù)移動(dòng)，支持交互式分析能力，支持實(shí)時(shí)數(shù)據(jù)關(guān)聯(lián)歷史數(shù)據(jù)

高性能

• OLAP場(chǎng)景性能好于Clickhouse、Impala、Presto，支持亞秒級(jí)響應(yīng)與高QPS
• 在線服務(wù)（點(diǎn)查）場(chǎng)景性能好于HBase，點(diǎn)查支持100K+QPS

Hologres：一站式實(shí)時(shí)數(shù)倉(cāng)

Hologres為什么能支持高性能，高吞吐寫入？

實(shí)際上沒有神秘的地方，Hologres更多還是依賴于整個(gè)IT行業(yè)，有很多底層技術(shù)上的進(jìn)步。比如，帶寬變寬，延遲變低。好處是之前必須依賴本地的操作，比如之前依賴本地磁盤，現(xiàn)在可以依賴網(wǎng)盤。其實(shí)Hologres底層的存儲(chǔ)，分多副本存儲(chǔ)，高可靠存儲(chǔ)，把這些負(fù)責(zé)狀態(tài)管理的事情，都交給阿里云，底層是盤古存儲(chǔ)引擎，自帶多副本，自帶壓縮，自帶緩存，自帶高可靠。這就會(huì)使整個(gè)計(jì)算節(jié)點(diǎn)的邏輯變的輕薄和簡(jiǎn)單，也讓高可靠更加簡(jiǎn)單。任何一個(gè)節(jié)點(diǎn)宕掉之后，可以很快從一個(gè)分布式的網(wǎng)盤里恢復(fù)狀態(tài)。會(huì)讓計(jì)算層變的無(wú)狀態(tài)，這是第一點(diǎn)。第二點(diǎn)是磁盤的利用，過(guò)去磁盤的轉(zhuǎn)速有機(jī)械瓶頸。機(jī)械磁盤是按圈去轉(zhuǎn)的，一秒鐘多少轉(zhuǎn)。所以我們的IO場(chǎng)景都是面向掃描場(chǎng)景做了大量的優(yōu)化。我們希望所有的數(shù)據(jù)都是以塊為單位，進(jìn)行更新、讀寫。所以在過(guò)去這種高更新場(chǎng)景，在整個(gè)數(shù)倉(cāng)里很難實(shí)現(xiàn)。Hologres是采用SSD設(shè)計(jì)，固態(tài)硬盤支持更好的隨機(jī)讀寫能力。這讓我們?cè)O(shè)計(jì)存儲(chǔ)架構(gòu)的時(shí)可以拋開過(guò)去必須依賴于這種掃描場(chǎng)景，去設(shè)計(jì)整個(gè)存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)。Hologres可以行存也可以列存，分別適應(yīng)不同的場(chǎng)景，同時(shí)也采用log structured merge tree 的方式。支持高吞吐數(shù)據(jù)的寫入和更新的場(chǎng)景。第三個(gè)是CPU多核化，CUP的主頻已經(jīng)不會(huì)有本質(zhì)的提升。但是在多核化場(chǎng)景下，如果可以把一CPU內(nèi)部多個(gè)核并行利用起來(lái)，就能把CPU資源充分發(fā)揮到極致。這就要求對(duì)操作系統(tǒng)的底層語(yǔ)言掌握的要比較好，Hologres使用C++實(shí)現(xiàn)的數(shù)倉(cāng)。Hologres底層的算子都會(huì)用向量化方式重寫，盡量發(fā)揮多核化并行計(jì)算能力，吧計(jì)算力發(fā)揮到極致。

從下圖可以看出，我們?cè)诰W(wǎng)絡(luò)上、存儲(chǔ)上、計(jì)算上、硬件層面有很多改進(jìn)，這些改進(jìn)都充分發(fā)揮出來(lái)，能夠做出一個(gè)不一樣的效果的系統(tǒng)。

人群圈選場(chǎng)景之前提到，既有預(yù)計(jì)算場(chǎng)景，又有MPP分布式計(jì)算場(chǎng)景。使用單一某一個(gè)技術(shù)往往不太適合，真正落地的時(shí)候，希望既有預(yù)計(jì)算又有分布式計(jì)算，要把兩個(gè)技術(shù)更好的整合在一起。比如維度過(guò)濾場(chǎng)景就很適合用BITMAP，因?yàn)榭梢栽贐ITMAP上做位圖索引。如true和false的場(chǎng)景，購(gòu)買級(jí)別、對(duì)什么產(chǎn)品關(guān)注等等，這些需要過(guò)濾的場(chǎng)景就適合做位圖索引。Hologres是支持位圖索引的。

第二種是關(guān)系運(yùn)算，關(guān)系運(yùn)算是我們提到的各種數(shù)據(jù)集之間的交差并，也非常適合位圖計(jì)算。因?yàn)槲粓D計(jì)算相當(dāng)于是0和1之間，做很多與或差的操作，而且是并行操作，效率也是非常高的。

精確去重是BITMAP天生就具備的能力，因?yàn)槲粓D在構(gòu)建時(shí)，就通過(guò)下標(biāo)位，就唯一確定了ID。通過(guò)不同下標(biāo)位之間上面一的值的簡(jiǎn)單累加，就可以很快計(jì)算出精確去重的值是多少。這幾乎是把一個(gè)O(N)的問(wèn)題變成O(1)的場(chǎng)景，效果也非常明顯。所以在做人群圈選場(chǎng)景里面，預(yù)計(jì)算是很重要的技術(shù)。Hologres支持RoaringBitmap數(shù)據(jù)類型，高效率實(shí)現(xiàn)Bitmap的交叉并計(jì)算。

上文提到預(yù)計(jì)算是靈活性不足，需要通過(guò)分布式計(jì)算把計(jì)算力發(fā)揮出來(lái)，就用到了Hologres的向量化執(zhí)行引擎。對(duì)MaxCompute數(shù)據(jù)外表直接加速，包括MaxCompute數(shù)據(jù)同步到Hologres里，是會(huì)比MaxCompute同步到其它數(shù)據(jù)源性能提高10倍已上。

典型架構(gòu)圖

典型架構(gòu)圖如下，數(shù)據(jù)源基本是通過(guò)埋點(diǎn)數(shù)據(jù)，通過(guò)消息中間件kafka，第一件時(shí)間投遞到Flink，做一次輕量級(jí)數(shù)據(jù)加工，包括數(shù)據(jù)治理的修正，數(shù)據(jù)輕度匯總，數(shù)據(jù)維度拉寬。其中維度關(guān)聯(lián)是一個(gè)很重要的場(chǎng)景，真正的埋點(diǎn)數(shù)據(jù)都是記錄某些ID，這些ID都要轉(zhuǎn)換成有屬性意義的維度信息。第一件事就是做維度拉寬，這是就可以使用Hologres的行存表，維度關(guān)聯(lián)時(shí)，基本是通過(guò)主鍵去關(guān)聯(lián)的，使用Hologres的行存表，可以存幾億幾十億的維度信息。這些信息可以實(shí)時(shí)的被更新。加工的結(jié)果集會(huì)寫到kafka里面，因?yàn)椴⒉皇且淮渭庸?#xff0c;可能是加工幾個(gè)循環(huán)。通過(guò)kafka做消息驅(qū)動(dòng)的方式，在Flink里面做幾次加工，加工的結(jié)果基本上雙寫的場(chǎng)景會(huì)比較多，一部分實(shí)時(shí)寫入Hologres，另一部分以批量方式寫到MaxCompute里面。離線數(shù)倉(cāng)到實(shí)時(shí)數(shù)倉(cāng)是一個(gè)很好的數(shù)據(jù)修正的場(chǎng)景，數(shù)據(jù)是一定會(huì)被修正的，所以會(huì)有大量通過(guò)離線數(shù)倉(cāng)對(duì)實(shí)時(shí)數(shù)倉(cāng)進(jìn)行修正的場(chǎng)景，包括標(biāo)簽加工也是典型的離線數(shù)倉(cāng)來(lái)補(bǔ)充實(shí)時(shí)數(shù)倉(cāng)的場(chǎng)景。所以一些行為是需要通過(guò)離線數(shù)倉(cāng)加工好之后，把數(shù)據(jù)同步到實(shí)時(shí)數(shù)倉(cāng)里。但有另外一些屬性，是跟當(dāng)下決策有關(guān)系的。這些是可以直接寫到實(shí)時(shí)數(shù)倉(cāng)Hologres里。所以可以把標(biāo)簽分為離線和實(shí)時(shí)兩部分，實(shí)時(shí)寫到Hologres，離線通過(guò)MaxCompute加工后同步到Hologres。

在對(duì)外提供數(shù)據(jù)服務(wù)是，有幾種方式。建議的方式是，對(duì)外提供服務(wù)時(shí)，加一個(gè)網(wǎng)關(guān)，網(wǎng)關(guān)服務(wù)里面會(huì)做很多限流、熔斷等等，這也是能提高數(shù)據(jù)服務(wù)穩(wěn)定性的一個(gè)很好的幫助。如果是對(duì)內(nèi)使用交互式分析的長(zhǎng)治，可以直接通過(guò)JDBC的方式連接Hologres，如果是一個(gè)在線應(yīng)用，建議通過(guò)API網(wǎng)關(guān)連接到Hologres。

	MaxCompute	Hologres
使用場(chǎng)景	ETL加工，標(biāo)簽加工	在線查詢、面向外部應(yīng)用，交互式分析
用戶使用	異步的Job/Task	同步的Query
集群資源	共享大集群，計(jì)算時(shí)資源可擴(kuò)展	獨(dú)享集群，計(jì)算資源預(yù)分配
計(jì)算引擎	基于Stage和File設(shè)計(jì)的，持久化的，可擴(kuò)展SQLEngine	基于內(nèi)存的，超快速響應(yīng)的SQLEngine，計(jì)算不落盤
調(diào)度方式	進(jìn)程級(jí)別，運(yùn)行時(shí)分配	輕量級(jí)線程，資源預(yù)留
擴(kuò)展性	幾乎不受限制	復(fù)雜查詢盡量避免跨多節(jié)點(diǎn)數(shù)據(jù)shuffle
存儲(chǔ)格式	列式	行式、列式共存，面向不同場(chǎng)景
存儲(chǔ)成本	基于Pangu，HDD成本低	基于Pangu，SSD成本相對(duì)高
更新方式	批量更新	實(shí)時(shí)更新、批量更新
接口標(biāo)準(zhǔn)	MCSQL	PostgreSQL

數(shù)據(jù)結(jié)構(gòu)層

離線數(shù)倉(cāng)加工兩張表，一個(gè)是用戶基礎(chǔ)屬性表，記錄一些用戶屬性，性別城市年齡等。一個(gè)是交易明細(xì)表，記錄某個(gè)人在某一天針對(duì)某個(gè)商品買過(guò)多少，看過(guò)多少，收藏多少等。這些通過(guò)離線數(shù)倉(cāng)加工好后，數(shù)據(jù)導(dǎo)入Hologres。在通過(guò)配置把表列描述信息以人類可讀的方式描述出來(lái)，再配置相關(guān)屬性標(biāo)簽。把標(biāo)簽上線后，廣告主會(huì)通過(guò)交互界面進(jìn)行配置篩選。這種篩選背后都是翻譯成各種SQL語(yǔ)句，其實(shí)就是個(gè)各種SQL表達(dá)式。真正把查詢下發(fā)到底層引擎。那下發(fā)時(shí)底層引擎該如何建表呢？

寬表模式

?每行描述一個(gè)用戶的標(biāo)簽組合，每個(gè)key是一列，每一行對(duì)應(yīng)value。

?列不建議超過(guò)300列，列多會(huì)降低實(shí)時(shí)寫入的性能。分為熱點(diǎn)標(biāo)簽和非熱點(diǎn)標(biāo)簽

?熱點(diǎn)標(biāo)簽獨(dú)立為列，具備明確的數(shù)據(jù)類型，可以針對(duì)性設(shè)計(jì)索引，對(duì)查詢友好

?非熱點(diǎn)標(biāo)簽，通過(guò)數(shù)組類型和JSON支持，適合動(dòng)態(tài)更新，但索引不是最優(yōu)，可擴(kuò)展性更好

?適應(yīng)場(chǎng)景：維度屬性數(shù)量較低；實(shí)時(shí)寫入頻繁；更新以人的單位

?優(yōu)勢(shì)：開發(fā)簡(jiǎn)單快速上線

?方案描述：

用戶數(shù)據(jù)：例如user_tags表，寬表

行為數(shù)據(jù)：例如shop_behavior表，事實(shí)表

更新時(shí)，可以實(shí)時(shí)、批量更新不同的列

案例

-------------------- 用戶標(biāo)簽維度表 --------------------- begin; --3個(gè)熱點(diǎn)標(biāo)簽字段（text、integer、boolean類型），2個(gè)擴(kuò)展標(biāo)簽字段（text[]類型和JSON類型） create table user_tags (user_id text not null primary key,city_id text,consume_level integer,marriaged boolean,tag_array text[],tag_json json ); call set_table_property('user_tags', 'orientation', 'column'); -- 分布列 call set_table_property('user_tags', 'distribution_key', 'user_id'); -- text類型設(shè)置bitmap索引 call set_table_property('user_tags', 'bitmap_columns', 'city_id,tag_array'); -- 熱點(diǎn)標(biāo)簽，這是字典編碼 call set_table_property('user_tags', 'dictionary_encoding_columns', ‘city_id:auto’); commit; -------------------- 用戶行為事實(shí)表 --------------------- begin; create table shop_behavior (user_id text not null,shop_id text not null,pv_cnt integer,trd_amt integer,ds integer not null ); call set_table_property('shop_behavior', 'orientation', 'column'); call set_table_property('shop_behavior', 'distribution_key', 'user_id'); --- 聚合鍵 對(duì)group by等運(yùn)算更加友好 call set_table_property('shop_behavior', 'clustering_key', 'ds,shop_id'); Commit；

窄表模式

將user_tag表轉(zhuǎn)為窄表，每一個(gè)標(biāo)簽一行記錄，標(biāo)簽名為一列，標(biāo)簽值為一列。

數(shù)據(jù)類型均退化為字符串類型，適合標(biāo)簽不固定，標(biāo)簽稀疏，允許犧牲部分性能但提高標(biāo)簽定義的靈活度。支持幾十到幾十萬(wàn)不同標(biāo)簽規(guī)模。

?適應(yīng)場(chǎng)景：維度屬性數(shù)量高；更新以標(biāo)簽的單位

?優(yōu)勢(shì)：開發(fā)簡(jiǎn)單快速上線

案例

-------------------- 用戶標(biāo)簽維度表 --------------------- begin; create table tag2.user_tags (userid text not null,tag_key text,tag_value text,ds text ) partition by list(ds);call set_table_property('tag2.user_tags', 'orientation', 'column’); -- 分布列 call set_table_property('tag2.user_tags', 'distribution_key', 'user_id'); call set_table_property('tag2.user_tags', 'bitmap_columns', 'tag_key,tag_value'); call set_table_property('tag2.user_tags', 'dictionary_encoding_columns', 'tag_key:auto,tag_value:auto'); commit;--查詢例子-- WITH f1 AS (SELECT userid FROM tag2.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_single'AND tag_value = 'myname' ), f2 AS (SELECT userid FROM tag2.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_date'AND tag_value > '20210101' ), f3 AS (SELECT userid FROM tag2.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_numeric'AND to_number(tag_value, '99G999D9S') > 90 ), f4 AS (SELECT userid FROM tag2.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_multi'AND tag_value IN ('HONOR', 'MI') ) SELECT COUNT(DISTINCT userid) FROM ((SELECT userid FROM f1 UNION SELECT userid FROM f2) INTERSECT (SELECT userid FROM f3 EXCEPT SELECT userid FROM f4)) crowd;

預(yù)計(jì)算模式（寬表、窄表均適合）

對(duì)維度組合的人群固化為更優(yōu)的數(shù)據(jù)結(jié)構(gòu)bitmap

?適應(yīng)場(chǎng)景：基數(shù)高，計(jì)算復(fù)雜度大，更新頻率低場(chǎng)景

?優(yōu)勢(shì)：查詢性能高

方案描述：

由于roaringbitmap需要整數(shù)類型作為ID參數(shù)，因此增加usermapping表做用戶邏輯ID與底層物理ID的映射。

案例

-------------------- 用戶標(biāo)簽維度表 --------------------- BEGIN; CREATE TABLE tag3.user_tags ("tag_key" text,"tag_value" text,"userlist" roaringbitmap,ds text ) partition by list(ds); CALL SET_TABLE_PROPERTY('tag3.user_tags', 'orientation', 'column'); CALL SET_TABLE_PROPERTY('tag3.user_tags', 'bitmap_columns', 'tag_key,tag_value'); CALL SET_TABLE_PROPERTY('tag3.user_tags', 'dictionary_encoding_columns', 'tag_key:auto,tag_value:auto'); COMMIT;begin; create table tag3.usermapping (userid_int serial,userid text ); commit;--構(gòu)建RoaringBitmap-- INSERT INTO tag3. user_tags SELECT tag_key ,tag_value ,rb_build(array_agg(user_id::INT)) FROM tag2.user_tags GROUP BY tag_key ,tag_value --查詢例子-- SELECT Rb_cardinality(Rb_and(Rb_or(t1.r, t2.r), Rb_andnot(t3.r, t4.r))) FROM (SELECT Rb_and_agg(userlist) AS rFROM tag3.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_single'AND tag_value = 'myname' ) AS t1,(SELECT rb_and_agg(userlist) AS rFROM tag3.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_date'AND tag_value > '20210101' ) AS t2,(SELECT rb_and_agg(userlist) AS rFROM tag3.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_numeric'AND to_number(tag_value, '99G999D9S') > 90 ) AS t3,(SELECT rb_and_agg(userlist) AS rFROM tag3.user_tagsWHERE ds = '20210101'AND tag_key = 'tag_multi'AND tag_value IN ('HONOR','MI') ) AS t4

用戶畫像與圈定的一些經(jīng)驗(yàn)

?標(biāo)簽分為主畫像和擴(kuò)展畫像多張表，區(qū)分高頻訪問(wèn)和低頻訪問(wèn)

?標(biāo)簽分為實(shí)時(shí)(Flink)更新和離線(MaxCompute）更新兩部分，兩部分共享一張表，減少運(yùn)行時(shí)Join，Flink加工實(shí)時(shí)部分，MaxCompute加工離線部分，在Hologres中合并

?寬表模式簡(jiǎn)單，擅長(zhǎng)定性分析

?窄表模式靈活，計(jì)算量大，擅長(zhǎng)定量分析

?基于RoaringBitmap的預(yù)計(jì)算技術(shù)，用戶體驗(yàn)最好，開發(fā)復(fù)雜度較高（比如bitmap分桶），SQL需要定制，適合DMP等有封裝能力的平臺(tái)，擅長(zhǎng)UV

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的基于 MaxCompute + Hologres 的人群圈选和数据服务实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。