文/邵炤昭 王壯

高等教育行業(yè)的快速發(fā)展，暴露出傳統(tǒng)線下辦事流程時效低、體驗差等弊端，在一定程度上影響在校師生學(xué)習(xí)和生活的正常開展。不少高校通過開展數(shù)據(jù)治理工作，來解決線上服務(wù)中因數(shù)據(jù)交換困難而造成的弊端。

高校數(shù)據(jù)治理困境

不少學(xué)者分析國內(nèi)高校通用業(yè)務(wù)，總結(jié)出數(shù)據(jù)治理中的核心問題，主要體現(xiàn)在以下六個方面[1，2]:

第一，數(shù)據(jù)共享困難。首先是信息系統(tǒng)相互之間協(xié)調(diào)困難，出現(xiàn)信息化“煙囪”現(xiàn)象。同時，數(shù)據(jù)接口的多樣化，比如有的系統(tǒng)接口是數(shù)據(jù)庫視圖，有的則是數(shù)據(jù)文件，有的是采用Web Service 返回非標準的字符串等。另外，因數(shù)據(jù)共享機制，業(yè)務(wù)部門對自己管理的數(shù)據(jù)存在權(quán)利擔憂。最后，相關(guān)部門擔憂數(shù)據(jù)共享會反映自己業(yè)務(wù)管理存在瑕疵。

第二，數(shù)據(jù)質(zhì)量參差不齊。在信息化建設(shè)過程中，建設(shè)單位或部門，主要圍繞自身業(yè)務(wù)進行需求的確認和開發(fā)，在系統(tǒng)開發(fā)過程中，對于不影響自己業(yè)務(wù)的數(shù)據(jù)缺乏基礎(chǔ)校驗，或者校驗不足。這會導(dǎo)致在其他業(yè)務(wù)系統(tǒng)需要相關(guān)數(shù)據(jù)時，系統(tǒng)無法提供準確信息。同時，不少系統(tǒng)管理人員沒有專業(yè)的數(shù)據(jù)維護意識，在共享數(shù)據(jù)時，發(fā)現(xiàn)數(shù)據(jù)錯誤后，僅在下游系統(tǒng)進行手動修正，卻不提醒數(shù)據(jù)源頭維護好相關(guān)信息。

第三，數(shù)據(jù)權(quán)限管理混亂。國內(nèi)高校普遍缺乏數(shù)據(jù)管理權(quán)限體系。在業(yè)務(wù)場景中，最直接體現(xiàn)出來的問題就是一數(shù)多源。當下游業(yè)務(wù)系統(tǒng)無法確定數(shù)據(jù)源頭時，就自行開發(fā)數(shù)據(jù)收集界面，進一步加劇數(shù)據(jù)管理的混亂狀況。對于用戶而言，就會出現(xiàn)反復(fù)填寫信息的情況，體驗較差。與此同時，下游業(yè)務(wù)系統(tǒng)開發(fā)人員和系統(tǒng)管理員可能沒有相關(guān)資質(zhì)和培訓(xùn)，無法確保數(shù)據(jù)的機密性，進一步削弱數(shù)據(jù)安全體系。

第四，數(shù)據(jù)生命周期缺失。在實際業(yè)務(wù)中，業(yè)務(wù)系統(tǒng)對于數(shù)據(jù)的注銷和存檔相對不夠重視，在現(xiàn)實場景中最直接的問題體現(xiàn)就是僵尸賬號和數(shù)據(jù)垃圾，用戶在系統(tǒng)中完成核心業(yè)務(wù)流程后，用戶數(shù)據(jù)沒有執(zhí)行注銷、刪除和保存。此外，系統(tǒng)監(jiān)管存在空白，相關(guān)人員離校后，系統(tǒng)依然對外開放，給校內(nèi)系統(tǒng)留下后門漏洞。

第五，數(shù)據(jù)應(yīng)用監(jiān)管空白。目前，隨著《中華人民共和國數(shù)據(jù)安全法》和《中華人民共和國個人信息保護法》相繼出臺，數(shù)據(jù)隱私管理開始有法可依，但如何兼顧用戶個人數(shù)據(jù)隱私和數(shù)據(jù)共享，還待進一步研究。

