基于IFC標準的建筑信息模型分布式大數據平臺存儲技術研究

陳 遠 胡 航 岳石花

(鄭州大學土木工程學院 河南 鄭州 450001)

0 引 言

近年來，隨著信息技術與計算機網絡的發展，各個行業與領域的信息呈現出爆炸式的增長，人類社會已快速進入大數據的時代，而建筑業由于自身碎片化的特點，同樣面臨著海量數據的管理問題。建筑工程項目全生命周期中每天都會產生、傳輸、處理和保存大量的數據和信息。傳統的建筑工程項目基于分工理論，項目各參與方缺乏有效溝通，數據收集比較困難、數據保存相互孤立，導致項目管理過程中信息交互效率低下、信息丟失嚴重。BIM技術的出現打破了傳統的建筑業信息管理的困局，整合了工程項目全生命周期各階段的信息，為項目各方提供了統一的信息傳遞和管理平臺。

雖然基于BIM的建筑信息管理具有很大的潛力，但是隨著BIM模型的規模和復雜性的增加，利用單臺計算機處理多專業BIM模型的存儲和分析變得越來越困難。同時，不同BIM軟件供應商提供的BIM軟件產品都是基于自身特定的數據格式，軟件之間的互操作性較差，由此產生了新的信息孤島。而用來解決BIM信息交換問題的IFC標準，作為BIM技術的開放性標準，主要是基于文件的存儲和交互，這種交互方式依舊存在很大的缺陷。因此，基于IFC標準的建筑信息模型需要利用數據庫系統平臺，實現對建筑工程項目全生命周期內各種數據和信息進行存儲、交互和管理。然而，傳統的基于關系數據庫、面向對象數據庫已經無法滿足當下建筑業全生命周期內海量和多樣化數據存儲和管理的需求。因此，運用分布式大數據技術平臺，存儲基于IFC標準的BIM結構化和非結構化數據，是提高建筑業海量數據存儲與交換管理效率的關鍵，也是提高基于大數據技術的建筑數據分析能力的基礎。

1 基于傳統數據庫的IFC數據存儲技術

基于BIM的理念，建筑項目全生命周期各個階段產生的信息，是由不同的管理人員和工程技術人員通過多種BIM相關應用軟件所產生，為了更好地解決不同軟件間信息共享與交互問題，有必要制定開放性的BIM數據交換標準。IFC標準能夠很好地描述建筑實體信息，是BIM數據共享與建筑信息傳遞的重要標準，可以使BIM軟件具有更好的數據交換性和互操作性。但是基于文件的IFC數據交換和管理仍存在很多不足之處，包括無法形成完整的BIM模型，數據傳輸與變更實施困難，無法實現對象級的數據控制，不能完全支持同步修改與協同工作等[1]。

為解決基于文件進行數據管理所帶來的上述問題，許多學者利用傳統的關系數據庫、面向對象數據庫等技術來存儲基于IFC標準的BIM模型信息。例如通過研究IFC數據向關系數據模式轉換的算法，為IFC數據在關系數據庫中的存儲提供了理論探討[2]；通過建立IFC數據與關系型數據模式之間的映射關系，實現面向對象數據模型到關系數據表之間的轉換，構建符合IFC標準的BIM數據庫[3]。基于數據庫管理IFC信息的系統包括：利用關系數據庫Oracle存儲IFC構件信息的ACTIVe3D系統[4]；利用關系數據庫Access存儲IFC數據的IFC Model Server[5]；利用面向對象數據庫Object Store存儲IFC數據的 WISPER系統[6]。

研究表明，利用關系數據庫存儲IFC 數據可以克服基于文件存儲IFC數據的一些不足，并且已經取得一些成果。但是由于IFC數據是使用面向對象的Express語言進行描述，而關系型數據庫使用預定義的表和表之間的關系，不支持對象類型數據的存儲，并且關系型數據庫與面向對象特性之間的沖突在IFC標準中還未解決，因此并不適用IFC數據的存儲。另外，面向對象數據庫，其數據的擴展能力比較差，無法完成大規模的動態擴展。在工程項目全生命周期不僅產生基于BIM的結構化數據，還會產生大量的非結構化數據。傳統的數據庫系統擅長記錄結構化的建筑信息，在處理非結構化建筑信息方面具有一定的局限性。隨著大數據技術的發展和成熟，利用大數據存儲技術不僅可以解決上述的數據存儲問題，還可以通過大數據分析技術來提升工程項目海量數據的分析能力。

2 大數據存儲與分析技術在建筑業的應用

