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

楊 科 唐朝國(guó) 袁 焦 伏 坤 鄒文露

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

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

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

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

1 現(xiàn)狀分析

1.1 電子施工日志和EBS

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

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

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

1.2 分布式系統(tǒng)

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

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

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

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

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

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

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

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

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

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

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

2.2.1購(gòu)物籃化過程

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

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

圖1 購(gòu)物籃化現(xiàn)場(chǎng)數(shù)據(jù)MapReduce流程圖

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

2.2.2初始化頻繁1-項(xiàng)集過程

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

圖2 生成頻繁1-項(xiàng)集MapReduce流程圖

2.2.3生成候選k-項(xiàng)集過程

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

圖3 生成候選k-項(xiàng)集流程圖

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

2.2.4生成頻繁k-項(xiàng)集過程

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

圖4 生成頻繁k-項(xiàng)集MapReduce流程圖

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

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

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

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

3 分析結(jié)果

3.1 模型好壞的評(píng)價(jià)指標(biāo)的制定

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

3.2 實(shí)驗(yàn)結(jié)果

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

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

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

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

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

4 結(jié)束語(yǔ)

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