目前，越來越多的企業，在大數據應用上，都會選擇用戶畫像這一主題，為什么呢？因為用戶畫像相對于做推薦以及機器學習等簡單容易的多，做畫像，更多是就是對用戶數據的整合，然后做一些用戶聚類、用推薦算法，比如基于用戶的推薦和基于商品的推薦，獲取用戶或者進行商品營銷應用。

而在我們的實際應用中，不僅有用戶畫像，而且有關于物的畫像，比如設備畫像。然而，大多數情況下有一種常見的錯誤想法是畫像維度的數據越多越好，畫像數據越豐富越好，費了很大的力氣進行畫像后，卻發現只剩下了用戶畫像，和業務相差甚遠，沒有辦法直接支持業務運營，投入精力巨大但是回報微小，可以說得不償失。鑒于此，我們的畫像的維度和設計原則都是緊緊跟著業務需求去推動。換句話說，對于數據的應用就是基于業務來做的，業務和數據雙向驅動。

本篇文章，并不過多介紹用戶畫像如果去做，而是去解決用戶畫像數據存儲與快速檢索的痛點，如果想仔細了解用戶畫像，推薦一篇博客：用戶畫像構建策略及應用實踐

在實際的項目中，常用的用戶畫像數據存儲除了常規關系型數據塊外，應用比較多的是Hbase和Elasticsearch集群的快速檢索。所以在實際使用時，如果選型，要根據具體的業務來選擇。下面說說著種方式：

1. 基于Hbase的用戶畫像

直觀的表達就是用Hbase集群來存儲用戶的數據，使用rowkey快速檢索方式來構建查詢。

博主曾經接觸過一個項目，rowkey基于用戶身份證號碼設計，因為每個人的身份證就是獨一無二的，在根據用戶不同維度的信息給用戶打標簽，做分類到最后做畫像。

2. 基于Elasticserch的用戶畫像

直觀的表達就是用ES集群來存儲用戶的數據，使用ES快速檢索方式來構建查詢。

案例：攜程 | 手把手教你用大數據打造用戶畫像

總結

以上是生活随笔為你收集整理的用户画像2种数据存储的方式的全部內容，希望文章能夠幫你解決所遇到的問題。

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