第六，數(shù)據(jù)創(chuàng)新應(yīng)用不足。主要體現(xiàn)在數(shù)據(jù)治理的成效對于數(shù)據(jù)源頭管理單位貢獻不大，或目前存在的數(shù)據(jù)問題不是長期或嚴重的問題,對于數(shù)據(jù)需求系統(tǒng)的提升有限。

高校數(shù)據(jù)治理方案

針對數(shù)據(jù)治理面臨的困境，不少業(yè)內(nèi)專家提出卓有成效的解決方案，并在任職機構(gòu)取得積極反饋[3，4]。這些方案主要是從以下三個層面進行改革和突破:

首先，完善學(xué)校頂層信息化建設(shè)規(guī)劃。依據(jù)學(xué)校未來5年或者長期目標，對學(xué)校業(yè)務(wù)和數(shù)據(jù)流向進行分析，依據(jù)分析結(jié)果，成立數(shù)據(jù)核心管理層和數(shù)據(jù)指導(dǎo)團隊。該團隊主要負責(zé)制定數(shù)據(jù)治理的藍圖和收益方向、平衡數(shù)據(jù)治理中各方的責(zé)任、風(fēng)險和成效，以及梳理數(shù)據(jù)治理中組織結(jié)構(gòu)關(guān)系，監(jiān)控數(shù)據(jù)治理的成效?？偟膩碚f，該團隊負責(zé)數(shù)據(jù)治理的最終方向。

其次，搭建數(shù)據(jù)協(xié)調(diào)團隊。數(shù)據(jù)協(xié)調(diào)團隊是協(xié)調(diào)數(shù)據(jù)的責(zé)任主體，主要負責(zé)制定數(shù)據(jù)的技術(shù)標準，確保上游業(yè)務(wù)系統(tǒng)能提供符合技術(shù)規(guī)范的高質(zhì)量數(shù)據(jù)。在數(shù)據(jù)治理期間，因為數(shù)據(jù)源頭可能存在技術(shù)或者業(yè)務(wù)困難，協(xié)調(diào)團隊會通過持續(xù)更新數(shù)據(jù)的采集和分發(fā)策略，來確保數(shù)據(jù)平臺能夠按照預(yù)期標準進行采集。

最后，組建技術(shù)團隊。技術(shù)團隊主要責(zé)任是搭建數(shù)據(jù)平臺、維護數(shù)據(jù)接口、保護數(shù)據(jù)隱私以及保障數(shù)據(jù)安全。團隊主要任務(wù)包括日常數(shù)據(jù)收集，數(shù)據(jù)轉(zhuǎn)換，數(shù)據(jù)標準化，確保數(shù)據(jù)存儲安全；適當進行數(shù)據(jù)接口的開發(fā)和定制；保護數(shù)據(jù)平臺中數(shù)據(jù)的隱私，對關(guān)鍵信息，例如手機號和證件號，進行去隱私和加密處理；保障監(jiān)控平臺數(shù)據(jù)的完整性，對數(shù)據(jù)寫入和讀取進行審計。

盡管在數(shù)據(jù)治理的體系方面有很多參考資源，但在技術(shù)層面的文獻和探討相對缺乏。部分學(xué)者推薦參照企業(yè)治理中的SOA架構(gòu)來重構(gòu)業(yè)務(wù)流程，然而市場上相關(guān)廠商則宣揚用大數(shù)據(jù)來進行數(shù)據(jù)治理。由此可見，技術(shù)平臺選擇的多樣化，讓很多高校的信息部門或者數(shù)據(jù)治理小組難以做出決策。

數(shù)據(jù)交換平臺技術(shù)架構(gòu)及治理案例

