基于數據中臺的高校數據服務體系及快速應用構建研究

陸劍江

(蘇州大學 計算機科學與技術學院，江蘇 蘇州 215006)

0 引言

隨著信息化的不斷深入，各種業務的數字化產生了前所未有的數據量，也生成了各種各樣的數據類型，這些給數據的共享和利用帶來了新的挑戰，尤其是在一些互聯網平臺上，每天產生的數據對業務提出了更高的要求，此時，需要有更加靈活的、能力更強的平臺來負責大量的數據處理[1]。傳統模式下，每個業務模塊僅會處理各自龐雜的數據，這樣不僅效率不高，還會產生很多重復的工作，由于每個業務模塊都是一個獨立的數據孤島，因此后續的數據交換和數據同步無法應對靈活多變的業務需求，而這種多樣性的業務對數據的要求更高，數據本身的復雜性、對海量數據處理的要求、數據處理的實時性等都需要有能力更強的數據平臺來應對[2]。

高校的信息化發展已經進入了數字化和智能化的時代，各種業務基本完成了數字化改造，目前最大的問題是存在各種數據孤島，數據不能完全共享，各業務系統數據不能很好地為跨部門流程服務，無法處理非結構化數據，無法很好地支撐實時數據等[3]。為了解決上述問題，很多企業如阿里、騰訊和華為等，采用了數據中臺(Data Platform，DP)的解決方案，將各業務模塊中的數據處理模塊進行整合，增加數據治理和數據服務能力，使其不僅具備傳統數據倉庫的功能，還具備對大數據處理的能力。通過數據建模、數據分析和數據服務，能夠對各類數據應用提供更好的支持[4]。所以，高?？梢越梃b企業的中臺解決方案，在數據采集、數據加工和數據服務等方面進行全面改造和升級，從而讓高校在大數據處理能力方面有很好的提升。通過構建數據中臺，結合各類業務平臺，則基于大中臺、微服務的方式可以對原有系統進行解構，重新根據不同業務邏輯進行模塊化組裝，這勢必將會逐步改變業務系統的建設模式。

1 高校數據中臺架構

數據一般都依賴于各類業務系統在業務進行過程中產生，不同的業務系統由于沒有統一的數據標準，生成的數據會出現各種不一致的情況，當需要把這些數據聚集在一起使用時，就會遇到各種問題。目前，解決這類問題的辦法主要是通過數據的集成、加工處理成統一標準形式后，再進行共享的方式。通過建設共享數據平臺可以在數據量不大、數據形式不多的情況下解決問題，但隨著大數據的出現，以及對各種數據類型和數據實時性要求的提高，傳統的數據平臺已經無法滿足要求，數據中臺的概念應運而生。

數據中臺是布署在底層網絡計算存儲資源之上、頂層各類應用之下的中間層。南向有各類的數據輸入，即數據匯集；北向有各類的數據輸出，即數據服務，數據中臺負責對各類數據進行匯集、加工、處理和開發，最終將原始數據提供給各種具體的系統和應用[5]。高校數據中臺的架構如圖1所示。

圖1 高校數據中臺架構圖

從圖1的架構圖可以看出，高校的數據中臺主要包括數據采集(Data Collection，DC)、數據集成(Data Integration，DI)、數據治理(Data Governance，DG)和數據服務(Data Service，DS)等功能模塊，各個模塊負責數據流中各個過程的數據處理工作，存在DP={DC，DI，DG，DS}，可見，數據中臺其實是各類技術的集合體，在上述基礎上，還可以納入更多技術，比如數據分析等。

從圖1的數據流圖來看，數據中臺的整個工作流程如下：

(1)作為南向的數據輸入，對各個異構的數據源進行實時或定時數據抽取，這些數據直接進入中臺的數據湖(Data Lake，DL)，DL中存放各類數據源數據庫的原始鏡像數據。

(2)對照數據標準，對DL中的數據進行清洗、過濾等DG操作，經過處理的標準化數據根據各自的屬性或類別，如教學、科研或財務，以及所屬的具體應用，分別進入到對應的主題數據庫或者專題數據庫中，這個過程由DI模塊負責。

(3)作為中臺北向的數據服務和共享模塊，中臺還將生成各種數據接口，數據最終以數據服務的形式提供給各類應用。

上述幾個步驟分別完成了DC、DI、DG和DS的過程，用戶可以通過各類數據應用，從門戶、APP和小程序等訪問DP提供的這些數據。通常，中臺還可以提供基于其中各層的數據，按照特定的指標進行數據分析的能力。

2 數據分層架構設計

數據來源于不同的數據源，為了對所有數據進行各類處理，需要把原始數據引入到數據湖中，中臺對引入湖中的數據進行各類操作，不會對數據源有任何影響。數據湖支持任意數據源、任意格式、任意位置和任意復雜網絡環境下的高效數據采集和傳輸，支持全量數據集成，支持數據開發、圖形化、可視化實時監控[6]，支持各種類型的數據，包括結構化、半結構化和非結構化，實時的和非實時的數據。

