用戶畫像項目筆記3

用戶畫像標籤的設計

需求簡單明瞭: 用戶標籤的數量多少(以權重來表示) 
爲方便管理 不同的標籤分類(以模塊來表示)
字段 gid, 模塊名,標籤名,標籤值,權重

主題分類

人口屬性模塊、註冊信息、終端設備、消費訂單屬性、消費商品退拒屬性、生命週期、活躍屬性、事件行爲屬性、商品偏好屬性、價值屬性、DSP屬性、APP屬性、興趣類關鍵字、活躍地域標籤

• 主題和標籤由字典表構成

商城系統行爲日誌數據

用戶終端屬性、訪問行爲屬性、活躍屬性、偏好屬性

商城系統業務數據

消費訂單類屬性、消費商品類、價值屬性、註冊信息

DSP系統競價日誌數據

廣告欄位名稱、廣告平臺商、興趣關鍵詞標籤、終端屬性、App屬性

移動運營商流量日誌

終端屬性、購物類興趣關鍵字、App屬性

標籤的抽取

每個值都是一個標籤
不同日誌抽取的標籤合併用union合併標籤

功能：將當日的標籤計算結果，整合歷史（前一日）標籤結果

要考慮的點：
1. 當日可能有新的人
2. 歷史記錄中的人，當日可能沒出現
3. 歷史記錄中的人，當日有新標籤
4. 歷史記錄中的人，當日出現出現過的標籤
5. 歷史記錄中的人，有標籤當日沒有出現
總結出來就是：
-- 對有權重的數據
歷史標籤  full join  當日標籤
2. 歷史有，當日有，權重累加
3. 歷史有，當日無，權重衰減  (應該有衰減係數字典)
4. 歷史無，當日有，取當日
-- 對無權重的數據
無權重標籤，都是數倉報表中出來的，而數倉報表的數據，每天抽過來其實都是歷史以來積累到當日的全量結果！
直接取當日數據！

----知識庫構建------------
1. 地理位置字典構建
	-- geohash
	-- 高德地圖開發api使用
	
2. app信息知識庫構建
3. url內容知識庫構建
	-- java爬蟲
	-- css選擇器
	-- jsoup  selenium  chromedriver
	-- 反爬：檢查useragent/檢查一個ip上的請求量/重要數據用ajax異步請求/登錄攔截
	-- 應對反爬-- useragent設置/切換代理服務器/控制爬取速度/selenium即所得/設置cookie
	
4. idmp字典構建
	-- 圖計算（爲了不借助外部存儲直接找出id之間的關聯關係）
	-- 最大連通子圖
	-- 注意點：過濾弱關聯
	
-----數據預處理--------
1. 商城系統用戶行爲日誌
2. dsp競價日誌
3. cmcc流量日誌
	清洗、過濾  -- 髒數據的處理（filter，字段數不夠，某些字段爲空的，數據解析失敗的）
	解析  -- （切字段、json解析）
	集成  -- （根據日誌中的一個字段，去外部匹配更多的信息，追加到結果中： skuid->sku信息）
	格式轉換  -- （最終結果統一成parquet格式）

-----事實標籤提取--------
******《標籤主題體系》******
1. 商城系統用戶行爲日誌
2. dsp競價日誌
3. cmcc流量日誌
4. 用戶訂單統計報表
5. 用戶商品統計報表
6. 用戶註冊信息（註冊手機、註冊賬號、註冊性別、註冊年齡、註冊時間、註冊方式（app上註冊、pc上註冊、微信小程序註冊）、註冊渠道（自發、百度搜索、x廣告推廣來的、x活動推廣來的））

提取的標籤有哪些？
*人口屬性信息
*註冊信息
*終端屬性信息
*商品偏好信息
	- 品類偏好
	- 品牌偏好
	- 價格偏好 :  30天內的商品消費價格區間偏好: 2   -9999.9
	    rangeid,rangename
	 	1,       0-50
	 	2,       50-100
	 	3,       100-200
	 	4,       200-400
	 	5,       400-600
	 	6,       600-800
	 	7,       800-1000
    - 顏色等商品屬性偏好：
	- 商品相關關鍵字偏好：瀑布屏:89   黑科技：10   

