摘要：鑒于當(dāng)前的數(shù)據(jù)治理管控方法缺乏統(tǒng)一標(biāo)準(zhǔn)約束，治理管控效果比較差，故此設(shè)計(jì)一種基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法。使用Apache Atlas元數(shù)據(jù)管理工具，配合Hadoop與Spark平臺完成管理工具的伸縮和擴(kuò)展，實(shí)現(xiàn)元數(shù)據(jù)管理，利用Hadoop與Spark大數(shù)據(jù)平臺中自帶的分布式文件系統(tǒng)GFS的結(jié)構(gòu)，內(nèi)置的大量塊服務(wù)器與客戶端功能使用的過程中進(jìn)行交互，搭建并行計(jì)算框架，數(shù)據(jù)治理過程主要針對數(shù)據(jù)的一致性、完整性和實(shí)時性三個方面進(jìn)行治理過程設(shè)計(jì)。方法性能測試結(jié)果表明：使用設(shè)計(jì)的數(shù)據(jù)治理管控方法，企業(yè)的運(yùn)營數(shù)據(jù)一致性、完整性、實(shí)時性分別為97.5%、97.7%、95.4%，由此可以看出數(shù)據(jù)質(zhì)量存在提升。

關(guān)鍵詞：Hadoop；Spark；大數(shù)據(jù)處理；平臺構(gòu)建

引言

當(dāng)前社會正處在大數(shù)據(jù)時代，各行各業(yè)在開發(fā)新的應(yīng)用程序過程中，都是以大量的行業(yè)數(shù)據(jù)為研發(fā)基石的，而行業(yè)大數(shù)據(jù)分析也已變成了公司在企業(yè)信息化構(gòu)建過程中的關(guān)鍵數(shù)據(jù)源泉[1]。大數(shù)據(jù)分析在提供給人們海量資訊的同時，也會隨之而來產(chǎn)生一系列數(shù)據(jù)問題，使得應(yīng)用程序無法有效而精準(zhǔn)地解決現(xiàn)實(shí)行業(yè)需求，嚴(yán)重時甚至?xí)绊懻麄€企業(yè)數(shù)據(jù)管理平臺的構(gòu)建[2]?；谶@種情況，對大數(shù)據(jù)進(jìn)行治理以提升數(shù)據(jù)質(zhì)量，是當(dāng)前企業(yè)在數(shù)據(jù)時代的必行之策。為解決因缺乏統(tǒng)一的標(biāo)準(zhǔn)約束，在數(shù)據(jù)治理過程中難以展示數(shù)據(jù)的不同維度，導(dǎo)致治理管控效果有限的不足，本文設(shè)計(jì)一種基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法。該方法以Hadoop與Spark大數(shù)據(jù)平臺為基礎(chǔ)，對數(shù)據(jù)進(jìn)行多方面的梳理與展示，為數(shù)據(jù)治理管控提供一定的便利條件。

1. 數(shù)據(jù)治理管控方法設(shè)計(jì)

1.1 設(shè)計(jì)元數(shù)據(jù)管理方案

大數(shù)據(jù)的背景下，元數(shù)據(jù)能夠?qū)?shù)據(jù)的種類進(jìn)行格式化的區(qū)分和描述，將非線性的大數(shù)據(jù)之間關(guān)系變得清晰，在實(shí)際應(yīng)用中能夠?qū)崿F(xiàn)精準(zhǔn)的數(shù)據(jù)生命周期管理[3]。元數(shù)據(jù)存在的意義是描述數(shù)據(jù)，對其進(jìn)行管理能夠?qū)⒃獢?shù)據(jù)的功能提供給所有的業(yè)務(wù)人員，促使業(yè)務(wù)人員能夠快速理解數(shù)據(jù)，保證數(shù)據(jù)的利用率提升。在元數(shù)據(jù)管理方案中，一般使用管理工具來實(shí)現(xiàn)對元數(shù)據(jù)的管理。目前市面上對于元數(shù)據(jù)管理的重視程度較低，因此針對開源元數(shù)據(jù)的管理工具較少。