在土木工程領域已有許多基于大數據存儲與分析的研究,其中MongoDB作為主要的大數據數據庫，許多研究人員將MongoDB作為建筑數據的基礎存儲平臺。例如，利用MongoDB存儲基于IFC標準的BIM數據信息，并以此為基礎開發的BIM 信息協作平臺[7]。以及Jeong等[8]開發的混合數據管理基礎設施，前端使用MongoDB臨時存儲結構化的的數據，核心數據層使用Apache Cassadra永久存儲帶有時間標記的傳感器數據流。利用公有云或私有云服務器，文獻[9]提出了基于云的BIMCloud框架，用來支持項目各參與方的協作和信息共享。另外利用圖數據庫和Graph DB和圖理論，文獻[10]通過對IFC模型進行分析，將IFC 模式自動轉換為屬性圖數據庫的工作流。

大數據技術不僅包括數據的存儲，更重要的是對存儲數據的分析。例如，文獻[11]采用數據挖掘技術，利用KDD(Knowledge Discovery in Database)框架分析海量的工程項目數據集，并通過統計學方法來克服傳統機器學習算法的局限性；文獻[12]通過數據挖掘技術，對已完工項目海量數據使用文本分析、鏈接分析和維度矩陣分析等方法進行學習，并將結果用于未來項目的交付；為了解決建筑設計中暖通、電氣和管道之間的碰撞沖突問題，文獻[13]利用數據挖掘技術分析BIM模型中有關碰撞問題的歷史數據，從而針對具體問題提出了合理建議。

綜上所述，利用大數據存儲平臺可以實現基于BIM的工程項目協同，項目參與方將模型數據存儲到分布式數據庫，利用網絡技術實現對所需業務數據的訪問，方便工程參與方的信息共享，實現多人協同。另外可以將工程建設過程中復雜的分析計算從本地終端移到云端進行，基于大數據的分析將大大提高工程計算分析的準確性和效率，進而提升工程整體質量。然而，由于IFC標準的復雜性，建筑信息結構化和非結構化的多樣性，大數據存儲平臺種類繁多、技術框架各不相同，目前對于“BIM+大數據”的研究仍處于探索階段，對于基于大數據平臺的建筑信息的存儲和管理的研究有待進一步加強。

3 面向分布式大數據平臺HBase的IFC模型存儲技術

目前大數據平臺系統有很多，如流式數據處理的平臺Twitter的Storm和Facebook的Scribe等；交互式數據處理平臺Berkeley的Spark和Google的Dremel等；批量處理數據的Hadoop平臺等。其中Hadoop憑借其優越的性能，已成為當前大數據處理的主流平臺。非關系型數據庫HBase作為Hadoop文件系統HDFS(Hadoop Distributed File System)的分布式開源數據庫，在大數據存儲中得到廣泛應用。本研究提出的面向Hadoop大數據平臺基于HBase數據庫的IFC模型存儲系統架構可以分為服務層、數據交互層和客戶端三個層次，如圖1所示。

圖1 面向Hadoop大數據平臺基于HBase數據庫的IFC模型存儲系統架構

3.1 服務層

服務層以Hadoop平臺的分布式文件系統(HDFS)作為物理層數據存儲基礎，利用HBase數據庫來管理IFC模型數據，該層存儲空間可以水平擴展，使用分布式計算機提供數據支持服務。服務層需要解決的技術問題包括IFC實體數據的存儲策略，面向IFC的HBase數據庫表格設計，以及BIM的非結構化數據存儲等。

3.1.1 IFC實體數據存儲策略

IFC標準的實體包括可獨立交換實體和資源層實體(不可獨立交換實體)。資源層實體一般作為可獨立交換實體的屬性，不獨立參與數據交換。因此數據庫建表時只考慮對可獨立交換實體建表，資源層實體可直接序列化存儲在對應的屬性值中。IFC的實體可以劃分成以下的邏輯類別存儲到數據庫：

H=∪{O,RL,R,P}

其中O為繼承自IfcObjectDefinition實體的集合，O實體在數據庫中以“IFC實體名_GUID”作為行鍵，并建立對應的列族保存其所有的屬性。如果實體的屬性為O，數據庫保存這個屬性的行鍵“IFC實體名_GUID”而不是具體的數據。

RL是繼承IfcRelationship的實體，RL實體主要作為O實體之間的連接或連接O實體與資源層實體。RL實體采用與O實體相同存儲策略，如果一個實體的屬性為RL實體，數據庫僅保存這個屬性的行鍵“IFC實體名_GUID”。

R代表資源層定義的數據類型和實體。在HBase中直接將對象實例序列化，并存儲在對應的主體實體的屬性列中。

P指繼承IfcPropertyDefinition的實體，這種類型實體的屬性集包括靜態屬性集和動態屬性集。靜態屬性集中的屬性是以IFC實體屬性的方式來定義，因此可以按照O實體的存儲策略來存儲。動態屬性集用IfcPropertySet來表示，由于IfcPropertySet實體只是裝載屬性的容器，具體的屬性是由資源層的IfcProperty實體及其子類來描述。因此動態屬性集中的實體存儲策略與資源層R實體存儲策略相同，將對象實例序列化并存儲在主體實體的屬性列中。

