文章目錄

• 一、標簽的管理
• 二、標簽的存儲
• • 2.1、橫表存儲
  • • 那么用橫表有什么問題嗎？
  • 2.2、豎表存儲
  • 2.3、橫表+豎表存儲
• 三、Spark 計算標簽

一、標簽的管理

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

• 1）、如何解決頻繁新增和刪除標簽；
• 2）、如何解決不同標簽更新時間和頻率不同的問題；

標簽系統WEB Platform管理平臺，主要創建標簽、修改標簽、刪除標簽及調度標簽對應應用程序執行。


??還有一個問題， 如果實現了這個管理系統，那么這個標簽有可能是隨著時間而發生變化的。比如 一個用戶以前消費能力很弱，打了一個"屌絲"的標簽，但一年之后這個用戶消費能力提升 ，就需要對這個用戶重新進行判定，如何實現？

二、標簽的存儲

??在大數據領域接觸比較多的的存儲引擎有這幾個：Hive、HBase、Elasticsearch/Solr，
這也在選擇存儲系統中幾個主要的備選方案。

2.1、橫表存儲

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

??可以看到每一列對應一個標簽， 如果想生成這樣的一張用戶畫像表， 其實要先找到每一列標簽數據的計算應該需要哪些數據，如下：

1）、性別 2）、年齡 3）、學校 4）、訂單和消費記錄

這些字段可能來自于兩張表：

1）、用戶表（tbl_users) 2）、訂單表(tbl_orders)

那現在的問題， 就是如何從這兩張源表中得到用戶畫像表呢？ 可以通過 Hive SQL 來完成：

select gender, school from ods_tbl_user ；

當然，上面這段SQL是片面的， 并沒有把所有字段計算出來，但是大家可以捕獲到兩點：

1）、數據從數倉來ODS表示數據倉庫中第一層 2）、可以使用 SQL 直接獲取到目標表, 可以使用 CASE WHEN 或者 UDF 之類的方式計算指標

那么用橫表有什么問題嗎？

• 第一、由于用戶的標簽會非常多，而且隨著用戶畫像的深入，會有很多細分領域的標簽，這就意味著標簽的數量會隨時增加，而且可能會很頻繁。
• 第二、不同的標簽計算頻率不同，比如說學歷一周計算一次都是可以接收的，但是APP登錄活躍情況卻可能需要每天都要計算。
• 第三、計算完成時間不同，如果是以橫表的形式存儲，那么最終需要把各個小表的計算結果合并，此時如果出現了一部分結果早上3點計算完成，一部分要早上10點才能計算完成，那么橫表最終的生成時間就要很晚（T+1）。
• 第四、大量空缺的標簽會導致存儲稀疏，有一些標簽會有很多的缺失，這在用戶畫像中很常見。

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

2.2、豎表存儲

豎表其實就是將標簽都拆開，一個用戶有多少標簽，那么就會有多條數據 。

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

2.3、橫表+豎表存儲

??如前面所分析，豎表和橫表各有所長和所短，那么能不能兩者結合呢？這其實也要考慮橫表和豎表的特性，整體來講就是豎表對計算層支持的好，橫表對查詢層支持的好。那么設計的化就可以這樣：

??標簽的計算可以使用Hive、Spark這些計算引擎，這個沒什么問題，然后就是這些標簽的單獨存儲可以以Hive或HBase為主來存儲。

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

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

三、Spark 計算標簽

??使用 Spark Application 的方式來計算， 每一個Application 計算一個標簽，最終合并進一張畫像表 ， 如下：

項目中每個標簽對應一個模型，每個模型就是一個Spark Application，如下圖目錄結構：

總結

以上是生活随笔為你收集整理的标签存储与计算的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。