1.1數(shù)據(jù)應(yīng)用體系層級劃分：
1.2標(biāo)簽類型：
分為統(tǒng)計類標(biāo)簽呢灶、規(guī)則類標(biāo)簽那伐、機器學(xué)習(xí)挖掘類標(biāo)簽、自定義類型標(biāo)簽叮叹；
統(tǒng)計類標(biāo)簽：用戶的近7日活躍時長可以從用戶注冊數(shù)據(jù)、用戶訪問爆存、消費數(shù)據(jù)中統(tǒng)計得出衬横，該類型的標(biāo)簽構(gòu)成了用戶畫像的基礎(chǔ)；
規(guī)則類標(biāo)簽：在實際開發(fā)畫像的過程中终蒂，由于運營人員對業(yè)務(wù)更為熟悉，而數(shù)據(jù)人員對數(shù)據(jù)的結(jié)構(gòu)遥诉、分布拇泣；特征更為熟悉，因此規(guī)則類標(biāo)簽的規(guī)則由運營人員以及數(shù)據(jù)人員共同協(xié)商而定矮锈。如經(jīng)過某個業(yè)務(wù)數(shù)據(jù)流轉(zhuǎn)霉翔，可以獲得得到一個標(biāo)簽；
機器學(xué)習(xí)挖掘類標(biāo)簽：通過機器學(xué)習(xí)挖掘產(chǎn)生苞笨，用于對用戶的某些屬性或某些行為進行預(yù)測判斷债朵，該類標(biāo)簽需要通過算法挖掘產(chǎn)生。
總結(jié)：統(tǒng)計類規(guī)則類標(biāo)簽用的比較常見瀑凝，占系統(tǒng)開發(fā)的大多數(shù)，機器學(xué)習(xí)挖掘用的比較少。
1.3數(shù)據(jù)架構(gòu)
用戶畫像是不是產(chǎn)生數(shù)據(jù)的源頭曹动，而是對于基于數(shù)據(jù)倉庫DW沐寺、ODS、DM層中與用戶相關(guān)數(shù)據(jù)的二次建模加工，在ETL過程中將用戶標(biāo)簽計算結(jié)果寫入Hive宪塔，由于不同數(shù)據(jù)庫有不同的應(yīng)用場景磁奖，后續(xù)需要進一步到將數(shù)據(jù)同步到MySQL、HBASE某筐、Elasticsearch中比搭；
解釋：
（1）ETL是英文Extract-Transform-Load 的縮寫，用來描述將數(shù)據(jù)從來源端經(jīng)過抽饶咸堋（extract）身诺、轉(zhuǎn)換（transform）、加載（load）至目的端的過程弟疆。
（2）ODS：操作性數(shù)據(jù)
（3）DW：數(shù)據(jù)倉庫
（4）DM：數(shù)據(jù)集市
（5） MySQL：一個關(guān)系型數(shù)據(jù)庫管理系統(tǒng)戚长，存儲元數(shù)據(jù)標(biāo)簽、監(jiān)控相關(guān)數(shù)據(jù)怠苔，導(dǎo)出到業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同廉；
（6）Elasticsearch：一個分布式、高擴展柑司、高實時的搜索與數(shù)據(jù)分析引擎迫肖，支持海量數(shù)據(jù)的實時查詢分析，用于存儲用戶人群計算攒驰、用戶群透視分析所需的用戶標(biāo)簽數(shù)據(jù)（由于用戶人群計算蟆湖、用戶群透視分析的條件轉(zhuǎn)化成的SQL語句多條件嵌套較為復(fù)雜，使用Impala執(zhí)行也需要花大量時間）
（7）HBase：一個分布式的玻粪、面向列的開源數(shù)據(jù)庫隅津，存儲線上接口實時調(diào)用類數(shù)據(jù)
（8）FTP：文件傳輸
（9）Hive：存儲用戶標(biāo)簽計算結(jié)果、用戶人群計算結(jié)果劲室、用戶特征庫計算結(jié)果伦仍；
1.4主要覆蓋模塊：
1.5開發(fā)流程：
（1）目標(biāo)解讀：
在建立用戶畫像前，首先需要明確用戶畫像服務(wù)于企業(yè)的對象很洋，再根據(jù)業(yè)務(wù)方需求充蓝，明確未來產(chǎn)品建設(shè)目標(biāo)和用戶畫像分析之后的預(yù)期效果；
（2）任務(wù)分解與需求調(diào)研
當(dāng)已經(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)系，明確分析維度协怒。
（3）需求場景討論與明確
數(shù)據(jù)運營人員需要根據(jù)與需求方的溝通結(jié)果涝焙，輸出產(chǎn)品用戶畫像需求文檔，在該文檔中明確畫像應(yīng)用場景孕暇、最終開發(fā)出的標(biāo)簽內(nèi)容與應(yīng)用方式纱皆，溝通確認湾趾。
（4）應(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ù)口徑近迁，需要產(chǎn)出產(chǎn)品用戶畫像開發(fā)文檔艺普，并且文檔中需要明確應(yīng)用場景，標(biāo)簽開發(fā)的模型鉴竭，涉及的數(shù)據(jù)庫與表以及應(yīng)用實施流程歧譬。
（5）特征選取與模型數(shù)據(jù)落表
將已經(jīng)明確的需求場景進行業(yè)務(wù)建模，寫好HQL邏輯搏存，將相應(yīng)的模型邏輯寫入臨時表中瑰步，并抽取數(shù)據(jù)校驗是否符合業(yè)務(wù)場景需求
（6）線下模型數(shù)據(jù)驗收與測試
數(shù)據(jù)倉庫團隊的人員將相關(guān)數(shù)據(jù)落表后，設(shè)置定時調(diào)度任務(wù)璧眠，定期增量更新數(shù)據(jù)缩焦。數(shù)據(jù)運營人員需求驗收數(shù)據(jù)倉庫加工的HQL邏輯是否符合預(yù)期，根據(jù)業(yè)務(wù)需求抽取表中數(shù)據(jù)查看是否在合理范圍內(nèi)责静，如果發(fā)現(xiàn)問題要及時反饋給數(shù)據(jù)倉庫人員調(diào)整代碼邏輯和行為權(quán)重的數(shù)值
（7）線上模型發(fā)布與效果追蹤
通過持續(xù)追蹤標(biāo)簽應(yīng)用效果及業(yè)務(wù)方反饋袁滥，調(diào)整優(yōu)化模型及相關(guān)權(quán)重配置。
1.6畫像體系開發(fā)主要階段
（1）標(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ā)在整個畫像項目周期中占有較大比重嵌赠；
（2）ETL調(diào)度：熟路需要調(diào)度的個任務(wù)之間的依賴關(guān)系，開發(fā)調(diào)度腳本及調(diào)度監(jiān)控告警腳本熄赡，上線調(diào)度系統(tǒng)猾普；
（3）打通服務(wù)層接口：為了讓畫像數(shù)據(jù)走出數(shù)據(jù)倉庫，應(yīng)用到用戶身上本谜，需要打通數(shù)據(jù)倉庫和各業(yè)務(wù)系統(tǒng)的接口；
（4）畫像產(chǎn)品化：需要產(chǎn)品經(jīng)理與業(yè)務(wù)人員偎窘、技術(shù)開發(fā)人員一起對接業(yè)務(wù)需求點和產(chǎn)品功能實現(xiàn)形式乌助，話產(chǎn)品原型，確定工作排期陌知，JAVA WEB端開發(fā)完成后他托，需要數(shù)據(jù)開發(fā)人員 面向?qū)?yīng)的庫表中灌入數(shù)據(jù)
（5）開發(fā)的優(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)化纫溃；
（6）面向業(yè)務(wù)方推廣應(yīng)用：用戶畫像最終的價值產(chǎn)出點是業(yè)務(wù)方應(yīng)用畫像數(shù)據(jù)進行用戶分析，多渠道觸達運營用戶韧掩，分析ROI紊浩，提升用戶活躍度或營收。面向用戶提供使用文檔疗锐。
