基于可視化元數據配置的大數據治理方案

鄭響萍

(浙江理工大學科技與藝術學院，浙江 紹興 312369)

1 引言(Introduction)

全球數據量正飛速增長，據數據統(tǒng)計互聯網公司Statistat統(tǒng)計預測，2020 年全球數據存儲量已達到47 ZB，2035 年將達到2，142 ZB，目前企業(yè)運營中產生的數據以每年42.2%的速度快速增長，但是只有56%數據能被企業(yè)獲取，而在獲取的數據中也僅有57%的數據會被有效利用。2016 年《國家“十三五”時期文化發(fā)展改革規(guī)劃綱要》正式提出，大數據發(fā)展進入深化階段，2021 年國家把大數據列入《中華人民共和國國民經濟和社會發(fā)展第十四個五年規(guī)劃和2035 年遠景目標綱要》中的重要一環(huán)，足見國家對大數據的重視[1]。近年來，大數據技術的發(fā)展日新月異，但是針對中小企業(yè)業(yè)務場景的大數據解決方案較少，并且實施成本高。

本文提出一種可視化配置的大數據治理方案，主要能解決中小企業(yè)使用大數據平臺成本高的問題。企業(yè)大數據通常有“3V”屬性，即高速度(Velocity)、多樣性(Variety)和大體量(Volume)[2]，目前使用較多是Hadoop體系架構，Hadoop可以較好地解決“3V”屬性帶來的存儲和計算難題，但Hadoop體系架構維護成本較高，并且日常云運營對專業(yè)大數據技術人員的依賴程度高。本文的研究重點是通過可視化配置的方式，使得非大數據技術人員也可以方便地進行大數據分析。

2 方案簡介(Solution introduction)

本文設計的大數據平臺包括數據采集、數據處理、數據服務和應用服務四大模塊。參考通用大數據架構設計和MPP架構[3]，將數據存儲、數據處理和數據應用服務分開，實現元數據配置、數據模型可視化及數據處理流程自動化[4]。

數據處理流程包括數據的定義和采集、數據清洗和模型存儲、數據分析和打標，以及標簽與業(yè)務系統(tǒng)結合等操作步驟，通過流程、模型定義等的配置，滿足企業(yè)的個性化業(yè)務場景需求，系統(tǒng)概覽如圖1所示。

圖1 系統(tǒng)概覽Fig.1 System overview

業(yè)界已有不少大數據平臺解決方案，例如國內各大云服務商的數據治理平臺、開源平臺Hadoop體系。這些平臺解決方案相較于本方案，云服務使用價格高，開源平臺Hadoop體系的運行對專業(yè)技術人才的依賴程度更高，并且使用成本、維護成本也比較高，很難在中小企業(yè)中得到快速普及使用。本方案通過可視化配置組合開源工具，對可視化大數據架構和容器化進行了深入研究，彌補了大數據過于依賴專業(yè)技術人才和使用成本高等問題。各大數據平臺解決方案比較如表1所示。

表1 大數據方案比較Tab.1 Comparison of big data solutions

從表1可以看出，中小企業(yè)最關心的幾個指標為使用成本、維護成本、服務能力等，本文提出的方案都能較好地滿足。

3 系統(tǒng)架構(System architecture)

系統(tǒng)采用開源方案，不額外增加企業(yè)成本，以自動化和可視化為前提，盡量降低企業(yè)對大數據專業(yè)技術人才的依賴程度。系統(tǒng)使用的開源工具包括Spark、Hive、MySQL、Snowplow等實現，系統(tǒng)架構圖如圖2所示。

圖2 系統(tǒng)架構圖Fig.2 System architecture diagram

數據采集層Snowplow作為業(yè)務系統(tǒng)的數據采集工具，其為自動化數據流而設計，通過API管理數據結構定義，可提升采集數據的質量，減少無效數據帶來的成本。Snowplow通過Kafka將數據傳輸到后端存儲。后端存儲選型為Hive，考慮到采集數據的多樣性，KV存儲特性能有效支持Snowplow自動采集的數據。