本文主要使用的是Apache Atlas元數(shù)據(jù)管理工具，該管理工具是元數(shù)據(jù)廠商出品的商業(yè)智能套件之一，在客戶端所提供的版本是C/S版本。在實(shí)際的平臺應(yīng)用中，支持Hadoop與Spark大數(shù)據(jù)平臺數(shù)據(jù)庫的數(shù)據(jù)源，在數(shù)據(jù)通用標(biāo)準(zhǔn)模型中也能發(fā)揮自身的功能。該工具對于元數(shù)據(jù)模型具有良好的描述效果，對于數(shù)據(jù)的屬性也在可編輯范圍內(nèi)[4]。在實(shí)際的使用過程中，可以結(jié)合工具的其他功能完成報表的設(shè)計(jì)以及OLAP分析。與此同時，在附件導(dǎo)入、Web界面訪問等功能上都有良好的表現(xiàn)。與其他工具相比，功能更加豐富強(qiáng)大。除此之外，Atlas元數(shù)據(jù)管理工具在大數(shù)據(jù)處理體系中，能夠配合Hadoop與Spark平臺完成管理工具的伸縮和擴(kuò)展，實(shí)現(xiàn)大數(shù)據(jù)的治理。在這樣的組件使用方式下，能夠形成大數(shù)據(jù)與工具組件信息之間的統(tǒng)一管理。

1.2 建立基于Hadoop與Spark大數(shù)據(jù)平臺的并行計(jì)算框架

在Hadoop與Spark大數(shù)據(jù)平臺中，所包含的HDFS分布式文件與大數(shù)據(jù)平臺并行計(jì)算框架之間高度相關(guān)。作為大數(shù)據(jù)平臺中的文件系統(tǒng)，其中的主要功能就是并行計(jì)算與存儲組織計(jì)算機(jī)數(shù)據(jù)。Hadoop與Spark大數(shù)據(jù)平臺上，在利用自帶分布式文件系統(tǒng)GFS的結(jié)構(gòu)中，存儲的文件規(guī)模大，但是數(shù)量較少，與傳統(tǒng)的大量文件之間是存在一定區(qū)別的。該文件系統(tǒng)在存儲和讀寫數(shù)據(jù)的過程中，一般是直接在存儲文件的代碼末尾附加一個縮略數(shù)據(jù)，以達(dá)到減少開銷的目的。與此同時，該縮略數(shù)據(jù)能區(qū)分?jǐn)?shù)據(jù)流與控制流。GFS系統(tǒng)在運(yùn)行過程中，內(nèi)置的大量塊服務(wù)器與客戶端功能在使用的過程中進(jìn)行交互，這樣的直接交互方式能夠提升計(jì)算過程繁忙時段的效率。Hadoop與Spark大數(shù)據(jù)平臺中的HDFS分布式結(jié)構(gòu)非常適合并行計(jì)算，在進(jìn)行數(shù)據(jù)治理管控的過程中，能夠提供良好的存儲環(huán)境。數(shù)據(jù)在訪問和存儲過程中，這種分布式的集群環(huán)境都能夠提升數(shù)據(jù)治理管控過程中平臺的吞吐量。在不同功能節(jié)點(diǎn)劃分的狀態(tài)下，可以實(shí)現(xiàn)一對多。

本文所設(shè)計(jì)的數(shù)據(jù)治理管控方法就是在這樣的環(huán)境下搭建MapReduce并行計(jì)算框架。通過合并之后轉(zhuǎn)到下一個reduce過程進(jìn)行處理。在搭建的并行計(jì)算框架中，根據(jù)框架中原有的編寫作業(yè)，運(yùn)行進(jìn)程會生成一個對應(yīng)的唯一作業(yè)，每次在執(zhí)行程序的過程中，會生成一個對應(yīng)的工作ID。每次只能實(shí)現(xiàn)一個作業(yè)的單一執(zhí)行，這樣會提升并行計(jì)算的效率，且請求的資源能夠完全提交到HDFS上，能夠避免因?yàn)檫\(yùn)行期間等待提交超時而被誤認(rèn)為異常的情況發(fā)生。

1.3 數(shù)據(jù)多維度治理

