簡介：?本文主要介紹如何通過 MaxCompute 進行海量人群的標簽加工，通過 Hologres 進行分析建模，從而支持大規模人群復雜圈選場景下的交互式體驗，以及基于API的數據服務最佳實踐。

本文作者 劉一鳴 阿里云智能 高級產品專家

人群圈選系統基本邏輯架構

人群圈選并不是一個新業務， 幾乎所有的互聯網公司都在做，因為這是一個基本營銷場景，選定的人群要發代金券，要導入流量，要做針對性促銷，要選擇合適的人群，那怎么做這件事情呢？實際上要通過人群的行為特征，采購特性，關注特征，興趣特性，甚至是教育程度等等，把人群劃分成不同的組。通過劃分人群組，在有限的營銷預算里面，將資源投放給轉化率或點擊率最高的人群。

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

那這個業務需求的背后技術要求是什么呢？

典型人群業務版塊的核心是洞察分析，洞察分析一般的場景是，要支撐幾萬個不同的廣告主，他們會在平臺上自由選擇更感興趣的人群，每個廣告主對人群的訴求是不一樣的，某些人關注的購買力，有些關注的是收藏行為。每天數萬廣告主發出數百萬次的查詢請求，構建數萬次各種人群包，各個系統的計算復雜度是要求非常高的。這里的核心訴求包含幾個點，毫秒級洞察，因為所有的查詢希望是交互式的，需要在界面上每一次互動，每一次下拉菜單，每一次選擇，每一次條件組合，都希望看到一個互動結果，整個人群是變大還是變小，目標人群是不是跟期望的相似。這一點對性能要求是非常大的。同時提醒大家，數據一定要脫敏處理，保護好用戶的個人隱私，所有的分析都是建立在合規數據基礎之上的分析。

人群圈選系統服務引擎核心訴求

規模數據上的交互式分析性能

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

靈活篩選能力

用戶的篩選行為多種多樣，等值比較、數值大小范圍比較、時間范圍比較等。各種各樣的篩選條件能夠靈活組合，表達這些篩選結果就體現出來計算引擎的能力。

高吞吐更新能力

用戶標簽并不是靜態的，當前一切實時化，一切在線化，所有的行為數據變化，都希望能夠實時觸發，實時反饋下一時刻的系統決策。比如最新收藏夾里放了什么商品，這種行為能不能成為在線畫像的一部分。所以對高實時的吞吐能力要求會很高。

從計算層面來講，可以分成下圖幾種計算模式。

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

這里就有很多不同的解決優化思路，是用更多的內存還是CPU。行業內大致的思路有兩種。

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

所以真正落地一套人群篩選方案時，一般不是只選擇一個方案。因為不管是預計算方案還是MPP方案都有一些本質的缺陷。

那市場上哪些技術更適合做存儲和查詢呢？

第一類技術，大家都比較熟悉的事務數據庫。事務數據庫是行存儲，對單行數據寫入存儲效率是非常高的，用來做查詢，做過濾統計，在千萬級以上會發現消耗資源是非常大的。所以一般不會拿TP系統直接做分析操作。

第二類系統，AP系統，是我們常見OLAP系統。這一類系統針對大規模數據掃描場景做了優化，包括利用分布式技術，列存技術，壓縮技術、索引的技術等等。這類技術查的都很快，但本質缺陷是大部分系統更新上做的不太友好，因為數據查的快，所以數據該緊湊緊湊，該壓縮壓縮，所以在更新能力上弱一些。還有一類系統，在大數據分析也常見，我們把它叫Serving系統，支持在線業務的一類系統，這類系統查的是足夠快，但犧牲的其實是查詢的靈活性。比如，文檔數據庫、KeyValue系統查詢方式有很大的局限，只能按照它的key去查詢。這樣靈活性減少了，但是性能上無限放大，因為可以橫向擴展，因為key相對來說訪問效率是最高的，而且更新效率也非常高，按照key更新，可以替換整條記錄。我們過去就不得不針對不同場景，把數據拆分到TP、AP、Serving，數據在幾個系統之間來回傳遞。讓我們對整個系統的依賴度變的更高，只要數據有一次依賴，就會產生一次數據不一致，產生數據不一致就意味著數據的修正，數據的開發成本變的更高。所以大家都會在很多領域做創新，第一類創新是在TP和AP領域里做一個混合負載能力。嘗試通過一個技術把這兩個場景解決掉。有支持事務，又能支持分析，也希望未來有一天這個系統真正很好的落地。這類系統也有一定的局限，要支持事務操作，各種分布式鎖開銷還是必不可少的。這類系統因為具備了一些能力，所以在整個并發和性能上，開銷是比較大的，所以有一定的性能瓶頸。

