基于數據中臺的建筑企業數據治理探索與實踐

文｜中國建筑一局（集團）有限公司信息部 周志萍 蔣圣平 于旭旭 袁哲

0 引言

隨著數據被國家列為生產要素[1]，數據的價值日益彰顯，數據的治理工作成為推動大數據與實體經濟深度融合、助力經濟轉向高質量發展階段的重要內容。建筑施工行業也積極推進數字化轉型，在集團運營和項目現場管理等方面實施了不少業務系統，如項目管理平臺、財務管理平臺、智慧工地集成平臺等。這些業務系統的實施廠商眾多，大多數是分期建設、間隔時間長、缺少標準、功能模塊之間相對獨立，在企業內部形成多個“數據孤島”，并且指標在定義和計算邏輯上可能各不相同，無法真正實現數據的開放共享，導致建筑行業雖有大量數據，但數據利用率低，無法發揮數據的價值。建筑企業的全域數據具有明顯的大數據5V 特征[2]：數據量大（Volume）、數據種類和來源多樣化（Variety）、數據增長快且分析處理和實效性高（Velocity）、數據準確性要求高（Veracity）、潛在的數據價值高（Value）。建筑行業的軟件廠商也關注數據應用，但往往局限于自身軟件模塊數據的治理和挖掘，甚至沒有建立專門的數據倉庫。筆者單位基于傳統的數據倉庫架構建立數據分析中心，解決企業內部集團層面項目管理、資源管理等信息系統的數據治理問題，在集團管控層面提升了數據的應用和價值[3]，但無法應對大數據量計算、非結構化數據集成等問題。總體而言，在建筑企業仍沒有一個成熟的解決方案實現從集團到項目間全域的數據治理和數據共享。

互聯網的發展讓我們可以收集和獲取的數據以不可預計的速度增長，大數據的分析及其應用成為了一大科研熱點。2008年，Hadoop 分布式處理軟件成為Apache開源基金會的頂級項目，互聯網行業率先采用基于Hadoop 分布式計算框架進行企業級數據處理，其分布式和高容錯等特性使得企業可以使用廉價的普通服務器構建大規模集群，提高數據的處理能力。阿里巴巴提出的數據中臺概念[4]，將數據統一化、工具組件化、應用服務化，極大的屏蔽了大數據技術本身的復雜性，在電力、教育、金融等行業得到了很好的應用[5-7]。

針對建筑企業全域的數據治理現狀，結合數據中臺技術的發展，本文探索性的將數據中臺引入到建筑行業全域數據的治理中，并提供全域數據治理和數據共享解決方案，對比了數據中臺架構和傳統數據倉庫架構的優缺點，為企業在數據治理方案選擇提供參考。

1 基于數據中臺的數據治理解決方案

1.1 總體架構

數據中臺基本功能包括數據采集、數據清洗、數據轉換與數據同步等[8]。部分數據中臺產商引入數據資產管理理念，在數據中臺產品中設計了數據標準、數據質量、數據安全、數據價值、數據共享管理等功能[9]。結合建筑企業特點，設計架構如圖1所示。

圖1 數據治理架構圖

1.2 數據采集方案

數據采集指從企業內外獲取數據的過程，數據包括結構化數據，如數據庫表數據、半結構化數據如Excel、XML、JSON 數據和非結構化數據如網頁、文檔、視頻、圖片等。針對數據源的不同，采集方案如下：

（1）數據庫采集

企業內部業務系統的數據大多存儲在數據庫中，數據采集只需通過配置ODBC/JDBC 鏈接，即可實現數據同步到Hadoop。數據中臺產品基本都配置相應插件，通過簡單配置，即可實現數據采集。

（2）半結構化數據采集

建筑企業內一些數據仍存在Excel 臺賬管理，此外，以API 方式從外部獲取一些公共數據如天氣信息，返回的格式通常是JSON 或XML。針對這些半結構化數據，數據中臺產品提供內嵌Python/Shell 腳本，通過自定義編寫Python/Shell 程序實現半結構化數據采集。

（3）網絡數據采集

如果網絡數據不能以API 方式提供，可使用Python 開發爬蟲程序或者選擇專門的RPA（Robotic Process Automation）工具，實現將網絡數據抓取到本地的業務數據庫，然后利用數據中臺產品通過數據庫采集方式同步到Hadoop。

（4）文檔、圖片、視頻類采集

針對文檔/圖片/視頻等文件的大數據處理，需要在文件同步到大數據平臺后，基于Python 程序開發。以視頻為例，通過Python 加載視頻后，對視頻進行分幀處理，運用合理的模式識別算法，提取圖片有用信息，轉換為業務場景需要的數據模型,將結果保存到數據庫。

在數據采集階段，根據數據時效性的不同要求，可采用離線采集和實時采集進行。對時效性要求不高的數據，通過全量或增量的方式按天或者按小時等進行數據同步，實現大批量數據的周期性遷移；對低時延、高時效的流數據應用場景，通過讀取日志或消息通知的方式，來實現數據的實時處理。

1.3 數據開發方案

1.3.1 建立數據倉庫模型

盡管數據中臺架構不同，但數據倉庫建模方法還是一致的，推薦以維度建模搭建企業數據倉庫模型[10]。維度建模以分析決策的需求出發，根據不同維度和主題域建立數據模型。數據倉庫模型設計后，需要利用數據中臺產品創建物理數據倉庫。

1.3.2 數據治理開發

（1）離線數據治理開發

離線數據治理采用分層處理，將復雜問題簡單化，減少重復開發，降低對業務變更的影響。數據分層開發從下到上可分為：操作數據層(ODS：Operation Data Store)、數倉明細層(DWD：Data Warehouse Detail)、數倉匯總層(DWS：Data Warehouse Summary)、應用數據層(ADS:Application Data Store)、公共維度層(DIM:Dimension)、數據應用層，整體的數據分層開發模型如圖2所示。

