用戶畫像（方法論與工程化解方案）

用戶畫像方法論與工程化解方案目錄\h第1章用戶畫像基礎(chǔ)\h1.1用戶畫像是什么\h1.1.1畫像簡介\h1.1.2標(biāo)簽類型\h1.2數(shù)據(jù)架構(gòu)\h1.3主要覆蓋模塊\h1.4開發(fā)階段流程\h1.4.1開發(fā)上線流程\h1.4.2各階段關(guān)鍵產(chǎn)出\h1.5畫像應(yīng)用的落地\h1.6某用戶畫像案例\h1.6.1案例背景介紹\h1.6.2相關(guān)元數(shù)據(jù)\h1.6.3畫像表結(jié)構(gòu)設(shè)計\h1.7定性類畫像\h1.8本章小結(jié)\h第2章數(shù)據(jù)指標(biāo)體系\h2.1用戶屬性維度\h2.1.1常見用戶屬性\h2.1.2用戶性別\h2.2用戶行為維度\h2.3用戶消費維度\h2.4風(fēng)險控制維度\h2.5社交屬性維度\h2.6其他常見標(biāo)簽劃分方式\h2.7標(biāo)簽命名方式\h2.8本章小結(jié)\h第3章標(biāo)簽數(shù)據(jù)存儲\h3.1Hive存儲\h3.1.1Hive數(shù)據(jù)倉庫\h3.1.2分區(qū)存儲\h3.1.3標(biāo)簽匯聚\h3.1.4ID-MAP\h3.2MySQL存儲\h3.2.1元數(shù)據(jù)管理\h3.2.2監(jiān)控預(yù)警數(shù)據(jù)\h3.2.3結(jié)果集存儲\h3.3HBase存儲\h3.3.1HBase簡介\h3.3.2應(yīng)用場景\h3.3.3工程化案例\h3.4Elasticsearch存儲\h3.4.1Elasticsearch簡介\h3.4.2應(yīng)用場景\h3.4.3工程化案例\h3.5本章小結(jié)\h第4章標(biāo)簽數(shù)據(jù)開發(fā)\h4.1統(tǒng)計類標(biāo)簽開發(fā)\h4.1.1近30日購買行為標(biāo)簽案例\h4.1.2最近來訪標(biāo)簽案例\h4.2規(guī)則類標(biāo)簽開發(fā)\h4.2.1用戶價值類標(biāo)簽案例\h4.2.2用戶活躍度標(biāo)簽案例\h4.3挖掘類標(biāo)簽開發(fā)\h4.3.1案例背景\h4.3.2特征選取及開發(fā)\h4.3.3文本分詞處理\h4.3.4數(shù)據(jù)結(jié)構(gòu)處理\h4.3.5文本TF-IDF權(quán)重\h4.3.6樸素貝葉斯分類\h4.4流式計算標(biāo)簽開發(fā)\h4.4.1流式標(biāo)簽建?？蚣躙h4.4.2Kafka簡介\h4.4.3SparkStreaming集成Kafka\h4.4.4標(biāo)簽開發(fā)及工程化\h4.5用戶特征庫開發(fā)\h4.5.1特征庫規(guī)劃\h4.5.2數(shù)據(jù)開發(fā)\h4.5.3其他特征庫規(guī)劃\h4.6標(biāo)簽權(quán)重計算\h4.6.1TF-IDF詞空間向量\h4.6.2時間衰減系數(shù)\h4.6.3標(biāo)簽權(quán)重配置\h4.7標(biāo)簽相似度計算\h4.7.1案例場景\h4.7.2數(shù)據(jù)開發(fā)\h4.8組合標(biāo)簽計算\h4.8.1應(yīng)用場景\h4.8.2數(shù)據(jù)計算\h4.9數(shù)據(jù)服務(wù)層開發(fā)\h4.9.1推送至營銷系統(tǒng)\h4.9.2接口調(diào)用服務(wù)\h4.10GraphX圖計算用戶\h4.10.1圖計算理論及應(yīng)用場景\h4.10.2數(shù)據(jù)開發(fā)案例\h4.11本章小結(jié)\h第5章開發(fā)性能調(diào)優(yōu)\h5.1數(shù)據(jù)傾斜調(diào)優(yōu)\h5.2合并小文件\h5.3緩存中間數(shù)據(jù)\h5.4開發(fā)中間表\h5.5本章小結(jié)\h第6章作業(yè)流程調(diào)度\h6.1crontab命令調(diào)度\h6.2Airflow工作平臺\h6.2.1基礎(chǔ)概念\h6.2.2Airflow服務(wù)構(gòu)成\h6.2.3Airflow安裝\h6.2.4主要模塊功能\h6.2.5工作流調(diào)度\h6.2.6腳本實例\h6.2.7常用命令行\(zhòng)h6.2.8工程化調(diào)度方案\h6.3數(shù)據(jù)監(jiān)控預(yù)警\h6.3.1標(biāo)簽監(jiān)控預(yù)警\h6.3.2服務(wù)層預(yù)警\h6.4ETL異常排查\h6.5本章小結(jié)\h第7章用戶畫像產(chǎn)品化\h7.1即時查詢\h7.2標(biāo)簽視圖與標(biāo)簽查詢\h7.3元數(shù)據(jù)管理\h7.4用戶分群功能\h7.5人群分析功能\h7.6本章小結(jié)\h第8章用戶畫像應(yīng)用\h8.1經(jīng)營分析\h8.1.1商品分析\h8.1.2用戶分析\h8.1.3渠道分析\h8.1.4漏斗分析\h8.1.5客服話術(shù)\h8.1.6人群特征分析\h8.2精準營銷\h8.2.1短信/郵件營銷\h8.2.2效果分析\h8.3個性化推薦與服務(wù)\h8.4本章小結(jié)\h第9章實踐案例詳解\h9.1風(fēng)控反欺詐預(yù)警\h9.1.1應(yīng)用背景\h9.1.2用戶畫像切入點\h9.2A/B人群效果測試\h9.2.1案例背景\h9.2.2用戶畫像切入點\h9.2.3效果分析\h9.3用戶生命周期劃分與營銷\h9.3.1生命周期劃分\h9.3.2不同階段的用戶觸達策略\h9.3.3畫像在生命周期中的應(yīng)用\h9.3.4應(yīng)用案例\h9.4高價值用戶實時營銷\h9.4.1項目應(yīng)用背景\h9.4.2用戶畫像切入點\h9.4.3HBase應(yīng)用場景小結(jié)\h9.5短信營銷用戶\h9.5.1案例背景\h9.5.2畫像切入及其應(yīng)用效果\h9.6Session行為分析應(yīng)用\h9.6.1關(guān)于用戶行為分析\h9.6.2案例背景\h9.6.3特征構(gòu)建\h9.6.4分析方法與結(jié)論\h9.7人群效果監(jiān)測報表搭建\h9.7.1案例背景\h9.7.2邏輯梳理\h9.7.3自動報表郵件\h9.8基于用戶特征庫篩選目標(biāo)人群\h9.8.1案例背景\h9.8.2應(yīng)用方式及效果\h9.9本章小結(jié)\h附錄某產(chǎn)品用戶畫像項目規(guī)劃文檔第1章用戶畫像基礎(chǔ)1.1用戶畫像是什么在互聯(lián)網(wǎng)步入大數(shù)據(jù)時代后，用戶行為給企業(yè)的產(chǎn)品和服務(wù)帶來了一系列的改變和重塑，其中最大的變化在于，用戶的一切行為在企業(yè)面前是可“追溯”“分析”的。企業(yè)內(nèi)保存了大量的原始數(shù)據(jù)和各種業(yè)務(wù)數(shù)據(jù)，這是企業(yè)經(jīng)營活動的真實記錄，如何更加有效地利用這些數(shù)據(jù)進行分析和評估，成為企業(yè)基于更大數(shù)據(jù)量背景的問題所在。隨著大數(shù)據(jù)技術(shù)的深入研究與應(yīng)用，企業(yè)的關(guān)注點日益聚焦在如何利用大數(shù)據(jù)來為精細化運營和精準營銷服務(wù)，而要做精細化運營，首先要建立本企業(yè)的用戶畫像。1.1.1畫像簡介用戶畫像，即用戶信息標(biāo)簽化，通過收集用戶的社會屬性、消費習(xí)慣、偏好特征等各個維度的數(shù)據(jù)，進而對用戶或者產(chǎn)品特征屬性進行刻畫，并對這些特征進行分析、統(tǒng)計，挖掘潛在價值信息，從而抽象出用戶的信息全貌，如圖1-1所示。用戶畫像可看作企業(yè)應(yīng)用大數(shù)據(jù)的根基，是定向廣告投放與個性化推薦的前置條件，為數(shù)據(jù)驅(qū)動運營奠定了基礎(chǔ)。由此看來，如何從海量數(shù)據(jù)中挖掘出有價值的信息越發(fā)重要。圖1-1某用戶標(biāo)簽化大數(shù)據(jù)已經(jīng)興起多年，其對于互聯(lián)網(wǎng)公司的應(yīng)用來說已經(jīng)如水、電、空氣對于人們的生活一樣，成為不可或缺的重要組成部分。從基礎(chǔ)設(shè)施建設(shè)到應(yīng)用層面，主要有數(shù)據(jù)平臺搭建及運維管理、數(shù)據(jù)倉庫開發(fā)、上層應(yīng)用的統(tǒng)計分析、報表生成及可視化、用戶畫像建模、個性化推薦與精準營銷等應(yīng)用方向。很多公司在大數(shù)據(jù)基礎(chǔ)建設(shè)上投入很多，也做了不少報表，但業(yè)務(wù)部門覺得大數(shù)據(jù)和傳統(tǒng)報表沒什么區(qū)別，也沒能體會大數(shù)據(jù)對業(yè)務(wù)有什么幫助和價值，究其原因，其實是“數(shù)據(jù)靜止在數(shù)據(jù)倉庫，是死的”。而用戶畫像可以幫助大數(shù)據(jù)“走出”數(shù)據(jù)倉庫，針對用戶進行個性化推薦、精準營銷、個性化服務(wù)等多樣化服務(wù)，是大數(shù)據(jù)落地應(yīng)用的一個重要方向。數(shù)據(jù)應(yīng)用體系的層級劃分如圖1-2所示。圖1-2數(shù)據(jù)應(yīng)用體系的層級劃分1.1.2標(biāo)簽類型用戶畫像建模其實就是對用戶“打標(biāo)簽”，從對用戶打標(biāo)簽的方式來看，一般分為3種類型（如圖1-3所示）：①統(tǒng)計類標(biāo)簽；②規(guī)則類標(biāo)簽；③機器學(xué)習(xí)挖掘類標(biāo)簽。圖1-3標(biāo)簽類型下面我們介紹這3種類型的標(biāo)簽的區(qū)別：1.統(tǒng)計類標(biāo)簽這類標(biāo)簽是最為基礎(chǔ)也最為常見的標(biāo)簽類型，例如，對于某個用戶來說，其性別、年齡、城市、星座、近7日活躍時長、近7日活躍天數(shù)、近7日活躍次數(shù)等字段可以從用戶注冊數(shù)據(jù)、用戶訪問、消費數(shù)據(jù)中統(tǒng)計得出。該類標(biāo)簽構(gòu)成了用戶畫像的基礎(chǔ)。2.規(guī)則類標(biāo)簽該類標(biāo)簽基于用戶行為及確定的規(guī)則產(chǎn)生。例如，對平臺上“消費活躍”用戶這一口徑的定義為“近30天交易次數(shù)≥2”。在實際開發(fā)畫像的過程中，由于運營人員對業(yè)務(wù)更為熟悉，而數(shù)據(jù)人員對數(shù)據(jù)的結(jié)構(gòu)、分布、特征更為熟悉，因此規(guī)則類標(biāo)簽的規(guī)則由運營人員和數(shù)據(jù)人員共同協(xié)商確定；3.機器學(xué)習(xí)挖掘類標(biāo)簽該類標(biāo)簽通過機器學(xué)習(xí)挖掘產(chǎn)生，用于對用戶的某些屬性或某些行為進行預(yù)測判斷。例如，根據(jù)一個用戶的行為習(xí)慣判斷該用戶是男性還是女性、根據(jù)一個用戶的消費習(xí)慣判斷其對某商品的偏好程度。該類標(biāo)簽需要通過算法挖掘產(chǎn)生。在項目工程實踐中，一般統(tǒng)計類和規(guī)則類的標(biāo)簽即可以滿足應(yīng)用需求，在開發(fā)中占有較大比例。機器學(xué)習(xí)挖掘類標(biāo)簽多用于預(yù)測場景，如判斷用戶性別、用戶購買商品偏好、用戶流失意向等。一般地，機器學(xué)習(xí)標(biāo)簽開發(fā)周期較長，開發(fā)成本較高，因此其開發(fā)所占比例較小。1.2數(shù)據(jù)架構(gòu)在整個工程化方案中，系統(tǒng)依賴的基礎(chǔ)設(shè)施包括Spark、Hive、HBase、Airflow、MySQL、Redis、Elasticsearch。除去基礎(chǔ)設(shè)施外，系統(tǒng)主體還包括SparkStreaming、ETL、產(chǎn)品端3個重要組成部分。圖1-4所示是用戶畫像數(shù)倉架構(gòu)圖，下面對其進行詳細介紹。圖1-4用戶畫像數(shù)倉架構(gòu)圖1-4下方虛線框中為常見的數(shù)據(jù)倉庫ETL加工流程，也就是將每日的業(yè)務(wù)數(shù)據(jù)、日志數(shù)據(jù)、埋點數(shù)據(jù)等經(jīng)過ETL過程，加工到數(shù)據(jù)倉庫對應(yīng)的ODS層、DW層、DM層中。中間的虛線框即為用戶畫像建模的主要環(huán)節(jié)，用戶畫像不是產(chǎn)生數(shù)據(jù)的源頭，而是對基于數(shù)據(jù)倉庫ODS層、DW層、DM層中與用戶相關(guān)數(shù)據(jù)的二次建模加工。在ETL過程中將用戶標(biāo)簽計算結(jié)果寫入Hive，由于不同數(shù)據(jù)庫有不同的應(yīng)用場景，后續(xù)需要進一步將數(shù)據(jù)同步到MySQL、HBase、Elasticsearch等數(shù)據(jù)庫中?！ive：存儲用戶標(biāo)簽計算結(jié)果、用戶人群計算結(jié)果、用戶特征庫計算結(jié)果?！ySQL：存儲標(biāo)簽元數(shù)據(jù)，監(jiān)控相關(guān)數(shù)據(jù)，導(dǎo)出到業(yè)務(wù)系統(tǒng)的數(shù)據(jù)?！Base：存儲線上接口實時調(diào)用類數(shù)據(jù)?！lasticserch：支持海量數(shù)據(jù)的實時查詢分析，用于存儲用戶人群計算、用戶群透視分析所需的用戶標(biāo)簽數(shù)據(jù)（由于用戶人群計算、用戶群透視分析的條件轉(zhuǎn)化成的SQL語句多條件嵌套較為復(fù)雜，使用Impala執(zhí)行也需花費大量時間）。用戶標(biāo)簽數(shù)據(jù)在Hive中加工完成后，部分標(biāo)簽通過Sqoop同步到MySQL數(shù)據(jù)庫，提供用于BI報表展示的數(shù)據(jù)、多維透視分析數(shù)據(jù)、圈人服務(wù)數(shù)據(jù)；另一部分標(biāo)簽同步到HBase數(shù)據(jù)庫用于產(chǎn)品的線上個性化推薦。1.3主要覆蓋模塊搭建一套用戶畫像方案整體來說需要考慮8個模塊的建設(shè)，如圖1-5所示?！び脩舢嬒窕A(chǔ)：需要了解、明確用戶畫像是什么，包含哪些模塊，數(shù)據(jù)倉庫架構(gòu)是什么樣子，開發(fā)流程，表結(jié)構(gòu)設(shè)計，ETL設(shè)計等。這些都是框架，大方向的規(guī)劃，只有明確了方向后續(xù)才能做好項目的排期和人員投入預(yù)算。這對于評估每個開發(fā)階段重要指標(biāo)和關(guān)鍵產(chǎn)出非常重要，重點可看1.4節(jié)?！?shù)據(jù)指標(biāo)體系：根據(jù)業(yè)務(wù)線梳理，包括用戶屬性、用戶行為、用戶消費、風(fēng)險控制等維度的指標(biāo)體系。·標(biāo)簽數(shù)據(jù)存儲：標(biāo)簽相關(guān)數(shù)據(jù)可存儲在Hive、MySQL、HBase、Elasticsearch等數(shù)據(jù)庫中，不同存儲方式適用于不同的應(yīng)用場景?！?biāo)簽數(shù)據(jù)開發(fā)：用戶畫像工程化的重點模塊，包含統(tǒng)計類、規(guī)則類、挖掘類、流式計算類標(biāo)簽的開發(fā)，以及人群計算功能的開發(fā)，打通畫像數(shù)據(jù)和各業(yè)務(wù)系統(tǒng)之間的通路，提供接口服務(wù)等開發(fā)內(nèi)容。圖1-5用戶畫像主要覆蓋模塊·開發(fā)性能調(diào)優(yōu)：標(biāo)簽加工、人群計算等腳本上線調(diào)度后，為了縮短調(diào)度時間、保障數(shù)據(jù)的穩(wěn)定性等，需要對開發(fā)的腳本進行迭代重構(gòu)、調(diào)優(yōu)。·作業(yè)流程調(diào)度：標(biāo)簽加工、人群計算、同步數(shù)據(jù)到業(yè)務(wù)系統(tǒng)、數(shù)據(jù)監(jiān)控預(yù)警等腳本開發(fā)完成后，需要調(diào)度工具把整套流程調(diào)度起來。本書講解了Airflow這款開源ETL工具在調(diào)度畫像相關(guān)任務(wù)腳本上的應(yīng)用?！び脩舢嬒癞a(chǎn)品化：為了能讓用戶數(shù)據(jù)更好地服務(wù)于業(yè)務(wù)方，需要以產(chǎn)品化的形態(tài)應(yīng)用在業(yè)務(wù)上。產(chǎn)品化的模塊主要包括標(biāo)簽視圖、用戶標(biāo)簽查詢、用戶分群、透視分析等。·用戶畫像應(yīng)用：畫像的應(yīng)用場景包括用戶特征分析、短信、郵件、站內(nèi)信、Push消息的精準推送、客服針對用戶的不同話術(shù)、針對高價值用戶的極速退貨退款等VIP服務(wù)應(yīng)用。本書內(nèi)容安排也分別圍繞這8個模塊的內(nèi)容來展開。方便讀者更清楚地了解用戶畫像是如何從0到1搭建起來并提供服務(wù)、驅(qū)動用戶和實現(xiàn)營收增長的。1.4開發(fā)階段流程本節(jié)主要介紹畫像系統(tǒng)開發(fā)上線的流程以及各階段的關(guān)鍵產(chǎn)出。1.4.1開發(fā)上線流程用戶畫像建設(shè)項目流程，如圖1-6所示。圖1-6用戶畫像建設(shè)項目流程第一階段：目標(biāo)解讀在建立用戶畫像前，首先需要明確用戶畫像服務(wù)于企業(yè)的對象，再根據(jù)業(yè)務(wù)方需求，明確未來產(chǎn)品建設(shè)目標(biāo)和用戶畫像分析之后的預(yù)期效果。一般而言，用戶畫像的服務(wù)對象包括運營人員和數(shù)據(jù)分析人員。不同業(yè)務(wù)方對用戶畫像的需求有不同的側(cè)重點，就運營人員來說，他們需要分析用戶的特征、定位用戶行為偏好，做商品或內(nèi)容的個性化推送以提高點擊轉(zhuǎn)化率，所以畫像的側(cè)重點就落在了用戶個人行為偏好上；就數(shù)據(jù)分析人員來說，他們需要分析用戶行為特征，做好用戶的流失預(yù)警工作，還可根據(jù)用戶的消費偏好做更有針對性的精準營銷。第二階段：任務(wù)分解與需求調(diào)研經(jīng)過第一階段的需求調(diào)研和目標(biāo)解讀，我們已經(jīng)明確了用戶畫像的服務(wù)對象與應(yīng)用場景，接下來需要針對服務(wù)對象的需求側(cè)重點，結(jié)合產(chǎn)品現(xiàn)有業(yè)務(wù)體系和“數(shù)據(jù)字典”規(guī)約實體和標(biāo)簽之間的關(guān)聯(lián)關(guān)系，明確分析維度。就后文將要介紹的案例而言，需要從用戶屬性畫像、用戶行為畫像、用戶偏好畫像、用戶群體偏好畫像等角度去進行業(yè)務(wù)建模。第三階段：需求場景討論與明確在本階段，數(shù)據(jù)運營人員需要根據(jù)與需求方的溝通結(jié)果，輸出產(chǎn)品用戶畫像需求文檔，在該文檔中明確畫像應(yīng)用場景、最終開發(fā)出的標(biāo)簽內(nèi)容與應(yīng)用方式，并就該文檔與需求方反復(fù)溝通并確認無誤。第四階段：應(yīng)用場景與數(shù)據(jù)口徑確認經(jīng)過第三個階段明確了需求場景與最終實現(xiàn)的標(biāo)簽維度、標(biāo)簽類型后，數(shù)據(jù)運營人員需要結(jié)合業(yè)務(wù)與數(shù)據(jù)倉庫中已有的相關(guān)表，明確與各業(yè)務(wù)場景相關(guān)的數(shù)據(jù)口徑。在該階段中，數(shù)據(jù)運營方需要輸出產(chǎn)品用戶畫像開發(fā)文檔，該文檔需要明確應(yīng)用場景、標(biāo)簽開發(fā)的模型、涉及的數(shù)據(jù)庫與表以及應(yīng)用實施流程。該文檔不需要再與運營方討論，只需面向數(shù)據(jù)運營團隊內(nèi)部就開發(fā)實施流程達成一致意見即可。第五階段：特征選取與模型數(shù)據(jù)落表本階段中數(shù)據(jù)分析挖掘人員需要根據(jù)前面明確的需求場景進行業(yè)務(wù)建模，寫好HQL邏輯，將相應(yīng)的模型邏輯寫入臨時表中，并抽取數(shù)據(jù)校驗是否符合業(yè)務(wù)場景需求。第六階段：線下模型數(shù)據(jù)驗收與測試數(shù)據(jù)倉庫團隊的人員將相關(guān)數(shù)據(jù)落表后，設(shè)置定時調(diào)度任務(wù)，定期增量更新數(shù)據(jù)。數(shù)據(jù)運營人員需要驗收數(shù)倉加工的HQL邏輯是否符合需求，根據(jù)業(yè)務(wù)需求抽取表中數(shù)據(jù)查看其是否在合理范圍內(nèi)，如果發(fā)現(xiàn)問題要及時反饋給數(shù)據(jù)倉庫人員調(diào)整代碼邏輯和行為權(quán)重的數(shù)值。第七階段：線上模型發(fā)布與效果追蹤經(jīng)過第六階段，數(shù)據(jù)通過驗收之后，會通過Git進行版本管理，部署上線。使用Git進行版本管理，上線后通過持續(xù)追蹤標(biāo)簽應(yīng)用效果及業(yè)務(wù)方反饋，調(diào)整優(yōu)化模型及相關(guān)權(quán)重配置。1.4.2各階段關(guān)鍵產(chǎn)出為保證程序上線的準時性和穩(wěn)定性，需要規(guī)劃好各階段的任務(wù)排期和關(guān)鍵產(chǎn)出。畫像體系的開發(fā)分為幾個主要階段，包括前期指標(biāo)體系梳理、用戶標(biāo)簽開發(fā)、ETL調(diào)度開發(fā)、打通數(shù)據(jù)服務(wù)層、畫像產(chǎn)品端開發(fā)、面向業(yè)務(wù)方推廣應(yīng)用、為業(yè)務(wù)方提供營銷策略的解決方案等，如表1-1所示。表1-1用戶畫像項目各階段關(guān)鍵產(chǎn)出·標(biāo)簽開發(fā)：根據(jù)業(yè)務(wù)需求和應(yīng)用場景梳理標(biāo)簽指標(biāo)體系，調(diào)研業(yè)務(wù)上定義的數(shù)據(jù)口徑，確認數(shù)據(jù)來源，開發(fā)相應(yīng)的標(biāo)簽。標(biāo)簽開發(fā)在整個畫像項目周期中占有較大比重?！TL調(diào)度開發(fā)：梳理需要調(diào)度的各任務(wù)之間的依賴關(guān)系，開發(fā)調(diào)度腳本及調(diào)度監(jiān)控告警腳本，上線調(diào)度系統(tǒng)?！ご蛲ǚ?wù)層接口：為了讓畫像數(shù)據(jù)走出數(shù)據(jù)倉庫，應(yīng)用到用戶身上，需要打通數(shù)據(jù)倉庫和各業(yè)務(wù)系統(tǒng)的接口?！ぎ嬒癞a(chǎn)品化：需要產(chǎn)品經(jīng)理與業(yè)務(wù)人員、技術(shù)開發(fā)人員一起對接業(yè)務(wù)需求點和產(chǎn)品功能實現(xiàn)形式，畫產(chǎn)品原型，確定工作排期。JavaWeb端開發(fā)完成后，需要數(shù)據(jù)開發(fā)人員向?qū)?yīng)的庫表中灌入數(shù)據(jù)。·開發(fā)調(diào)優(yōu)：在畫像的數(shù)據(jù)和產(chǎn)品端搭建好架構(gòu)、能提供穩(wěn)定服務(wù)的基礎(chǔ)上，為了讓調(diào)度任務(wù)執(zhí)行起來更加高效、提供服務(wù)更加穩(wěn)健，需要對標(biāo)簽計算腳本、調(diào)度腳本、數(shù)據(jù)同步腳本等相關(guān)計算任務(wù)進行重構(gòu)優(yōu)化?！っ嫦驑I(yè)務(wù)方推廣應(yīng)用：用戶畫像最終的價值產(chǎn)出點是業(yè)務(wù)方應(yīng)用畫像數(shù)據(jù)進行用戶分析，多渠道觸達運營用戶，分析ROI，提升用戶活躍度或營收。因此，面向業(yè)務(wù)人員推廣畫像系統(tǒng)的使用方式、提供針對具體業(yè)務(wù)場景的解決方案顯得尤為重要。在該階段，相關(guān)人員需要撰寫畫像的使用文檔，提供業(yè)務(wù)支持。1.5畫像應(yīng)用的落地用戶畫像最終的價值還是要落地運行，為業(yè)務(wù)帶來實際價值。這里需要開發(fā)標(biāo)簽的數(shù)據(jù)工程師和需求方相互協(xié)作，將標(biāo)簽應(yīng)用到業(yè)務(wù)中。否則開發(fā)完標(biāo)簽后，數(shù)據(jù)還是只停留在數(shù)據(jù)倉庫中，沒有為業(yè)務(wù)決策帶來積極作用。畫像開發(fā)過程中，還需要開發(fā)人員組織數(shù)據(jù)分析、運營、客服等團隊的人員進行畫像應(yīng)用上的推廣。對于數(shù)據(jù)分析人員來說，可能會關(guān)注用戶畫像開發(fā)了哪些表、哪些字段以及字段的口徑定義；對運營、客服等業(yè)務(wù)人員來說，可能更關(guān)注用戶標(biāo)簽定義的口徑，如何在Web端使用畫像產(chǎn)品進行分析、圈定用戶進行定向營銷，以及應(yīng)用在業(yè)務(wù)上數(shù)據(jù)的準確性和及時性。只有業(yè)務(wù)人員在日常工作中真正應(yīng)用畫像數(shù)據(jù)、畫像產(chǎn)品，才能更好地推動畫像標(biāo)簽的迭代優(yōu)化，帶來流量提升和營收增長，產(chǎn)出業(yè)績價值。1.6某用戶畫像案例這里通過一個貫穿本書的實踐案例來將大家更好地帶入實際開發(fā)畫像、應(yīng)用畫像標(biāo)簽的場景中。本節(jié)主要介紹案例背景及相關(guān)的元數(shù)據(jù)，以及開發(fā)標(biāo)簽中可以設(shè)計的表結(jié)構(gòu)樣式。在本案例的開發(fā)工作中，基于Spark計算引擎，主要涉及的語言包括HiveQL、Python、Scala、Shell等。1.6.1案例背景介紹某圖書電商網(wǎng)站擁有超過千萬的網(wǎng)購用戶群體，所售各品類圖書100余萬種。用戶在平臺上可進行瀏覽、搜索、收藏、下單、購買等行為。商城的運營需要解決兩個問題：一方面在企業(yè)產(chǎn)品線逐漸擴張、信息資源過載的背景下，如何在兼顧自身商業(yè)目標(biāo)的同時更好地滿足消費者的需求，為用戶帶來更個性化的購物體驗，通過內(nèi)容的精準推薦，更好地提高用戶的點擊轉(zhuǎn)化率；另一方面在用戶規(guī)模不斷增長的背景下，運營方考慮建立用戶流失預(yù)警機制，及時識別將要流失的用戶群體，采取運營措施挽回用戶。商城自建立以來，數(shù)據(jù)倉庫中積累著大量的業(yè)務(wù)數(shù)據(jù)、日志數(shù)據(jù)及埋點數(shù)據(jù)。如何充分挖掘沉淀在數(shù)據(jù)倉庫中的數(shù)據(jù)的價值，有效支持用戶畫像的建設(shè)，成為當(dāng)前的重要工作。1.6.2相關(guān)元數(shù)據(jù)在本案例中，可以獲取的數(shù)據(jù)按其類型分為：業(yè)務(wù)類數(shù)據(jù)和用戶行為數(shù)據(jù)。其中業(yè)務(wù)類數(shù)據(jù)是指用戶在平臺上下單、購買、收藏物品、貨物配送等與業(yè)務(wù)相關(guān)的數(shù)據(jù)；用戶行為數(shù)據(jù)是指用戶搜索某條信息、訪問某個頁面、點擊某個按鈕、提交某個表單等通過操作行為產(chǎn)生（在解析日志的埋點表中）的數(shù)據(jù)。涉及數(shù)據(jù)倉庫中的表主要包括用戶信息表、商品訂單表、圖書信息表、圖書類目表、App端日志表、Web端日志表、商品評論表等。下面就用戶畫像建模過程中會用到的一些數(shù)據(jù)表做詳細介紹。1.用戶信息表用戶信息表（見表1-2）存放有關(guān)用戶的各種信息，如用戶姓名、年齡、性別、電話號碼、歸屬地等信息。表1-2用戶信息表（dim.user_basic_info）2.商品訂單表商品訂單表（見表1-3）存放商品訂單的各類信息，包括訂單編號、用戶id、用戶姓名、訂單生成時間、訂單狀態(tài)等信息。表1-3商品訂單表（dw.order_info_fact）3.埋點日志表埋點日志表（見表1-4）存放用戶訪問App時點擊相關(guān)控件的打點記錄。通過在客戶端做埋點，從日志數(shù)據(jù)中解析出來。表1-4埋點日志表（ods.page_event_log）4.訪問日志表訪問日志表（見表1-5）存放用戶訪問App的相關(guān)信息及用戶的LBS相關(guān)信息，通過在客戶端埋點，從日志數(shù)據(jù)中解析出來。表1-5訪問日志表（ods.page_view_log）5.商品評論表商品評論表（見表1-6）存放用戶對商品的評論信息。表1-6商品評論表（dw.book_comment）6.搜索日志表搜索日志表（見表1-7）存放用戶在App端搜索相關(guān)的日志數(shù)據(jù)。表1-7搜索日志表（dw.app_search_log）7.用戶收藏表用戶收藏表（見表1-8）記錄用戶收藏圖書的數(shù)據(jù)。8.購物車信息表購物車信息表（見表1-9）記錄用戶將圖書加入購物車的數(shù)據(jù)。表1-8用戶收藏表（dw.book_collection_df）表1-9購物車信息表（dw.shopping_cart_df）1.6.3畫像表結(jié)構(gòu)設(shè)計表結(jié)構(gòu)設(shè)計也是畫像開發(fā)過程中需要解決的一個重要問題。表結(jié)構(gòu)設(shè)計的重點是要考慮存儲哪些信息、如何存儲（數(shù)據(jù)分區(qū)）、如何應(yīng)用（如何抽取標(biāo)簽）這3個方面的問題。不同業(yè)務(wù)背景有不同的設(shè)計方式，這里提供兩種設(shè)計思路：一是每日全量數(shù)據(jù)的表結(jié)構(gòu)；二是每日增量數(shù)據(jù)的表結(jié)構(gòu)。Hive需要對輸入進行全盤掃描來滿足查詢條件，通過使用分區(qū)可以優(yōu)化查詢。對于用戶標(biāo)簽這種日加工數(shù)據(jù)，隨著時間的推移，分區(qū)數(shù)量的變動也是均勻的。每日全量數(shù)據(jù)，即該表的日期分區(qū)中記錄著截止到當(dāng)天的全量用戶數(shù)據(jù)。例如，“selectcount（*）fromuserprofilewheredata='20180701'”這條語句查詢的是userprofile表截止到2018年7月1日的全量用戶數(shù)據(jù)。日全量數(shù)據(jù)的優(yōu)勢是方便查詢，缺點是不便于探查更細粒度的用戶行為。每日增量數(shù)據(jù)，即該表的日期分區(qū)中記錄著當(dāng)日的用戶行為數(shù)據(jù)。例如，同樣是“selectcount（*）fromuserprofilewheredata='20180701'”，這條語句查詢的是userprofile表在2018年7月1日記錄的當(dāng)日用戶行為數(shù)據(jù)。日增量數(shù)據(jù)可視為ODS層的用戶行為畫像，在應(yīng)用時還需要基于該增量數(shù)據(jù)做進一步的建模加工。下面詳細介紹這兩種表結(jié)構(gòu)的設(shè)計方法。1.日全量數(shù)據(jù)日全量數(shù)據(jù)表中，在每天對應(yīng)的日期分區(qū)中插入截止到當(dāng)天為止的全量數(shù)據(jù)，用戶進行查詢時，只需查詢最近一天的數(shù)據(jù)即可獲得最新全量數(shù)據(jù)。下面以一個具體的日全量表結(jié)構(gòu)的例子來進行說明。CREATETABLE`dw.userprofile_attritube_all`(

`userid`stringCOMMENT'userid',

`labelweight`stringCOMMENT'標(biāo)簽權(quán)重',)