浙江大學(xué)國際聯(lián)合學(xué)院在2019年啟動數(shù)據(jù)交換平臺項目來開展數(shù)據(jù)治理。在建設(shè)實施前，采用傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)庫進行數(shù)據(jù)的存放和管理，項目開展后，引入SOA技術(shù)框架，對業(yè)務(wù)系統(tǒng)中交換頻繁的核心數(shù)據(jù)進行模型重構(gòu)，對SOA在數(shù)據(jù)治理中遇到的問題進行了分析，積累了大量的項目實施經(jīng)驗。同時，對大數(shù)據(jù)平臺的功能也做了深度調(diào)研，對部分業(yè)務(wù)數(shù)據(jù)量較大的場景進行實驗，總結(jié)出一套SOA技術(shù)架構(gòu)和大數(shù)據(jù)平臺整合的經(jīng)驗。技術(shù)平臺架構(gòu)如圖1所示，主要包括以下幾個核心組件:

圖1 數(shù)據(jù)治理階段各組件功能示意

ETL工具：ETL工具使用開源的Kettle，針對單次數(shù)據(jù)增加和更新小于10萬條目的格式化數(shù)據(jù)集合，通過開源工具Kettle對數(shù)據(jù)進行采集。對于日志格式類型等大容量數(shù)據(jù)，例如超過千萬條記錄，首先通過Sqoop將數(shù)據(jù)采集到臨時數(shù)據(jù)庫，再通過Impala進行初步過濾和加工，將加工后的數(shù)據(jù)寫入到主數(shù)據(jù)平臺。

Hadoop文件存儲系統(tǒng)：將采集過的原始數(shù)據(jù)寫入到Hadoop文件系統(tǒng)進行永久性存儲，Hadoop本身的文件系統(tǒng)在集群環(huán)境下自動實現(xiàn)數(shù)據(jù)的多備份，從而實現(xiàn)數(shù)據(jù)的可靠性，并且可以通過增加節(jié)點快速擴展存儲空間。

主數(shù)據(jù)平臺：將采集和清洗后的數(shù)據(jù)寫入主數(shù)據(jù)平臺。之所以選擇主數(shù)據(jù)平臺，不選擇數(shù)據(jù)倉庫，主要原因是主數(shù)據(jù)具有高精準、唯一識別性和高擴展性等特性。高精準體現(xiàn)在每一條記錄都可以追溯最后更新時間、數(shù)據(jù)源頭、轉(zhuǎn)化規(guī)則以及和其他數(shù)據(jù)集合的關(guān)聯(lián)關(guān)系；唯一識別性體現(xiàn)在每一條記錄都有一個唯一的主鍵和唯一的檢索名，避免出現(xiàn)冗余數(shù)據(jù)；高擴展性是指數(shù)據(jù)屬性緯度的高度可擴展性，例如對于人員屬性和性別，可以針對不同語言、不同別名進行創(chuàng)建，而不會破壞現(xiàn)有數(shù)據(jù)存儲結(jié)構(gòu)。在本案例中，采用商業(yè)產(chǎn)品Stibo主數(shù)據(jù)平臺進行數(shù)據(jù)的處理。

數(shù)據(jù)監(jiān)控平臺：對數(shù)據(jù)的質(zhì)量進行可視化的預(yù)覽，通過Power BI，業(yè)務(wù)單位可以隨時查看自己的業(yè)務(wù)數(shù)據(jù)質(zhì)量，對有質(zhì)量問題的數(shù)據(jù)進行修改。

API管理網(wǎng)關(guān)：在學(xué)校信息化建設(shè)過程中，第三方業(yè)務(wù)系統(tǒng)數(shù)量會隨著學(xué)校業(yè)務(wù)發(fā)展快速增加，隨之帶來了愈發(fā)嚴重的用戶權(quán)限問題和數(shù)據(jù)共享安全問題。API管理平臺可以把關(guān)數(shù)據(jù)權(quán)限和數(shù)據(jù)獲取的歷史進行記錄，從而保證數(shù)據(jù)的安全性。

