标签存储与计算
文章目錄
- 一、標簽的管理
- 二、標簽的存儲
- 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,如下圖目錄結構:
總結
- 上一篇: java基础之语法
- 下一篇: word怎么将选中的单词全部改为大写