數(shù)據(jù)治理主要是從數(shù)據(jù)的一致性、完整性和實(shí)時性三個方面進(jìn)行治理。數(shù)據(jù)的一致性主要是指數(shù)據(jù)在采集到表達(dá)的一整套過程的各個階段中，數(shù)據(jù)屬性字段的命令一致。相同數(shù)據(jù)在一些屬性的數(shù)據(jù)類型和精度方面是負(fù)荷實(shí)際需要的，在使用的過程中遵循數(shù)據(jù)的約束條件和實(shí)際的數(shù)據(jù)管理業(yè)務(wù)邏輯規(guī)則，才能夠避免不一致的數(shù)據(jù)出現(xiàn)，從源頭杜絕數(shù)據(jù)冗余。在一致性治理過程中，首先要對不規(guī)范數(shù)據(jù)進(jìn)行統(tǒng)計(jì)，將數(shù)據(jù)進(jìn)行分類，按照類別對不規(guī)范數(shù)據(jù)進(jìn)行查詢，利用SQL語句進(jìn)行編程，查找不一致數(shù)據(jù)。在得到統(tǒng)計(jì)的數(shù)據(jù)之后，將不符合規(guī)定的數(shù)據(jù)導(dǎo)出[5]，對不一致的數(shù)據(jù)字段利用不同的顏色進(jìn)行標(biāo)注，并按照不同的數(shù)據(jù)源進(jìn)行采集之后，按照單位屬性的不同進(jìn)行分組，下發(fā)到數(shù)據(jù)收集的各個部門中。負(fù)責(zé)數(shù)據(jù)采集的部門將自身部門數(shù)據(jù)按照一致性的字段進(jìn)行填寫之后，匯總到數(shù)據(jù)項(xiàng)目組中，進(jìn)行大數(shù)據(jù)平臺的統(tǒng)一更新。將收集到的模板數(shù)據(jù)導(dǎo)入后臺準(zhǔn)備的臨時數(shù)據(jù)表中，需要補(bǔ)充或修改的字段形式為代碼形式，那么先將其存儲之后，再導(dǎo)入平臺的臨時數(shù)據(jù)表中，利用字段進(jìn)行代碼翻譯。在完成以上工作之后，進(jìn)行數(shù)據(jù)更新，利用臨時數(shù)據(jù)表中的對應(yīng)字段與平臺設(shè)備數(shù)據(jù)進(jìn)行更新。數(shù)據(jù)的完整性和實(shí)時性治理過程與數(shù)據(jù)一致性的治理過程相似。在完成這三個方面的數(shù)據(jù)治理之后，數(shù)據(jù)質(zhì)量會有一定程度的提升。至此完成基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法的設(shè)計(jì)。

1.4 大數(shù)據(jù)可視化技術(shù)分析

Hive是用于Hadoop平臺的一種分布式數(shù)據(jù)分析框架，不僅能夠?qū)崿F(xiàn)Hadoop平臺的數(shù)據(jù)存取和轉(zhuǎn)換，還提供了豐富的SQL查詢處理手段。為了銜接底層并行處理結(jié)構(gòu)，Hive的查詢語句被系統(tǒng)轉(zhuǎn)換為Map和Reduce函數(shù)．利用這兩個函數(shù)實(shí)現(xiàn)并行處理，可以極大地降低查詢成本。同時，與HDFS類似，它也采用流模式進(jìn)行數(shù)據(jù)輸入和輸出，不支持?jǐn)?shù)據(jù)的隨機(jī)存取。但是Map和Reduce函數(shù)的轉(zhuǎn)換需要消耗一定的資源，因此對大規(guī)模查詢，效率將會下降，其實(shí)時查詢的效果也不佳。HBase是一種基于HDFS的數(shù)據(jù)庫，且它是開源和基于列的，通常傳統(tǒng)數(shù)據(jù)庫均是基于行進(jìn)行數(shù)據(jù)存取和查詢的，而HBase則基于列進(jìn)行相關(guān)操作，它的另外一個重要特征是可以用于存儲非結(jié)構(gòu)化數(shù)據(jù)（這正是大數(shù)據(jù)環(huán)境下亟待解決的問題）。傳統(tǒng)數(shù)據(jù)庫一般用于存儲符合某一范式的結(jié)構(gòu)化數(shù)據(jù)，但是大數(shù)據(jù)時代，非結(jié)構(gòu)化數(shù)據(jù)將成為主流（如網(wǎng)絡(luò)平臺上發(fā)布的照片，其分辨率、格式、顏色模式等不可能完全統(tǒng)一）。

2.方法性能測試

大數(shù)據(jù)的可視化呈現(xiàn)是基于平臺中所有相關(guān)企業(yè)的業(yè)務(wù)數(shù)據(jù)構(gòu)建的。由于原始數(shù)據(jù)采用的是多類型數(shù)據(jù)庫系統(tǒng)，且業(yè)務(wù)數(shù)據(jù)一般分散存儲在不同的服務(wù)器上，因此首先需要將數(shù)據(jù)集成，把分散的企業(yè)數(shù)據(jù)從分布式數(shù)據(jù)庫集成到Hadoop集群中，從而完成初始數(shù)據(jù)收集?；诔跏继峁?shù)據(jù)的結(jié)構(gòu)以關(guān)系型數(shù)據(jù)庫為主，需利用遷移工具Sqoop將數(shù)據(jù)從關(guān)系型數(shù)據(jù)庫遷移至Hadoop的HDFS存儲器上，進(jìn)而再將其加載到便于檢索、查詢的Hive數(shù)據(jù)庫。然后利用HQL語句對數(shù)據(jù)進(jìn)行查詢分析，并將查詢結(jié)果存入HBase數(shù)據(jù)庫。接下來將相應(yīng)的查詢結(jié)果與可視化的設(shè)計(jì)主題相結(jié)合，構(gòu)造對應(yīng)的可視化模型，并將模型以固定形式存入HBase，最后使用Echarts可視化插件對分析模型進(jìn)行圖形可視化呈現(xiàn)。為了驗(yàn)證本文所設(shè)計(jì)的基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法在實(shí)際應(yīng)用中的性能，選擇某公司的運(yùn)營數(shù)據(jù)作為測試案例，將本文數(shù)據(jù)治理管控方法應(yīng)用在該案例上，對該測試案例的數(shù)據(jù)質(zhì)量管理能力情況如圖1所示。

