高校數據治理技術框架研究

文/邵炤昭 王壯

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

高校數據治理困境

不少學者分析國內高校通用業務，總結出數據治理中的核心問題，主要體現在以下六個方面[1，2]:

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

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

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

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

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

第六，數據創新應用不足。主要體現在數據治理的成效對于數據源頭管理單位貢獻不大，或目前存在的數據問題不是長期或嚴重的問題,對于數據需求系統的提升有限。

高校數據治理方案

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

首先，完善學校頂層信息化建設規劃。依據學校未來5年或者長期目標，對學校業務和數據流向進行分析，依據分析結果，成立數據核心管理層和數據指導團隊。該團隊主要負責制定數據治理的藍圖和收益方向、平衡數據治理中各方的責任、風險和成效，以及梳理數據治理中組織結構關系，監控數據治理的成效。總的來說，該團隊負責數據治理的最終方向。

其次，搭建數據協調團隊。數據協調團隊是協調數據的責任主體，主要負責制定數據的技術標準，確保上游業務系統能提供符合技術規范的高質量數據。在數據治理期間，因為數據源頭可能存在技術或者業務困難，協調團隊會通過持續更新數據的采集和分發策略，來確保數據平臺能夠按照預期標準進行采集。

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

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

數據交換平臺技術架構及治理案例

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

圖1 數據治理階段各組件功能示意

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

Hadoop文件存儲系統：將采集過的原始數據寫入到Hadoop文件系統進行永久性存儲，Hadoop本身的文件系統在集群環境下自動實現數據的多備份，從而實現數據的可靠性，并且可以通過增加節點快速擴展存儲空間。

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

數據監控平臺：對數據的質量進行可視化的預覽，通過Power BI，業務單位可以隨時查看自己的業務數據質量，對有質量問題的數據進行修改。

API管理網關：在學校信息化建設過程中，第三方業務系統數量會隨著學校業務發展快速增加，隨之帶來了愈發嚴重的用戶權限問題和數據共享安全問題。API管理平臺可以把關數據權限和數據獲取的歷史進行記錄，從而保證數據的安全性。

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

基于SOA的主數據改造

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

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

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

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

基于數據可視化的質量控制

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

基于消息隊列的數據服務發布

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

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

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

表1 生產系統配置

表2 接口響應時間 單位：ms

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

表3 消息隊列中數據條目及其對應資源消耗 單位：條

基于日志類型的數據分析

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

浙江大學國際聯合學院 數據治理成效

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

從本次項目實施成效來看，SOA在傳統的結構化數據治理方面確實有更好的擴展性；在日志類型的大數據層面，基于Hadoop的分布式系統更加具有優勢。