基于分布式計算模型的施工工序關(guān)聯(lián)分析

楊 科 唐朝國 袁 焦 伏 坤 鄒文露

(中鐵二院工程集團(tuán)有限責(zé)任公司， 成都 610031)

在鐵路工程建設(shè)期間，施工質(zhì)量問題時有發(fā)生，分析這類問題發(fā)現(xiàn)，其中相當(dāng)一部分問題是由施工工序安排不當(dāng)造成的。其原因在于施工安排在很大程度上依賴于現(xiàn)場管理人員的知識和經(jīng)驗，人為因素影響較大，在進(jìn)度壓力下，往往易忽視施工工序的規(guī)律性。

施工工序為鐵路工程風(fēng)險管理提供了基礎(chǔ)支撐，是定位風(fēng)險事件的最小單位，尋找工序之間的邏輯關(guān)系，再根據(jù)現(xiàn)場實際選擇合理的工序安排，能幫助現(xiàn)場施工人員緩解和預(yù)防風(fēng)險的發(fā)生[1]。

施工工序的安排具備客觀性，若能通過分析現(xiàn)場施工數(shù)據(jù)，找到工序之間的規(guī)律，勢必能夠改善風(fēng)險控制、成本監(jiān)控、進(jìn)度管理等過程。隨著鐵路工程電子施工日志在全國鐵路建設(shè)項目中的普及，施工現(xiàn)場數(shù)據(jù)逐漸被統(tǒng)一、規(guī)范，為上述問題的解決提供了數(shù)據(jù)基礎(chǔ)。本文將利用分布式計算框架，借助鐵路工程實體分解結(jié)構(gòu)(EBS)[2]，從海量施工日志數(shù)據(jù)中尋找鐵路工程施工工序之間的規(guī)律。

1 現(xiàn)狀分析

1.1 電子施工日志和EBS

電子施工日志系統(tǒng)利用信息化的方式將以往紙質(zhì)的施工日志統(tǒng)一規(guī)劃，將施工現(xiàn)場的技術(shù)情況、安全檢查情況、質(zhì)量檢查情況等管理起來，以桌面應(yīng)用、移動應(yīng)用的方式呈現(xiàn)，方便現(xiàn)場用戶進(jìn)行填報。

EBS是鐵路工程實體分解結(jié)構(gòu)的縮寫，由中國鐵路BIM聯(lián)盟于2014年發(fā)布。不同于基于工作分解結(jié)構(gòu)(WBS)[3]，EBS結(jié)構(gòu)按照專業(yè)將工程系統(tǒng)分解為樹形結(jié)構(gòu)，更滿足工程系統(tǒng)的特點，更利于鐵路工程管理。電子施工日志提供的數(shù)據(jù)采集功能就是以EBS為紐帶串聯(lián)起來。橋涵專業(yè)的部分EBS項如表1所示。

表1 橋涵專業(yè)部分EBS項列表

1.2 分布式系統(tǒng)

作為一款采集現(xiàn)場數(shù)據(jù)的信息系統(tǒng)，施工日志具備面向事務(wù)系統(tǒng)(OLTP)的所有特征，其數(shù)據(jù)通過關(guān)系型數(shù)據(jù)庫進(jìn)行存儲，根據(jù)業(yè)務(wù)的不同，將數(shù)據(jù)分散到不同的數(shù)據(jù)表中。采集端在確認(rèn)用戶信息后，在本地將用戶每日填報的現(xiàn)場環(huán)境、施工進(jìn)度、材料使用情況、人員投入情況等打包上傳，通過互聯(lián)網(wǎng)集中傳輸?shù)綉?yīng)用服務(wù)器，并最終進(jìn)入到數(shù)據(jù)庫中。這樣的方式可使業(yè)務(wù)系統(tǒng)快速響應(yīng)各個增刪查改的需求，但面對耗時、海量查詢的統(tǒng)計分析需求時，就顯得力不從心，強(qiáng)行在OLTP系統(tǒng)上執(zhí)行統(tǒng)計分析，反而會使業(yè)務(wù)的處理率下降，甚至造成數(shù)據(jù)丟失，嚴(yán)重影響系統(tǒng)的推廣使用。