3.1.2 HBase數據庫表格設計

HBase數據庫以行健(RowKey)、列族(ColumnFamily)、列(Column)和時間戳(TimeStamp)來確定數據單元(Cell)。行健是HBase數據庫檢索查詢的關鍵，在創建表時定義列族，列可以在存儲數據時動態擴展添加到列族中，因此行鍵和列族的設計是HBase數據庫表格設計的關鍵。

HBase中每行數據都有自己的唯一標識行健(RowKey)，雖然IFC中每個實體實例都有計算機自動生成的唯一標識符(GUID)，但是這些字符串對于用戶進行查詢時作用不大，因此可以在GUID前加上IFC實體名“IFC實體名_GUID”作為行鍵，方便根據IFC實體來進行快速查詢。另外，HBase中的行是按照行鍵的字典順序進行排序，在一定程度上方便按照行健進行數據的聚集和整合，因此可以在行鍵前部加上IFC項目文件名，這樣同一個項目中的每個行鍵前都有相同的前綴，可以將同一個項目之間的信息存儲在一起，方便用戶在較小的鍵值范圍內快速查詢信息。所以最終行鍵確定為：“IFC項目名_IFC實體名_GUID”。

根據IFC標準中實體屬性的類別，在HBase數據庫中，按照直接屬性(Driect)、導出屬性(Derive)、逆屬性(Inverse)這三種屬性分別對應三個列族：Driect列族、Derive列族和Inverse列族。其中Driect列族的直接屬性可以將屬性值以字符串的形式保存在對應的列內。對于Derive列族中的導出屬性，當屬性值對應的是資源層的實體時，將這些實體對象進行二進制序列化處理。對象序列化不僅可以保存一個對象的數據，而且可以遞歸保存對象引用的每個對象的數據，序列化一個對象可以得到整個對象序列。所以利用序列化方法可以很好地解決導出屬性對應的IFC實體的多層引用關系。對于Inverse列族中的逆屬性，是通過關系實體來表達該實體與另一個實體的一對一或一對多的關聯關系。因此需要先關聯相應的關系實體實例，此關系實體實例在HBase表格中的某行存儲。為了保持該實體實例與關系實體實例之間的關聯，將對應的關系實體實例的行鍵存儲在該實體逆屬性對應的列中。圖2以IfcProject實體實例和其某個屬性中對應的關系實體實例IfcRelAggregates來說明IFC數據結構在HBase數據庫中表的設計。

圖2 IFC數據結構在HBase數據庫中表的設計

3.2 數據交互層

數據交互層的主要作用包括：將BIM模型的非結構化數據和解析后IFC數據通過調用HBase Java API上傳到HBase數據庫中；調用HBase Java API從HBase中讀取數據，利用AJAX(Asynchronous JavaScript And XML)數據交互技術將數據傳遞到WEB前端。

3.2.1 基于IFC標準的BIM模型解析

IFC標準使用的EXPRESS是一種面向對象的信息描述語言，不是編程語言，不能直接編程開發，因此首先需要對底層的IFC標準的數據進行解析，才能運用計算機語言如C#、C++、JAVA等來編程實現具體功能。目前針對IFC數據進行解析的軟件工具主要包括Jotne EPM Technology 公司的EDM，基于C++的IfcPlusPlus，基于.NET平臺的xBIMToolKit，基于JAVA的IFC JAVA Toolbox等。本研究采用IFC JAVA Toolbox[14]作為解析工具，創建IfcModel類作為BIM模型類，該類包含了模型中所有的實體。IFC模型數據中的根實體IfcProject是解析對象的起點，是整個模型的最高級別實體類型，因此解析模型中每一個零部件、一根桿件，還是整個工程項目，都從IfcProject開始，自上而下地逐層定義對象，直到完整解析所有的模型實體及其屬性。具體的解析方法可見參考文獻[15-16]。

3.2.2 基于HBase Java API的數據交互

HBase數據庫接口為上層進行數據存取提供了多個類包,實現了兩個主要功能,一可以對數據庫表一級進行操作,二是可以對表進行數據存儲操作。如圖3所示，該系統主要包括7個類，其中HBaseConfigurationToIfc是系統的配置類，AdminHTable類和HBaseDataCURD類都繼承自HBaseConfigurationToIfc類，進而繼承該類配置文件對象conf，由conf對象實現自動載入所需配置文件，該對象也提供相應的方法用來設置配置文件里的變量信息。通過AdminHTable類可以對數據庫表格進行操作，通過HBaseDataCURD類可以對表格中的數據進行操作，這兩個類都是通用的操作類，其他Ifc、Picture、Document、User類是通過通用操作類封裝的操作接口，對HBase數據庫表和表對應的數據進行操作。