數據從數據源到數據中臺后，將對數據進行清洗、過濾等數據治理操作，經過一系列的加工處理，從而確保數據的質量。在構建數據中臺的過程中，需要預先根據學校的業務對數據進行全面建模，建立各種主題數據庫，如教工主題庫、學生主題庫等，這些主題庫的結構、數據類型等即構成了各種主題域模型。如果有具體的應用需求，可以在主題庫的基礎上構建各類支撐特定應用的專題數據庫，這些專題數據就形成了各種數據的聚合。經過治理后的數據，會根據所屬的主題域模型，進入到不同的主題數據庫中?？梢?，經過一系列數據操作，數據在邏輯上被劃分為各個不同的層次。

如果用SL、BL、TL和ZL分別表示貼源層、標準層、主題層和專題層，則存在DP={SL，BL，TL，ZL}，根據不同層之間的邏輯關系，數據的具體流向為：SL→BL→TL→ZL，各層的歷史數據定期在歷史庫中歸檔，各個層都是存儲數據集的邏輯區域?？梢?，數據中臺不僅是各種技術的集合體，同時也是各種數據邏輯層的集合體，各層之間的邏輯關系和數據流向如圖2所示。

圖2 總體邏輯信息架構和數據流圖

從圖2中可以看出，數據首先從內部或外部的各種數據源進入到貼源層中，此過程可能會有必要的數據類型轉換操作，該層保存了全量的原始數據，所有數據表的庫表結構及數據內容與數據源保持一致。隨后，數據會進入到標準層，該層對數據進行標準代碼轉換、清洗過濾等操作，為后續的數據抽取做準備，這里保存了數據表在做標準轉換之后和數據整合之前的狀態。經過標準化處理后的數據，可以進入到主題層中，但在所有數據進入相關主題域之前，需要根據其存儲的數據內容，判斷其屬于哪個主題域并存放在各自的主題域下，該層包含有最細粒度的原子數據，也包含經過簡單計算和匯總的數據。為了服務于特定的應用，主題庫的數據可以進一步生成特定的專題庫，對應存放在中臺的專題層中，有時為滿足時效性等需求，專題層的數據可直接取自于貼源層，該層主要存放面向最終應用的數據，應用對數據進行的一系列操作也在該層中完成。

所有數據層的數據最終都會通過定期抽取存儲到歷史數據庫中，這樣可以減小各數據層的大小，提高數據讀寫效率，同時能滿足對離線歷史數據查詢的需求，避免對源數據的重復抽取。

3 基于數據模型的數據服務體系

在數據中臺的主題層中，可以根據業務場景，通過歸納、抽象，建立相應的主題域模型[7]。參考國標高校數據集，對于高校的業務活動，可以建立組織、人員、教學、科研、資產、財務和服務等主題域模型。首先對高校進行全域的邏輯模型設計，給出若干邏輯實體，然后設計相應的物理模型，即主題庫和物理實體表，并為每一張表開發數據抽取、轉換和加載(Extract-Transform-Load，ETL)的映射關系，同時根據表的數據特征，制定不同的ETL策略。

在專題層中，針對高校的具體應用場景，可以在主題域的基礎上，就某個特定的具體應用，建立單獨的專題域模型，如迎新、離校等專題域模型。

可見，數據中臺的數據模型包含主題域模型和專題域模型。用D來表示數據，L表示數據項，M表示數據模型，S表示數據服務，假設存在n個數據項，則所有的數據項可以用一個向量來表示為：。每個數據項又包含不同的數據，則對于某個數據項li而言，存在﹛li，﹜，表示某個數據項所包含的所有數據。

類似地，存在﹛mi，﹜，表示某個模型所包含的所有數據項；{si，}，表示某個服務所包含的所有模型集合。

可見，S、M、L和D共同構成了一個樹形結構，表明與特定服務相關的所有模型、數據項和數據的集合，存在DS={D，L，M，S}，構建了從數據→數據項→模型→服務的層次體系結構，其邏輯結構如圖3所示。

圖3 數據服務體系層次結構圖

從圖3可以看出，數據中臺不再直接提供數據，而是提供接口服務，接口不屬于某個特定的數據應用，而是部署在統一的數據服務中，而且接口可以在不同的數據應用之間進行共享?？梢?，數據服務打通了數據和應用之間的訪問鏈路，建立了從數據應用到數據中臺的全鏈路數據血緣關系，從而構建了基于(D，L，M，S)層次結構的，包含了服務封裝、服務發布和服務授權的數據服務體系。通過該數據服務體系，可以在數據模型的基礎上，為新系統的構建快速提供基礎數據，協助新系統更快上線。

另外，在數據中臺中，通過建立主題域模型，基于元數據和規范定義進行建模，構建主題邏輯表，提供主題式的數據服務，通過統一的數據接入層，屏蔽多種異構數據源，可以實現跨源數據服務[8]。經過封裝的數據服務，可以由不同應用系統調用，實現靈活的數據共享，減少重復開發，滿足不同應用數據在時效性、開發成本等方面的要求，還可以提供一站式數據查詢和分析等服務。