圖2 離線數據開發分層架構

圖中，ODS 層提供了對原始數據的備份，避免直接調用業務系統的數據；DWD層對ODS 層的數據進行過濾、清洗、轉換，形成最細粒度的明細表；DWS 層將DWD層的明細數據，按照不同維度、不同粒度進行匯總聚合，構建命名規范、口徑統一的統計指標，形成不同業務需求的匯總表；ADS 層對DWD 層或DWS 層數據進行個性化加工、數據匯總，形成某一個主題域的服務數據，為數據應用提供數據支持；DIM層整合不同業務系統的維度相關信息，建立統一的標準的企業維表；數據應用層同步ADS 層的交易數據和DIM 層的維度數據到關系型數據庫，面向最終應用。

（2）實時數據治理開發

實時數據治理邏輯簡單，但特別消耗資源，總體開發過程如圖3所示。

圖3 實時開發流程

實時采集通過讀取數據庫中的日志，利用數據抽取插件解析日志，逐條讀取各種數據庫操作，以流式數據的方式記錄到Kafka；Flink 作為實時計算的計算引擎，以SQL 的形式處理Kafka 中的流式數據：將Kafka 中的數據映射為源表，然后通過Flink 計算引擎以及特定的數據計算邏輯，完成對實時數據的分析處理，并將數據輸出到數據庫中。

1.4 數據共享服務

數據共享將數據變為一種服務能力，主要包括以下3 種方式：

（1）API 方式

開發服務接口，發布到API 市場后，企業內外部的人員可以授權申請使用，最終實現企業內外的數據共享。

（2）數據庫同步

數據庫同步提供面向目標數據源的跨數據源類型轉換的數據同步能力，實現直接向目標數據庫表以增量或全量的方式推送數據，主要用于企業內部的數據交換。

（3）多租戶模式

多租戶模式讓所有子企業共享集團統一的數據中臺及大數據平臺?？紤]到Hadoop 集群資源和多任務并行，多租戶使用時，需實現多重隔離：

邏輯隔離。從租戶的角度出發，每個租戶都有獨立的邏輯模型，擁有獨立的資源以及基于相同的邏輯模型實現的統一授權模型。

資源隔離。對于不同租戶的任務，在集群運行時，能夠實現統一的、全局最優的任務調度能力以及資源隔離能力。

運行隔離機制。用戶任務請求運行在yarn 調度上，相互無影響，各進行隔離。

2 應用效果分析

筆者單位于2019年采用傳統數據倉庫架構，成功實施數據分析中心項目。為了更好探索大數據在建筑企業的應用，在2021年申請并實施基于數據中臺的數據治理科研課題。實踐表明，相比傳統的數據倉庫架構（以商用ETL 工具SAP Data Services為例），基于數據中臺架構（以數棧為例）的數據治理主要有如下優缺點：

2.1 功能方面

數據源：數據中臺支持更多數據源，無縫對接處理大數據產品，ETL 工具對大數據產品的支持不夠；數據中臺產品不能直接對關系型數據庫增刪改查，ETL 工具可以自由操作。

離線開發：數據中臺產品支持Python/Shell/Spark 等多種工具開發，易于擴展；傳統的ETL 工具在邏輯控制（如控制數據流是否抽取、循環抽取等）更靈活。

實時開發：數據中臺產品通過Kafka、Flink 等實現實時開發；ETL 工具不支持。

數據共享：傳統的ETL 工具僅支持數據庫同步，不具有API 和多租戶模式功能。

版本管理：數據中臺產品有良好的版本管理和團隊協作功能；ETL 工具較差。

其他：數據中臺產品功能更全，集成數據資產管理，提供可視化分析如數據地圖、價值分析等；ETL 工具不支持。

2.2 性能方面

通過對比3000 萬條和6000 萬條SAP憑證進行數據治理，數據中臺架構數據加載到HIVE，ETL 架構加載到Oracle。設計兩種業務場景：場景一是對憑證進行簡單的數據轉換操作（減少輸出字段、更改日期類型、過濾無效記錄）；場景二是對憑證進行復雜的業務處理，生成項目的營業收入、監理批量等關鍵財務指標。測試環境：數據中臺架構，數據中臺服務器2 臺，數據節點3 臺；傳統數據倉庫架構，ETL 服務器1 臺，數據倉庫服務器一臺。對比結果如表1所示。

從表1可知，簡單的憑證清洗操作，相比傳統ETL 工具，數據中臺架構在3000萬記錄提升35.6%，6000 萬記錄提升50%；復雜的邏輯轉換，數據中臺架構在3000 萬記錄提升43.8%，6000 萬記錄提升66.7%。此外，針對復雜邏輯處理，數據中臺架構在數據量增大后，耗時增長為12.9%，也遠遠低于傳統ETL 工具的耗時增長48.4%。可見，數據中臺架構在大數據量的處理方面，性能優勢明顯，而且數據量越大，性能差異越大。

表1 數據中臺架構和傳統ETL 架構處理性能結果對比

3 結論

針對建筑企業的全域數據，傳統的數據倉庫架構在進行數據治理時存在很多問題和挑戰，這與大數據的本質特征密不可分。本文提出的數據中臺架構數據治理方案，可集成各種數據類型的數據源，支持實時和離線數據治理，提供靈活的數據共享服務，測試結果表明數據中臺架構在大數據處理方面性能優勢明顯，而且隨著數據量的增長可靈活擴展，能夠滿足建筑企業全域數據的數據治理。下一步，將聚焦建筑企業大數據潛在價值的挖掘及更多實際場景的應用。