基于可視化元數(shù)據(jù)配置的大數(shù)據(jù)治理方案

鄭響萍

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

1 引言(Introduction)

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

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

2 方案簡(jiǎn)介(Solution introduction)

本文設(shè)計(jì)的大數(shù)據(jù)平臺(tái)包括數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)服務(wù)和應(yīng)用服務(wù)四大模塊。參考通用大數(shù)據(jù)架構(gòu)設(shè)計(jì)和MPP架構(gòu)[3]，將數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理和數(shù)據(jù)應(yīng)用服務(wù)分開(kāi)，實(shí)現(xiàn)元數(shù)據(jù)配置、數(shù)據(jù)模型可視化及數(shù)據(jù)處理流程自動(dòng)化[4]。

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

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

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

表1 大數(shù)據(jù)方案比較Tab.1 Comparison of big data solutions

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

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

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

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

數(shù)據(jù)采集層Snowplow作為業(yè)務(wù)系統(tǒng)的數(shù)據(jù)采集工具，其為自動(dòng)化數(shù)據(jù)流而設(shè)計(jì)，通過(guò)API管理數(shù)據(jù)結(jié)構(gòu)定義，可提升采集數(shù)據(jù)的質(zhì)量，減少無(wú)效數(shù)據(jù)帶來(lái)的成本。Snowplow通過(guò)Kafka將數(shù)據(jù)傳輸?shù)胶蠖舜鎯?chǔ)。后端存儲(chǔ)選型為Hive，考慮到采集數(shù)據(jù)的多樣性，KV存儲(chǔ)特性能有效支持Snowplow自動(dòng)采集的數(shù)據(jù)。

需采集的原始數(shù)據(jù)模型通過(guò)元數(shù)據(jù)定義描述，元數(shù)據(jù)被存儲(chǔ)到關(guān)系型數(shù)據(jù)庫(kù)MySQL中，通過(guò)Echarts和Vue等前端技術(shù)實(shí)現(xiàn)元數(shù)據(jù)的可視化配置。業(yè)務(wù)系統(tǒng)通過(guò)API獲取事件的元數(shù)據(jù)定義，構(gòu)建采集的數(shù)據(jù)結(jié)構(gòu)，將事件數(shù)據(jù)填充好并通過(guò)采集器傳入Snowplow采集器中。采集到的數(shù)據(jù)將被Snowplow采集器傳入Kafka中，通過(guò)消息清洗平臺(tái)ETL調(diào)度中心，將Kafka中數(shù)據(jù)消費(fèi)并進(jìn)行結(jié)構(gòu)化處理后再次保存到Hive中，即可完成原始數(shù)據(jù)的存儲(chǔ)。

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

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

3.1 基礎(chǔ)服務(wù)

基礎(chǔ)服務(wù)包括元數(shù)據(jù)管理和任務(wù)調(diào)度兩大系統(tǒng)。

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

元數(shù)據(jù)管理系統(tǒng)采用微服務(wù)架構(gòu)，通過(guò)Vue前端技術(shù)和SpringBoot后端技術(shù)實(shí)現(xiàn)元數(shù)據(jù)的配置功能，進(jìn)行可視化的元數(shù)據(jù)定義管理[4-6]。元數(shù)據(jù)定義存儲(chǔ)在MySQL中，并在Redis中緩存?zhèn)浞荩蕴嵘憫?yīng)速度。元數(shù)據(jù)定義根據(jù)場(chǎng)景分為數(shù)據(jù)采集元數(shù)據(jù)定義、數(shù)據(jù)清洗元數(shù)據(jù)定義和業(yè)務(wù)模型元數(shù)據(jù)定義三大模塊。

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

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

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

表3 元數(shù)據(jù)任務(wù)綁定表Tab.3 Metadata task binding table

表4 TradeTask任務(wù)定義表Tab.4 TradeTask definition table

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

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

圖3 任務(wù)系統(tǒng)架構(gòu)圖Fig.3 Task system architecture diagram

將調(diào)度系統(tǒng)與大數(shù)據(jù)存儲(chǔ)、計(jì)算平臺(tái)結(jié)合，構(gòu)建可視化的配置系統(tǒng)和數(shù)據(jù)報(bào)表系統(tǒng)，完成從原始數(shù)據(jù)、數(shù)據(jù)清洗到大數(shù)據(jù)運(yùn)算結(jié)果的流程自動(dòng)化。考慮到系統(tǒng)運(yùn)維服務(wù)搭建的復(fù)雜度，對(duì)系統(tǒng)創(chuàng)建docker鏡像，通過(guò)docker容器化管理工具快速完成部署[9-10]。

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

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

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

圖4 數(shù)據(jù)采集流程Fig.4 Data collection process

采集管理系統(tǒng)提供管理界面，系統(tǒng)通過(guò)SpringBoot微服務(wù)和Vue實(shí)現(xiàn)模塊管理，實(shí)現(xiàn)上傳Excel、導(dǎo)入數(shù)據(jù)及管理采集元數(shù)據(jù)定義等功能，采集數(shù)據(jù)綁定如圖5所示。

圖5 采集數(shù)據(jù)綁定Fig.5 Binding of collected data

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

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

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

圖6 數(shù)據(jù)處理鏈路圖Fig.6 Data processing link diagram

3.4 數(shù)據(jù)服務(wù)系統(tǒng)

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

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

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

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

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

3.5 測(cè)試結(jié)果

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

4 結(jié)論(Conclusion)

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