​

​ 在《什麼的是用戶畫像》一文中，我們已經知道用戶畫像對於企業的巨大意義，當然也有著非常大實時難度。那麼在用戶畫像的系統架構中都有哪些難度和重點要考慮的問題呢？

挑戰

• 大數據

  隨著互聯網的崛起和智能手機的興起，以及物聯網帶來的各種可穿戴設備，我們能獲取的每一個用戶的數據量是非常巨大的，而用戶量本身更是巨大的，我們面臨的是TB級，PB級的數據，所以我們必須要一套可以支撐大數據量的高可用性，高擴展性的系統架構來支撐用戶畫像分析的實現。毫無疑問，大數據時代的到來讓這一切都成為可能，近年來，以Hadoop為代表的大數據技術如雨後春筍般迅速發展，每隔一段時間都會有一項新的技術誕生，不斷驅動的業務向前，這讓我們對於用戶畫像的簡單統計，複雜分析，機器學習都成為可能。所以整體用戶畫像體系必須建立在大數據架構之上。

​

• 實時性

  在Hadoop崛起初期，大部分的計算都是通過批處理完成的，也就是T+1的處理模式，要等一天才能知道前一天的結果。但是在用戶畫像領域，我們越來越需要實時性的考慮，我們需要在第一時間就得到各種維度的結果，在實時計算的初期只有Storm一家獨大，而Storm對於時間視窗，水印，觸發器都沒有很好的支持，而且保證數據一致性時將付出非常大的性能代價。但Kafka和Flink等實時流式計算框架的出現改變了這一切，數據的一致性，事件時間視窗，水印，觸發器都成為很容易的實現。而實時的OLAP框架Druid更是讓互動式實時查詢成為可能。這這些高性能的實時框架成為支撐我們建立實時用戶畫像的最有力支持。

• 數據倉庫

  數據倉庫的概念由來已久，在我們得到海量的數據以後，如何將數據變成我們想要的樣子，這都需要ETL，也就是對數據進行抽取（extract）、轉換（transform）、載入（load）的過程，將數據轉換成想要的樣子儲存在目標端。毫無疑問，Hive是作為離線數倉的不二選擇，而hive使用的新引擎tez也有著非常好的查詢性能，而最近新版本的Flink也支持了hive性能非常不錯。但是在實時用戶畫像架構中，Hive是作為一個按天的歸檔倉庫的存在，作為歷史數據形成的最終存儲所在，也提供了歷史數據查詢的能力。而Druid作為性能良好的實時數倉，將共同提供數據倉庫的查詢與分析支撐，Druid與Flink配合共同提供實時的處理結果，實時計算不再是只作為實時數據接入的部分，而真正的挑起大梁。

  所以，兩者的區別僅在於數據的處理過程，實時流式處理是對一個個流的反覆處理，形成一個又一個流表，而數倉的其他概念基本一致。

  數倉的基本概念如下：

  • DB 是現有的數據來源(也稱各個系統的元數據)，可以為mysql、SQLserver、文件日誌等，為數據倉庫提供數據來源的一般存在於現有的業務系統之中。

  • ETL的是 Extract-Transform-Load 的縮寫，用來描述將數據從來源遷移到目標的幾個過程：

    • Extract，數據抽取，也就是把數據從數據源讀出來。
    • Transform，數據轉換，把原始數據轉換成期望的格式和維度。如果用在數據倉庫的場景下，Transform也包含數據清洗，清洗掉噪音數據。
    • Load 數據載入，把處理後的數據載入到目標處，比如數據倉庫。

  • ODS(Operational Data Store) 操作性數據，是作為資料庫到數據倉庫的一種過渡，ODS的數據結構一般與數據來源保持一致，便於減少ETL的工作複雜性，而且ODS的數據周期一般比較短。ODS的數據最終流入DW

  • DW (Data Warehouse)數據倉庫，是數據的歸宿，這裡保持這所有的從ODS到來的數據，並長期保存，而且這些數據不會被修改。

  • DM(Data Mart) 數據集市,為了特定的應用目的或應用範圍，而從數據倉庫中獨立出來的一部分數據，也可稱為部門數據或主題數據。面嚮應用。

    

    當然最終提供的服務不僅僅是可視化的展示，還有實時數據的提供，最終形成用戶畫像的實時服務，形成產品化。

    在整個數據的處理過程中我們還需要自動化的調度任務，免去我們重覆的工作，實現系統的自動化運行，Airflow就是一款非常不錯的調度工具，相比於老牌的Azkaban 和 Oozie，基於Python的工作流DAG，確保它可以很容易地進行維護，版本化和測試。

    至此我們所面臨的問題都有了非常好的解決方案，下麵我們設計出我們系統的整體架構，並分析我們需要掌握的技術與所需要的做的主要工作。

系統架構

​ 依據上面的分析與我們要實現的功能，我們將依賴Hive和Druid建立我們的數據倉庫，使用Kafka進行數據的接入，使用Flink作為我們的流處理引擎，對於標簽的元數據管理我們還是依賴Mysql作為把標簽的管理，並使用Airflow作為我們的調度任務框架，並最終將結果輸出到Mysql和Hbase中。對於標簽的前端管理，可視化等功能依賴Springboot+Vue.js搭建的前後端分離系統進行展示，而Hive和Druid的可視化查詢功能，我們也就使用強大的Superset整合進我們的系統中，最終系統的架構圖設計如下：

相對於傳統的技術架構，實時技術架構將極大的依賴於Flink的實時計算能力，當然大部分的聚合運算我們還是可以通過Sql搞定，但是複雜的機器學習運算需要依賴編碼實現。而標簽的存儲細節還是放在Mysql中，Hive與Druid共同建立起數據倉庫。相對於原來的技術架構，只是將計算引擎由Spark換成了Flink，當然可以選擇Spark的structured streaming同樣可以完成我們的需求，兩者的取捨還是依照具體情況來做分析。

傳統架構如下：

這樣我們就形成，數據存儲，計算，服務，管控的強有力的支撐，我們是否可以開始搭建大數據集群了呢？其實還不著急，在開工之前，需求的明確是無比重要的，針對不同的業務，電商，風控，還是其他行業都有著不同的需求，對於用戶畫像的要求也不同，那麼該如何明確這些需求呢，最重要的就是定義好用戶畫像的標簽體系，這是涉及技術人員，產品，運營等崗位共同討論的結果，也是用戶畫像的核心所在，下一篇，我們將討論用戶畫像的標簽體系。未完待續~

參考文獻

《用戶畫像：方法論與工程化解決方案》

更多實時數據分析相關博文與科技資訊，歡迎關註 “實時流式計算”