COMMENT'userid用戶畫像數(shù)據(jù)'

PARTITIONEDBY(`data_date`stringCOMMENT'數(shù)據(jù)日期',`theme`stringCOMMENT'二級主題',`labelid`stringCOMMENT'標(biāo)簽id')

這里userid表示用戶id，labelweight表示標(biāo)簽權(quán)重，theme表示標(biāo)簽歸屬的二級主題，labelid表示一個標(biāo)簽id。通過“日期+標(biāo)簽歸屬的二級主題+標(biāo)簽id”的方式進行分區(qū)，設(shè)置三個分區(qū)字段更便于開發(fā)和查詢數(shù)據(jù)。該表結(jié)構(gòu)下的標(biāo)簽權(quán)重僅考慮統(tǒng)計類型標(biāo)簽的權(quán)重，如：歷史購買金額標(biāo)簽對應(yīng)的權(quán)重為金額數(shù)量，用戶近30日訪問天數(shù)為對應(yīng)的天數(shù)，該權(quán)重值的計算未考慮較為復(fù)雜的用戶行為次數(shù)、行為類型、行為距今時間等復(fù)雜情況。通過表名末尾追加“_all”的規(guī)范化命名形式，可直觀看出這是一張日全量表。例如，對于主題類型為“會員”的標(biāo)簽，插入“20190101”日的全量數(shù)據(jù)，可通過語句：insertoverwritetabledw.userprofile_userlabel_allpartition（data_date='20190101'，theme='member'，labelid='ATTRITUBE_U_05_001'）來實現(xiàn)。查詢截止到“20190101”日的被打上會員標(biāo)簽的用戶量，可通過語句：selectcount（distinctuserid）fromdw.userprofile_userlabel_allwheredata_date='20190101'來實現(xiàn)。具體的開發(fā)過程在4.1節(jié)中詳細講解。2.日增量數(shù)據(jù)日增量數(shù)據(jù)表，即在每天的日期分區(qū)中插入當(dāng)天業(yè)務(wù)運行產(chǎn)生的數(shù)據(jù)，用戶進行查詢時通過限制查詢的日期范圍，就可以找出在特定時間范圍內(nèi)被打上特定標(biāo)簽的用戶。下面以一個具體的日增量表結(jié)構(gòu)的例子來說明。CREATETABLEdw.userprofile_act_feature_append(

labelidSTRINGCOMMENT'標(biāo)簽id',

cookieidSTRINGCOMMENT'用戶id',

act_cntintCOMMENT'行為次數(shù)',

tag_type_idintCOMMENT'標(biāo)簽類型編碼'，

act_type_idintCOMMENT'行為類型編碼')

