魅族大資料之使用者洞察平臺

通過對三方受眾資料的匯聚、清洗、智慧運算，構建了龐大的精準人群資料中心，提供豐富的使用者畫像資料以及實時的場景識別力。 

無縫對接各類業務平臺的資料應用，如廣告平臺，PUSH推送，個性化推薦之間建立了資料通道，支援公司級的精準營銷，訊息及時送達服務等等。

營銷效果評估，反饋資料可進一步加工，用於提升畫像標籤質量。

使用者洞察的核心需求包含了以下幾個部分。

標籤生成：網際網路業務變化快，標籤需求變更頻繁。要求系統快速響應標籤需求。

人群洞察：對全量使用者任意標籤進行過濾以及聚合計算，查詢1-2秒內響應。

受眾分發：在無縫對接各類業務系統，實現高效實時的精確營銷。

標籤查詢：根據使用者ID查詢使用者畫像詳情,對於廣告業務的查詢需要在更苛刻的50ms內返回。

整合開發平臺之作業排程系統上，配置和執行離線計算任務。流平臺(AnyStream)負責實時標籤計算。管理模組生成的相關規則，儲存在MySQL，供標籤生成任務(Hive/MR/流平臺）使用。使用者畫像（標籤）寬表儲存在ES上。Hbase和Redis提供kv查詢。使用開發平臺（OpenAPI）提供對外介面。

根據生成計算的過程，標籤分為兩類，其中一類是統計類標籤。首先從使用者的行為裡統計出指標，然後根據標籤生成規則和統計指標作為輸入，就可以對應到哪個使用者屬於什麼消費等級。

標籤除了統計類的之外還有一種演算法類的。

選取高置信度資料（如使用者註冊資訊）和使用者行為資料作輸入進行模型訓練。然後使用訓練好的模型進行屬性預測。

單值標籤是指使用者在該標籤下只能取一個值，不能多選。

多值標籤是使用者可以取該標籤下的多個取值組合。比如使用者可以有多個興趣愛好。 多值標籤的存在，會影響儲存查詢引擎的選型和儲存結構設計。

這種模式的優點是配置化管理，提供 Web UI 管理標籤的生命週期；基於配置生成標籤，標籤寬表資料與後設資料100%一致。

尚存的不足是目前配置化管理只涵蓋到最終的標籤寬表生成。與上游的指標統計和演算法預有脫節。上游計算過程是單獨開發，指標定義只是另外配置的資料描述（可能存在不一致）。一些標籤下線（廢除）後，相應的上游任務的依賴需要另外廢除，否則會遺留無用的作業浪費計算資源。

ElasticSearch（ES）是一個基於Lucene構建的開源、分散式、RESTful搜尋引擎。能夠達到實時搜尋，穩定，可靠，快速。基於 ES 實現對全量使用者任意標籤進行線上篩選和聚合分析，秒及響應。Hbase 提供大吞吐量的 key/value 查詢。效能要求更為苛刻的 key/value 查詢（廣告平臺）通過使用 Redid 來實現。

傳統的Vertica社群版有3個節點和1T儲存容量限制。隨著資料規模和呼叫數暴增，效能出現瓶頸對於多值標籤，只能採用csv方式儲存在varchar欄位，效能低下。

多值標籤檢索使用字串 LIKE 操作；聚合雖能通過一些 trick 來支援，但效能太差。

而現在ES能夠達到實時搜尋，穩定，可靠，快速。線上更新（實時/準實時更新）水平擴充套件能力強。Array type完美支援多值標籤儲存和分析場景。

Hbase提供低成本，高吞吐量的 kv 查詢。滿足一般業務的查詢，缺點是查詢響應時間不太理想（針對廣告業務而言）。

而對於Redis，廣告業務提出 50ms 內的查詢延遲，這種苛刻要求需用 Redis 實現。 Redis儲存目前只服務於廣告平臺的查詢呼叫。

考慮成本因素，主要使用 Hbase 來提供KV查詢。部分要求苛刻的業務，使用 Redis 作為補充。

平臺的主要功能有五種，人群管理、人群篩選、畫像洞察、受眾分發和畫像查詢。

人群管理可通過兩種方式建立。1、指定標籤條件；2、匯入imei列表，對人群進行修改、刪除等操作。

人群篩選是指定標籤條件選項，查詢滿足條件的使用者數。

畫像洞察分為兩步。首先指定標籤條件選項選出使用者群體，然後再指定要分析的標籤，通過聚合運算，分析使用者特徵。

受眾分發需要採取一定的技術手段，把指定人群推至下游的營銷渠道（廣告平臺、推送平臺、OTA等）。

畫像查詢則是對下游系統提供查詢介面，呼叫方指定使用者標識（imei）查詢該使用者的畫像標籤。

今天的分享就到這裡，謝謝大家