前言
以前開發過一個畫像項目，併爲你們介紹了項目過程當中部分開發的細節，例如PSM，RFE，USG等模型的標籤開發落地。可是後來考慮到對於沒有畫像開發經驗，尤爲是零基礎的大數據小白而言不是很友好，理解起來也不是很容易。正好最近在看一些文獻資料，因此，我又專門開了一個專題，打算從新爲你們講解關於用戶畫像的知識。感興趣的小夥伴記得關注加星標，天天第一時間收穫技術乾貨！web
1. 用戶畫像是什麼？
在互聯網步入大數據時代後，用戶行爲給企業的產品和服務帶來了一系列的改變和重塑，其中最大的變化在於，用戶的一切行爲在企業面前是可「追溯」「分析」的。企業內保存了大量的原始數據和各類業務數據，這是企業經營活動的真實記錄，如何更加有效地利用這些數據進行分析和評估，成爲企業基於更大數據量背景的問題所在。隨着大數據技術的深刻研究與應用，企業的關注點日益聚焦在如何利用大數據來爲精細化運營和精準營銷服務，而要作精細化運營，首先要創建本企業的用戶畫像。
面試
1.1 畫像簡介
用戶畫像，即用戶信息標籤化，經過收集用戶的社會屬性、消費習慣、偏好特徵等各個維度的數據，進而對用戶或者產品特徵屬性進行刻畫，並對這些特徵進行分析、統計，挖掘潛在價值信息，從而抽象出用戶的信息全貌，如圖1-1所示。用戶畫像可看做企業應用大數據的根基，是定向廣告投放與個性化推薦的前置條件，爲數據驅動運營奠基了基礎。由此看來，如何從海量數據中挖掘出有價值的信息愈加重要。
大數據已經興起多年，其對於互聯網公司的應用來講已經如水、電、空氣對於人們的生活同樣，成爲不可或缺的重要組成部分。從基礎設施建設到應用層面，主要有數據平臺搭建及運維管理、數據倉庫開發、上層應用的統計分析、報表生成及可視化、用戶畫像建模、個性化推薦與精準營銷等應用方向。算法
不少公司在大數據基礎建設上投入不少，也作了很多報表，但業務部門以爲大數據和傳統報表沒什麼區別，也沒能體會大數據對業務有什麼幫助和價值，究其緣由，實際上是「數據靜止在數據倉庫，是死的」。數據庫
而用戶畫像能夠幫助大數據「走出」數據倉庫，針對用戶進行個性化推薦、精準營銷、個性化服務等多樣化服務，是大數據落地應用的一個重要方向。數據應用體系的層級劃分如圖1-2所示。微信
1.2 標籤類型
用戶畫像建模其實就是對用戶「打標籤」，從對用戶打標籤的方式來看，通常分爲3種類型（如圖1-3所示）：①統計類標籤；②規則類標籤；③機器學習挖掘類標籤。架構
下面咱們介紹這3種類型的標籤的區別：框架
1.統計類標籤運維
這類標籤是最爲基礎也最爲常見的標籤類型，例如，對於某個用戶來講，其性別、年齡、城市、星座、近7日活躍時長、近7日活躍天數、近7日活躍次數等字段能夠從用戶註冊數據、用戶訪問、消費數據中統計得出。該類標籤構成了用戶畫像的基礎。機器學習
2.規則類標籤svg
該類標籤基於用戶行爲及肯定的規則產生。例如，對平臺上「消費活躍」用戶這一口徑的定義爲「近30天交易次數≥2」。在實際開發畫像的過程當中，因爲運營人員對業務更爲熟悉，而數據人員對數據的結構、分佈、特徵更爲熟悉，所以規則類標籤的規則由運營人員和數據人員共同協商肯定；
3.機器學習挖掘類標籤
該類標籤經過機器學習挖掘產生，用於對用戶的某些屬性或某些行爲進行預測判斷。例如，根據一個用戶的行爲習慣判斷該用戶是男性仍是女性、根據一個用戶的消費習慣判斷其對某商品的偏好程度。該類標籤須要經過算法挖掘產生。
在項目工程實踐中，通常統計類和規則類的標籤便可以知足應用需求，在開發中佔有較大比例。機器學習挖掘類標籤多用於預測場景，如判斷用戶性別、用戶購買商品偏好、用戶流失意向等。通常地，機器學習標籤開發週期較長，開發成本較高，所以其開發所佔比例較小
2. 數據架構
在整個工程化方案中，系統依賴的基礎設施包括Spark、Hive、HBase、Airflow、MySQL、Redis、Elasticsearch。除去基礎設施外，系統主體還包括 Spark Streaming、ETL、產品端 3個重要組成部分。圖 2-1 所示是用戶畫像數倉架構圖，下面對其進行詳細介紹。
圖1-4 下方虛線框中爲常見的數據倉庫ETL加工流程，也就是將每日的業務數據、日誌數據、埋點數據等通過ETL過程，加工到數據倉庫對應的ODS層、DW層、DM層中。
中間的虛線框即爲用戶畫像建模的主要環節，用戶畫像不是產生數據的源頭，而是對基於數據倉庫ODS層、DW層、DM層中與用戶相關數據的二次建模加工。在ETL過程當中將用戶標籤計算結果寫入Hive，因爲不一樣數據庫有不一樣的應用場景，後續須要進一步將數據同步到MySQL、HBase、Elasticsearch 等數據庫中。
- Hive：存儲用戶標籤計算結果、用戶人羣計算結果、用戶特徵庫計算結果
- MySQL：存儲標籤元數據，監控相關數據，導出到業務系統的數據
- HBase：存儲線上接口實時調用類數據
- Elasticserch：支持海量數據的實時查詢分析，用於存儲用戶人羣計算、用戶羣透視分析所需的用戶標籤數據（因爲用戶人羣計算、用戶羣透視分析的條件轉化成的SQL語句多條件嵌套較爲複雜，使用 Impala 執行也需花費大量時間）
用戶標籤數據在Hive中加工完成後，部分標籤經過Sqoop同步到MySQL數據庫，提供用於BI報表展現的數據、多維透視分析數據、圈人服務數據；另外一部分標籤同步到HBase數據庫用於產品的線上個性化推薦
3. 主要覆蓋模塊
搭建一套用戶畫像方案總體來講須要考慮8個模塊的建設，如圖3-1所示。
- 用戶畫像基礎：須要瞭解、明確用戶畫像是什麼，包含哪些模塊，數據倉庫架構是什麼樣子，開發流程，表結構設計，ETL設計等。這些都是框架，大方向的規劃，只有明確了方向後續才能作好項目的排期和人員投入預算。這對於評估每一個開發階段重要指標和關鍵產出很是重要。
- 數據指標體系：根據業務線梳理，包括用戶屬性、用戶行爲、用戶消費、風險控制等維度的指標體系。
- 標籤數據存儲：標籤相關數據可存儲在Hive、MySQL、HBase、Elasticsearch等數據庫中，不一樣存儲方式適用於不一樣的應用場景。
- 標籤數據開發：用戶畫像工程化的重點模塊，包含統計類、規則類、挖掘類、流式計算類標籤的開發，以及人羣計算功能的開發，打通畫像數據和各業務系統之間的通路，提供接口服務等開發內容。
- 開發性能調優：標籤加工、人羣計算等腳本上線調度後，爲了縮短調度時間、保障數據的穩定性等，須要對開發的腳本進行迭代重構、調優。
- 做業流程調度：標籤加工、人羣計算、同步數據到業務系統、數據監控預警等腳本開發完成後，須要調度工具把整套流程調度起來。
- 用戶畫像產品化：爲了能讓用戶數據更好地服務於業務方，須要以產品化的形態應用在業務上。產品化的模塊主要包括標籤視圖、用戶標籤查詢、用戶分羣、透視分析等。
- 用戶畫像應用：畫像的應用場景包括用戶特徵分析、短信、郵件、站內信、Push消息的精準推送、客服針對用戶的不一樣話術、針對高價值用戶的極速退貨退款等VIP服務應用。
4. 開發階段流程
下面主要介紹畫像系統開發上線的流程以及各階段的關鍵產出。
4.1 開發上線流程
用戶畫像建設項目流程，如圖4-1
第一階段：目標解讀
在創建用戶畫像前，首先須要明確用戶畫像服務於企業的對象，再根據業務方需求，明確將來產品建設目標和用戶畫像分析以後的預期效果。
通常而言，用戶畫像的服務對象包括運營人員和數據分析人員。不一樣業務方對用戶畫像的需求有不一樣的側重點，就運營人員來講，他們須要分析用戶的特徵、定位用戶行爲偏好，作商品或內容的個性化推送以提升點擊轉化率，因此畫像的側重點就落在了用戶我的行爲偏好上；就數據分析人員來講，他們須要分析用戶行爲特徵，作好用戶的流失預警工做，還可根據用戶的消費偏好作更有針對性的精準營銷。
第二階段：任務分解與需求調研
通過第一階段的需求調研和目標解讀，咱們已經明確了用戶畫像的服務對象與應用場景，接下來須要針對服務對象的需求側重點，結合產品現有業務體系和「數據字典」規約實體和標籤之間的關聯關係，明確分析維度。
第三階段：需求場景討論與明確
在本階段，數據運營人員須要根據與需求方的溝通結果，輸出產品用戶畫像需求文檔，在該文檔中明確畫像應用場景、最終開發出的標籤內容與應用方式，並就該文檔與需求方反覆溝通並確認無誤。
第四階段：應用場景與數據口徑確認
通過第三個階段明確了需求場景與最終實現的標籤維度、標籤類型後，數據運營人員須要結合業務與數據倉庫中已有的相關表，明確與各業務場景相關的數據口徑。在該階段中，數據運營方須要輸出產品用戶畫像開發文檔，該文檔須要明確應用場景、標籤開發的模型、涉及的數據庫與表以及應用實施流程。該文檔不須要再與運營方討論，只需面向數據運營團隊內部就開發實施流程達成一致意見便可。
第五階段：特徵選取與模型數據落表
本階段中數據分析挖掘人員須要根據前面明確的需求場景進行業務建模，寫好 HQL 邏輯，將相應的模型邏輯寫入臨時表中，並抽取數據校驗是否符合業務場景需求。
第六階段：線下模型數據驗收與測試
數據倉庫團隊的人員將相關數據落表後，設置定時調度任務，按期增量更新數據。數據運營人員須要驗收數倉加工的 HQL 邏輯是否符合需求，根據業務需求抽取表中數據查看其是否在合理範圍內，若是發現問題要及時反饋給數據倉庫人員調整代碼邏輯和行爲權重的數值。
第七階段：線上模型發佈與效果追蹤
通過第六階段，數據經過驗收以後，會經過Git進行版本管理，部署上線。使用Git進行版本管理，上線後經過持續追蹤標籤應用效果及業務方反饋，調整優化模型及相關權重配置。
4.2 各階段關鍵產出
爲保證程序上線的準時性和穩定性，須要規劃好各階段的任務排期和關鍵產出。畫像體系的開發分爲幾個主要階段，包括前期指標體系梳理、用戶標籤開發、ETL調度開發、打通數據服務層、畫像產品端開發、面向業務方推廣應用、爲業務方提供營銷策略的解決方案等，如表4-2 所示。
- 標籤開發：根據業務需求和應用場景梳理標籤指標體系，調研業務上定義的數據口徑，確認數據來源，開發相應的標籤。標籤開發在整個畫像項目週期中佔有較大比重。
- ETL調度開發：梳理須要調度的各任務之間的依賴關係，開發調度腳本及調度監控告警腳本，上線調度系統。
- 打通服務層接口：爲了讓畫像數據走出數據倉庫，應用到用戶身上，須要打通數據倉庫和各業務系統的接口。
- 畫像產品化：須要產品經理與業務人員、技術開發人員一塊兒對接業務需求點和產品功能實現形式，畫產品原型，肯定工做排期。Java Web端開發完成後，須要數據開發人員向對應的庫表中灌入數據。
- 開發調優：在畫像的數據和產品端搭建好架構、能提供穩定服務的基礎上，爲了讓調度任務執行起來更加高效、提供服務更加穩健，須要對標籤計算腳本、調度腳本、數據同步腳本等相關計算任務進行重構優化。
5. 畫像應用的落地
用戶畫像最終的價值仍是要落地運行，爲業務帶來實際價值。這裏須要開發標籤的數據工程師和需求方相互協做，將標籤應用到業務中。不然開發完標籤後，數據仍是隻停留在數據倉庫中，沒有爲業務決策帶來積極做用。
畫像開發過程當中，還須要開發人員組織數據分析、運營、客服等團隊的人員進行畫像應用上的推廣。對於數據分析人員來講，可能會關注用戶畫像開發了哪些表、哪些字段以及字段的口徑定義；對運營、客服等業務人員來講，可能更關注用戶標籤訂義的口徑，如何在Web端使用畫像產品進行分析、圈定用戶進行定向營銷，以及應用在業務上數據的準確性和及時性。
只有業務人員在平常工做中真正應用畫像數據、畫像產品，才能更好地推進畫像標籤的迭代優化，帶來流量提高和營收增加，產出業績價值
小結
本期內容從用戶畫像的定義出發，依次爲你們介紹了用戶畫像的數據架構，和主要的覆蓋模塊，最後簡單介紹了一下用戶畫像的開發階段流程，以及畫像應用如何實際落地。整體來講，可謂乾貨滿滿，對於零基礎小白而言我相信更是打開了新世界的大門(〃‘▽’〃)。以後我可能會更新一些關於用戶畫像其餘開發方向的內容，例如數據存儲，性能調優，任務流調度等內容，敬請期待！受益的朋友記得三連，我是Alice，咱們下一期見！
你知道的越多，你不知道的也越多！
文章持續更新，能夠微信搜一搜「 猿人菌 」第一時間閱讀，思惟導圖，大數據書籍，大數據高頻面試題，海量一線大廠面經…期待您的關注!
本文同步分享在 博客「Alice菌」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。