從圖1可以看出，該公司對于運(yùn)營數(shù)據(jù)的治理管控存在一定的問題，管理級別方面的評分較低，需要進(jìn)一步在數(shù)據(jù)標(biāo)準(zhǔn)與數(shù)據(jù)質(zhì)量方面進(jìn)行優(yōu)化、治理與管控。通過加強(qiáng)對公司主營范圍內(nèi)的業(yè)務(wù)數(shù)據(jù)以及指標(biāo)數(shù)據(jù)的完善，在此基礎(chǔ)上，使用本文設(shè)計(jì)的基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法和該公司原有的數(shù)據(jù)治理管控方式對數(shù)據(jù)進(jìn)行治理。實(shí)驗(yàn)時間為12個月，對比在不同數(shù)據(jù)治理管控方法下，該公司的數(shù)據(jù)一致性、完整性和實(shí)時性。該公司原有的數(shù)據(jù)治理管控結(jié)果如表1所示。

在使用本文設(shè)計(jì)的基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法下，該公司的數(shù)據(jù)治理管控結(jié)果如表2所示。

分析表1和表2中的數(shù)據(jù)，可以看出，與該公司采用原有的數(shù)據(jù)治理管控方法的結(jié)果相比，在使用本文所設(shè)計(jì)的數(shù)據(jù)治理管控方法下，一年之內(nèi)的數(shù)據(jù)質(zhì)量均有不同程度的上升。在數(shù)據(jù)一致性中，本文方法比原有的方法提升了5.5%，數(shù)據(jù)完整性提升了3.6%，數(shù)據(jù)實(shí)時性提升了7%。由此可以看出，在使用本文設(shè)計(jì)的基于Hadoop與Spark大數(shù)據(jù)平臺的數(shù)據(jù)治理管控方法下，該公司的運(yùn)營數(shù)據(jù)質(zhì)量有一定程度的提升。

結(jié)語

綜上所述，本文針對目前數(shù)據(jù)治理管控方法存在的缺點(diǎn)，從實(shí)際的應(yīng)用過程出發(fā)，考慮Hadoop與Spark大數(shù)據(jù)平臺為數(shù)據(jù)治理能夠提供的便利條件，來應(yīng)對數(shù)據(jù)治理在當(dāng)下的困難局面。本文從元數(shù)據(jù)管理、并行計(jì)算框架的設(shè)計(jì)以及數(shù)據(jù)多維度治理方面，對數(shù)據(jù)治理管控方法進(jìn)行了設(shè)計(jì)和優(yōu)化，并通過性能測試驗(yàn)證了本文方法的有效性。

參考文獻(xiàn)：

[1]張黎平，段淑萍，俞占倉.基于Hadoop的大數(shù)據(jù)處理平臺設(shè)計(jì)與實(shí)現(xiàn)[J].電子測試，2022，36（20）：74-75，83.

[2]郭海波，宋達(dá)，高翔宇，等.基于EdgeX的艦艇大數(shù)據(jù)處理平臺架構(gòu)[J].艦船科學(xué)技術(shù)，2021，43（17）：170-173.

[3]張海峰，魏可欣.一種基于Spark大數(shù)據(jù)處理平臺的查詢方法[J].南京郵電大學(xué)學(xué)報（自然科學(xué)版），2021，41（4）：82-90.

[4]李濤.Spark平臺下電力監(jiān)測大數(shù)據(jù)并行處理與模型的跨平臺遷移[D].華北電力大學(xué)，2021.

[5]李寧偉.大數(shù)據(jù)處理平臺Hadoop攻擊和檢測技術(shù)研究[D].南京航空航天大學(xué)，2021.

作者簡介：朱毓，在職碩士研究生，講師，研究方向：計(jì)算機(jī)應(yīng)用。

基金項(xiàng)目：安徽省高校自然科學(xué)研究重點(diǎn)項(xiàng)目——基于BPF面向容器網(wǎng)絡(luò)模型研究與優(yōu)化（編號：KJ2021A1467）。