comment'用戶畫像-用戶行為標(biāo)簽表'

PARTITIONEDBY(data_dateSTRINGCOMMENT'數(shù)據(jù)日期')

這里，labelid表示標(biāo)簽名稱；cookieid表示用戶id；act_cnt表示用戶當(dāng)日行為次數(shù)，如用戶當(dāng)日瀏覽某三級品類商品3次，則打上次數(shù)為3；tag_type_id為標(biāo)簽類型，如母嬰、3C、數(shù)碼等不同類型；act_type_id表示行為類型，如瀏覽、搜索、收藏、下單等行為。分區(qū)方式為按日期分區(qū)，插入當(dāng)日數(shù)據(jù)。通過表名末尾追加“_append”的規(guī)范化命名形式，可直觀看出這是一張日增量表。例如，某用戶在“20180701”日瀏覽某3C電子商品4次（act_cnt），即給該用戶（userid）打上商品對應(yīng)的三級品類標(biāo)簽（tagid），標(biāo)簽類型（tag_type_id）為3C電子商品，行為類型（act_type_id）為瀏覽。這里可以通過對標(biāo)簽類型和行為類型兩個字段配置維度表的方式，對數(shù)據(jù)進行管理。例如對于行為類型（act_type_id）字段，可以設(shè)定1為購買行為、2為瀏覽行為、3為收藏行為等，在行為標(biāo)簽表中以數(shù)值定義用戶行為類型，在維度表中維護每個數(shù)值對應(yīng)的具體含義。該日增量數(shù)據(jù)表可視為ODS層用戶行為標(biāo)簽明細。在查詢過程中，例如對于某用戶id為001的用戶，查詢其在“20180701”日到“20180707”日被打上的標(biāo)簽，可通過命令：select*fromdw.userprofile_act_feature_appendwhereuserid='001'anddata_date>='20180701'anddata_date<='20180707'查詢。該日增量的表結(jié)構(gòu)記錄了用戶每天的行為帶來的標(biāo)簽，但未計算打在用戶身上標(biāo)簽的權(quán)重，計算權(quán)重時還需做進一步建模加工。標(biāo)簽權(quán)重算法詳見4.6節(jié)的內(nèi)容。3.關(guān)于寬表設(shè)計用戶畫像表結(jié)構(gòu)如何設(shè)計，沒有一定要遵循的固定的格式，符合業(yè)務(wù)需要、能滿足應(yīng)用即可。下面通過兩個寬表設(shè)計的案例，提供另一種解決方案的思路。用戶屬性寬表設(shè)計（見表1-10），主要記錄用戶基本屬性信息。表1-10用戶屬性寬表設(shè)計用戶日活躍寬表設(shè)計（見表1-11），主要記錄用戶每天訪問的信息。表1-11用戶日活躍寬表設(shè)計1.7定性類畫像本書重點講解如何運用大數(shù)據(jù)定量刻畫用戶畫像，然而對于用戶的刻畫除了定量維度外，定性刻畫也是常見手段。定性類畫像多見于用戶研究等運營類崗位，通過電話調(diào)研、網(wǎng)絡(luò)調(diào)研問卷、當(dāng)面深入訪談、網(wǎng)上第三方權(quán)威數(shù)據(jù)等方式收集用戶信息，幫助其理解用戶。這種定性類調(diào)研相比大數(shù)據(jù)定量刻畫用戶來說，可以更精確地了解用戶需求和行為特征，但這個樣本量是有限的，得出的結(jié)論也不一定能代表大部分用戶的觀點。通過制定調(diào)研問卷表，我們可以收集用戶基本信息以及設(shè)置一個或多個場景，專訪用戶或網(wǎng)絡(luò)回收調(diào)研問卷，在分析問卷數(shù)據(jù)后獲取用戶的畫像特征。目前市場上“問卷星”等第三方問卷調(diào)查平臺可提供用戶問卷設(shè)計、鏈接發(fā)放、采集數(shù)據(jù)和信息、調(diào)研結(jié)果分析等一系列功能，如圖1-7所示。圖1-7某調(diào)研問卷示例（截圖自“問卷星”）根據(jù)回收的調(diào)研問卷，可結(jié)合統(tǒng)計數(shù)據(jù)進一步分析用戶畫像特征（如圖1-8所示）。圖1-8回收的調(diào)研問卷（截圖自“問卷星”）1.8本章小結(jié)本章主要介紹了用戶畫像的一些基礎(chǔ)知識，包括畫像的簡介、標(biāo)簽類型、整個畫像系統(tǒng)的數(shù)據(jù)架構(gòu)，開發(fā)畫像系統(tǒng)主要覆蓋的8個模塊，以及開發(fā)過程中的各階段關(guān)鍵產(chǎn)出。初步介紹了畫像系統(tǒng)的輪廓概貌，幫助讀者對于如何設(shè)計畫像系統(tǒng)、開發(fā)周期、畫像的應(yīng)用方式等有宏觀的初步的了解。本書后面的章節(jié)將圍繞1.3節(jié)中畫像系統(tǒng)覆蓋的8個模塊依次展開。第2章數(shù)據(jù)指標(biāo)體系數(shù)據(jù)指標(biāo)體系是建立用戶畫像的關(guān)鍵環(huán)節(jié)，也是在標(biāo)簽開發(fā)前要進行的工作，具體來說就是需要結(jié)合企業(yè)的業(yè)務(wù)情況設(shè)定相關(guān)的指標(biāo)?；ヂ?lián)網(wǎng)相關(guān)企業(yè)在建立用戶畫像時一般除了基于用戶維度（userid）建立一套用戶標(biāo)簽體系外，還會基于用戶使用設(shè)備維度（cookieid）建立相應(yīng)的標(biāo)簽體系?；赾ookieid維度的標(biāo)簽應(yīng)用也很容易理解，當(dāng)用戶沒有登錄賬戶而訪問設(shè)備時，也可以基于用戶在設(shè)備上的行為對該設(shè)備推送相關(guān)的廣告、產(chǎn)品和服務(wù)。建立的用戶標(biāo)簽按標(biāo)簽類型可以分為統(tǒng)計類、規(guī)則類和機器學(xué)習(xí)挖掘類，相關(guān)內(nèi)容在1.1.2節(jié)中有詳細介紹。從建立的標(biāo)簽維度來看，可以將其分為用戶屬性類、用戶行為類、用戶消費類和風(fēng)險控制類等常見類型。下面詳細介紹用戶標(biāo)簽體系的構(gòu)成及應(yīng)用場景。2.1用戶屬性維度2.1.1常見用戶屬性用戶屬性是刻畫用戶的基礎(chǔ)。常見用戶屬性指標(biāo)包括：用戶的年齡、性別、安裝時間、注冊狀態(tài)、城市、省份、活躍登錄地、歷史購買狀態(tài)、歷史購買金額等。用戶屬性維度的標(biāo)簽建成后可以提供客服電話服務(wù)，為運營人員了解用戶基本情況提供幫助。用戶屬性標(biāo)簽包含統(tǒng)計類、規(guī)則類、機器學(xué)習(xí)挖掘類等類型。統(tǒng)計類標(biāo)簽的開發(fā)較為簡單，機器學(xué)習(xí)挖掘類標(biāo)簽將在4.3節(jié)中通過具體案例進行講解。本節(jié)主要介紹常見用戶屬性標(biāo)簽主要包括的維度。表2-1給出了常用的用戶屬性維度標(biāo)簽。表2-1用戶屬性維度標(biāo)簽示例表2-1對于相同的一級標(biāo)簽類型，需要判斷多個標(biāo)簽之間的關(guān)系為互斥關(guān)系還是非互斥關(guān)系。例如，在判斷性別時，用戶性別為男的情況下就不能同時為女，所以標(biāo)簽之間為互斥關(guān)系；在判斷用戶是否在黑名單內(nèi)時，用戶既可能在短信黑名單中，也可能同時在郵件黑名單中，所以這種就為非互斥關(guān)系。對于根據(jù)數(shù)值進行統(tǒng)計、分類的標(biāo)簽開發(fā)相對容易。例如，用戶的“性別”“年齡”“城市”“歷史購買金額”等確定性的標(biāo)簽。而在對規(guī)則類的標(biāo)簽進行開發(fā)前則首先需要進行數(shù)據(jù)調(diào)研。例如，對于用戶價值度劃分（RFM），如何確定一個用戶是重要價值用戶還是一般價值用戶，對于用戶活躍度的劃分如何確定是高活躍、中活躍、低活躍還是已經(jīng)流失，需要結(jié)合數(shù)據(jù)調(diào)研情況給出科學(xué)的規(guī)則并進行劃分。在4.2節(jié)中，將會通過兩個案例介紹規(guī)則類標(biāo)簽如何開發(fā)。2.1.2用戶性別用戶性別可細分為自然性別和購物性別兩種。自然性別是指用戶的實際性別，一般可通過用戶注冊信息、填寫調(diào)查問卷表單等途徑獲得。該標(biāo)簽只需要從相應(yīng)的表中抽取數(shù)據(jù)即可，加工起來較為方便。用戶購物性別是指用戶購買物品時的性別取向。例如，一位實際性別為男性的用戶，可能經(jīng)常給妻子購買女性的衣物、包等商品，那么這位用戶的購物性別則是女性。2.2用戶行為維度用戶行為是另一種刻畫用戶的常見維度，通過用戶行為可以挖掘其偏好和特征。常見用戶行為維度指標(biāo)（見表2-2）包括：用戶訂單相關(guān)行為、下單/訪問行為、用戶近30天行為類型指標(biāo)、用戶高頻活躍時間段、用戶購買品類、點擊偏好、營銷敏感度等相關(guān)行為。表2-2用戶行為維度標(biāo)簽示例2.3用戶消費維度對于用戶消費維度指標(biāo)體系的建設(shè)，可從用戶瀏覽、加購、下單、收藏、搜索商品對應(yīng)的品類入手，品類越細越精確，給用戶推薦或營銷商品的準確性越高。如圖2-1所示，根據(jù)用戶相關(guān)行為對應(yīng)商品品類建設(shè)指標(biāo)體系，本案例精確到商品三級品類。表2-3為用戶消費維度的標(biāo)簽設(shè)計。圖2-1用戶消費維度指標(biāo)梳理表2-3用戶消費維度標(biāo)簽示例這里通過一個場景來介紹構(gòu)建用戶消費維度的標(biāo)簽的應(yīng)用。某女裝大促活動期間，渠道運營人員需要篩選出平臺上的優(yōu)質(zhì)用戶，并通過短信、郵件、Push等渠道進行營銷，可以通過圈選“瀏覽”“收藏”“加購”“購買”“搜索”與該女裝相關(guān)品類”的標(biāo)簽來篩選出可能對該女裝感興趣的潛在用戶，進一步組合其他標(biāo)簽（如“性別”“消費金額”“活躍度”等）篩選出對應(yīng)的高質(zhì)量用戶群，推送到對應(yīng)渠道。因此將商品品類抽象成標(biāo)簽后，可通過品類+行為的組合應(yīng)用方式找到目標(biāo)潛在用戶人群。2.4風(fēng)險控制維度互聯(lián)網(wǎng)企業(yè)的用戶可能會遇到薅羊毛、惡意刷單、借貸欺詐等行為的用戶，為了防止這類用戶給平臺帶來損失和風(fēng)險，互聯(lián)網(wǎng)公司需要在風(fēng)險控制維度構(gòu)建起相關(guān)的指標(biāo)體系，有效監(jiān)控平臺的不良用戶。結(jié)合公司業(yè)務(wù)方向，例如可從賬號風(fēng)險、設(shè)備風(fēng)險、借貸風(fēng)險等維度入手構(gòu)建風(fēng)控維度標(biāo)簽體系。下面詳細介紹一些常見的風(fēng)險控制維度的標(biāo)簽示例，如表2-4所示。表2-4風(fēng)險控制維度標(biāo)簽示例2.5社交屬性維度社交屬性用于了解用戶的家庭成員、社交關(guān)系、社交偏好、社交活躍程度等方面，通過這些信息可以更好地為用戶提供個性化服務(wù)。表2-5是常用的社交屬性維度標(biāo)簽示例。表2-5社交屬性維度標(biāo)簽示例在日常使用社交軟件時，我們可以發(fā)現(xiàn)社交軟件中的信息流廣告會結(jié)合我們的社交特征進行個性化推送。如圖2-2所示，結(jié)合我所在城市、經(jīng)?；钴S地段及近期收藏的電腦相關(guān)文章，在微信朋友圈給我推送了相關(guān)電腦營銷的廣告。如圖2-3所示，基于我的星座和年齡段信息，推送符合我某些特征的婚慶攝影廣告。圖2-2朋友圈信息流廣告–基于位置（截圖自微信）圖2-3朋友圈信息流廣告–基于星座（截圖自微信）2.6其他常見標(biāo)簽劃分方式本章前5節(jié)從用戶屬性、用戶行為、用戶消費、風(fēng)險控制、社交屬性共五大維度劃分歸類了用戶標(biāo)簽指標(biāo)體系。但對用戶標(biāo)簽體系的歸類并不局限于此，通過應(yīng)用場景對標(biāo)簽進行歸類也是常見的標(biāo)簽劃分方式。圖2-4展示了具體的畫像標(biāo)簽應(yīng)用場景劃分。從業(yè)務(wù)場景的角度出發(fā)，可以將用戶標(biāo)簽體系歸為用戶屬性、用戶行為、營銷場景、地域細分、偏好細分、用戶分層等維度。每個維度可細分出二級標(biāo)簽、三級標(biāo)簽等?！び脩魧傩裕喊ㄓ脩舻哪挲g、性別、設(shè)備型號、安裝/注冊狀態(tài)、職業(yè)等刻畫用戶靜態(tài)特征的屬性?！び脩粜袨椋喊ㄓ脩舻南M行為、購買后行為、近N日的訪問、收藏、下單、購買、售后等相關(guān)行為。圖2-4畫像標(biāo)簽應(yīng)用場景劃分·偏好細分：用戶對于商品品類、商品價格段、各營銷渠道、購買的偏好類型、不同營銷方式等方面的偏好特征；·風(fēng)險控制：對用戶從征信風(fēng)險、使用設(shè)備的風(fēng)險、在平臺消費過程中產(chǎn)生的問題等維度考量其風(fēng)險程度；·業(yè)務(wù)專用：應(yīng)用在各種業(yè)務(wù)上的標(biāo)簽，如A/B測試標(biāo)簽、Push系統(tǒng)標(biāo)簽等；·營銷場景：以場景化進行分類，根據(jù)業(yè)務(wù)需要構(gòu)建一系列營銷場景，激發(fā)用戶的潛在需求，如差異化客服、場景用戶、再營銷用戶等；·地域細分：標(biāo)識用戶的常住城市、居住商圈、工作商圈等信息，應(yīng)用在基于用戶地理位置進行推薦的場景中；·用戶分層：對用戶按生命周期、RFM、消費水平類型、活躍度類型等進行分層劃分。本節(jié)提供了一種從業(yè)務(wù)場景的角度出發(fā)對標(biāo)簽體系進行歸類的解決方案。為讀者構(gòu)建標(biāo)簽體系提供了另外一種參考維度。2.7標(biāo)簽命名方式為了便于對諸多標(biāo)簽進行集中管理，需要對每個標(biāo)簽對應(yīng)的標(biāo)簽id進行命名。例如，對性別為“男”的用戶打上標(biāo)簽“ATTRITUBE_U_ol_001”，性別為“女”的用戶打上標(biāo)簽“ATTRITUBE_U_01_002”。下面我們詳細介紹如何建立起這套標(biāo)簽命名方式。對于一個標(biāo)簽，可以從標(biāo)簽主題、刻畫維度、標(biāo)簽類型、一級歸類等多角度入手來確定每個標(biāo)簽的唯一名稱，如圖2-5所示。圖2-5用戶標(biāo)簽命名維度·標(biāo)簽主題：用于刻畫屬于哪種類型的標(biāo)簽，如人口屬性、行為屬性、用戶消費、風(fēng)險控制等多種類型，可分別用ATTRITUBE、ACTION、CONSUME、RISKMANAGE等單詞表示各標(biāo)簽主題?！び脩艟S度：用于刻畫該標(biāo)簽是打在用戶唯一標(biāo)識（userid）上，還是打在用戶使用的設(shè)備（cookieid）上?？捎肬、C等字母分別標(biāo)識userid和cookieid維度?！?biāo)簽類型：類型可劃分為統(tǒng)計型、規(guī)則型和算法型。其中統(tǒng)計型開發(fā)可直接從數(shù)據(jù)倉庫中各主題表建模加工而成，規(guī)則型需要結(jié)合公司業(yè)務(wù)和數(shù)據(jù)情況，算法型開發(fā)需要對數(shù)據(jù)做機器學(xué)習(xí)的算法處理得到相應(yīng)的標(biāo)簽。·一級維度：在每個標(biāo)簽主題大類下面，進一步細分維度來刻畫用戶。參照上面的命名維度和命名方式，下面通過幾個例子來講述如何命名標(biāo)簽。對于用戶的性別標(biāo)簽，標(biāo)簽主題是人口屬性，用戶維度為userid，標(biāo)簽類型屬于算法型。給男性用戶打上標(biāo)簽“ATTRITUBE_U_01_001”，給女性用戶打上標(biāo)簽“ATTRITUBE_U_01_002”，其中“ATTRITUBE”為人口屬性主題，“_”后面的”U”為userid維度，“_”后面“01”為一級歸類，最后面的“001”和“002”為該一級標(biāo)簽下的標(biāo)簽明細，如果是劃分高中低活躍用戶的，對應(yīng)一級標(biāo)簽下的明細可劃分為“001”“002”“003”。標(biāo)簽統(tǒng)一命名后，維護一張碼表記錄標(biāo)簽id名稱、標(biāo)簽含義及標(biāo)簽口徑等主要信息，后期方便元數(shù)據(jù)的維護和管理。本節(jié)介紹的標(biāo)簽命名方式可作為開發(fā)標(biāo)簽過程中的一種參考方式。2.8本章小結(jié)本章主要介紹了如何結(jié)合業(yè)務(wù)場景去搭建刻畫用戶的數(shù)據(jù)指標(biāo)體系。其中2.1節(jié)到2.5節(jié)介紹了一種從用戶屬性、用戶行為、用戶消費、風(fēng)險控制和社交屬性5個維度建立用戶標(biāo)簽體系的思路，2.6節(jié)提供了一種基于應(yīng)用場景搭建指標(biāo)體系的思路。2.7節(jié)介紹了一種規(guī)范化命名標(biāo)簽的解決方案，可保證對每一個業(yè)務(wù)標(biāo)簽打上唯一的標(biāo)簽id。對于互聯(lián)網(wǎng)企業(yè)來說，其存儲的海量用戶訪問日志數(shù)據(jù)便于分析用戶操作的行為特性；而對于傳統(tǒng)企業(yè)來說則可以更多地從用戶屬性維度去豐富指標(biāo)體系。第3章標(biāo)簽數(shù)據(jù)存儲在畫像系統(tǒng)搭建的過程中，數(shù)據(jù)存儲的技術(shù)選型是非常重要的一項內(nèi)容，不同的存儲方式適用于不同的應(yīng)用場景。本章主要介紹使用Hive、MySQL、HBase、Elasticsearch存儲畫像相關(guān)數(shù)據(jù)的應(yīng)用場景及對應(yīng)的解決方案。3.1Hive存儲本節(jié)內(nèi)容主要介紹使用Hive作為數(shù)據(jù)倉庫的應(yīng)用場景時，相應(yīng)的庫表結(jié)構(gòu)如何設(shè)計。3.1.1Hive數(shù)據(jù)倉庫建立用戶畫像首先需要建立數(shù)據(jù)倉庫，用于存儲用戶標(biāo)簽數(shù)據(jù)。Hive是基于Hadoop的數(shù)據(jù)倉庫工具，依賴于HDFS存儲數(shù)據(jù)，提供的SQL語言可以查詢存儲在HDFS中的數(shù)據(jù)。開發(fā)時一般使用Hive作為數(shù)據(jù)倉庫，存儲標(biāo)簽和用戶特征庫等相關(guān)數(shù)據(jù)?！皵?shù)據(jù)倉庫之父”W.H.Inmon在《BuildingtheDataWarehouse》一書中定義數(shù)據(jù)倉庫是“一個面向主題的、集成的、非易失的、隨時間變化的、用來支持管理人員決策的數(shù)據(jù)集合”?！っ嫦蛑黝}：業(yè)務(wù)數(shù)據(jù)庫中的數(shù)據(jù)主要針對事務(wù)處理，各個業(yè)務(wù)系統(tǒng)之間是相互分離的，而數(shù)據(jù)倉庫中的數(shù)據(jù)是按照一定主題進行組織的?！ぜ桑簲?shù)據(jù)倉庫中存儲的數(shù)據(jù)是從業(yè)務(wù)數(shù)據(jù)庫中提取出來的，但并不是對原有數(shù)據(jù)的簡單復(fù)制，而是經(jīng)過了抽取、清理、轉(zhuǎn)換（ETL）等工作。業(yè)務(wù)數(shù)據(jù)庫記錄的是每一項業(yè)務(wù)處理的流水賬。這些數(shù)據(jù)不適合進行分析處理，進入數(shù)據(jù)倉庫之前需要經(jīng)過一系列計算，同時拋棄一些無關(guān)分析處理的數(shù)據(jù)?！し且资В簶I(yè)務(wù)數(shù)據(jù)庫中一般只存儲短期數(shù)據(jù)，因此其數(shù)據(jù)是不穩(wěn)定的，記錄的是系統(tǒng)中數(shù)據(jù)變化的瞬態(tài)。數(shù)據(jù)倉庫中的數(shù)據(jù)大多表示過去某一時刻的數(shù)據(jù)，主要用于查詢、分析，不像業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)庫一樣經(jīng)常修改，一般數(shù)據(jù)倉庫構(gòu)建完成后主要用于訪問，不進行修改和刪除?！るS時間變化：數(shù)據(jù)倉庫關(guān)注的是歷史數(shù)據(jù)，按時間順序定期從業(yè)務(wù)庫和日志庫里面載入新的數(shù)據(jù)進行追加，帶有時間屬性。數(shù)據(jù)抽取到數(shù)據(jù)倉庫的流程如圖3-1所示。圖3-1數(shù)據(jù)抽取到數(shù)據(jù)倉庫在數(shù)據(jù)倉庫建模的過程中，主要涉及事實表和維度表的建模開發(fā)（圖3-2）。事實表主要圍繞業(yè)務(wù)過程設(shè)計，就應(yīng)用場景來看主要包括事務(wù)事實表，周期快照事實表和累計快照事實表：·事務(wù)事實表：用于描述業(yè)務(wù)過程，按業(yè)務(wù)過程的單一性或多業(yè)務(wù)過程可進一步分為單事務(wù)事實表和多事務(wù)事實表。其中單事務(wù)事實表分別記錄每個業(yè)務(wù)過程，如下單業(yè)務(wù)記入下單事實表，支付業(yè)務(wù)記入支付事實表。多事務(wù)事實表在同一個表中包含了不同業(yè)務(wù)過程，如下單、支付、簽收等業(yè)務(wù)過程記錄在一張表中，通過新增字段來判斷屬于哪一個業(yè)務(wù)過程。當(dāng)不同業(yè)務(wù)過程有著相似性時可考慮將多業(yè)務(wù)過程放到多事務(wù)事實表中?！ぶ芷诳煺帐聦嵄恚涸谝粋€確定的時間間隔內(nèi)對業(yè)務(wù)狀態(tài)進行度量。例如查看一個用戶的近1年付款金額、近1年購物次數(shù)、近30日登錄天數(shù)等?！だ塾嬁煺帐聦嵄恚河糜诓榭床煌录g的時間間隔，例如分析用戶從購買到支付的時長、從下單到訂單完結(jié)的時長等。一般適用于有明確時間周期的業(yè)務(wù)過程。圖3-2數(shù)據(jù)倉庫建模維度表主要用于對事實屬性的各個方面描述，例如，商品維度包括商品的價格、折扣、品牌、原廠家、型號等方面信息。維度表開發(fā)的過程中，經(jīng)常會遇到維度緩慢變化的情況，對于緩慢變化維一般會采用：①重寫維度值，對歷史數(shù)據(jù)進行覆蓋；②保留多條記錄，通過插入維度列字段加以區(qū)分；③開發(fā)日期分區(qū)表，每日分區(qū)數(shù)據(jù)記錄當(dāng)日維度的屬性；④開發(fā)拉鏈表按時間變化進行全量存儲等方式進行處理。在畫像系統(tǒng)中主要使用Hive作為數(shù)據(jù)倉庫，開發(fā)相應(yīng)的維度表和事實表來存儲標(biāo)簽、人群、應(yīng)用到服務(wù)層的相關(guān)數(shù)據(jù)。3.1.2分區(qū)存儲如果將用戶標(biāo)簽開發(fā)成一張大的寬表，在這張寬表下放幾十種類型標(biāo)簽，那么每天該畫像寬表的ETL作業(yè)將會花費很長時間，而且不便于向這張寬表中新增標(biāo)簽類型。要解決這種ETL花費時間較長的問題，可以從以下幾個方面著手：·將數(shù)據(jù)分區(qū)存儲，分別執(zhí)行作業(yè)；·標(biāo)簽?zāi)_本性能調(diào)優(yōu)；·基于一些標(biāo)簽共同的數(shù)據(jù)來源開發(fā)中間表。下面介紹一種用戶標(biāo)簽分表、分區(qū)存儲的解決方案。根據(jù)標(biāo)簽指標(biāo)體系的人口屬性、行為屬性、用戶消費、風(fēng)險控制、社交屬性等維度分別建立對應(yīng)的標(biāo)簽表進行分表存儲對應(yīng)的標(biāo)簽數(shù)據(jù)。如圖3-3所示?！と丝趯傩员恚篸w.userprofile_attritube_all；·行為屬性表：dw.userprofile_action_all；·用戶消費表：dw.userprofile_consume_all；·風(fēng)險控制表：dw.userprofile_riskmanage_all；·社交屬性表：dw.userprofile_social_all圖3-3用戶標(biāo)簽數(shù)據(jù)ETL邏輯示意圖例如創(chuàng)建用戶的人口屬性寬表：同樣的，用戶其他id維度（如cookieid、deviceid、registerid等）的標(biāo)簽數(shù)據(jù)存儲，也可以使用上面案例中的表結(jié)構(gòu)。在上面的創(chuàng)建中通過設(shè)立人口屬性維度的寬表開發(fā)相關(guān)的用戶標(biāo)簽，為了提高數(shù)據(jù)的插入和查詢效率，在Hive中可以使用分區(qū)表的方式，將數(shù)據(jù)存儲在不同的目錄中。在Hive使用select查詢時一般會掃描整個表中所有數(shù)據(jù)，將會花費很多時間掃描不是當(dāng)前要查詢的數(shù)據(jù)，為了掃描表中關(guān)心的一部分數(shù)據(jù)，在建表時引入了partition的概念。在查詢時，可以通過Hive的分區(qū)機制來控制一次遍歷的數(shù)據(jù)量。3.1.3標(biāo)簽匯聚在3.1.2節(jié)的案例中，用戶的每個標(biāo)簽都插入到相應(yīng)的分區(qū)下面，但是對一個用戶來說，打在他身上的全部標(biāo)簽存儲在不同的分區(qū)下面。為了方便分析和查詢，需要將用戶身上的標(biāo)簽做聚合處理。緊接3.1.2節(jié)的案例，下面講解標(biāo)簽匯聚的開發(fā)案例（見圖3-4）。標(biāo)簽匯聚后將一個每個用戶身上的全量標(biāo)簽匯聚到一個字段中，表結(jié)構(gòu)設(shè)計如下：CREATETABLE`dw.userprofile_userlabel_map_all`(

`userid`stringCOMMENT'userid',

`userlabels`map<string,string>COMMENT'tagsmap',)

