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

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

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

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

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

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

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

靈活篩選能力

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

高吞吐更新能力

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

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

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

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

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

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

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

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

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

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

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

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

統(tǒng)一存儲

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

統(tǒng)一接口

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

實時離線一體

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

高性能

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

Hologres：一站式實時數倉

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

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

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

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

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

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

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

典型架構圖

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

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

數據結構層

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

寬表模式

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

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

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

非熱點標簽，通過數組類型和JSON支持，適合動態(tài)更新，但索引不是最優(yōu)，可擴展性更好

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

優(yōu)勢：開發(fā)簡單快速上線

方案描述：

用戶數據：例如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表轉為窄表，每一個標簽一行記錄，標簽名為一列，標簽值為一列。

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

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

優(yōu)勢：開發(fā)簡單快速上線

案例