目前，已有很多研究對鐵路工程的“大數(shù)據(jù)”統(tǒng)計分析進(jìn)行了實施和應(yīng)用[4]。隨著分布式系統(tǒng)逐步成為大數(shù)據(jù)的核心技術(shù)，以Hadoop生態(tài)圈為代表的平臺將為工程的建設(shè)業(yè)務(wù)提供解決方案，為項目的成功落地提供技術(shù)保障[5]。

1.3 關(guān)聯(lián)分析和R語言

關(guān)聯(lián)分析是數(shù)據(jù)挖掘的一種主要方法，用于查找隱藏在數(shù)據(jù)集合中的頻繁模式，即集合中各項之間存在的關(guān)聯(lián)規(guī)則。利用支持度和置信度兩個指標(biāo)來保證找到有意義的規(guī)則，避免某些偶爾出現(xiàn)規(guī)則對于整個模型的影響。Apriori算法是關(guān)聯(lián)分析的常用算法，解決了很多潛在頻繁模式的挖掘問題(如經(jīng)典的“啤酒尿布”案例等)。

R語言是一門用于統(tǒng)計分析的編程語言和開發(fā)環(huán)境，包括了豐富的統(tǒng)計算法和制圖函數(shù)，更加貼近統(tǒng)計學(xué)家的使用習(xí)慣，在大數(shù)據(jù)前沿科學(xué)的研究中使用更加廣泛。如RHadoop[6]利用MapRecude[7]API集成了常用的R函數(shù)，使數(shù)據(jù)分析人員能夠利用R語言進(jìn)行HDFS、HBase的連接和訪問，再配合R語言強(qiáng)大的數(shù)據(jù)分析能力，快速實現(xiàn)分析目標(biāo)。但這類軟件也存在缺點，如RHadoop對于數(shù)據(jù)庫的支持就較弱，沒有API直接訪問Hive，通過RJDBC訪問需對數(shù)據(jù)進(jìn)行轉(zhuǎn)換，比較耗能。

1.4 施工工序的關(guān)聯(lián)分析

施工工序是項目管理的基礎(chǔ)，要實施施工組織管理信息系統(tǒng)，就需建立可靠的施工工序活動。傳統(tǒng)常利用需求工程方法，從現(xiàn)場環(huán)境、人員、設(shè)備、材料到場情況等維度，向項目管理人員、施工技術(shù)人員收集原始信息，依靠他們的豐富經(jīng)驗和知識來保證系統(tǒng)的可靠性。但從信息系統(tǒng)的角度來看，領(lǐng)域知識的獲取最為困難，易導(dǎo)致后期模型的不確定性。另一個方法是依賴現(xiàn)場數(shù)據(jù)，從實際工作中尋找客觀規(guī)律。施工日志為我們提供了數(shù)據(jù)來源，但面對海量的數(shù)據(jù)，傳統(tǒng)的分析方法在時間耗費、資源占用上都已滿足不了實際需要。面對用戶需求和分析方法的矛盾，采用分布式架構(gòu)，解決數(shù)據(jù)的大容量可靠存儲以及分析的并行計算，勢必會成為施工日志數(shù)據(jù)向應(yīng)用轉(zhuǎn)換的唯一途徑。

2 關(guān)聯(lián)模式分析

2.1 數(shù)據(jù)及數(shù)據(jù)模式

要構(gòu)建海量數(shù)據(jù)基礎(chǔ)上的關(guān)聯(lián)分析，必須首先分析現(xiàn)有數(shù)據(jù)的內(nèi)在關(guān)系，構(gòu)建穩(wěn)定、成熟的數(shù)據(jù)模式。在施工日志中，工序相關(guān)的數(shù)據(jù)分散在多張數(shù)據(jù)表中，具備典型的多維數(shù)據(jù)特點。為便于分析，且保證分析過程不影響業(yè)務(wù)系統(tǒng)的正常運行，需對多維數(shù)據(jù)進(jìn)行抽取、轉(zhuǎn)換和加載(ETL過程)，最終進(jìn)入分布式存儲系統(tǒng)之中。