在下圖左側部分也是可以做一些創新的，左側的創新會發現最大的問題是不支持事務。把事務能力弱化，不需要那么多事務，希望查的足夠快，更新的足夠快。所以這個地方是有可能做技術創新，這個技術既具備很好的靈活的分析能力，也具備很好的數據寫入能力，有具備完整的SQL表達能力。所以左側的交集部分的技術，很適合剛才提到的三點技術要求。這就是今天要分享的產品Hologres。

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

Hologres，一站式實時數倉，提供實時分析（OLAP）與在線服務（點查）兩種能力，與MaxCompute無縫打通，實現一套架構，多種負載（OLAP、在線服務、交互式分析）共存，減少數據孤島，避免數據割裂，簡化鏈路，提升用戶體驗。

統一存儲

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

統一接口

• 接口兼容開源Postgres協議，支持主流開發和BI工具，無需應用層重寫，生態開放
• 統一用SQL描述多種場景，提高數據應用開發效率
• 統一數據模型，通過“表”來描述數倉模型，語義一致

實時離線一體

• 支持實時寫入、實時更新、寫入即可查，原生集成Flink
• 與MaxCompute存儲無縫打通，透明加速，無需數據移動，支持交互式分析能力，支持實時數據關聯歷史數據

高性能

• OLAP場景性能好于Clickhouse、Impala、Presto，支持亞秒級響應與高QPS
• 在線服務（點查）場景性能好于HBase，點查支持100K+QPS

Hologres：一站式實時數倉

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

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

從下圖可以看出，我們在網絡上、存儲上、計算上、硬件層面有很多改進，這些改進都充分發揮出來，能夠做出一個不一樣的效果的系統。

人群圈選場景之前提到，既有預計算場景，又有MPP分布式計算場景。使用單一某一個技術往往不太適合，真正落地的時候，希望既有預計算又有分布式計算，要把兩個技術更好的整合在一起。比如維度過濾場景就很適合用BITMAP，因為可以在BITMAP上做位圖索引。如true和false的場景，購買級別、對什么產品關注等等，這些需要過濾的場景就適合做位圖索引。Hologres是支持位圖索引的。

第二種是關系運算，關系運算是我們提到的各種數據集之間的交差并，也非常適合位圖計算。因為位圖計算相當于是0和1之間，做很多與或差的操作，而且是并行操作，效率也是非常高的。

精確去重是BITMAP天生就具備的能力，因為位圖在構建時，就通過下標位，就唯一確定了ID。通過不同下標位之間上面一的值的簡單累加，就可以很快計算出精確去重的值是多少。這幾乎是把一個O(N)的問題變成O(1)的場景，效果也非常明顯。所以在做人群圈選場景里面，預計算是很重要的技術。Hologres支持RoaringBitmap數據類型，高效率實現Bitmap的交叉并計算。

上文提到預計算是靈活性不足，需要通過分布式計算把計算力發揮出來，就用到了Hologres的向量化執行引擎。對MaxCompute數據外表直接加速，包括MaxCompute數據同步到Hologres里，是會比MaxCompute同步到其它數據源性能提高10倍已上。

典型架構圖