消息隊列和內(nèi)存數(shù)據(jù)庫：在數(shù)據(jù)獲取過程中，個別業(yè)務(wù)系統(tǒng)對數(shù)據(jù)的響應(yīng)延時提出了更高要求。主數(shù)據(jù)平臺加上API管理雖然能提供可靠、安全的數(shù)據(jù)請求管理，但這套組合在目前主流技術(shù)架構(gòu)下，無法提供低延時的請求。解決方案是，通過消息隊列和內(nèi)存數(shù)據(jù)庫組合的方式實現(xiàn)低延時的請求響應(yīng)。消息隊列存儲數(shù)據(jù)更新的時間戳，內(nèi)存數(shù)據(jù)庫存放時間戳對應(yīng)的數(shù)據(jù)。當消息隊列中相關(guān)時間戳被消耗后，對應(yīng)的數(shù)據(jù)從內(nèi)存數(shù)據(jù)庫釋放，從而實現(xiàn)高性能的數(shù)據(jù)發(fā)布。同時，消息隊列也可以用來解耦系統(tǒng)的關(guān)聯(lián)性，實現(xiàn)業(yè)務(wù)系統(tǒng)數(shù)據(jù)的異步、削峰、解耦。當然，系統(tǒng)維護的復(fù)雜性和不穩(wěn)定性也會因此增加，需要結(jié)合場景去考慮。

基于SOA的主數(shù)據(jù)改造

數(shù)據(jù)治理從傳統(tǒng)的角度可以簡化為以下生命周期：數(shù)據(jù)的獲取，數(shù)據(jù)的轉(zhuǎn)換和清洗，數(shù)據(jù)的標準化和模型化，數(shù)據(jù)的發(fā)布和歸檔。在項目開展之前，采用傳統(tǒng)結(jié)構(gòu)化的SQL模型進行數(shù)據(jù)的存儲和管理。但是在實際運行中，因業(yè)務(wù)需求發(fā)生變更，導(dǎo)致數(shù)據(jù)的存儲結(jié)構(gòu)頻繁調(diào)整，在調(diào)整過程中，對應(yīng)的數(shù)據(jù)收集和數(shù)據(jù)分發(fā)接口產(chǎn)生重構(gòu)，因此導(dǎo)致時效低、穩(wěn)定性差的弊端。在參考相關(guān)文獻建議后[5，6]，引入SOA技術(shù)架構(gòu)的重組和改造。SOA的改造基本遵循上述流程。

但在實際場景中發(fā)現(xiàn)，數(shù)據(jù)標準化和數(shù)據(jù)建模更多依賴于數(shù)據(jù)發(fā)布的格式。因此，通過數(shù)據(jù)交換出去的格式，來反推數(shù)據(jù)的存儲模式和字段，持續(xù)更迭模型之間的邏輯關(guān)系。具體來說，從數(shù)據(jù)的流程管理進行分析，先分析數(shù)據(jù)會被哪些業(yè)務(wù)系統(tǒng)使用，得出數(shù)據(jù)的建模方向。

在數(shù)據(jù)建模方面，基于NoSQL的主數(shù)據(jù)模型可以很好地處理因業(yè)務(wù)需求變更而帶來的數(shù)據(jù)模型變更。基于NoSQL的主數(shù)據(jù)模型以主鍵作為對象的唯一標識，主鍵不一定限制于學(xué)號或者工號，任何一個能唯一標識一個對象的都可以作為主鍵。以課表為例，在課表標識上，采用教學(xué)班代碼加學(xué)期代碼作為唯一標識符，通過該唯一標識符構(gòu)建屬性組，例如上課地點、人員、課表等。得益于NoSQL的數(shù)據(jù)模型，數(shù)據(jù)對象屬性的變更或者調(diào)整，對于數(shù)據(jù)接口中的抽取和發(fā)布影響較小。

系統(tǒng)在確定好數(shù)據(jù)模型后，開始數(shù)據(jù)清洗規(guī)則的配置，包括數(shù)據(jù)的轉(zhuǎn)換規(guī)則，數(shù)據(jù)的篩選規(guī)則；在數(shù)據(jù)的清洗和抽取的過程中，采用主數(shù)據(jù)平臺自帶的數(shù)據(jù)標準轉(zhuǎn)化功能，進行數(shù)據(jù)標準化；對數(shù)據(jù)進行追蹤溯源，每一個數(shù)據(jù)字段都能追蹤到最后一次的變更日期和操作者信息，從而得到可以直接交付給業(yè)務(wù)系統(tǒng)的黃金數(shù)據(jù)，即完整、準確、可追溯的數(shù)據(jù)。