4 基于數據中臺的快速應用構建

數據中臺匯聚了各類業務系統的數據，經過數據治理和數據加工，形成了各類主題數據和專題數據，尤其是專題數據，可以為某個特定應用場景提供數據支撐服務。如數據中臺支撐數字迎新系統的構建和運行就是一個典型的案例。數字迎新流程涉及學校的多個業務部門，需要使用各個部門的數據來共同完成迎新過程，在這樣的場景中，傳統的、功能單一的共享數據平臺已經無法滿足要求，而匯集了數據集成、數據處理和數據服務功能的數據中臺可以輕松完成任務[9]。

一般而言，迎新的業務流程是新生在各個部門辦理各種報到手續的過程，與此同時，新生的各種數據也同步在各個部門之間進行流轉，這便形成了迎新的數據流。從招生、教務、宿管、人武部、信息中心、財務、學工到學院等，各個環節都會分享和生成相關數據。在迎新辦理現場，新生的實時報到數據還會在相應環節進行實時交互，這些數據來自于諸多不同的業務系統，這些系統的數據在結構、形式等方面并不統一，無法完成數據的直接交互處理。如果采用基于數據中臺的模式來構建迎新系統，可以在統一數據標準和數據服務的前提下，模塊化地搭建迎新系統的各個功能，采用大中臺、小應用的模式，快速構建各個階段的數據處理任務[10]。

基于數據中臺的迎新系統架構如圖4所示，可見數據的流向為各個數據源→數據中臺→各業務平臺→各迎新應用，參照數據中臺的作用，這里的各類業務平臺共同組成了業務中臺，可以理解為，迎新所涉及的各類應用是在數據中臺和業務中臺的基礎上快速構建起來的。比如站群平臺可以構建PC端和移動端的迎新網站，消息平臺可以構建迎新系統中各種消息推送，身份認證可以用于迎新系統中人員的身份登錄授權，繳費平臺可以用于迎新中各類繳費業務，流程平臺可以用于迎新中各種跨部門的流程應用，業務中臺的所有數據都來源于數據中臺，所以，迎新系統各個功能模塊的構建可以從這些大的已有平臺中直接生成，這樣不僅能減少重復開發，還能實現應用的快速靈活構建。

圖4 迎新系統架構圖

從數據中臺的角度看，構建類似迎新這類跨部門流程的系統可以按如下步驟進行：

(1)將迎新所涉及的各業務系統的數據通過數據采集模塊集成到數據湖中。

(2)根據數據中臺的數據標準對這些數據進行清洗和過濾等操作，形成統一的標準化數據。

(3)依據不同的類別，將這些數據分別歸屬到不同的主題域中。

(4)生成迎新專題庫，后續所有和迎新相關的數據操作都將在該專題庫中完成。

(5)在專題庫的基礎上，定制相應的數據服務接口，用于外部程序訪問數據中臺的數據。

(6)利用現有各類公共平臺的能力，構建迎新業務的通用功能模塊，如身份認證等。

(7)利用門戶的集成能力，整合上述各類功能模塊，為用戶提供個性化的、統一的服務入口。

通過上述步驟，可以在數據中臺結合各類業務平臺的能力，快速拼裝式地構建一個迎新系統，結合數據中臺的大數據分析能力，為迎新提供實時的數據處理和分析能力，同時由于各個模塊之間是松耦合的關系，后續在統一數據中臺的支撐下，可以隨意升級各模塊的功能，不會影響整體的迎新服務。

5 結束語

數據越來越多，也越來越重要，這一切都為中臺孕育了很好的土壤，尤其在高校里，業務部門眾多，業務系統繁雜，對于數據的采集和治理都是一個不小的挑戰。隨著圖像、視頻等應用的增多，對于非結構化數據的處理要求也越來越高，另外各類大數據分析以及實時的數據交互等都是不小的挑戰，對于這些而言，數據中臺都可以輕松化解。但是高校數據中臺的建設不能一蹴而就，應該是一個循序漸進的過程，屬于技術和管理結合的綜合范疇。從技術上講，需要有數據庫、數據抽取工具、數據治理平臺、數據接口平臺和數據分析平臺等；從管理上講，需要協調各業務部門配合提供數據，合理使用數據，數據流的每個環節都在中臺里扮演著重要的角色。作為學校的數據中樞和數據加工工廠，中臺將匯集所有的數據，這些數據經過一系列標準化處理之后，再分享到學校日?；顒拥母鱾€環節。

高校的數據孤島現象可以在數據中臺的驅動下逐步得到改善，高校的信息化建設模式也可以在中臺的影響下逐步發生改變，大中臺、小應用的模式將來會逐步取代如今各個龐大臃腫的系統，換來系統的快速迭代和需求的快速響應。中臺的成熟應用，將會使得高校的數字化轉型進入到一個加速車道，高校的信息化建設也將進入到一個飛速發展時期，逐步向更高階段跨越。