圖3 基于HBase Java API的系統類表

3.3 基于Web的客戶端

系統采用基于Web的客戶端，將BIM的IFC數據存儲在HBase數據庫中，通過AJAX實時發送回Web前端，從而實現前端界面和后臺之間的時時交互。JavaScript用于啟動鍵盤和鼠標觸發事件。系統客戶端網頁框架分為3組：菜單組、項目組、賬戶組。其中：菜單組提供網頁的頁面布局與索引；項目組管理用戶上傳基于IFC標準的BIM模型數據和查看模型數據列表，并且可以動態地添加工程中產生的其他非結構化數據；賬戶組提供賬戶的注冊和登錄信息。

4 案例驗證

系統技術驗證采用的是由Revit建立的教學樓BIM模型，如圖4所示。該模型分為三層結構的教學區和一層結構的食堂兩部分。本案例中的BIM模型不僅包括建筑物模型，還包括場地地形模型，以及場地平整與場地構件模型(如場地上籃球場、灌木叢、路燈等的布置)，這些模型豐富了模型導出的IFC實體類，驗證了HBase存儲IFC實體數據的多樣性。

圖4 案例驗證的教學樓BIM模型

4.1 Hadoop與HBase分布式大數據環境搭建

分布式大數據環境和傳統的單機或服務器環境有所不同，它使用基于集群的分布式存儲與并行計算體系結構和硬件平臺，能夠處理結構化與非結構化/半結構化數據。由于大數據環境的復雜性，Hadoop與HBase環境的搭建是IFC模型存儲的第一步，表1為本文所用軟件及版本號。

表1 本文所用軟件及版本號

Linux是一款開源的操作系統，許多公司在其原有基礎上開發出性能更加優越的操作系統，Ubuntu以Linux為內核，人機界面采用窗口式，其使用和升級全都是免費和開源的。Hadoop系統運行于由普通商用服務器組成的計算集群上，該集群在提供大規模分布式數據存儲資源的同時，也提供大規模的并行化計算資源。圖5為安裝和配置完成以后，Hadoop啟動進程的網頁瀏覽。另外，在HBase安裝和配置成功后，可以通過訪問Web界面，查看 NameNode和Datanode信息，還可以在線查看 HDFS 中的文件，如圖6所示。

圖5 Hadoop啟動進程的網頁瀏覽

圖6 HBase啟動進程的網頁瀏覽

4.2 基于Hadoop與HBase的IFC數據存儲流程

如圖7所示，基于分布式大數據環境的IFC數據存儲包括以下幾個步驟：首先將BIM模型導出IFC格式的文本文件；其次對IFC格式的文本文件進行解析；然后調用封裝的HBase Java API類對解析后的數據進行處理并存儲到HBase數據庫，同時該系統支持其他各種非結構化數據的導入；最后根據用戶的需要可以通過Web前端將Hbase數據庫中的數據反饋給前端用戶，使用戶可以在前端界面實現相應的功能。

圖7 基于大數據環境的IFC數據存儲流程

4.3 基于BIM的結構化和非結構化工程數據存儲技術的實現

用戶管理模塊主要用于管理用戶的信息以及對用戶操作該系統的合法性進行驗證。圖8所示為用戶注冊和登錄界面。該系統的存儲模塊包括對IFC結構化數據的存儲和管理，以及對項目非結構化數據的存儲和管理。圖9所示為系統加載IFC文件的界面，圖10為后臺HBase加載IFC數據的過程，圖11為解析和加載完成后，HBase數據庫表中保存的IFC數據。

圖8 用戶注冊和登錄界面

圖9 系統加載IFC文件

圖10 后端HBase加載IFC數據的過程

圖11 后端HBase數據庫表中保存的IFC數據

對于保持在HBase數據庫中的IFC數據和非結構化數據，可以利用關鍵字進行檢索和查詢，并且可以在Web終端顯示，圖12為Web終端顯示的IFC數據，圖13為現實的非結構化數據。

圖12 Web終端顯示的IFC數據

圖13 Web終端顯示的非結構化數據

5 結 語

大數據技術的出現為建筑信息模型海量數據的存儲、交互、管理和分析帶來了極大的潛力。本研究分析了大數據技術與BIM技術相結合的優勢，深入探討了分布式大數據平臺Hadoop和HBase整體架構和存儲模型；創建了基于HBase數據庫存儲IFC結構化數據和非結構化數據的策略及數據表格的設計；建立了基于HBase數據庫的建筑信息模型存儲系統，實現了對BIM數據的基本管理操作，并通過實例驗證了該系統的可行性。本研究為下一步基于分布式大數據環境的BIM模型可視化和工程項目的大數據分析，提供了堅實的數據平臺。