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

挑戰

• 大數據

  隨着互聯網的崛起和智能手機的興起，以及物聯網帶來的各種可穿戴設備，我們能獲取的每一個用戶的數據量是非常巨大的，而用戶量本身更是巨大的，我們面臨的是 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 配合共同提供實時的處理結果，實時計算不再是隻作爲實時數據接入的部分，而真正的挑起大梁。

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

  數倉的基本概念如下：

• Extract，數據抽取，也就是把數據從數據源讀出來。

• Transform，數據轉換，把原始數據轉換成期望的格式和維度。如果用在數據倉庫的場景下，Transform 也包含數據清洗，清洗掉噪音數據。

• Load 數據加載，把處理後的數據加載到目標處，比如數據倉庫。

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

• ETL 的是 Extract-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 同樣可以完成我們的需求，兩者的取捨還是依照具體情況來做分析。

傳統架構如下：

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/V6DLlfnqMeJdnxJvbp_xeQ