COMMENT'userid用戶標(biāo)簽匯聚'

PARTITIONEDBY(`data_date`stringCOMMENT'數(shù)據(jù)日期')

圖3-4標(biāo)簽匯聚數(shù)據(jù)開發(fā)udf函數(shù)“cast_to_json”將用戶身上的標(biāo)簽匯聚成json字符串，執(zhí)行命令將按分區(qū)存儲的標(biāo)簽進行匯聚：insertoverwritetabledw.userprofile_userlabel_map_allpartition(data_date="data_date")

selectuserid,

cast_to_json(concat_ws(',',collect_set(concat(labelid,':',labelweight))))asuserlabels

from“用戶各維度的標(biāo)簽表”

wheredata_date="data_date"

groupbyuserid

匯聚后用戶標(biāo)簽的存儲格式如圖3-5所示圖3-5標(biāo)簽匯聚數(shù)據(jù)將用戶身上的標(biāo)簽進行聚合便于查詢和計算。例如，在畫像產(chǎn)品中，輸入用戶id后通過直接查詢該表，解析標(biāo)簽id和對應(yīng)的標(biāo)簽權(quán)重后，即可在前端展示該用戶的相關(guān)信息（如圖3-6所示）。圖3-6用戶標(biāo)簽查詢3.1.4ID-MAP開發(fā)用戶標(biāo)簽的時候，有項非常重要的內(nèi)容——ID-MApping，即把用戶不同來源的身份標(biāo)識通過數(shù)據(jù)手段識別為同一個主體。用戶的屬性、行為相關(guān)數(shù)據(jù)分散在不同的數(shù)據(jù)來源中，通過ID-MApping能夠把用戶在不同場景下的行為串聯(lián)起來，消除數(shù)據(jù)孤島。圖3-7展示了用戶與設(shè)備間的多對多關(guān)系。圖3-8展示了同一用戶在不同平臺間的行為示意圖。圖3-7用戶和設(shè)備間的多對多關(guān)系圖3-8串聯(lián)同一個用戶在不同平臺間行為舉例來說，用戶在未登錄App的狀態(tài)下，在App站內(nèi)訪問、搜索相關(guān)內(nèi)容時，記錄的是設(shè)備id（即cookieid）相關(guān)的行為數(shù)據(jù)。而用戶在登錄App后，訪問、收藏、下單等相關(guān)的行為記錄的是賬號id（即userid）相關(guān)行為數(shù)據(jù)。雖然是同一個用戶，但其在登錄和未登錄設(shè)備時記錄的行為數(shù)據(jù)之間是未打通的。通過ID-MApping打通userid和cookieid的對應(yīng)關(guān)系，可以在用戶登錄、未登錄設(shè)備時都能捕獲其行為軌跡。下面通過一個案例介紹如何通過Hive的ETL工作完成ID-Mapping的數(shù)據(jù)清洗工作。緩慢變化維是在維表設(shè)計中常見的一種方式，維度并不是不變的，隨時間也會發(fā)生緩慢變化。如用戶的手機號、郵箱等信息可能會隨用戶的狀態(tài)變化而改變，再如商品的價格也會隨時間變化而調(diào)整上架的價格。因此在設(shè)計用戶、商品等維表時會考慮用緩慢變化維來開發(fā)。同樣，在設(shè)計ID-Mapping表時，由于一個用戶可以在多個設(shè)備上登錄，一個設(shè)備也能被多個用戶登錄，所以考慮用緩慢變化維表來記錄這種不同時間點的狀態(tài)變化（圖3-9）。圖3-9ID-Mapping拉鏈表拉鏈表是針對緩慢變化維表的一種設(shè)計方式，記錄一個事物從開始到當(dāng)前狀態(tài)的全部狀態(tài)變化信息。在上圖中，通過拉鏈表記錄了userid每一次關(guān)聯(lián)到不同cookieid的情況。如userid為44463729的用戶，在20190101這天登錄某設(shè)備，在6號那天變換了另一個設(shè)備登錄。其中start_date表示該記錄的開始日期，end_date表示該記錄的結(jié)束日期，當(dāng)end_date為99991231時，表示該條記錄當(dāng)前仍然有效。首先需要從埋點表和訪問日志表里面獲取到cookieid和userid同時出現(xiàn)的訪問記錄。下面案例中，ods.page_event_log是埋點日志表，ods.page_view_log是訪問日志表，將獲取到的userid和cookieid信息插入cookieid-userid關(guān)系表（ods.cookie_user_signin）中。代碼執(zhí)行如下：INSERTOVERWRITETABLEods.cookie_user_signinPARTITION(data_date='${data_date}')