基于數(shù)據(jù)可視化的質(zhì)量控制

完成建模和數(shù)據(jù)清洗、標準化后，通過可視化工具進行數(shù)據(jù)質(zhì)量的監(jiān)控。可視化工具采用的是傳統(tǒng)的報表工具。在業(yè)務(wù)邏輯上，傳統(tǒng)的用戶報表業(yè)務(wù)一般都定位于數(shù)據(jù)流程末端的展示層。但是在數(shù)據(jù)治理中，數(shù)據(jù)質(zhì)量的監(jiān)控和用戶報表業(yè)務(wù)有明顯區(qū)分。在監(jiān)控層面，報表工具主要集中在空值、異常值，以及非標準值的監(jiān)控。然而在用戶報表業(yè)務(wù)，報表主要集中在用戶關(guān)注的特定維度。以國家字段為例，在用戶展示層面，更加關(guān)注國家數(shù)據(jù)，比如說外國留學(xué)生來源國家前十排名，以及海外留學(xué)生國家總數(shù)統(tǒng)計；在數(shù)據(jù)監(jiān)控層面，報表更加關(guān)注國家字段中的空值、異常值，以及非標準數(shù)值，例如國家名稱，有的寫中國，有的寫中華人民共和國。

基于消息隊列的數(shù)據(jù)服務(wù)發(fā)布

在數(shù)據(jù)發(fā)布層面，針對不同場景，提供不同的技術(shù)發(fā)布模式。對于數(shù)據(jù)量小，并且更新相對不頻繁的業(yè)務(wù)，采用Web Service的方式進行數(shù)據(jù)發(fā)布。針對數(shù)據(jù)量大，并且響應(yīng)延時低的業(yè)務(wù)，采用消息隊列以及內(nèi)存數(shù)據(jù)庫的混合模式，進行分發(fā)和管理。例如，對于浙江大學(xué)國際聯(lián)合學(xué)院的門戶網(wǎng)站黃頁接口數(shù)據(jù)而言，數(shù)據(jù)包含照片等非文本文件，數(shù)據(jù)量超過20M，但要求內(nèi)網(wǎng)門戶在調(diào)用該接口的時候，響應(yīng)延時不高于3秒。針對這樣的場景，采用消息隊列加內(nèi)存數(shù)據(jù)庫的模式進行數(shù)據(jù)分發(fā)。

具體而言，消息隊列中存放數(shù)據(jù)變化的時間戳，該時間戳為前面提到的數(shù)據(jù)最后一次的更新時間。內(nèi)存數(shù)據(jù)庫中存放時間戳對應(yīng)的數(shù)據(jù)。通過自行開發(fā)調(diào)度程序，定時將主數(shù)據(jù)平臺中的相關(guān)數(shù)據(jù)最后更新時間戳推送到消息隊列平臺中。下游業(yè)務(wù)系統(tǒng)獲取消息隊列中時間戳信息，將該時間戳和內(nèi)存數(shù)據(jù)庫中時間戳主鍵進行對比，如果時間戳有變化，就從主數(shù)據(jù)平臺更新最新數(shù)據(jù)，并且將該數(shù)據(jù)寫入內(nèi)存數(shù)據(jù)庫用于緩存。如果無變化，直接讀取內(nèi)存數(shù)據(jù)中緩存數(shù)據(jù)。

本案例中，生產(chǎn)系統(tǒng)配置參數(shù)見表1，性能見表2。在未加載內(nèi)存數(shù)據(jù)庫緩存數(shù)據(jù)時，單個請求分別從主數(shù)據(jù)平臺和無緩存的內(nèi)存服務(wù)器讀取，數(shù)據(jù)的平均響應(yīng)時間分別為6.1秒和7.1秒，用戶體驗較差。將數(shù)據(jù)放入內(nèi)存數(shù)據(jù)庫后，響應(yīng)時間下降到0.6秒，用戶體驗明顯改善。在使用多線程模擬并發(fā)壓力測試的情況下，內(nèi)存數(shù)據(jù)庫的延遲比例明顯低于其他兩種場景。