需采集的原始數據模型通過元數據定義描述，元數據被存儲到關系型數據庫MySQL中，通過Echarts和Vue等前端技術實現元數據的可視化配置。業(yè)務系統(tǒng)通過API獲取事件的元數據定義，構建采集的數據結構，將事件數據填充好并通過采集器傳入Snowplow采集器中。采集到的數據將被Snowplow采集器傳入Kafka中，通過消息清洗平臺ETL調度中心，將Kafka中數據消費并進行結構化處理后再次保存到Hive中，即可完成原始數據的存儲。

ETL任務流交由調度中心配置，數據模型由元數據定義描述，ETL任務將原始數據作為輸入源，與元數據定義的輸出數據進行映射，實現數據清洗的自動化，ETL清洗處理完的數據將被保存到Hive中。工作人員可通過可視化報表系統(tǒng)快速獲得模型數據，實現用戶畫像、業(yè)務模型與報表的快速實時獲取。

系統(tǒng)按數據處理流程共分為基礎服務、數據采集、數據處理、數據服務四大子系統(tǒng)。

3.1 基礎服務

基礎服務包括元數據管理和任務調度兩大系統(tǒng)。

元數據管理系統(tǒng)貫穿整個流程，包括數據采集時元數據配置、業(yè)務模型元數據定義等，在數據采集、數據清洗、數據建模期間都需定義數據模型綁定關系。

元數據管理系統(tǒng)采用微服務架構，通過Vue前端技術和SpringBoot后端技術實現元數據的配置功能，進行可視化的元數據定義管理[4-6]。元數據定義存儲在MySQL中，并在Redis中緩存?zhèn)浞?，以提升響應速度。元數據定義根據場景分為數據采集元數據定義、數據清洗元數據定義和業(yè)務模型元數據定義三大模塊。

以業(yè)務模型元數據定義為例(表2)，定義了元數據字段Order.Price，該字段含義為訂單金額，數據來源是trade表的price字段。

表2 業(yè)務模型元數據定義表Tab.2 Business model metadata definition table

元數據定義完成后，通過調度任務完成數據清洗和構建數據模型工作。將元數據定義與ETL任務進行綁定，綁定信息包括任務輸入、輸出及流程規(guī)則(表3、表4)，定義了訂單交易數據任務清單。

表3 元數據任務綁定表Tab.3 Metadata task binding table

表4 TradeTask任務定義表Tab.4 TradeTask definition table

調度系統(tǒng)通過定義表的映射關系創(chuàng)建ETL任務隊列，任務自動獲取數據，按流程處理數據。ETL任務調度系統(tǒng)參考業(yè)界流式數據清洗架構，并在此基礎上進行優(yōu)化，將元數據管理和調度系統(tǒng)結合，整合Spark、ClickHouse及MQ等技術[7]。規(guī)則字段定義的mouth_of等模塊，由Clickhouse、Hive平臺的能力支持，包裝成ETL任務通用計算模塊。

任務系統(tǒng)是一個集群，由Zookeeper選舉獲取Master節(jié)點，其余為Worker節(jié)點。Master節(jié)點負責編排、調度和分發(fā)，確保任務的執(zhí)行均衡，Worker節(jié)點負責執(zhí)行任務。Master的任務編排模塊會梳理任務執(zhí)行鏈路、任務類型等，整理出任務流程，分發(fā)到任務執(zhí)行平臺執(zhí)行任務。Worker節(jié)點獲取原始數據定義，并自動從MySQL、Hive等平臺中獲取原始數據，依次在Master節(jié)點的指揮下并行或串行完成任務鏈[8]。任務系統(tǒng)架構圖如圖3所示。

圖3 任務系統(tǒng)架構圖Fig.3 Task system architecture diagram

將調度系統(tǒng)與大數據存儲、計算平臺結合，構建可視化的配置系統(tǒng)和數據報表系統(tǒng)，完成從原始數據、數據清洗到大數據運算結果的流程自動化?？紤]到系統(tǒng)運維服務搭建的復雜度，對系統(tǒng)創(chuàng)建docker鏡像，通過docker容器化管理工具快速完成部署[9-10]。

3.2 數據采集系統(tǒng)

數據采集包括采集工具和管理系統(tǒng)兩個部分組成。

采集工具選型Snowplow數據采集器，在元數據管理中配置好數據采集定義后，Snowplow可以通過API獲取最新定義的采集元數據定義，控制客戶端采集數據模型，采集的數據暫存到Kafka緩沖區(qū)中，等待數據處理層處理，采集過程如圖4所示。