具體而言就是將多源數(shù)據(jù)平面化，這些平面化數(shù)據(jù)稱為“現(xiàn)場數(shù)據(jù)”(如表2所示)，數(shù)量已達(dá)到億級，需要借助Sqoop工具，用命令行的方式執(zhí)行相關(guān)SQL并導(dǎo)入HDFS。根據(jù)不同的分析維度(如每天、每周、每月等)，靈活地執(zhí)行不同的SQL語句，抽取相應(yīng)的數(shù)據(jù)結(jié)果。

表2 數(shù)據(jù)分析原始數(shù)據(jù)表

2.2 關(guān)聯(lián)分析的分布式設(shè)計

R語言在Hadoop上已有成熟的應(yīng)用，統(tǒng)計分析人員也更習(xí)慣于采用RHadoop進(jìn)行數(shù)據(jù)分析，雖然已有其他編程語言(平臺)實現(xiàn)甚至改進(jìn)了分布式系統(tǒng)上的關(guān)聯(lián)分析算法[8]，但可惜的是R語言提供的arule包的對應(yīng)算法并不支持分布式計算，在面對海量數(shù)據(jù)時，無法保證處理效率。因此需尋求一種基于MapReduce模型的算法來支持大數(shù)據(jù)的分析計算。

2.2.1購物籃化過程

Apriori所需的事務(wù)數(shù)據(jù)集以某一屬性為維度，聚合該維度下的數(shù)據(jù)。現(xiàn)場數(shù)據(jù)是每日施工情況的流水賬，應(yīng)當(dāng)以“工點”+“日期”為維度，聚合多道工序，該過程可稱為“購物籃化”。其數(shù)據(jù)結(jié)構(gòu)如表3所示，分布式流程如圖1所示。

表3 事務(wù)數(shù)據(jù)集(購物籃化)表

圖1 購物籃化現(xiàn)場數(shù)據(jù)MapReduce流程圖

輸入數(shù)據(jù)是平面化的數(shù)據(jù)，每一行包含一組施工信息，處理邏輯可分為兩個子流程。首先是將同一天、同一工點的數(shù)據(jù)找出來的分組邏輯，然后是將同一分組內(nèi)的工序(EBS編碼)拼接并以逗號分隔的合并邏輯，最終輸出到HDFS之中。對應(yīng)到RHadoop的相關(guān)開發(fā)包，需在Map任務(wù)實現(xiàn)第一個子流程，在Reduce任務(wù)實現(xiàn)第二個子流程。鑒于第一個子流程產(chǎn)生的中間結(jié)果比較龐大，利用RHadoop提供的Combine任務(wù)，可對結(jié)果進(jìn)行合并，只需實現(xiàn)和Reduce的相同邏輯，即可減輕網(wǎng)絡(luò)負(fù)載，減小Reduce任務(wù)執(zhí)行期壓力。Reduce任務(wù)還可過濾聚合后只有一道工序的記錄，降低下一過程的計算量。

2.2.2初始化頻繁1-項集過程

頻繁1-項集是從購物籃化的數(shù)據(jù)中，抽取只包含1條EBS編碼的作為項。該過程需從購物籃化后的數(shù)據(jù)中生成，由于數(shù)據(jù)量預(yù)期都會很大，因此還需借助MapReduce來實現(xiàn)。其具體流程如圖2所示。

圖2 生成頻繁1-項集MapReduce流程圖

2.2.3生成候選k-項集過程

該過程在一個循環(huán)體中。候選項集的生成有很多種算法，主流的算法是對頻繁(k-1)-項集自身做組合，生成候選k-項集。一個專業(yè)的EBS編碼大概在 1 000～20 000區(qū)間內(nèi)，組合以后滿足支持度閾值的更少，因此該過程可在內(nèi)存中進(jìn)行計算，以提高整體分析的速度。候選集的算法過程如圖3所示。

圖3 生成候選k-項集流程圖

圖3是一個頻繁3-項集生成候選4-項集的過程，A-E代表了1條EBS編碼，由于BC、CE開頭的只有一項，根據(jù)Apriori定理，不會產(chǎn)生頻繁項，因此直接淘汰，從ABC、ABD、ABE中生成。

2.2.4生成頻繁k-項集過程

