使用者畫像資料是一種資料規模較大、資料結構複雜、查詢種類多的資料，是公司差異化運營的基礎，是打造「千人千面」、智慧型化的核心資料，幫產品找到最佳目標客戶，對各種產品而言是一種很有價值的資料。
我們接下來先看一下使用者畫像資料的場景和特徵，僅以儲存和查詢的角度看一下使用者畫像資料的儲存選擇。
使用者畫像的資料有兩大類，一類是使用者行為日誌，實時由使用者的行為產生，資料規模和產品使用者的數量和活躍程度相關，這部分是使用者畫像資料的原始素材，用來產生最終的使用者畫像資料，另一類就是主角：使用者畫像資料，這部分資料是真正的使用者的畫像資料，表示使用者的多種維度的特徵，包括使用者屬性、社交關係和行為偏好等。第一類資料會經過複雜的計算分析後產生第二種資料。第二種資料會被最終的各類系統用來給不同使用者輸送不同的內容。
使用者畫像資料中表示了乙個使用者的多重維度的特徵，維度越多，資料格式越複雜，不僅有多種型別， 也有多種層次，比如使用者屬性、社交關係和行為偏好等：
社交關係：
行為偏好：
這類資料中的資料型別較多，大多數情況下還會有巢狀型別等多維資料，雖然多維資料更加複雜，但是更加自然，符合人的思維，更好理解，但是大多數分布式系統為了水平擴充套件而犧牲了對這種型別資料的支援。
使用者畫像資料需要被多種場景使用，一種是需要被使用者行為分析系統查詢，這種都是指定使用者id批量讀取。再一種是被運營系統查詢，這種需要按照多種維度查詢，以及會有統計聚合需求，比如查詢「對巴厘島感興趣」的所有使用者，比如比較下「對巴厘島感興趣」和「對仙本那感興趣」的使用者的數量或者其他特徵值。
上述舉得兩個簡單例子中，就會有多種的查詢需求：
針對上述的場景需求，目前業內已經有多種解決方案，我們接下來看一下：
一種很容易想到的方案是使用關係型資料庫，比如mysql或postgresql儲存，但是這種只適合儲存小資料量，如果資料量超過單機儲存能力，則會不適合。就算採用了分庫分表的方式，也會帶來極大的運維壓力和產品功能犧牲。
另外一種方案，使用hbase等分布式資料庫，但是這種nosql資料庫只提供單key和key字首範圍查詢，無法支援按照其他屬性列查詢，無法滿足我們上面的需求，就算引入phoenix使用了二級索引，也需要提前固定好查詢，無法支援自由組合，更無法支援巢狀查詢。
還有一種方案，是從查詢複雜度考慮，直接使用搜尋引擎elasticsearch或solr，但是這種雖然能滿足查詢需求，可惜沒法滿足資料不能丟的要求，存在丟失資料的風險。
至此，考慮了所有開源系統後，沒有乙個系統能滿足使用者需求，那麼只能退而求其次，採用組合的方式：
上述架構方案，看起來滿足了我們上面的所有需求，雖然麻煩了點。但是只能算是基本滿足，因為這套架構存在比較大的問題：
除此之外，還需要運維hbase、lily index、proxy和solr四個系統，需要配備熟悉這四個開源系統的人員，這個又是一筆額外支出。除了開源解決方案外，如今又多了一種選擇，使用雲解決方案。
在現有的各種雲產品中，能滿足上述使用者畫像資料儲存需求的系統並不多，阿里雲tablestore是一款符合要求的系統，10年前就開始自研，多年的雙十
一、公有雲客戶的錘煉沉澱，保證了系統的可靠性和穩定性。
我們先來看一下基於tablestore儲存使用者畫像資料的架構方案：
tablestore是分布式系統，可以水平擴充套件，目前生產環境單錶最大有幾十pb，每秒寫入有幾千萬行，完全能勝任任何大資料的寫入和儲存。
接下來，我們舉個例子幫助讀者理解。
有乙個大型連鎖超市，有一套自己的使用者畫像系統，涉及的使用者畫像包括下列特徵；
社交關係：
行為偏好：
首先，我們設計tablestore中主表結構：
主鍵列屬性列
屬性列屬性列
屬性列屬性列
屬性列屬性列
使用者id
年齡家庭住址
家庭位置
可能認識的人
**敏感度
商圈偏好
標籤string
long
string
string
string array
bool
string array
string array
100001
39杭州市***街道***小區
[30.295,120.059]
[1002, 1003]
true
["週六"、「**」，「距離遠」]
上述表結構中，只能按照使用者id查詢該使用者的畫像，但是沒法通過使用者的畫像屬性反查使用者id，比如**系統需要查詢週六可能回來購物的使用者時，就沒法查詢了。
為了支援屬性列查詢，我們需要使用多元索引功能，接下來設計多元索引的結構：列列
列列列列
使用者id
年齡家庭住址
家庭位置
商圈偏好
標籤string
long
text
geopoint
nested
string array
基於上述索引，我沒就能支援很多鐘查詢了，比如：
基於上述的表和index，我們就能滿足上述提到的所有需求。
開源解決方案和tablestore雲解決方案都介紹完了，使用了tablestore雲解決方案後，可以為架構和系統帶來不少的收益。
減少運維負擔
在tablestore解決方案中，使用者只需要運維自己的應用程式，不需要運維任何的儲存系統、查詢系統和其他中介軟體，運維壓力大大減少，同時也減少了運維方面的成本開支。
同時，tablestore是serverless的服務化產品，使用者也無需考慮運維，不需要關注擴容、水位等事項，即開即用，只需要關注功能開發即可。
在開源解決方案中6個系統，而tablestore解決方案中只有3個系統，系統數減少後，系統架構會更簡單，系統可能產生的風險會更少，系統的穩定性等會更高，可以提供更優質的服務體驗。
tablestore雲架構方案相對於開源方案，系統更少，從零開始到上線需要的開發時間更少，同時，tablestore是serverless的雲服務，全球多個區域即開即用，可以大大降低客戶的開發上線的時間，提前將產品推出，搶先爭取市場領先優勢。
tablestore作為一款雲產品，提供了sla保障，目前在可用性上是3個9的保障，可靠性是10個9的保障，這個在業內算是比較高的了，比自己搭建開源系統的可用性和可靠性都要高的多。而且，如果達不到，會有多倍賠償，盡量讓使用者能安心專注產品研發和占領市場。
目前，已經有大量的業務在使用tablestore，後續我們會繼續優化改進tablestore，為客戶持續提供一款高效能、豐富功能、低成本、高可用性的分布式系統，為客戶的海量資料保駕護航。
數倉 使用者畫像
在數倉開發中，主要目的就是2個，乙個是基於現有資料提煉出規律和資訊，乙個是基於現有資料訓練模型，然後 未來的資料。使用者畫像屬於前者，但由於畫像的特殊性，如果乙個人的畫像標籤較多，較完善，其實可以一定程度 其未來行為規律。具體可以看 夏洛克 中的心理側寫，就是一樣的道理，乙個人有哪些特質，喜愛，偏好...
使用者畫像 如何構建使用者畫像
1 使用者畫像是什麼 what 2 為什麼要構建使用者畫像 why 3 如何構建使用者畫像 how 下文將會對這三部分內容做詳細介紹。1 什麼是使用者畫像 使用者畫像是一種用來描述產品目標使用者特徵的使用者研究方法，在實際操作的過程中往往會以最為淺顯和貼近生活的標籤將使用者的屬性 行為與需求聯絡起來...
使用者畫像 使用者畫像之新使用者分類
使用者畫像的簡單介紹 使用者畫像是一種勾畫目標使用者 聯絡使用者訴求與設計方向的有效工具，利用使用者的基本屬性，訪問特徵，交易特徵，社交特徵及風險特徵等組合的資訊形成一些列的使用者標籤組合稱之為使用者畫像。構建使用者畫像的目的 使用者運營 活動運營過程中，制定策略，對使用者精準投放策略，促使平台引流...