表1 生產(chǎn)系統(tǒng)配置

表2 接口響應(yīng)時間 單位：ms

隨著業(yè)務(wù)擴展，消息隊列的數(shù)據(jù)量也會水漲船高，因此，也需要對對應(yīng)硬件做相關(guān)的預(yù)估和規(guī)劃。對此，應(yīng)先統(tǒng)計現(xiàn)有的業(yè)務(wù)產(chǎn)生的消息隊列數(shù)據(jù)，從表3可知，短期內(nèi)現(xiàn)有硬件資源能滿足業(yè)務(wù)的需求。值得注意的是，消息隊列數(shù)據(jù)量的增長，并非線性增長，其原因有兩點：首先，個別業(yè)務(wù)系統(tǒng)對于消息隊列的數(shù)據(jù)需求，明顯高于其他業(yè)務(wù)系統(tǒng)；其次，下游系統(tǒng)從消息隊列獲取數(shù)據(jù)，輪詢時間隔較長，導(dǎo)致數(shù)據(jù)在消息隊列停留時間較長。針對相關(guān)問題，下游業(yè)務(wù)系統(tǒng)可以依據(jù)業(yè)務(wù)場景和性能進行調(diào)整，避免后期可能出現(xiàn)的擁塞。長期來看，業(yè)務(wù)增長應(yīng)屬于緩慢增長，現(xiàn)有硬件資源可以滿足后期業(yè)務(wù)開展。

表3 消息隊列中數(shù)據(jù)條目及其對應(yīng)資源消耗 單位：條

基于日志類型的數(shù)據(jù)分析

在項目實施后期，業(yè)務(wù)需求進一步提升。在日志型數(shù)據(jù)中，關(guān)鍵信息的抽取和交換需求開始浮現(xiàn)，傳統(tǒng)的SOA架構(gòu)已經(jīng)無法滿足日志型文件的存放，針對該問題，采用Hadoop生態(tài)群中的類SQL組件進行數(shù)據(jù)的抽取和加工。在分析Hive、Spark SQL，以及Impala后發(fā)現(xiàn)，Spark SQL性能最優(yōu)，但是技術(shù)文檔和穩(wěn)定性有待提升，Hive和Impala文獻比較充足，并且穩(wěn)定性相對較高，在性能上Impala略勝一籌。因此，采用Impala進行數(shù)據(jù)的加工和關(guān)鍵信息的抽取，抽取后的結(jié)果數(shù)據(jù)會寫入主數(shù)據(jù)平臺。對需要存儲的過程性數(shù)據(jù)，可存放在Hadoop的HDFS文件系統(tǒng)中，供后期調(diào)用。

浙江大學(xué)國際聯(lián)合學(xué)院 數(shù)據(jù)治理成效

經(jīng)過數(shù)據(jù)改造后，目前浙江大學(xué)國際聯(lián)合學(xué)院交換平臺核心數(shù)據(jù)質(zhì)量從原來的77%準確性，上升到91%，其中人員核心數(shù)據(jù)的可靠性上升到99.9%。數(shù)據(jù)業(yè)務(wù)范圍從人員數(shù)據(jù)擴展到課表數(shù)據(jù)、教室多媒體數(shù)據(jù)、會議室數(shù)據(jù)、住宿數(shù)據(jù)。日志類型數(shù)據(jù)每天實現(xiàn)300M以上的增量同步。接入應(yīng)用系統(tǒng)從7個上升到21個。核心業(yè)務(wù)系統(tǒng)數(shù)據(jù)實效性從平均1天下降到20分鐘。

從本次項目實施成效來看，SOA在傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)治理方面確實有更好的擴展性；在日志類型的大數(shù)據(jù)層面，基于Hadoop的分布式系統(tǒng)更加具有優(yōu)勢。