我先引用梵谷的一句話：「我想強調的是，同乙個人有多樣的自畫像。與其追求照相般的相似性，不如深入地發掘相似處」。下圖是是當時梵谷比較得意時的畫像，戴了禮帽，穿了西服，但那時耳朵已經割掉了。我覺得作為乙個好的架構師，要有藝術家的精神。時至今日架構發生了很多變化，新語言在不斷出現，我覺得沒必要把思維停留在某乙個方面。
使用者畫像定義使用標籤來量化使用者特性屬性，達到描述使用者的目的。使用者畫像的難點就是資料來源，因為你拿要拿到足夠多足夠全的資料很不容易，所以要與業務結合，比如說這個人在30天內購買了你的商品，這就是乙個標籤，但是如果你不參與開發這個系統，你不會想到有這個標籤。然後是動態更新，乙個人是不斷變化的，就像梵谷一樣，他不同時期的自畫像也是不一樣的。
最簡單的分析不同性別的群體特徵，做特定營銷。分析廣州、北京、客戶的群體特徵，分析90後、80後的群體特徵。其實這裡面有共同點，就是說分類和聚類。京東也好、**也好、一號店也好，我不可能真的每乙個使用者生成一套推薦方案，我們都是把人分成了一萬個類，或者一千個類，我們把你劃分到某乙個類別裡面，在那個類別裡面做乙個推薦。而且群體特徵往往更能反映你的個人喜好，就是說其實人與人之間是有共同點的，也是有異同點的。
1號店建立使用者畫像的初中是來自於《千人千面》專案，簡而言之：分析不同群體特徵，針對群體進行推薦調整，典型的群體有小區、學校公司等。下圖是2023年9月份轉化率的資料。我們覆蓋面也比較大，目前差不多355家公司，591個行業，覆蓋293個城市的4.26萬個小區。
1號店從零開始打造了自己的使用者畫像系統，包含了使用者標籤畫像、使用者偏好畫像。經歷了全量版畫像、storm版實時畫像、電商使用者標籤畫像等演進和完善的過程。在兩年的時間裡，遇到了效能瓶頸、資料質量評估、使用者標籤的膨脹、畫像在精準化營銷等應用場景的摸索，一步步成長，在推薦系統發揮了巨大作用。
我們的使用者標籤包含基本特徵、社會身份、顧客使用者生命週期、類目偏好等等。比如說你怎麼判斷乙個人是不是對**感興趣，假設我們有乙個類目就是**，那很好辦，如果你購買都是**，那會認為你這個人對**比較感興趣。如下圖所示。
我們期間遇到了兩方面的挑戰：
億級畫像系統實踐和應用
記錄和儲存億級使用者的畫像，支援和擴充套件不斷增加的維度和偏好，毫秒級的更新，支撐個公司性化推薦、廣告投放和精細化營銷等產品
使用者畫像演算法模型不斷優化
引入storm等實時技術
主題推薦標籤、使用者命名實體等新增標籤補充進畫像
資料流不斷優化
資料儲存改進
執行一次全量的資料更新太慢
使用者的偏好得分資料分布不合理，得分呈多波峰分布，且在6.0、8.0區間的得分數目幾乎為0
使用者強偏好和弱偏好的閾值界限未有明顯規定
使用者未產生新的行為，興趣偏好分值將不會發生變化（未按時間進行衰減）
關於演算法模型做了一些優化，第乙個優化就是得分，通過操作得分使它的偏好更有區分性，歷史行為應有衰減。你這個得分假設永遠是疊加的，這也是有問題的，因為你乙個月之前或者一年之前所有的行為，如果現在還影響著你的得分，會有不準確性，所以會有乙個歷史的衰減得分。偏好得分分布應與使用者對類目的權重分布一致，關鍵是對資料的處理，還有怎麼樣去調整你的模型。
偏好畫像的得分應滿足三個條件：
對於類目偏好，需先將使用者對類目偏好離散化提高某些場景效能，最簡單的行為可劃分為兩檔【喜歡|一般】。
引數調整原則：
（結合使用者在不同類目下的購買週期，見下頁）
然後有乙個購買週期的問題，就是說不同的東西會有乙個購買週期的，比如說牙膏多久前買的，牛奶多久前買的，這些東西的週期性是比較強的。後面會有乙個實時推薦，根據使用者的行為進行算分，根據各個類目的偏好進行乙個實時推薦。
主題標籤，比如說吃貨，比如說愛吃零食的女性，算是吃貨範圍。還有數碼極客，就是通過主題劃分人。具體的方法我就不多講，就是通過你購買的東西進行分類。下圖是使用者不同類目的購買週期。
主題和標籤的對映關係如下：
商品打標籤公式為：
使用者打標籤公式為：
我們還有乙個選人機制，就是使用者畫像的另乙個場景，既然你有使用者的各種資訊了，那麼對於其他業務，比如說廣告業務，比如說**業務他們提供了乙個需求，就是選人，是基於solr做的乙個選人中心。如下圖所示。
根據畫像表每一台機器的熱點，遷移或者切分。
guid和userid的對應關係中，濾掉公用電腦和黃牛賬戶（全國有20萬左右人從事刷單產業鏈）。為了進一步提高離線部分的計算速度，犧牲演算法精確性，使用者的行為權重計算亦可以增量計算
設wh為使用者對某個類目的歷史行為權重，wc為使用者最新一天的行為權重，則總的行為權重
wt = λwh + wc, 0
如果採用上述方法，則不必遍歷使用者的所有的行為資料，每次更新時，只需遍歷一天的資料即可。
使用者行為和行為統計表hbase替換為hive，最後的畫像表保留為hbase；
考慮到類目偏好使用比較頻繁，而導購屬性偏好資料量遠大於類目偏好，解耦來將兩者分開儲存；
類目偏好離線資料結構-hive
主要優化和改進如下圖所示。
我們曾經想做實時畫像，實時的達到導到實時裡面，但是現在我們並不是做實時畫像，我們做的是實時推薦，為什麼不做呢？因為這些演算法不太好算，比如說算乙個衰減週期，你要根據30天的編號算乙個你當前類目的變化，你要拿30天的資料，這樣的演算法壓力就很重。未來想做就是使用hbase映象雙集群，apache lgnite+hbase。
我們也做了一些有趣的東西，就是一些排行榜，對某些大學做一些排行榜的排名，實際上根據大學的特定群體我們已經做了推薦，這個東西其實還蠻好玩的。
提煉出該案例（或專案）的哲理、方**。
演算法準確度、資料規模、更新速度相互制衡，提高某些指標，必須犧牲其他指標。
乙個系統遇到效能瓶頸的時候，跳出系統本身，了解業務，根據業務解耦，以滿足不同場景。
資料流各個環節都可能出錯，自動化檢查各個節點的中間資料，考慮降級和延遲環境。
系統的演進是個長期的過程，系統的分分合合和業務量有關，防止過度架構浪費資源。
不同版本開發的時候，適度換些開發者，融入新的思路，避免思維定式。
標籤體系的管理規範比技術本身更重要，否則大部分標籤會沉睡，後面基本用不到。
資料驅動，通過觀察和研究資料，對資料有一定的敏感度，產生新的使用者畫像資料。
七牛架構師實踐日是由七牛雲發起的線下技術沙龍活動，聯合業內資深技術大牛以及各大巨頭公司和創業品牌的優秀架構師，致力於為業內開發者、架構師和決策者提供最前沿、最有深度的技術交流平台，幫助大家知悉技術動態，學習經驗成果。架構師速成1 前言
從事it工作10餘年，痛並快樂著。忠告以下人員遠離it 不能吃苦 耐不住寂寞 想賺大錢 如果你不是上面的人，而且非常想成為架構師話，請繼續看下去。需要3年時間 需要超強自制力 需要極強計畫能力 需要吃苦 如果你能滿足以上4條，那肯定就可以速成。可能有人會說 3年也算速成，這也太龜速了 我回答你，如果...
架構師應該了解的知識1
原題 被架構師秒殺之後 今天被架構師問了一連串的問題，估計問了有乙個多小時吧，有很多問題都答不上來，突然發現原來自己沒有掌握的知識太多了，原來我覺得技術是用來解決問題的，而不是用來研究的，但現在覺得要更快捷的解決問題，還得好好的研究他們的原理，凡事多問個 他的原理是什麼，底層是怎麼實現的 回來好好整...
系統架構師修煉之道 （1） 序
系統架構師是乙個很虛的職位，也是很多程式猿追求的目標，它代表了一定的技術高度，特別是當今網際網路時代，真正懂架構的人不多，我希望能寫下筆記，記錄我的成長一步步成長歷程，希望能和大家一起分享，一起共勉。做過很多簡單的架構，都屬於copy型吧，突然老闆說，你要有個完整的理論基礎，我忽然意識到很多知識都掌...