基于Data Vault的交通行業數據倉庫設計

韋 揚，陳成偉

(1.廣西交通運輸信息管理中心，廣西 南寧 530029；2.廣西交通設計集團有限公司，廣西 南寧 530029)

0 引言

當前社會已經從信息技術時代發展進入數據技術時代。數據，已經滲透到每一個行業和業務職能領域，成為重要的生產因素。雖然交通運輸行業信息化建設起步較早，已相繼建成很多業務系統，但缺乏較好的頂層設計，各個系統各自為戰，導致出現重復投資、信息孤島等問題。為解決交通運輸行業信息化的痛點、難點，同時順應數據時代的發展要求，本文以廣西交通運輸廳現行業務系統的歷史數據和實時數據為基礎，首先介紹數據倉庫模型設計常見方法及問題，進而提出使用Data Vault建模方法，嘗試構建以可追溯、易擴展為特點的交通運輸行業數據倉庫。

1 數據模型設計

數據模型是數據的組織和存儲方式，它是整個數據倉庫設計的核心。一方面，數據模型是ETL的目標結構，ETL的設計是基于數據模型而開展的；另一方面，數據模型是數據分析的基石，決定了報表邏輯以及機器學習等數據挖掘工具的數據輸入格式。數據倉庫建模方法主要有范式建模(關系模型)和維度建模(多維模型)。

范式建模源于Inmon提出的集線器式自上而下的數據倉庫架構。關系模型通過使用關鍵字和外鍵在不同行的數據間建立關聯，關系型數據以使數據分解成非常低粒度的標準化的形式存在，以標準化程度的不同可以分為：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等。

維度建模源于Kimball博士提出的總線式自下而上的數據倉庫架構，多維模型也稱星型連接。多維模型以包含大量數據值的事實表為中心，其周圍圍繞的維表用并不多的數據來描述事實表的某個重要方面。

兩種建模方式的特點歸納如表1所示。

表1 兩種建模方式特點歸納表

交通行業信息系統數據具有多源異構、業務變動頻繁、數據量大等特點，因此，交通行業數據倉庫的建設要求可擴展性高、處理數據量大的建模方法，同時也需要兼顧開發人員行業經驗、開發維護成本等因素。本文嘗試采用一種新的建模方法Data Vault進行數據倉庫建模。

2 使用Data Vault進行數據倉庫模型設計

2.1 Data Vault及其特點

Data Vault是Dan Linstedt發明的一種數據模型，它強調數據的歷史性、可追溯性、原子性，不需要對數據進行過度一致性處理和整合。同時它基于主題概念將數據進行結構化組織，并引入了更進一步的范式處理來優化模型，以應對源系統變更的擴展性。Data Vault主要由Hub、Link和Satellite三個部分組成。相較于范式建模和維度建模，Data Vault的優越性明顯：

(1)可擴展性高。實體分為實體的key值、實體的屬性值、實體的關系三種存在形式，三者分開存儲，降低了耦合度，提高了靈活性與可擴展性。

(2)符合大數據特征。Data Vault是基于客觀事實進行的數據增量抽取，不做邏輯校驗，因此可以大規模抽取和處理數據。

(3)建模簡單。模型中只有Hub、Link、Satellite表。只要區分這些表，剩下的重點就只有設計和調度ETL，這在很大程度上簡化了建模過程。

(4)開發敏捷。使用Data Vault建模，2～3周即可完成一次迭代，發布周期短，可以更便捷地應對業務需求。

2.2 Data Vault實體設計

Hub表示業務核心實體，由實體主鍵、倉庫代理鍵、裝載時間、數據來源等構成。BK為原系統的業務主鍵；SK為代理鍵，它由業務主鍵與來源節點LOG_SRC_NODE按規則生成，用來唯一標識一個實體。Hub的代理鍵會向外延伸到與其相關的Satellite和Link中。

Link標識Hub之間的關系，它是提升模型擴展性的關鍵，不需要任何變更就可以直接表示1∶1、1∶n、n∶m的關系。

Satellite描述Hub或者Link的相關屬性和上下文內容。代理鍵SK由Hub中延伸到Satellite的業務主鍵(在Satellite中為FK)和記錄變化時間LOG_CHG_TIME共同計算得出，由此可以記錄歷史信息。如圖1所示為在模型設計中常用的字段及其釋意。

圖1 實體示例圖

3 在數據倉庫建設過程中的應用

3.1 業務模型

