? [圖片上傳失敗...(image-185472-1590370876851)]

? 在《什么的是用戶畫像》一文中，我們已經(jīng)知道用戶畫像對(duì)于企業(yè)的巨大意義，當(dāng)然也有著非常大實(shí)時(shí)難度。那么在用戶畫像的系統(tǒng)架構(gòu)中都有哪些難度和重點(diǎn)要考慮的問題呢？

挑戰(zhàn)

• 大數(shù)據(jù)

  隨著互聯(lián)網(wǎng)的崛起和智能手機(jī)的興起，以及物聯(lián)網(wǎng)帶來(lái)的各種可穿戴設(shè)備，我們能獲取的每一個(gè)用戶的數(shù)據(jù)量是非常巨大的，而用戶量本身更是巨大的，我們面臨的是TB級(jí)，PB級(jí)的數(shù)據(jù)，所以我們必須要一套可以支撐大數(shù)據(jù)量的高可用性，高擴(kuò)展性的系統(tǒng)架構(gòu)來(lái)支撐用戶畫像分析的實(shí)現(xiàn)。毫無(wú)疑問，大數(shù)據(jù)時(shí)代的到來(lái)讓這一切都成為可能，近年來(lái)，以Hadoop為代表的大數(shù)據(jù)技術(shù)如雨后春筍般迅速發(fā)展，每隔一段時(shí)間都會(huì)有一項(xiàng)新的技術(shù)誕生，不斷驅(qū)動(dòng)的業(yè)務(wù)向前，這讓我們對(duì)于用戶畫像的簡(jiǎn)單統(tǒng)計(jì)，復(fù)雜分析，機(jī)器學(xué)習(xí)都成為可能。所以整體用戶畫像體系必須建立在大數(shù)據(jù)架構(gòu)之上。

[圖片上傳失敗...(image-31ca31-1590370876851)]

?

• 實(shí)時(shí)性

  在Hadoop崛起初期，大部分的計(jì)算都是通過(guò)批處理完成的，也就是T+1的處理模式，要等一天才能知道前一天的結(jié)果。但是在用戶畫像領(lǐng)域，我們?cè)絹?lái)越需要實(shí)時(shí)性的考慮，我們需要在第一時(shí)間就得到各種維度的結(jié)果，在實(shí)時(shí)計(jì)算的初期只有Storm一家獨(dú)大，而Storm對(duì)于時(shí)間窗口，水印，觸發(fā)器都沒有很好的支持，而且保證數(shù)據(jù)一致性時(shí)將付出非常大的性能代價(jià)。但Kafka和Flink等實(shí)時(shí)流式計(jì)算框架的出現(xiàn)改變了這一切，數(shù)據(jù)的一致性，事件時(shí)間窗口，水印，觸發(fā)器都成為很容易的實(shí)現(xiàn)。而實(shí)時(shí)的OLAP框架Druid更是讓交互式實(shí)時(shí)查詢成為可能。這這些高性能的實(shí)時(shí)框架成為支撐我們建立實(shí)時(shí)用戶畫像的最有力支持。

[圖片上傳失敗...(image-6340ac-1590370876851)]

• 數(shù)據(jù)倉(cāng)庫(kù)

  數(shù)據(jù)倉(cāng)庫(kù)的概念由來(lái)已久，在我們得到海量的數(shù)據(jù)以后，如何將數(shù)據(jù)變成我們想要的樣子，這都需要ETL，也就是對(duì)數(shù)據(jù)進(jìn)行抽?。╡xtract）、轉(zhuǎn)換（transform）、加載（load）的過(guò)程，將數(shù)據(jù)轉(zhuǎn)換成想要的樣子儲(chǔ)存在目標(biāo)端。毫無(wú)疑問，Hive是作為離線數(shù)倉(cāng)的不二選擇，而hive使用的新引擎tez也有著非常好的查詢性能，而最近新版本的Flink也支持了hive性能非常不錯(cuò)。但是在實(shí)時(shí)用戶畫像架構(gòu)中，Hive是作為一個(gè)按天的歸檔倉(cāng)庫(kù)的存在，作為歷史數(shù)據(jù)形成的最終存儲(chǔ)所在，也提供了歷史數(shù)據(jù)查詢的能力。而Druid作為性能良好的實(shí)時(shí)數(shù)倉(cāng)，將共同提供數(shù)據(jù)倉(cāng)庫(kù)的查詢與分析支撐，Druid與Flink配合共同提供實(shí)時(shí)的處理結(jié)果，實(shí)時(shí)計(jì)算不再是只作為實(shí)時(shí)數(shù)據(jù)接入的部分，而真正的挑起大梁。

  所以，兩者的區(qū)別僅在于數(shù)據(jù)的處理過(guò)程，實(shí)時(shí)流式處理是對(duì)一個(gè)個(gè)流的反復(fù)處理，形成一個(gè)又一個(gè)流表，而數(shù)倉(cāng)的其他概念基本一致。

  數(shù)倉(cāng)的基本概念如下：

  • DB 是現(xiàn)有的數(shù)據(jù)來(lái)源(也稱各個(gè)系統(tǒng)的元數(shù)據(jù))，可以為mysql、SQLserver、文件日志等，為數(shù)據(jù)倉(cāng)庫(kù)提供數(shù)據(jù)來(lái)源的一般存在于現(xiàn)有的業(yè)務(wù)系統(tǒng)之中。

  • ETL的是 Extract-Transform-Load 的縮寫，用來(lái)描述將數(shù)據(jù)從來(lái)源遷移到目標(biāo)的幾個(gè)過(guò)程：

    • Extract，數(shù)據(jù)抽取，也就是把數(shù)據(jù)從數(shù)據(jù)源讀出來(lái)。
    • Transform，數(shù)據(jù)轉(zhuǎn)換，把原始數(shù)據(jù)轉(zhuǎn)換成期望的格式和維度。如果用在數(shù)據(jù)倉(cāng)庫(kù)的場(chǎng)景下，Transform也包含數(shù)據(jù)清洗，清洗掉噪音數(shù)據(jù)。
    • Load 數(shù)據(jù)加載，把處理后的數(shù)據(jù)加載到目標(biāo)處，比如數(shù)據(jù)倉(cāng)庫(kù)。

  • ODS(Operational Data Store) 操作性數(shù)據(jù)，是作為數(shù)據(jù)庫(kù)到數(shù)據(jù)倉(cāng)庫(kù)的一種過(guò)渡，ODS的數(shù)據(jù)結(jié)構(gòu)一般與數(shù)據(jù)來(lái)源保持一致，便于減少ETL的工作復(fù)雜性，而且ODS的數(shù)據(jù)周期一般比較短。ODS的數(shù)據(jù)最終流入DW

  • DW (Data Warehouse)數(shù)據(jù)倉(cāng)庫(kù)，是數(shù)據(jù)的歸宿，這里保持這所有的從ODS到來(lái)的數(shù)據(jù)，并長(zhǎng)期保存，而且這些數(shù)據(jù)不會(huì)被修改。

  • DM(Data Mart) 數(shù)據(jù)集市,為了特定的應(yīng)用目的或應(yīng)用范圍，而從數(shù)據(jù)倉(cāng)庫(kù)中獨(dú)立出來(lái)的一部分?jǐn)?shù)據(jù)，也可稱為部門數(shù)據(jù)或主題數(shù)據(jù)。面向應(yīng)用。

    image

