0x00 前言

隨便聊一下用戶畫像的存儲(chǔ)。

現(xiàn)在的用戶畫像，動(dòng)不動(dòng)就是幾千幾萬個(gè)標(biāo)簽，標(biāo)簽一多就出現(xiàn)了一些需要克服的難題，比如下面兩個(gè)：

1. 如何解決頻繁新增和刪除標(biāo)簽的場(chǎng)景
2. 如何解決不同標(biāo)簽更新時(shí)間和頻率不同的問題

0x01 數(shù)據(jù)模型設(shè)計(jì)

從個(gè)人角度來講，在大數(shù)據(jù)領(lǐng)域接觸比較多的的存儲(chǔ)引擎有這幾個(gè)：Hive（Hdfs）、Hbase、ES。這也會(huì)是我們?cè)谶x擇存儲(chǔ)系統(tǒng)中幾個(gè)主要的備選方案。

優(yōu)缺點(diǎn)就不再分析了。我們切入正題：數(shù)據(jù)模型該怎么設(shè)計(jì)？

[[229427]]

一、橫表

以Hive為例，我們最常用的就是橫表，也就是一個(gè) key，跟上它的所有標(biāo)簽。比如下面是一個(gè)簡單的橫表。

那么用橫表有什么問題嗎？有的，其實(shí)也就是前言里面提到的：

1. 由于用戶的標(biāo)簽會(huì)非常多，而且隨著用戶畫像的深入，會(huì)有很多細(xì)分領(lǐng)域的標(biāo)簽，這就意味著標(biāo)簽的數(shù)量會(huì)隨時(shí)增加，而且可能會(huì)很頻繁。
2. 不同的標(biāo)簽計(jì)算頻率不同，比如說學(xué)歷一周計(jì)算一次都是可以接收的，但是APP登錄活躍情況卻可能需要每天都要計(jì)算。
3. 計(jì)算完成時(shí)間不同，如果是以橫表的形式存儲(chǔ)，那么最終需要把各個(gè)小表的計(jì)算結(jié)果合并，此時(shí)如果出現(xiàn)了一部分結(jié)果早上3點(diǎn)計(jì)算完成，一部分要早上10點(diǎn)才能計(jì)算完成，那么橫表最終的生成時(shí)間就要很晚。
4. 大量空缺的標(biāo)簽會(huì)導(dǎo)致存儲(chǔ)稀疏，有一些標(biāo)簽會(huì)有很多的缺失，這在用戶畫像中很常見。

嗯，上述的問題，主要是當(dāng)標(biāo)簽數(shù)量開始快速增多的時(shí)候會(huì)遇到的問題。標(biāo)簽量少的時(shí)候其實(shí)是不用擔(dān)心這些的。

那么這些問題該怎么解決呢？這就是下面要聊得豎表。

二、豎表

豎表長下面這個(gè)樣子：

這里就不再列舉全部內(nèi)容了，大概介紹一下，豎表其實(shí)就是將標(biāo)簽都拆開，一個(gè)用戶有多少標(biāo)簽，那么在這里面就會(huì)有幾條數(shù)據(jù)。

豎表能比較好地解決上面寬表的問題。但是它也會(huì)帶來了新的問題，比如說多標(biāo)簽組合的查詢需求：“我們想看年齡在23-30之間，月薪在10-20k之間，喜歡聽古典音樂的女性”，這種多標(biāo)簽查詢條件組合情況在豎表中就不太容易支持。

三、橫表+豎表

如前面所分析，豎表和橫表各有所長和所短，那么能不能兩者結(jié)合呢？

這其實(shí)也要考慮橫表和豎表的特性，整體來講就是豎表對(duì)計(jì)算層支持的好，橫表對(duì)查詢層支持的好。那么設(shè)計(jì)的化就可以這樣：

0x02 如何存儲(chǔ)？

關(guān)于存儲(chǔ)，我們以前文說的第三種方案為例。

標(biāo)簽的計(jì)算我們可以使用Hive、Spark這些計(jì)算引擎，這個(gè)沒什么問題，然后就是這些標(biāo)簽的單獨(dú)存儲(chǔ)可以以Hive為主來存儲(chǔ)。

那么在導(dǎo)入標(biāo)簽豎表的時(shí)候可以考慮兩種存儲(chǔ)引擎：Hive（Hdfs）和Hbase，其實(shí)筆者更傾向于Hbase，因?yàn)槿绻嬖贖base里的話會(huì)更方便查詢。順便再打上一個(gè)時(shí)間標(biāo)簽，用起來就更方便了。

***，標(biāo)簽寬表的話可以考慮ES。另外需要注意的就是，從豎表往寬表到數(shù)據(jù)的時(shí)候需要做一層數(shù)據(jù)的加工，而且考慮到數(shù)據(jù)稀疏的情況的話，需要在寬表存儲(chǔ)這里做一些優(yōu)化。