*活躍屬性	
	- 第一次訪問時間
	- 最近一次訪問時間
	- 30天內總訪問次數
	- 30天內總訪問時長
	- 30天內總訪問深度
	- 7天內
	- .....
	- 30天內的平均訪問間隔
	- ......
	- 30天內收藏總次數
	- 30天內點贊總次數
	- 30天內好評總次數
	- 30天內差評總次數
	- 30天內分享總次數
	
*消費屬性
	- 首單時間
	- 末單時間
	- 累計消費總額
	- 累計客單價
	- 累計消費筆數
	- 最大單筆消費額
	- 最小單筆消費額
	- 30天內消費總額
	- 30天內客單價
	- 30天內消費筆數
	- 30天內單筆消費額
	- 30天內單筆消費額
	- 14天內消費總額
	- 14天內客單價
	- 14天內消費筆數
	- 14天內單筆消費額
	- 14天內單筆消費額
	- 7天內消費總額
	- 7天內客單價
	- 7天內消費筆數
	- 7天內單筆消費額
	- 7天內單筆消費額
	- .........
	- 0-2點下單次數
	- 2-4點下單次數
	- 4-6點下單次數
	- 6-8點下單次數
	- 8-10點下單次數
	- .....
	

*興趣關鍵詞	（主要來自於dsp日誌和cmcc日誌）
	- 新聞類
	- 體育類
	- 娛樂類
	- 影視類

*DSP廣告業務標籤
	廣告欄位
	廣告平臺
	.....
	
******《標籤統一計算模型》******
一條數據，n個字段對畫像有意義，每個字段變成一個標籤，然後橫表變豎表，就可以用統一的計算方式來計算（wordcount）
標籤 ==》   模塊名(id)：標籤名(id)：標籤值：權重



-----事實標籤當日聚合--------
有權重：對相同人的相同標籤，分組累加聚合
無權重：


-----事實標籤T-1日和T日聚合--------
有權重： 跟T-1日的full join，該累加累加，該衰減衰減（引用外部的係數字典表及衰減算法，不同標籤有不同衰減速度）
無權重： 跟T-1日的full join，有新的就用新的，沒有新的保留舊的


-----模型（挖掘）標籤 --------
-- 價值指數
-- 流失率
-- 退拒風險
-- 黃牛預測

/*****************************************標籤明細層******相當於數倉的DWD層*******************************************/




-----畫像數據的運營系統（精準營銷、精細化運營的分析平臺、駕駛艙）---------相當於數倉的DWS和ADS層-------



-----數據入庫 -----------------------------
畫像標籤明細數據入庫 -- hbase  （bulkloader導入）
各類畫像運營分析報表的入庫 -- 寫入mysql  

畫像結果入庫

可能需要根據一個用戶的某個標識，查詢到這個人的整條或者某些標籤數據！

而且，數據量比較龐大（畫像數據中人數千萬級、億級）
（假如公司有用戶1千萬,標籤有： 1000 w * 15模塊 *10標籤 * 3個值 = 45億個標籤）

那麼，我們可以選擇什麼樣的數據庫來支撐這些需求呢？
mysql是否可以？ 數據量小一點可以（百萬級別-千萬級別），數據量大不合適
	優點：查詢功能特別強大，速度快，可以寫各種複雜sql查詢
	缺點：數量規模不能太大，而且不便於動態增長！不太適合半結構化數據！（明細標籤數據是一個稀疏表）

hbase是否可以？ 可以！
	優點：數據規模可以很龐大，而且支持動態增長！非常適合存儲稀疏表！
	缺點：支持的查詢功能簡單！對複雜查詢的支持非常弱！
缺點的改善方案：
創建二級索引！
或者使用phoenix（可以支持創建二級索引，可以支持複雜sql查詢，而且查詢性能在hbase原生api基礎上還有提升！）
	
elastic search(不是數據庫，全文檢索引擎)是否可以？ 可以！
	優點：  數據規模可以比較大（億級別，10億就需要深入優化）！
條件查詢很方便（全文索引）！
聚合統計查詢也能支持！（相比hive、mysql來說，還是很弱的）
	缺點： 對複雜查詢分析的支持不夠強！