當(dāng)然最終提供的服務(wù)不僅僅是可視化的展示，還有實(shí)時(shí)數(shù)據(jù)的提供，最終形成用戶畫像的實(shí)時(shí)服務(wù)，形成產(chǎn)品化。

在整個(gè)數(shù)據(jù)的處理過(guò)程中我們還需要自動(dòng)化的調(diào)度任務(wù)，免去我們重復(fù)的工作，實(shí)現(xiàn)系統(tǒng)的自動(dòng)化運(yùn)行，Airflow就是一款非常不錯(cuò)的調(diào)度工具，相比于老牌的Azkaban 和 Oozie，基于Python的工作流DAG，確保它可以很容易地進(jìn)行維護(hù)，版本化和測(cè)試。

至此我們所面臨的問題都有了非常好的解決方案，下面我們?cè)O(shè)計(jì)出我們系統(tǒng)的整體架構(gòu)，并分析我們需要掌握的技術(shù)與所需要的做的主要工作。

系統(tǒng)架構(gòu)

? 依據(jù)上面的分析與我們要實(shí)現(xiàn)的功能，我們將依賴Hive和Druid建立我們的數(shù)據(jù)倉(cāng)庫(kù)，使用Kafka進(jìn)行數(shù)據(jù)的接入，使用Flink作為我們的流處理引擎，對(duì)于標(biāo)簽的元數(shù)據(jù)管理我們還是依賴Mysql作為把標(biāo)簽的管理，并使用Airflow作為我們的調(diào)度任務(wù)框架，并最終將結(jié)果輸出到Mysql和Hbase中。對(duì)于標(biāo)簽的前端管理，可視化等功能依賴Springboot+Vue.js搭建的前后端分離系統(tǒng)進(jìn)行展示，而Hive和Druid的可視化查詢功能，我們也就使用強(qiáng)大的Superset整合進(jìn)我們的系統(tǒng)中，最終系統(tǒng)的架構(gòu)圖設(shè)計(jì)如下：

image

相對(duì)于傳統(tǒng)的技術(shù)架構(gòu)，實(shí)時(shí)技術(shù)架構(gòu)將極大的依賴于Flink的實(shí)時(shí)計(jì)算能力，當(dāng)然大部分的聚合運(yùn)算我們還是可以通過(guò)Sql搞定，但是復(fù)雜的機(jī)器學(xué)習(xí)運(yùn)算需要依賴編碼實(shí)現(xiàn)。而標(biāo)簽的存儲(chǔ)細(xì)節(jié)還是放在Mysql中，Hive與Druid共同建立起數(shù)據(jù)倉(cāng)庫(kù)。相對(duì)于原來(lái)的技術(shù)架構(gòu)，只是將計(jì)算引擎由Spark換成了Flink，當(dāng)然可以選擇Spark的structured streaming同樣可以完成我們的需求，兩者的取舍還是依照具體情況來(lái)做分析。

傳統(tǒng)架構(gòu)如下：

image

這樣我們就形成，數(shù)據(jù)存儲(chǔ)，計(jì)算，服務(wù)，管控的強(qiáng)有力的支撐，我們是否可以開始搭建大數(shù)據(jù)集群了呢？其實(shí)還不著急，在開工之前，需求的明確是無(wú)比重要的，針對(duì)不同的業(yè)務(wù)，電商，風(fēng)控，還是其他行業(yè)都有著不同的需求，對(duì)于用戶畫像的要求也不同，那么該如何明確這些需求呢，最重要的就是定義好用戶畫像的標(biāo)簽體系，這是涉及技術(shù)人員，產(chǎn)品，運(yùn)營(yíng)等崗位共同討論的結(jié)果，也是用戶畫像的核心所在，下一篇，我們將討論用戶畫像的標(biāo)簽體系。未完待續(xù)~

參考文獻(xiàn)

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

更多實(shí)時(shí)數(shù)據(jù)分析相關(guān)博文與科技資訊，歡迎關(guān)注 “實(shí)時(shí)流式計(jì)算”

image