SELECTt.*

FROM(

SELECTuserid,

cookieid,

from_unixtime(eventtime,'yyyyMMdd')assigndate

FROMods.page_event_log--埋點表

WHEREdata_date='${data_date}'

UNIONALL

SELECTuserid,

cookieid,

from_unixtime(viewtime,'yyyyMMdd')assigndate

FROMods.page_view_log--訪問日志表

WHEREdata_date='${data_date}'

)t

創(chuàng)建ID-Map的拉鏈表，將每天新增到ods.cookie_user_signin表中的數(shù)據(jù)與拉鏈表歷史數(shù)據(jù)做比較，如果有變化或新增數(shù)據(jù)則進行更新。CREATETABLE`dw.cookie_user_zippertable`(

`userid`stringCOMMENT'賬號ID',

`cookieid`stringCOMMENT'設(shè)備ID',

`start_date`stringCOMMENT'start_date',

`end_date`stringCOMMENT'end_date')

COMMENT'id-map拉鏈表'

ROWFORMATDELIMITEDFIELDSTERMINATEDBY'\t'

創(chuàng)建完成后，每天ETL調(diào)度將數(shù)據(jù)更新到ID-Mapping拉鏈表中，任務(wù)執(zhí)行如下。INSERTOVERWRITETABLEdw.cookie_user_zippertable

