目錄
0. 相關文章鏈接
1. Elasticsearch簡介
2. 應用場景
3. 工程化案例
4. 用戶畫像標簽資料存盤總結
注：此博文為根據 趙宏田 老師的 用戶畫像·方法論與工程化解決方案 一書讀后筆記而來，僅供學習使用
0. 相關文章鏈接
用戶畫像文章匯總
1. Elasticsearch簡介
Elasticsearch是一個開源的分布式全文檢索引擎，可以近乎實時地存盤、檢索資料，而且可擴展性很好，可以擴展到上百臺服務器， 處理PB級別的資料，對于用戶標簽查詢、用戶人群計算、用戶群多維 透視分析這類對叩應時間要求較高的場景，也可以考慮選用 Elasticsearch進行存盤，
Elasticsearch是面向檔案型資料庫，一條資料在這里就是一個文 檔，用json作為檔案格式，為了更清晰地理解Elasticsearch查詢的一 些概念，將其和關系資料庫的型別進行對照，如下圖所示，
在關系型資料庫中查詢資料時可通過選中資料庫、表、行、列來 定位所查找的內容，在Elasticsearch中通過索引（index）、型別 （type）、檔案（document）、欄位來定位查找內容，一個Elasticsearch集群可以包括多個索引（資料庫），也就是說，其中包 含了很多型別（表），這些型別中包含了很多的檔案（行），然后每 個檔案中又包含了很多的欄位（列）.Elasticsearch的互動可以使用 Java API,也可以使用HTTP的RESTful API方式，
2. 應用場景
基于HBase的存盤方案并沒有解決資料的高效檢索問題，在實際應用中，經常有根據特定的幾個欄位進行組合后檢索的應用場景，而 HBase采用rowkey作為一級索引，不支持多條件查詢，如果要對庫里的 非rowkey進行資料檢索和查詢，往往需要通過MapReduce等分布式框架 進行計算，時間延遲上會比較高，難以同時滿足用戶對于復雜條件查 詢和高效率回應這兩方面的需求，
為了既能支持對資料的高效查詢，同時也能支持通過條件篩選進 行復雜查詢，需要在HBase上構建二級索引，以滿足對應的需要，我們可以采用Elasticsearch存盤HBase的索引資訊，以支持復雜高效的查詢功能，
主要查詢程序包括：
1）在Elasticsearch中存放用于檢索條件的資料，并將rowkey也 存盤進去；
2）使用Elasticsearch的API根據組合標簽的條件查詢出rowkey的 集合；
3）使用上一步得到的rowkey去HBase資料庫查詢對應的結果（如下圖）；
HBase資料存盤資料的索引放在Elasticsearch中，實作了資料和 索引的分離，在Elasticsearch中documentid是檔案的唯一標識，在 HBase中rowkey是記出的唯一標識，在工程實踐中，兩者可同時選用用 戶在平臺上的唯一標識（如userid或deviceid）作為rowkey或 documentid,進而解決HBase和Elasticsearch索引關聯的問題，
下面通過使用Elasticsearch解決用戶人群計算和分析應用場景的 案例來了解這一程序，
對匯聚后的用戶標簽表 dw.userprofile_userlabel_map_all中的資料進行清洗， 過濾掉一些無效字符，達到匯入Elasticsearch的條件，如下圖所示，
然后將dw.userprofile_userlabel_map_all資料寫入 Elasticsearch中，之后需要資料就可以直接從Elasticsearch中獲取資料了，對比使用Impala從Hive中進行計算，效果可以從原先的幾十秒到幾分鐘優化到現在的秒級回應，
3. 工程化案例
下面通過一個工程案例來講解實作畫像產品中“用戶人 群”和“人群分析”功能對用戶群計算秒級回應的一種解決方案，
在每天的ETL調度中，需要將Hive計算的標簽資料匯入 Elasticsearch中，如圖3-28所示，在標簽調度完成且通過校驗后（如下圖中的“標簽監控預警”任務執行完成后），將標簽資料同步到 Elasticsearch中，
在與Elasticsearch資料同步完成并通過校驗后，向在MySQL中維 護的狀態表中插入一條狀態記錄，表示當前日期的Elasticsearch資料 可用，線上計算用戶人群的介面則讀取最近日期對應的資料，如果某 天因為調度延遲等方面的原因，沒有及時將當日資料匯入 Elasticsearch中，介面也能讀取最近一天對應的資料，是一種可行的災備方案，
例如，資料同步完成后向MySQL狀態表“elasticsearch_state”中插入記錄（如下圖所示），當日資料產出正常時，state欄位為“0”，產出例外時為“1”，圖3-29中1月 20榷訓入的資料出現例外，則“state”狀態欄位置1,線上介面掃描 該狀態記錄位后不讀取1月20日資料，而是取用最近的1月19日資料，
為了避免從Hive向Elasticsearch中灌入資料時發生資料缺失，在向狀態表更新狀態位前需要校驗Elasticsearch和Hive中的資料量是否 一致，還需要通過其他腳本來看資料校驗邏輯：
如上所示就是在工程化調度流中何時將Hive中的用戶標簽資料灌入 Elasticsearch中，之后業務人員在畫像產品端計算人群或透視分析人群時（如下圖1所示），通過RESTful API訪問Elasticsearch進行計算（如下圖2所示），
4. 用戶畫像標簽資料存盤總結
在前面的幾篇博文中講解了使用Hive、MySQL、HBase和Elasticsearch存盤標簽數 據的解決方案，包括：Hive存盤資料相關標簽表、人群計算表的表結 構設計以及ID-Mapping的一種實作方式；MySQL存盤標簽元資料、監控 資料及結果集資料；HBase存盤線上介面實時呼叫的資料； Elasticsearch存盤標簽用于人群計算和人群多維透視分析，存盤程序 中涉及如下相關表，
- dw.userprofile_attritube_all：存盤人口屬性維度的標簽 表；
- dw.userprofile_action_all：存盤行為屬性維度的標簽表；
- dw.userprofile_consume_all：存盤用戶消費維度的標簽表；
- dw.userprofile_riskmanage_all：存盤風險控制維度的標簽 表；
- dw.userprofile_social_all：存盤社交屬性維度的標簽表；
- dw.userprofile_userlabel_map_all：匯聚用戶各維度標簽的 表；
- dw.userprofile_usergroup_labels_all：存盤計算后人群資料 的表，
面向不同的工程場景使用不同的存盤方案，本章通過“工程場景 +案例”的形式介紹了一種可實作的用戶標簽存盤解決方案，
注：再次宣告，此博文為根據 趙宏田 老師的 用戶畫像·方法論與工程化解決方案 一書讀后筆記而來，僅供學習使用
注：其他相關文章鏈接由此進 -> 用戶畫像文章匯總
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/420016.html
標籤：其他