根據交通運輸部印發的《交通運輸政務信息資源目錄編制指南(試行)》(以下簡稱編制指南)，將信息資源劃分為行業、業務、管理對象、主題、信息類別五大分類。本文參考編制指南從宏觀視角對業務架構進行抽象，提出了“交通運輸行業全域模型”，如圖2所示。全域模型考慮到數據倉庫、數據集市的建設需求以及不同維度的特征，選取對象、行業、職能事務三個維度進行業務建模。由于任何事物都無法脫離時間與空間，且在交通運輸領域這種聯系尤為突出，因此，本文在對象域中添加了時間、空間兩個維度。此外，職能事務域作為對目錄編制指南中業務分類的整理，考慮到交通領域大數據未來的發展，除業務本身外，補充了企業業務和公眾業務兩個維度。由于業務建模實際上是在選取的維度上進行有限枚舉的劃分，因此反映到實際數據模型設計上時主要體現為對實體對象的命名劃分，如“H_船舶_運輸裝備_水路交通_運行管理”，下劃線區隔的后三部分“運輸裝備_水路交通_運行管理”分別從對象域、行業域和職能事務域三個維度對“船舶”這個Hub實體進行描述。

圖2 交通運輸行業全域模型圖

3.2 總體架構

一個完整的數據倉庫系統的定義為：數據倉庫系統(DWS)=抽取/轉換/加載(ETL)+數據倉庫(DW)+聯機分析處理(OLAP)+數據挖掘(DM)+決策支持(DS)。結合業務系統和數據來源情況，數據倉庫整體架構設計如圖3所示。

圖3 總體架構圖

整個系統架構分為數據源、數據平臺和應用三個主要部分。數據平臺負責數據的ETL、存儲和處理，經過匯總形成數據集市。本文關注的重點為數據倉庫部分，此部分采用Data Vault建模方法進行模型設計。通過對業務數據的解讀和分析，抽象出實體、關系及上下文等對象，然后按照對象的業務屬性從業務模型的三個維度進行劃分并按照規則完成命名，最后設置相關屬性和主外鍵關系。當設計完成后，從宏觀上看整個模型是由Hub、Link、Satellite組成的星型網狀結構，如圖4所示。

3.3 新數據的融合

Hub、Link和Satellite是刻劃實體和實體關系的基本要素，需要與實際業務相結合才能完成建模。使用Data Vault建模簡單靈活，可擴展性高。本文以一張新表(新實體)融入已有模型設計的過程為線索和切入點，對建模過程進行簡要描述。假設當前已經存在航道實體即航道Hub，當處理新引入的“瓶頸區段基本信息”表時，得到以下顯示：

圖4 星型網狀結構圖

(1)分析其內部各個字段識別實體。注意到其屬性“瓶頸區域編號”為主鍵可以標識一個實體，所以抽象為“瓶頸區域Hub”，而“航道編號”和“航道代碼”可以標識與其關聯的航道實體，其他字段描述了瓶頸區域的相關屬性。

(2)表屬性“航道編號”和“航道代碼”表明航道與瓶頸區段存在has-a關系，因此可將這種關系抽象為一個Link。

(3)表中其他屬性則是描述瓶頸區段Hub這個實體的上下文信息，需要將其抽象出來作為瓶頸區段Hub的Satellite(可以根據屬性的使用頻度、重要性、來源等劃分為多個Satellite)。由此可得如圖5所示的實體關系。

圖5 實體關系示例圖

通過以上方式持續加入新的實體，發掘實體與實體的關系，可以逐步構建出一張涵蓋所有交通運輸行業業務實體及其關系的網。限于篇幅，本文不能完全展示建模的詳細過程，但通過此片段不難看出使用Data Vault來進行建模具有可行性和很強的可操作性。

3.4 面向業務的后續數據處理

傳統的數據倉庫建設中，數據入倉時要做數據預處理，去除掉不合理的數據。而Data Vault模型基于客觀事實進行數據增量抽取，不做邏輯校驗，僅僅是反映了上游系統數據的真實性。而數據的處理工作相對靠后，在從數據倉庫到集市的ETL過程中完成數據的清洗工作，或以新增中間緩沖層的處理方式解決。

Data Vault模型的這些特點在聯網收費系統和票務系統中表現較為明顯，系統數據日增量在千萬級別，數據ETL工作量大、耗費資源。通過將數據從源系統直接抽取進入Data Vault模型，然后基于模型內的數據，經過清洗和轉換可以快速地建立出車輛主數據等主題應用。由此可見，基于Data Vault 模型不但可以快速大規模地抽取和處理數據，更符合大數據特征，同時可以快速生成面向業務分析需求的數據模型。

4 結語

本文介紹了基于Data Vault的數據倉庫總體架構和數據模型設計方法，為交通運輸行業大數據中心和數據倉庫建設提供了一種新的思路。目前已經接入結構化數據113.66億條記錄、2 100張表、29 591個字段。基于這些數據現有兩個主要應用：(1)整理出“人員”“公路路線”“行政機構”“企業”“船舶”“車輛”等主數據；(2)梳理出交通行業政務資源目錄。但目前引入的數據范圍和數據量仍較有限，數據模型設計的完備性、穩定性、擴展性還需要引入大量新數據源和更豐富的數據應用來考驗和優化。在此基礎上，如何有效管理數據倉庫元數據以更好的輔助數據的挖掘、分析和利用；如何通過質量審計來提高數據倉庫中的數據質量；如何利用大數據平臺高效存儲、管理非結構化數據(如圖片、視頻等)也將成為研究的重點方向。