SELECTt.*

FROM(

SELECTt1.user_num,

t1.mobile,

t1.reg_date,

t1.start_date,

CASEWHENt1.end_date='99991231'ANDt2.useridISNOTNULLTHEN'${data_date}'

ELSEt1.end_date

ENDASend_date

FROMdw.cookie_user_zippertablet1

LEFTJOIN(SELECT*

FROMods.cookie_user_signin

WHEREdata_date='${data_date}'

)t2

ONt1.userid=t2.userid

UNION

SELECTuserid,

cookieid,

'${data_date}'ASstart_date,

'99991231'ASend_date

FROMods.cookie_user_signin

WHEREdata_date='${data_date}'

)t

數(shù)據(jù)寫入表中，如圖3-9所示。對于該拉鏈表，可查看某日（如20190801）的快照數(shù)據(jù)。select*

fromdw.cookie_user_zippertable

wherestart_date<='20190801'andend_date>='20190801'

例如，目前存在一個記錄userid和cookieid關(guān)聯(lián)關(guān)系的表，但是為多對多的記錄（即一個userid對應(yīng)多條cookieid記錄，以及一條cookieid對應(yīng)多條userid記錄）。這里可以通過拉鏈表的日期來查看某個時間點userid對應(yīng)的cookieid。查看某個用戶（如32101029）在某天（如20190801）關(guān)聯(lián)到的設(shè)備id（圖3-10）。selectcookieid

