分區(qū)存儲

如果將用戶標簽開發(fā)成一張大的寬表，在這張寬表下放幾十種類型標簽，那么每天該用戶畫像寬表的ETL作業(yè)將會花費很長時間，而且不便于向這張寬表中新增標簽類型。 要解決這種ETL花費時間較長的問題，可以從以下幾個方面著手：

·將數(shù)據(jù)分區(qū)存儲，分別執(zhí)行作業(yè)；

·標簽腳本性能調優(yōu)；

·基于一些標簽共同的數(shù)據(jù)來源開發(fā)中間表。

下面介紹一種用戶標簽分表、分區(qū)存儲的解決方案。

根據(jù)標簽指標體系的人口屬性、行為屬性、用戶消費、風險控制、社交屬性等維度分別建立對應的標簽表進行分表存儲對應的標簽數(shù)據(jù)。如圖3-3所示。

·人口屬性表：dw.userprofifile_attritube_all；

·行為屬性表：dw.userprofifile_action_all；

·用戶消費表：dw.userprofifile_consume_all；

·風險控制表：dw.userprofifile_riskmanage_all；

·社交屬性表：dw.userprofifile_social_all

圖3-3 用戶標簽數(shù)據(jù)ETL邏輯示意圖

例如創(chuàng)建用戶的人口屬性寬表：

同樣的，用戶其他id維度（如cookieid、deviceid、registerid 等）的標簽數(shù)據(jù)存儲，也可以使用上面案例中的表結構。

在上面的創(chuàng)建中通過設立人口屬性維度的寬表開發(fā)相關的用戶標簽，為了提高數(shù)據(jù)的插入和查詢效率，在Hive中可以使用分區(qū)表的方式，將數(shù)據(jù)存儲在不同的目錄中。在Hive使用select查詢時一般會掃描整個表中所有數(shù)據(jù)，將會花費很多時間掃描不是當前要查詢的數(shù)據(jù)，為了掃描表中關心的一部分數(shù)據(jù)，在建表時引入了partition的概念。在查詢時，可以通過Hive的分區(qū)機制來控制一次遍歷的數(shù)據(jù)量。

標簽匯聚

在上面的案例中，用戶的每個標簽都插入到相應的分區(qū)下面， 但是對一個用戶來說，打在他身上的全部標簽存儲在不同的分區(qū)下面。為了方便分析和查詢，需要將用戶身上的標簽做聚合處理。緊接上面的案例，下面講解標簽匯聚的開發(fā)案例（見圖3-4）。

標簽匯聚后將一個用戶身上的每個全量標簽匯聚到一個字段中， 表結構設計如下：

CREATE TABLE `dw.userprofile_userlabel_map_all`(

`userid` string COMMENT 'userid',

`userlabels` map<string,string> COMMENT 'tagsmap',)

COMMENT 'userid 用戶標簽匯聚'

PARTITIONED BY ( `data_date` string COMMENT '數(shù)據(jù)日期')

圖3-4 標簽匯聚數(shù)據(jù)

開發(fā)udf函數(shù)“cast_to_json”將用戶身上的標簽匯聚成json字符串，執(zhí)行命令將按分區(qū)存儲的標簽進行匯聚：

insert overwrite table dw.userprofile_userlabel_map_all

partition(data_date= "data_date")

select userid,

cast_to_json(concat_ws(',',collect_set(concat(labelid,':',labelweight))))

as userlabels

from “用戶各維度的標簽表”

where data_date= " data_date "

group by userid

匯聚后用戶標簽的存儲格式如圖3-5所示

圖3-5 標簽匯聚數(shù)據(jù)

將用戶身上的標簽進行聚合便于查詢和計算。例如，在畫像產(chǎn)品中，輸入用戶id后通過直接查詢該表，解析標簽id和對應的標簽權重后，即可在前端展示該用戶的相關信息（如圖3-6所示）。

圖3-6 用戶標簽查詢