該過程和上一個過程在同一個循環(huán)體內(nèi)，利用上一過程產(chǎn)生的候選k-項集，在購物籃中遍歷查找是否存在這樣的項，找到1次計數(shù)加1。當(dāng)數(shù)據(jù)量較大時，在購物籃中遍歷查找也是一個非常消耗性能的操作，必須把該過程放到Map中，實現(xiàn)數(shù)據(jù)的分而治之，隨著Map計算節(jié)點的增加，遍歷的時間會得到有效的控制。其具體流程如圖4所示。

圖4 生成頻繁k-項集MapReduce流程圖

每次循環(huán)產(chǎn)生的頻繁k-項集加入到頻繁項集集合F中，若沒有產(chǎn)生頻繁k-項集，則終止循環(huán)體。

2.2.5從頻繁項集生成關(guān)聯(lián)規(guī)則

從尋找工序間的關(guān)聯(lián)關(guān)系而言，頻繁項集F已經(jīng)夠用，但從尋找工序的規(guī)則而言，還需對頻繁項集F進(jìn)一步加工，該過程在內(nèi)存中進(jìn)行計算。

規(guī)則的生成依賴于置信度，以頻繁項集t：{0301010101010108，03030101010102，030301010211}為例，其有6個規(guī)則，如{0301010101010108}→{03030101010102，030301010211}、{03030101010102}→{0301010101010108，030301010211}、{03030101010102，030301010211} → {0301010101010108}等作為候選，表示為{Left}→{Right}，通過在頻繁項集集合F中計算該頻繁項集支持度δ(t)與箭頭左邊的項集支持度δ(Left)的商，即得到confidence(Left→Right)。無論{Left}還是t肯定存在于F中，支持度已知，整個計算過程并不會消耗太多資源。

3 分析結(jié)果

3.1 模型好壞的評價指標(biāo)的制定

從上述的設(shè)計、實現(xiàn)過程可知，施工工序的關(guān)聯(lián)分析依賴于“支持度閾值”的制定。“支持度閾值”是整個分析的關(guān)鍵指標(biāo)，該指標(biāo)決定了模型的好壞以及計算的時間、空間復(fù)雜度。因此，采用均衡計算量+用戶評價的方式，先實驗一個較低的支持度閾值(如0.55)，將獲取到的規(guī)則交給現(xiàn)場施工人員、技術(shù)專家評價，再增大或降低支持度閾值[9]，力求達(dá)到計算量與可信模型之間的平衡。

3.2 實驗結(jié)果

本文通過分析百萬級橋涵專業(yè)施工日志的數(shù)據(jù)，得到實驗結(jié)果如表4所示。

表4 橋涵專業(yè)工序頻繁集表(百萬級)

根據(jù)EBS代碼反查工序名稱，發(fā)現(xiàn)橋墩地基承臺的“混凝土”和“鋼筋”頻繁出現(xiàn)在施工工序安排中，這與施工現(xiàn)場的實際情況相吻合。利用同樣的算法，再選取施工日志填報優(yōu)秀的橋涵工點進(jìn)行分析，獲取更加精準(zhǔn)的實驗結(jié)果，如表5所示。

表5 橋涵專業(yè)工序頻繁集表(十萬級)

根據(jù)EBS代碼反查可知，“預(yù)應(yīng)力混凝土簡支箱梁架設(shè)”與“球型鋼支座”的關(guān)聯(lián)程度較高，在日常工作安排中，可考慮兩者先后施工。

4 結(jié)束語

在調(diào)用傳統(tǒng)的R函數(shù)進(jìn)行關(guān)聯(lián)分析時，內(nèi)存占用會明顯增長，易導(dǎo)致整個分析系統(tǒng)崩潰。采用分布式的Apriori算法，在處理施工日志的海量數(shù)據(jù)時，內(nèi)存消耗低，且并行的處理方式也降低了分析時間。在此基礎(chǔ)上，本文分析了鐵路工程施工工序，獲得了現(xiàn)場工序安排的規(guī)律，為管理人員把握施工進(jìn)度、合理安排現(xiàn)場工作提供了一種智能化的解決方式。可以預(yù)見，隨著電子施工日志的逐步普及，越來越多的項目會采用電子日志進(jìn)行填報，未來的數(shù)據(jù)質(zhì)量、數(shù)量會進(jìn)一步增加，最終提高分析結(jié)果的精度和覆蓋范圍。