fromdw.cookie_user_zippertable

whereuserid='32101029'andstart_date<='20190801'andend_date>='20190801'

圖3-10某用戶在拉鏈表中記錄上圖可看出用戶‘32101029’在歷史中曾登錄過3個設(shè)備，通過限定時間段可找到特定時間下用戶的登錄設(shè)備。在開發(fā)中需要注意關(guān)于userid與cookieid的多對多關(guān)聯(lián)，如果不加條件限制就做關(guān)聯(lián)，很可能引起數(shù)據(jù)膨脹問題。在實際應(yīng)用中，會遇到許多需要將userid和cookieid做關(guān)聯(lián)的情況。例如，需要在userid維度開發(fā)出該用戶近30日的購買次數(shù)、購買金額、登錄時長、登錄天數(shù)等標(biāo)簽。前兩個標(biāo)簽可以很容易地從相應(yīng)的業(yè)務(wù)數(shù)據(jù)表中根據(jù)算法加工出來，而登錄時長、登錄天數(shù)的數(shù)據(jù)存儲在相關(guān)日志數(shù)據(jù)中，日志數(shù)據(jù)表記錄的userid與cookieid為多對多關(guān)系。因此在結(jié)合業(yè)務(wù)需求開發(fā)標(biāo)簽時，要確定好標(biāo)簽口徑定義。本節(jié)中通過案例介紹了將userid和cookieid打通的一種解決方案，實踐中還存在需要將用戶在不同平臺間（如Web端和App端）行為打通的應(yīng)用場景。3.2MySQL存儲MySQL作為關(guān)系型數(shù)據(jù)庫，在用戶畫像中可用于元數(shù)據(jù)管理、監(jiān)控預(yù)警數(shù)據(jù)、結(jié)果集存儲等應(yīng)用中。下面詳細介紹這3個應(yīng)用場景。3.2.1元數(shù)據(jù)管理Hive適合于大數(shù)據(jù)量的批處理作業(yè)，對于量級較小的數(shù)據(jù)，MySQL具有更快的讀寫速度。Web端產(chǎn)品讀寫MySQL數(shù)據(jù)庫會有更快的速度，方便標(biāo)簽的定義、管理。在7.2節(jié)和7.3節(jié)中，我們會介紹元數(shù)據(jù)錄入和查詢功能，將相應(yīng)的數(shù)據(jù)存儲在MySQL中。用戶標(biāo)簽的元數(shù)據(jù)表結(jié)構(gòu)設(shè)計會在7.3節(jié)進行詳細的介紹。這里給出了平臺標(biāo)簽視圖（如圖3-11所示）和元數(shù)據(jù)管理頁面（如圖3-12所示）。圖3-11平臺標(biāo)簽視圖圖3-12標(biāo)簽編輯管理平臺標(biāo)簽視圖中的標(biāo)簽元數(shù)據(jù)可以維護在MySQL關(guān)系數(shù)據(jù)庫中，便于標(biāo)簽的編輯、查詢和管理。3.2.2監(jiān)控預(yù)警數(shù)據(jù)MySQL還可用于存儲每天對ETL結(jié)果的監(jiān)控信息。從整個畫像調(diào)度流的關(guān)鍵節(jié)點來看，需要監(jiān)控的環(huán)節(jié)主要包括對每天標(biāo)簽的產(chǎn)出量、服務(wù)層數(shù)據(jù)同步情況的監(jiān)控等主要場景。圖3-13所示是用戶畫像調(diào)度流主要模塊，下面詳細介紹。圖3-13用戶畫像調(diào)度流主要模塊1.標(biāo)簽計算數(shù)據(jù)監(jiān)控主要用于監(jiān)控每天標(biāo)簽ETL的數(shù)據(jù)量是否出現(xiàn)異常，如果有異常情況則發(fā)出告警郵件，同時暫停后面的ETL任務(wù)。2.服務(wù)層同步數(shù)據(jù)監(jiān)控服務(wù)層一般采用HBase、Elasticsearch等作為數(shù)據(jù)庫存儲標(biāo)簽數(shù)據(jù)供線上調(diào)用，將標(biāo)簽相關(guān)數(shù)據(jù)從Hive數(shù)倉向服務(wù)層同步的過程中，有出現(xiàn)差錯的可能，因此需要記錄相關(guān)數(shù)據(jù)在Hive中的數(shù)量及同步到對應(yīng)服務(wù)層后的數(shù)量，如果數(shù)量不一致則觸發(fā)告警。在對畫像的數(shù)據(jù)監(jiān)控中，調(diào)度流每跑完相應(yīng)的模塊，就將該模塊的監(jiān)控數(shù)據(jù)插入MySQL中，當(dāng)校驗任務(wù)判斷達到觸發(fā)告警閾值時，發(fā)送告警郵件，同時中斷后續(xù)的調(diào)度任務(wù)。待開發(fā)人員解決問題后，可重啟后續(xù)調(diào)度。3.2.3結(jié)果集存儲結(jié)果集可以用來存儲多維透視分析用的標(biāo)簽、圈人服務(wù)用的用戶標(biāo)簽、當(dāng)日記錄各標(biāo)簽數(shù)量，用于校驗標(biāo)簽數(shù)據(jù)是否出現(xiàn)異常。有的線上業(yè)務(wù)系統(tǒng)使用MySQL、Oracle等關(guān)系型數(shù)據(jù)庫存儲數(shù)據(jù)，如短信系統(tǒng)、消息推送系統(tǒng)等。在打通畫像數(shù)據(jù)與線上業(yè)務(wù)系統(tǒng)時，需要考慮將存儲在Hive中的用戶標(biāo)簽相關(guān)數(shù)據(jù)同步到各業(yè)務(wù)系統(tǒng)，此時MySQL可用于存儲結(jié)果集。Sqoop是一個用來將Hadoop和關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)相互遷移的工具。它可以將一個關(guān)系型數(shù)據(jù)庫（如MySQL、Oracle、PostgreSQL等）中的數(shù)據(jù)導(dǎo)入Hadoop的HDFS中，也可以將HDFS中的數(shù)據(jù)導(dǎo)入關(guān)系型數(shù)據(jù)庫中。下面通過一個案例來講解如何使用Sqoop將Hive中的標(biāo)簽數(shù)據(jù)遷移到MySQL中。電商、保險、金融等公司的客服部門的日常工作內(nèi)容之一是對目標(biāo)用戶群（如已流失用戶、高價值用戶等）進行主動外呼，以此召回用戶來平臺進行購買或復(fù)購。這里可以借助用戶畫像系統(tǒng)實現(xiàn)該功能。將Hive中存儲的與用戶身份相關(guān)的數(shù)據(jù)同步到客服系統(tǒng)中，首先在Hive中建立一張記錄用戶身份相關(guān)信息的表（dw.userprofile_userservice_all）。設(shè)置日期分區(qū)以滿足按日期選取當(dāng)前人群的需要。CREATETABLE`dw.userprofile_userservice_all`(

`user_id`stringCOMMENT'userid',

`user_sex`stringCOMMENT'user_sex',

`city`stringCOMMENT'city',

`payid_money`stringCOMMENT'payid_money',

`payid_num`stringCOMMENT'payid_num',

`latest_product`stringCOMMENT'latest_product',

`date`stringCOMMENT'date',

`data_status`stringCOMMENT'data_status')

