這裡講解下使用者畫像的技術架構和整體實現，那麼就從資料整理、資料平台、面向應用三個方面來討論乙個架構的實現(個人見解)。
資料整理：
1、資料指標的的梳理**於各個系統日常積累的日誌記錄系統，通過sqoop匯入hdfs,也可以用**來實現，比如spark的jdbc連線傳統資料庫進行資料的cache。還有一種方式，可以通過將資料寫入本地檔案，然後通過sparksql的load或者hive的export等方式匯入 hdfs。
2、通過hive編寫udf 或者hiveql 根據業務邏輯拼接etl，使使用者對應上不同的使用者標籤資料(這裡的指標可以理解為為每個使用者打上了相應的標籤)，生成相應的源表資料,以便於後續使用者畫像系統，通過不同的規則進行標籤寬表的生成。
資料平台
1、資料平台應用的分布式檔案系統為hadoop的hdfs，因為hadoop2.0以後,任何的大資料應用都可以通過 resouremanager申請資源，註冊服務。比如(sparksubmit、hive)等等。而基於記憶體的計算框架的出現，就並不選用hadoop 的mapreduce了。當然很多離線處理的業務，很多人還是傾向於使用hadoop,但是hadoop的封裝的函式只有map和reduce太過單一，而不像spark一類的計算框架有更多封裝的函式(可參考部落格spark專欄)。可以大大提公升開發效率。
2、計算的框架選用spark以及rhadoop,這裡spark的主要用途有兩種，一種是對於資料處理與上層應用所指定的規則的資料篩選過濾， (通過scala編寫spark**提交至sparksubmit)。一種是服務於上層應用的sparksql(通過啟動spark thriftserver與前台應用進行連線)。 rhadoop的應用主要在於對於標籤資料的打分，比如利用協同過濾演算法等各種推薦演算法對資料進行各方面評分。
3、mongodb記憶體資料的應用主要在於對於單個使用者的實時的查詢，也是通過對spark資料梳理後的標籤寬表進行資料格式轉換(json格式)匯入mongodb,前台應用可通過連線mongodb進行資料轉換，從而進行單個標籤的展現。(當然也可將資料轉換為redis中的key value形式，匯入redis集群)
4、mysql的作用在於針對上層應用標籤規則的儲存，以及頁面資訊的展現。後台的資料寬表是與spark相關聯，通過連線mysql隨後 cache元資料進行filter,select,map,reduce等對元資料資訊的整理,再與真實存在於hdfs的資料進行處理。
面向應用
從剛才的資料整理、資料平台的計算，都已經將服務於上層應用的標籤大寬表生成。(使用者所對應的各類標籤資訊)。那麼前台根據業務邏輯，勾選不同的標籤進行求和、剔除等操作，比如本月流量大於200m使用者(標籤)+本月消費超過100元使用者(標籤)進行和的操作，通過前台**實現sql的拼接，進行客戶數目的探索。這裡就是通過jdbc的方式連線spark的thriftserver，通過集群進行hdfs上的大寬表的運算求count。(這裡要注意一點，很多sql聚合函式以及多表關聯join 相當於hadoop的mapreduce的shuffle,很容易造成記憶體溢位，相關引數調整可參考本部落格spark欄目中的配置資訊) 這樣便可以定位相應的客戶數量，從而進行客戶群、標籤的分析，產品的策略匹配從而精準營銷。
使用者畫像的技術選型與架構實現
這裡講解下使用者畫像的技術架構和整體實現，那麼就從資料整理 資料平台 面向應用三個方面來討論乙個架構的實現 個人見解 資料整理 1 資料指標的的梳理 於各個系統日常積累的日誌記錄系統，通過sqoop匯入hdfs,也可以用 來實現，比如spark的jdbc連線傳統資料庫進行資料的cache。還有一種方...
推薦系統眼中的你 使用者畫像
我們已經進入到網際網路的下半場，增長的動力來自資料驅動。而資料分析的出發點，來自於對使用者行為及需求的洞察。如何將使用者標籤化以便推薦系統能夠推薦合適的內容給使用者是使用者畫像的重點。使用者畫像的準則 我們需要解決三個問題 step1 統一標識 使用者唯一標識是整個使用者畫像的核心 step2 給使...
TableStore 使用者畫像資料的儲存和查詢利器
使用者畫像資料是一種資料規模較大 資料結構複雜 查詢種類多的資料，是公司差異化運營的基礎，是打造 千人千面 智慧型化的核心資料，幫產品找到最佳目標客戶，對各種產品而言是一種很有價值的資料。我們接下來先看一下使用者畫像資料的場景和特徵，僅以儲存和查詢的角度看一下使用者畫像資料的儲存選擇。使用者畫像的資...