典型架構圖如下，數據源基本是通過埋點數據，通過消息中間件kafka，第一件時間投遞到Flink，做一次輕量級數據加工，包括數據治理的修正，數據輕度匯總，數據維度拉寬。其中維度關聯是一個很重要的場景，真正的埋點數據都是記錄某些ID，這些ID都要轉換成有屬性意義的維度信息。第一件事就是做維度拉寬，這是就可以使用Hologres的行存表，維度關聯時，基本是通過主鍵去關聯的，使用Hologres的行存表，可以存幾億幾十億的維度信息。這些信息可以實時的被更新。加工的結果集會寫到kafka里面，因為并不是一次加工，可能是加工幾個循環。通過kafka做消息驅動的方式，在Flink里面做幾次加工，加工的結果基本上雙寫的場景會比較多，一部分實時寫入Hologres，另一部分以批量方式寫到MaxCompute里面。離線數倉到實時數倉是一個很好的數據修正的場景，數據是一定會被修正的，所以會有大量通過離線數倉對實時數倉進行修正的場景，包括標簽加工也是典型的離線數倉來補充實時數倉的場景。所以一些行為是需要通過離線數倉加工好之后，把數據同步到實時數倉里。但有另外一些屬性，是跟當下決策有關系的。這些是可以直接寫到實時數倉Hologres里。所以可以把標簽分為離線和實時兩部分，實時寫到Hologres，離線通過MaxCompute加工后同步到Hologres。

在對外提供數據服務是，有幾種方式。建議的方式是，對外提供服務時，加一個網關，網關服務里面會做很多限流、熔斷等等，這也是能提高數據服務穩定性的一個很好的幫助。如果是對內使用交互式分析的長治，可以直接通過JDBC的方式連接Hologres，如果是一個在線應用，建議通過API網關連接到Hologres。

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

數據結構層

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

寬表模式

?每行描述一個用戶的標簽組合，每個key是一列，每一行對應value。

?列不建議超過300列，列多會降低實時寫入的性能。分為熱點標簽和非熱點標簽

?熱點標簽獨立為列，具備明確的數據類型，可以針對性設計索引，對查詢友好

?非熱點標簽，通過數組類型和JSON支持，適合動態更新，但索引不是最優，可擴展性更好

?適應場景：維度屬性數量較低；實時寫入頻繁；更新以人的單位

?優勢：開發簡單快速上線

?方案描述：

用戶數據：例如user_tags表，寬表

行為數據：例如shop_behavior表，事實表

更新時，可以實時、批量更新不同的列

案例

-------------------- 用戶標簽維度表 --------------------- begin; --3個熱點標簽字段（text、integer、boolean類型），2個擴展標簽字段（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類型設置bitmap索引 call set_table_property('user_tags', 'bitmap_columns', 'city_id,tag_array'); -- 熱點標簽，這是字典編碼 call set_table_property('user_tags', 'dictionary_encoding_columns', ‘city_id:auto’); commit; -------------------- 用戶行為事實表 --------------------- 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'); --- 聚合鍵 對group by等運算更加友好 call set_table_property('shop_behavior', 'clustering_key', 'ds,shop_id'); Commit；

窄表模式

將user_tag表轉為窄表，每一個標簽一行記錄，標簽名為一列，標簽值為一列。

數據類型均退化為字符串類型，適合標簽不固定，標簽稀疏，允許犧牲部分性能但提高標簽定義的靈活度。支持幾十到幾十萬不同標簽規模。

?適應場景：維度屬性數量高；更新以標簽的單位

?優勢：開發簡單快速上線

案例

-------------------- 用戶標簽維度表 --------------------- 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;

預計算模式（寬表、窄表均適合）

對維度組合的人群固化為更優的數據結構bitmap

?適應場景：基數高，計算復雜度大，更新頻率低場景

?優勢：查詢性能高

方案描述：

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

案例

-------------------- 用戶標簽維度表 --------------------- 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;--構建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

用戶畫像與圈定的一些經驗

?標簽分為主畫像和擴展畫像多張表，區分高頻訪問和低頻訪問

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

?寬表模式簡單，擅長定性分析

?窄表模式靈活，計算量大，擅長定量分析

?基于RoaringBitmap的預計算技術，用戶體驗最好，開發復雜度較高（比如bitmap分桶），SQL需要定制，適合DMP等有封裝能力的平臺，擅長UV

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。