COMMENT'userid用戶客服數(shù)據(jù)'

PARTITIONEDBY(`data_date`stringCOMMENT'數(shù)據(jù)日期')

在MySQL中建立一張用于接收同步數(shù)據(jù)的表（userservice_data）。CREATETABLE`userservice_data`(

`user_id`varchar(128)DEFAULTNULLCOMMENT'用戶id',

`user_sex`varchar(128)NOTNULLCOMMENT'用戶性別',

`city`varchar(128)DEFAULTNULLCOMMENT'城市',

`payid_money`varchar(128)DEFAULTNULLCOMMENT'消費金額',

`payid_num`varchar(128)DEFAULTNULLCOMMENT'消費次數(shù)',

`latest_product`varchar(128)DEFAULTNULLCOMMENT'最近購買產(chǎn)品',

`date`varchar(64)NOTNULLCOMMENT'傳輸日期',

`data_status`varchar(64)DEFAULT'0'COMMENT'0:未傳輸,1:傳輸中,2:成功,3:失敗',

PRIMARYKEY(`user_id`),

)ENGINE=InnoDBAUTO_INCREMENT=2261628DEFAULTCHARSET=utf8COMMENT='用戶客服數(shù)據(jù)表';

通過Python腳本調(diào)用shell命令，將Hive中的數(shù)據(jù)同步到MySQL中。執(zhí)行如下腳本：#-*-coding:utf-8-*-

importos

importMySQLdb

importsys

defexport_data(hive_tab,data_date):

sqoop_command="sqoopexport--connectjdbc:mysql://10.xxx.xxx.xxx:3306/mysql_database--usernameusername--passwordpassword--tablemysql_table--export-dirhdfs://nameservice1/user/hive/warehouse

/dw.db/"+hive_tab+"/data_date="+data_date+"--input-fields-terminated-by'\001'"

os.system(sqoop_command)

print(sqoop_command)

if__name__=='__main__':

export_data("dw.userprofile_userservice_all",'20181201')

其中用到了sqoop從Hive導(dǎo)出數(shù)據(jù)到MySQL的命令：sqoopexport

--connect指定JDBC連接字符串,包括IP端口數(shù)據(jù)庫名稱\

--usernameJDBC連接的用戶名\

--passowrdJDBC連接的密碼\

--table表名\

--export-dir導(dǎo)出的Hive表,對應(yīng)的是HDFS地址\

--inputfileds-terminated-by‘,’分隔符號

同步后MySQL中的數(shù)據(jù)如圖3-14所示。圖3-14同步到MySQL中的數(shù)據(jù)3.3HBase存儲3.3.1HBase簡介HBase是一個高性能、列存儲、可伸縮、實時讀寫的分布式存儲系統(tǒng)，同樣運行在HDFS之上。與Hive不同的是，HBase能夠在數(shù)據(jù)庫上實時運行，而不是跑MapReduce任務(wù)，適合進行大數(shù)據(jù)的實時查詢。畫像系統(tǒng)中每天在Hive里跑出的結(jié)果集數(shù)據(jù)可同步到HBase數(shù)據(jù)庫，用于線上實時應(yīng)用的場景。下面介紹幾個基本概念：·rowkey：用來表示唯一一行記錄的主鍵，HBase的數(shù)據(jù)是按照rowkey的字典順序進行全局排列的。訪問HBase中的行只有3種方式：·通過單個rowkey訪問；·通過rowkey的正則訪問；·全表掃描。由于HBase通過rowkey對數(shù)據(jù)進行檢索，而rowkey由于長度限制的因素不能將很多查詢條件拼接在rowkey中，因此HBase無法像關(guān)系數(shù)據(jù)庫那樣根據(jù)多種條件對數(shù)據(jù)進行篩選。一般地，HBase需建立二級索引來滿足根據(jù)復(fù)雜條件查詢數(shù)據(jù)的需求。Rowkey設(shè)計時需要遵循三大原則：·唯一性原則：rowkey需要保證唯一性，不存在重復(fù)的情況。在畫像中一般使用用戶id作為rowkey?！らL度原則：rowkey的長度一般為10-100bytes。·散列原則：rowkey的散列分布有利于數(shù)據(jù)均衡分布在每個RegionServer，可實現(xiàn)負載均衡?！olumnsfamily：指列簇，HBase中的每個列都歸屬于某個列簇。列簇是表的schema的一部分，必須在使用表之前定義。劃分columnsfamily的原則如下：·是否具有相似的數(shù)據(jù)格式；·是否具有相似的訪問類型。常用的增刪改查命令如下。1）創(chuàng)建一個表，指定表名和列簇名：create'<tablename>','<columnfamily>'

2）掃描表中數(shù)據(jù)，并顯示其中的10條記錄：scan'<tablename>',{LIMIT=>10}

3）使用get命令讀取數(shù)據(jù)：get'<tablename>','row1'

4）插入數(shù)據(jù)：put'<tablename>','row1','<colfamily:colname>','<valu