閑聊用戶畫像的存儲
? ? ?作者：木東居士
? ? ?來源：木東居士
0x00 前言
隨便聊一下用戶畫像的存儲。
現(xiàn)在的用戶畫像，動不動就是幾千幾萬個標簽，標簽一多就出現(xiàn)了一些需要克服的難題，比如下面兩個：
如何解決頻繁新增和刪除標簽的場景
如何解決不同標簽更新時間和頻率不同的問題
0x01 數(shù)據(jù)模型設(shè)計
從個人角度來講，在大數(shù)據(jù)領(lǐng)域接觸比較多的的存儲引擎有這幾個：Hive（Hdfs）、Hbase、ES。這也會是我們在選擇存儲系統(tǒng)中幾個主要的備選方案。
優(yōu)缺點就不再分析了。我們切入正題：數(shù)據(jù)模型該怎么設(shè)計？
一、橫表
以Hive為例，我們最常用的就是橫表，也就是一個 key，跟上它的所有標簽。比如下面是一個簡單的橫表。
| 用戶ID | 性別 | 年齡 | 學(xué)歷 | 職業(yè) | 月薪 | 月消費能力 |
|---|---|---|---|---|---|---|
| 001 | 男 | 28 | 本科 | 程序員 | 10k-20k | 1k-2k |
| 002 | 女 | 23 | 大專 | 銷售 | 不詳 | 100-200 |
那么用橫表有什么問題嗎？有的，其實也就是前言里面提到的：
由于用戶的標簽會非常多，而且隨著用戶畫像的深入，會有很多細分領(lǐng)域的標簽，這就意味著標簽的數(shù)量會隨時增加，而且可能會很頻繁。
不同的標簽計算頻率不同，比如說學(xué)歷一周計算一次都是可以接收的，但是APP登錄活躍情況卻可能需要每天都要計算。
計算完成時間不同，如果是以橫表的形式存儲，那么最終需要把各個小表的計算結(jié)果合并，此時如果出現(xiàn)了一部分結(jié)果早上3點計算完成，一部分要早上10點才能計算完成，那么橫表最終的生成時間就要很晚。
大量空缺的標簽會導(dǎo)致存儲稀疏，有一些標簽會有很多的缺失，這在用戶畫像中很常見。
嗯，上述的問題，主要是當標簽數(shù)量開始快速增多的時候會遇到的問題。標簽量少的時候其實是不用擔心這些的。
那么這些問題該怎么解決呢？這就是下面要聊得豎表。
二、豎表
豎表長下面這個樣子：
| 用戶ID | 標簽名 | 標簽值 |
|---|---|---|
| 001 | sex | 男 |
| 001 | salary_month | 10k-20k |
| 002 | sex | 女 |
| 002 | age | 23 |
這里就不再列舉全部內(nèi)容了，大概介紹一下，豎表其實就是將標簽都拆開，一個用戶有多少標簽，那么在這里面就會有幾條數(shù)據(jù)。
豎表能比較好地解決上面寬表的問題。但是它也會帶來了新的問題，比如說多標簽組合的查詢需求：“我們想看年齡在23-30之間，月薪在10-20k之間，喜歡聽古典音樂的女性”，這種多標簽查詢條件組合情況在豎表中就不太容易支持。
三、橫表+豎表
如前面所分析，豎表和橫表各有所長和所短，那么能不能兩者結(jié)合呢？
這其實也要考慮橫表和豎表的特性，整體來講就是豎表對計算層支持的好，橫表對查詢層支持的好。那么設(shè)計的化就可以這樣：
0x02 如何存儲？
關(guān)于存儲，我們以前文說的第三種方案為例。
標簽的計算我們可以使用Hive、Spark這些計算引擎，這個沒什么問題，然后就是這些標簽的單獨存儲可以以Hive為主來存儲。
那么在導(dǎo)入標簽豎表的時候可以考慮兩種存儲引擎：Hive（Hdfs）和Hbase，其實筆者更傾向于Hbase，因為如果存在Hbase里的話會更方便查詢。順便再打上一個時間標簽，用起來就更方便了。
最后，標簽寬表的話可以考慮ES。另外需要注意的就是，從豎表往寬表到數(shù)據(jù)的時候需要做一層數(shù)據(jù)的加工，而且考慮到數(shù)據(jù)稀疏的情況的話，需要在寬表存儲這里做一些優(yōu)化。
0xFF 總結(jié)
之前寫的一篇文章，內(nèi)容還算ok，最近很多小伙伴問到了這個問題就給大家再分享一次！
◆?◆?◆ ?◆?◆
長按二維碼關(guān)注我們
數(shù)據(jù)森麟公眾號的交流群已經(jīng)建立，許多小伙伴已經(jīng)加入其中，感謝大家的支持。大家可以在群里交流關(guān)于數(shù)據(jù)分析&數(shù)據(jù)挖掘的相關(guān)內(nèi)容，還沒有加入的小伙伴可以掃描下方管理員二維碼，進群前一定要關(guān)注公眾號奧，關(guān)注后讓管理員幫忙拉進群，期待大家的加入。
管理員二維碼：