電商用戶畫像（下） http://sanwen.net/a/bawuobo.html
商品標簽存儲在hbase的product_tags表
格式為，
用戶標簽存儲在hbase的user_tags表
格式為，
實際生產環境中，HBase會有不少坑，離線寫可以通過bulkload等批量寫的方式，但是對于在線讀，應避免特別大的Scan,我們把畫像的數據也寫在了分布式索引的Solr，對于批量讀，或者二級索引可以優先走Solr,其次再考慮HBase的二級索引，減少HBase的壓力。
實踐過程
3.3主題推薦標簽、用戶命名實體等新增標簽補充進畫像
主題推薦標簽
主題和標簽的映射關系：
使用標簽表中的關鍵詞列表，結合商品的評論、標題數據給商品打標簽。
商品打標簽公式為：
商品標簽存儲在hbase的product_tags表
格式為，
用戶打標簽公式為：
用戶標簽存儲在hbase的user_tags表
格式為，
值得注意的是，在這一步需要統計平均每個用戶被打上標簽的數量。針對標簽稀疏問題，我們在3.3中嘗試使用CF對用戶標簽做平滑處理。
用戶命名實體識別的標簽
通過用戶歷史訂單地址做地址結構化,再對結構化中的地址做用戶命名實時識別,最后對每一個用戶的地址做地址匹配,即可識別出用戶的公司、小區、校園標簽，具體實現方法見作者在2015年qcon上的分享，識別的命名實時數目如下：
3.4HBase的離線和在線分離、KV讀和批量讀分離
離線Hadoop任務會對數據庫某段時間I/O頻繁訪問，影響實時的性能，把離線和實時的集群分開。在離線集群上應用bulkload生成HBase的元文件hfile，在實時線上集群上拉取離線集群的hfile：
Hadoop dfs -cp hftp://ip1:port/userProfileBulkLoad hdfs://ip2:port / userProfileBulkLoad
實時線上集群通過LoadIncrementalHFiles命令，補上丟失的增量數據：
HBase org.apache.Hadoop.HBase.mapreduce.LoadIncrementalHFiles / userProfileBulkLoad userProfile
這樣做避免了對數據庫頻繁寫入的壓力，也避免了離線任務對實時任務的影響。
另外，實際生產環境中，HBase會有不少坑，離線寫可以通過bulkload等批量寫的方式，但是對于在線讀，應避免特別大的Scan,我們把畫像的數據也寫在了分布式索引的Solr，對于批量讀，或者二級索引可以優先走Solr,其次再考慮HBase的二級索引，減少HBase的壓力。
3.5畫像性能優化
處理邏輯和規則
a)離線部分的track解析遷移至統一的行為解析數據庫，在加快運行速度的同時，還可以提高行為解析的準確率。
待商榷：
用戶行為數據設計到userid和guid：
1)在同一sessionid中，若userid出現過，則該sessionid中的所有行為對應至該userid
2)在guid和userid的對應關系中，濾掉公用電腦和黃牛賬戶；
b)為了進一步提高離線部分的計算速度，用戶的行為權重計算亦可以增量計算。
設Wh為用戶對某個類目的歷史行為權重，Wc為用戶最新一天的行為權重，則總的行為權重
Wt = λWh + Wc, 0<λ<1
采用此權重，帶入模型，計算偏好。
然后更新Wh = Wt。
如果采用上述方法，則不必遍歷用戶的所有的行為數據，每次更新時，只需遍歷一天的數據即可。
3.6數據存儲優化
畫像離線與在線數據的存儲結構
離線的數據結構采用Hive。
在線的數據存儲：第一版畫像的數據存儲在Hbase中，每天可支撐數千萬次的訪問，時延10ms左右，性能尚可，并且存儲的數據量是TB級，如果用傳統的數據庫，隨著標簽急速的增加，勢必要不停的分表，存儲的擴展性不是很好，新版畫像的在線存儲系統仍然使用HBase。考慮到類目偏好使用比較頻繁，而導購屬性偏好數據量遠大于類目偏好，將兩者分開存儲。
類目偏好離線數據結構-Hive
離線的全量數據進行過濾之后，導入在線部分。過濾原則:
a)每個用戶的偏好類目數量小于一個固定值
b)用戶偏好得分大于下限，該下限可假設用戶當天在某個類目只有一個加車行為，然后帶入模型反推出來
類目偏好在線數據結構-HBase
Rowkey: userid,
ColumnFamily:category_level
Column:category_id
Value: weight
導購屬性偏好離線數據結構-Hive
離線的全量數據進行過濾之后，導入在線部分。過濾原則:
屬性偏好大于一個固定的下限
屬性值的數量小于一個上限
屬性值偏好大于一個固定下限
效果評價
畫像系統使得公司廣告投放ROI提升3%；
實時畫像（意圖）對猜你喜歡欄位的共享占比60%多
首頁大輪播的GMV提升千分之三；
應用到首頁猜你喜歡、團購、閃購、搜索、推薦、營銷等欄位或者產品；
了解受眾群體的變遷，適時推出適合的產品；
降低自營商品的采購數量，指導了廠商優化產品結構
基于標簽畫像的千人千面上線效果:
推廣建議
提煉出該案例（或項目）的哲理、方法論。
算法準確度、數據規模、更新速度相互制衡，提高某些指標，必須犧牲其他指標
一個系統遇到性能瓶頸的時候，適度分解系統，以滿足不同場景
系統給在線欄位用的時候，一定得考慮降級和延遲環境
數據流各個環節都可能出錯，自動化檢查各個節點的中間數據
系統演進的時候，有不同的方案，爭取多數人支持，減少一個人拍板的方案
不同版本開發的時候，適度換些開發者，融入新的思路，避免少數人思維定式
避免運營驅動，不同時期，過來新的標簽需求，如果研發團隊只管添加，大部分標簽會沉睡，后面基本用不到。研發團隊首先確定自己的標準和規范，以篩選新需求的標簽和排優先級
數據驅動，通過觀察和研究數據，對數據有一定的敏感度，產生新的用戶畫像數據。
作者簡介
陳敏敏
1號店精準化部門架構團隊負責人，《Storm技術內幕與大數據實踐》一書作者，在此之前曾服務于微軟和三星電子等公司，長期從事大數據、搜索和推薦平臺相關工作，目前主要關注于NoSQL、實時計算框架、推薦、大數據營銷等相關技術。
