聊一聊用戶畫像如何存儲

0x00 前言

隨便聊一下用戶畫像的存儲。

現在的用戶畫像，動不動就是幾千幾萬個標籤，標籤一多就出現了一些需要克服的難題，比如下面兩個：

如何解決頻繁新增和刪除標籤的場景

如何解決不同標籤更新時間和頻率不同的問題

0x01 數據模型設計

從個人角度來講，在大數據領域接觸比較多的的存儲引擎有這幾個：Hive（Hdfs）、Hbase、ES。這也會是我們在選擇存儲系統中幾個主要的備選方案。

優缺點就不再分析了。我們切入正題：數據模型該怎麼設計？

一、橫表

以Hive為例，我們最常用的就是橫表，也就是一個 key，跟上它的所有標籤。比如下面是一個簡單的橫表。

那麼用橫表有什麼問題嗎？有的，其實也就是前言裡面提到的：

由於用戶的標籤會非常多，而且隨著用戶畫像的深入，會有很多細分領域的標籤，這就意味著標籤的數量會隨時增加，而且可能會很頻繁。

不同的標籤計算頻率不同，比如說學歷一周計算一次都是可以接收的，但是APP登錄活躍情況卻可能需要每天都要計算。

計算完成時間不同，如果是以橫表的形式存儲，那麼最終需要把各個小表的計算結果合併，此時如果出現了一部分結果早上3點計算完成，一部分要早上10點才能計算完成，那麼橫表最終的生成時間就要很晚。

大量空缺的標籤會導致存儲稀疏，有一些標籤會有很多的缺失，這在用戶畫像中很常見。

嗯，上述的問題，主要是當標籤數量開始快速增多的時候會遇到的問題。標籤量少的時候其實是不用擔心這些的。

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

二、豎表

豎表長下面這個樣子：

這裡就不再列舉全部內容了，大概介紹一下，豎表其實就是將標籤都拆開，一個用戶有多少標籤，那麼在這裡面就會有幾條數據。

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

三、橫表+豎表

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

這其實也要考慮橫表和豎表的特性，整體來講就是豎表對計算層支持的好，橫表對查詢層支持的好。那麼設計的化就可以這樣：

0x02 如何存儲？

關於存儲，我們以前文說的第三種方案為例。

標籤的計算我們可以使用Hive、Spark這些計算引擎，這個沒什麼問題，然後就是這些標籤的單獨存儲可以以Hive為主來存儲。

那麼在導入標籤豎表的時候可以考慮兩種存儲引擎：Hive（Hdfs）和Hbase，其實筆者更傾向於Hbase，因為如果存在Hbase里的話會更方便查詢。順便再打上一個時間標籤，用起來就更方便了。

最後，標籤寬表的話可以考慮ES。另外需要注意的就是，從豎表往寬表到數據的時候需要做一層數據的加工，而且考慮到數據稀疏的情況的話，需要在寬表存儲這裡做一些優化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！