圖4 數據采集流程Fig.4 Data collection process

采集管理系統(tǒng)提供管理界面，系統(tǒng)通過SpringBoot微服務和Vue實現模塊管理，實現上傳Excel、導入數據及管理采集元數據定義等功能，采集數據綁定如圖5所示。

圖5 采集數據綁定Fig.5 Binding of collected data

3.3 數據處理系統(tǒng)

采集數據暫存在Kafka中，由數據處理系統(tǒng)接收并處理后，輸出模型數據并持久化存儲。

數據處理系統(tǒng)依賴基礎服務的任務調度系統(tǒng)，通過運算模塊完成數據處理。任務模塊主要包括二元和多元運算、算法平臺實現等，任務配置通過SpringBoot微服務實現，Vue實現前端可視化的綁定配置，例如訂單交易額為原始數據，而用戶的歷史累計交易、單月交易額等需要多元運算，例如表4中規(guī)則字段定義的mouth_of等方法，包裝Clickhouse、Hive平臺查詢語法，沉淀為通用運算。元數據存儲在關系型數據庫中，最終經過數據處理系統(tǒng)實現原始數據模型及二次數據模型的運算和存儲。數據存儲在Hive和Clickhouse等持久化平臺中，以便數據服務系統(tǒng)進一步實現用戶畫像、標簽化等[11-12]。數據處理鏈路圖如圖6所示。

圖6 數據處理鏈路圖Fig.6 Data processing link diagram

3.4 數據服務系統(tǒng)

數據服務系統(tǒng)為面向業(yè)務人員使用的系統(tǒng)，將數據處理系統(tǒng)完成的模型通過數據可視化報表和表格等形式展示給業(yè)務人員。

常用的可視化工具為Highcharts、Echarts、D3等，本文數據服務系統(tǒng)選擇Echarts數據可視化圖表庫，原因是從兼容性角度考慮，Echarts兼容IE9及所有主流瀏覽器且開源免費，支持較多圖表類型，可封裝成通用組件，并且Apache官網自帶有編輯工具，可快速完成編程。Highcharts的使用是需要收費的，D3雖然編程靈活，但是操作復雜。

數據服務系統(tǒng)構建可視化的數據報表供業(yè)務人員選擇，組件包括數據表格、折線圖、柱狀圖等，將數據處理系統(tǒng)完成的模型數據定義綁定到以上可供選擇的組件中，數據可視化組件封裝了從Hive、Clickhouse等平臺自動獲取模型數據的功能，通過簡單配置就可完成數據可視化。

數據服務系統(tǒng)整合了數據處理系統(tǒng)和基礎服務平臺能力，可以配置數據采集、數據處理的元數據定義和任務定義鏈，完成數據清洗到模型的配置過程。

業(yè)務人員可以利用數據處理系統(tǒng)可視化配置模型的能力，構建一套數據指標體系及創(chuàng)建用戶畫像、交易模型等業(yè)務模型。業(yè)務人員可利用數據標簽指導商業(yè)活動，例如構建用戶畫像標簽后，根據場景圈定不同的標簽人群做具體業(yè)務場景的商業(yè)化服務，可圈定標簽為某地域組合、某時間段、交易額在一定范圍的多個人群組進行下一階段的精準營銷，可以創(chuàng)建多組分組測試數據，用于判斷哪個商業(yè)化行為更有優(yōu)勢。

3.5 測試結果

系統(tǒng)模擬電商平臺中的1萬用戶和100萬單訂單數據，在4 臺4 核8 G服務器上部署完成整套系統(tǒng)，通過可視化任務平臺建立用戶畫像標簽50 項，包括商品類目喜好、大促敏感、交易能力等，分鐘級別地完成標簽的輸出和更新，并通過可視化表格的方式呈現給業(yè)務人員。

4 結論(Conclusion)

本文提出的基于可視化配置的中小企業(yè)大數據解決方案，利用開源工具，結合容器化技術，能快速完成系統(tǒng)搭建，并且成本低。企業(yè)非專業(yè)技術人員通過可視化平臺進行數據收集和數據定義，即可完成模型和標簽的大數據計算和存儲；工作人員通過系統(tǒng)輸出的模型數據報表指導業(yè)務運營，整個操作簡單直觀且不需要專業(yè)技術人員介入，能有效降低中小企業(yè)大數據運營成本。