鄭響萍

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

1 引言(Introduction)

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

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

2 方案簡介(Solution introduction)

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

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

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

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

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

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

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

系統(tǒng)采用開源方案，不額外增加企業(yè)成本，以自動化和可視化為前提，盡量降低企業(yè)對大數(shù)據(jù)專業(yè)技術(shù)人才的依賴程度。系統(tǒng)使用的開源工具包括Spark、Hive、MySQL、Snowplow等實現(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ù)采集工具，其為自動化數(shù)據(jù)流而設(shè)計，通過API管理數(shù)據(jù)結(jié)構(gòu)定義，可提升采集數(shù)據(jù)的質(zhì)量，減少無效數(shù)據(jù)帶來的成本。Snowplow通過Kafka將數(shù)據(jù)傳輸?shù)胶蠖舜鎯?。后端存儲選型為Hive，考慮到采集數(shù)據(jù)的多樣性，KV存儲特性能有效支持Snowplow自動采集的數(shù)據(jù)。

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

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

系統(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)貫穿整個流程，包括數(shù)據(jù)采集時元數(shù)據(jù)配置、業(yè)務(wù)模型元數(shù)據(jù)定義等，在數(shù)據(jù)采集、數(shù)據(jù)清洗、數(shù)據(jù)建模期間都需定義數(shù)據(jù)模型綁定關(guān)系。

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

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

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

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

任務(wù)系統(tǒng)是一個集群，由Zookeeper選舉獲取Master節(jié)點，其余為Worker節(jié)點。Master節(jié)點負(fù)責(zé)編排、調(diào)度和分發(fā)，確保任務(wù)的執(zhí)行均衡，Worker節(jié)點負(fù)責(zé)執(zhí)行任務(wù)。Master的任務(wù)編排模塊會梳理任務(wù)執(zhí)行鏈路、任務(wù)類型等，整理出任務(wù)流程，分發(fā)到任務(wù)執(zhí)行平臺執(zhí)行任務(wù)。Worker節(jié)點獲取原始數(shù)據(jù)定義，并自動從MySQL、Hive等平臺中獲取原始數(shù)據(jù)，依次在Master節(jié)點的指揮下并行或串行完成任務(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ù)存儲、計算平臺結(jié)合，構(gòu)建可視化的配置系統(tǒng)和數(shù)據(jù)報表系統(tǒng)，完成從原始數(shù)據(jù)、數(shù)據(jù)清洗到大數(shù)據(jù)運算結(jié)果的流程自動化?？紤]到系統(tǒng)運維服務(wù)搭建的復(fù)雜度，對系統(tǒng)創(chuàng)建docker鏡像，通過docker容器化管理工具快速完成部署[9-10]。

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

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

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

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

采集管理系統(tǒng)提供管理界面，系統(tǒng)通過SpringBoot微服務(wù)和Vue實現(xiàn)模塊管理，實現(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ù)并持久化存儲。

數(shù)據(jù)處理系統(tǒng)依賴基礎(chǔ)服務(wù)的任務(wù)調(diào)度系統(tǒng)，通過運算模塊完成數(shù)據(jù)處理。任務(wù)模塊主要包括二元和多元運算、算法平臺實現(xiàn)等，任務(wù)配置通過SpringBoot微服務(wù)實現(xiàn)，Vue實現(xiàn)前端可視化的綁定配置，例如訂單交易額為原始數(shù)據(jù)，而用戶的歷史累計交易、單月交易額等需要多元運算，例如表4中規(guī)則字段定義的mouth_of等方法，包裝Clickhouse、Hive平臺查詢語法，沉淀為通用運算。元數(shù)據(jù)存儲在關(guān)系型數(shù)據(jù)庫中，最終經(jīng)過數(shù)據(jù)處理系統(tǒng)實現(xiàn)原始數(shù)據(jù)模型及二次數(shù)據(jù)模型的運算和存儲。數(shù)據(jù)存儲在Hive和Clickhouse等持久化平臺中，以便數(shù)據(jù)服務(wù)系統(tǒng)進一步實現(xiàn)用戶畫像、標(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)完成的模型通過數(shù)據(jù)可視化報表和表格等形式展示給業(yè)務(wù)人員。

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

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

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

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

3.5 測試結(jié)果

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

4 結(jié)論(Conclusion)

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