基于大數(shù)據(jù)技術(shù)系統(tǒng)架構(gòu)應(yīng)用探討

周維琴，趙文博，李 峰，李錄兵，寧 瑩

（中國石油長慶油田分公司第三采油廠，寧夏銀川 750006）

1 信息系統(tǒng)應(yīng)用現(xiàn)狀

截至2017年，長慶油田采油三廠與生產(chǎn)管理有關(guān)的系統(tǒng)共有20套，其中統(tǒng)建8套，自建12套，經(jīng)營管理類共7套系統(tǒng)，統(tǒng)建6套，自建1套，這些系統(tǒng)都為獨立運行的系統(tǒng)，應(yīng)用程序之間不能共享數(shù)據(jù)，相互之間都沒有提供一套標準及統(tǒng)一的接口獲取該系統(tǒng)數(shù)據(jù)的方法。目前該廠使用的系統(tǒng)除了SCADA系統(tǒng)使用實時數(shù)據(jù)庫外，其余系統(tǒng)都是基于關(guān)系數(shù)據(jù)庫開發(fā)的，主要有mysql、sqlserver、oracle。關(guān)系型數(shù)據(jù)庫要建立索引，支持對數(shù)據(jù)的篩選和排序等操作，主要是發(fā)現(xiàn)和整理數(shù)據(jù)之間的關(guān)系，通過對數(shù)據(jù)關(guān)系的分析得到一個統(tǒng)計意義的結(jié)論。那么關(guān)系型數(shù)據(jù)庫的特點決定了它不可能在讀寫性能上要求很高。

油田企業(yè)隨著數(shù)字化的全覆蓋，信息化水平的提升，生產(chǎn)業(yè)務(wù)系統(tǒng)越來越多，同時隨著SCADA系統(tǒng)的應(yīng)用，生產(chǎn)現(xiàn)場近90%的生產(chǎn)過程數(shù)據(jù)實現(xiàn)了在線監(jiān)控以及歷史存儲，與此同時也導(dǎo)致數(shù)據(jù)的幾何倍數(shù)的增長，數(shù)據(jù)在急劇膨脹的過程中，數(shù)據(jù)庫的優(yōu)缺點就會體現(xiàn)出來。

2 系統(tǒng)架構(gòu)與應(yīng)用問題分析

采油三廠目前數(shù)字化油井5900口，水井2230口，站點330座，油井數(shù)據(jù)采集頻率是10分鐘，其他數(shù)據(jù)都是1秒，一天共采集大概316800000條記錄。生產(chǎn)現(xiàn)場數(shù)據(jù)采集存儲都是基于SCADA系統(tǒng)實時數(shù)據(jù)庫技術(shù)，整個系統(tǒng)架構(gòu)主要包括采集層、存儲層、應(yīng)用層（見圖1）。

目前一天3.1億條數(shù)據(jù)，一個月可產(chǎn)生200 G的數(shù)據(jù)量，一年可產(chǎn)生2 T的數(shù)據(jù)量，如果要存儲歷史數(shù)據(jù)就需要提供存儲空間更大的設(shè)備。隨著歷史數(shù)據(jù)的增多、數(shù)字化深度應(yīng)用需求的增加，需面對三大問題：（1）海量數(shù)據(jù)高效；（2）海量數(shù)據(jù)快速檢索；（3）海量數(shù)據(jù)挖掘應(yīng)用。

圖1 SCADA系統(tǒng)架構(gòu)

2.1 油井采集數(shù)據(jù)處理流程及存在問題分析

油井采集數(shù)據(jù)流轉(zhuǎn)至最終用戶可視經(jīng)過7個環(huán)節(jié)（見圖2），每個環(huán)節(jié)的不穩(wěn)定都會影響整體系統(tǒng)功能，隨著數(shù)據(jù)采集存儲量的增加，數(shù)據(jù)存儲環(huán)節(jié)的問題逐漸凸顯，出現(xiàn)數(shù)據(jù)庫卡死，軟件卡死，數(shù)據(jù)實時分析處理速度變慢等情況，特別是ECHOMS_CQ數(shù)據(jù)庫，當數(shù)據(jù)量增多的時候，容易引起KH2SQL軟件卡死，功圖分析客戶端程序分析數(shù)據(jù)速度慢，卡死等情況。

本架構(gòu)使用數(shù)據(jù)庫管理系統(tǒng)是關(guān)系數(shù)據(jù)庫MS Sqlserver2005，針對油井數(shù)據(jù)轉(zhuǎn)存庫ECHOMS_CQ進行分析，本數(shù)據(jù)庫中只有一張表2071表，主要用于存儲功圖數(shù)據(jù)，電參數(shù)據(jù)，表功能只用于讀寫而非計算統(tǒng)計等，數(shù)據(jù)表現(xiàn)形式跟文檔相似，而且該庫不存在表間任何關(guān)系，同時關(guān)系數(shù)據(jù)庫隨著數(shù)據(jù)量的增加，頻繁寫入數(shù)據(jù)就會導(dǎo)致數(shù)據(jù)的邏輯存儲分頁越多，則會大大提升數(shù)據(jù)庫IO消耗，造成性能下降。因此該數(shù)據(jù)不適合用關(guān)系數(shù)據(jù)庫管理，而適合用文檔數(shù)據(jù)庫管理——MongoDB數(shù)據(jù)庫。MongoDB是一個基于分布式文件存儲的數(shù)據(jù)庫。主要解決的是海量數(shù)據(jù)的訪問效率問題，為WEB應(yīng)用提供可擴展的高性能數(shù)據(jù)存儲解決方案。當數(shù)據(jù)量達到50 GB以上的時候，MongoDB的數(shù)據(jù)庫訪問速度是MySQL的10倍以上，每秒可以處理0.5萬～1.5萬次讀寫請求，并且MongoDB非常適合實時的插入，更新與查詢，并具備實時數(shù)據(jù)存儲所需的復(fù)制及高度伸縮性，可以支持海量的數(shù)據(jù)存儲。

2.2 站點采集數(shù)據(jù)處理流程及存在問題分析

SCADA數(shù)據(jù)采集流程主要是從前端現(xiàn)場設(shè)備采集數(shù)據(jù)由SCADA IO Server進行采集，然后實時轉(zhuǎn)存到SCADA工業(yè)庫中，然后通過SCADA腳本程序生成報警記錄數(shù)據(jù)，報表計算數(shù)據(jù)，系統(tǒng)操作日志數(shù)據(jù)存入關(guān)系數(shù)據(jù)庫MySQL數(shù)據(jù)庫中，整個流程（見圖3）。

圖2 油井數(shù)據(jù)處理流程

圖3 站點采集數(shù)據(jù)處理流程

當站點報警數(shù)據(jù)存儲比較多，報表處理功能比較復(fù)雜時SCADA站控平臺反應(yīng)就會變慢，目前為了確保SCADA站控平臺運行的高效穩(wěn)定，站控管理人員定期從MySQL數(shù)據(jù)庫中刪除報警數(shù)據(jù)并重新建立索引，報表只是部分數(shù)據(jù)的簡單統(tǒng)計顯示，整個數(shù)據(jù)處理過程比較簡單，對于應(yīng)用需求的滿足還有一定的差距，特別是報警準確率及報表功能還不能達標，主要由于整個SCADA架構(gòu)對于實時數(shù)據(jù)計算分析處理功能比較薄弱。

隨著數(shù)字化技術(shù)的深度應(yīng)用，對于實時、歷史數(shù)據(jù)的分析挖掘必然成為趨勢，包括管線運行情況的監(jiān)控、預(yù)警分析，油水井生產(chǎn)運行情況分析，上下游相關(guān)數(shù)據(jù)級聯(lián)分析調(diào)控站點平穩(wěn)運行，生產(chǎn)運行趨勢分析、異常分析，報表統(tǒng)計分析等，依據(jù)目前的系統(tǒng)架構(gòu)滿足不了這些應(yīng)用需求，借助大數(shù)據(jù)技術(shù)架構(gòu)平臺可以很好的解決上述問題，實現(xiàn)采集數(shù)據(jù)的大容量存儲和實時分析處理，針對實時數(shù)據(jù)流的分析可以采用Storm計算技術(shù)完成所需功能。使用Storm技術(shù)實現(xiàn)實時大數(shù)據(jù)分析，Storm是個實時的、分布式以及具備高容錯的計算系統(tǒng)。同Hadoop一樣Storm也可以處理大批量的數(shù)據(jù)，然而Storm在保證高可靠性的前提下還可以讓處理進行的更加實時。Storm業(yè)務(wù)主線是信息流處理，連續(xù)計算，分布式程序遠程調(diào)用。大數(shù)據(jù)處理架構(gòu)（見圖4）。數(shù)據(jù)源除了實時數(shù)據(jù)庫外，引入消息隊列，可以把數(shù)據(jù)臨時存儲在消息隊列中，后端處理速度就不會影響前端業(yè)務(wù)數(shù)據(jù)的產(chǎn)生。

3 基于大數(shù)據(jù)技術(shù)系統(tǒng)架構(gòu)探討

大數(shù)據(jù)指的是海量無法通過傳統(tǒng)方式管理的數(shù)據(jù)?；ヂ?lián)網(wǎng)范圍的數(shù)據(jù)正在推動能夠處理這類新數(shù)據(jù)的新架構(gòu)和應(yīng)用程序的創(chuàng)建。這些架構(gòu)高度可擴展，且能夠跨無限多的服務(wù)器并行、高效地處理數(shù)據(jù)。目前應(yīng)用比較廣泛的大數(shù)據(jù)架構(gòu)平臺有三個：Hadoop架構(gòu)平臺，Spark架構(gòu)平臺，Storm架構(gòu)平臺。Hadoop是一個開源+分布式存儲+分布式計算平臺，實現(xiàn)了MapReduce的思想，將數(shù)據(jù)切片計算來處理大量的離線數(shù)據(jù)，處理的數(shù)據(jù)必須是已經(jīng)存放在HDFS上或者類似Hbase的數(shù)據(jù)庫中，適用于海量數(shù)據(jù)的離線分析處理。Spark是在Hadoop的基礎(chǔ)上進行了一些架構(gòu)的改良，Hadoop使用硬盤來存儲數(shù)據(jù)，Spark使用內(nèi)存來存儲數(shù)據(jù)，可以提供超過Hadoop100倍的運算速度，由于內(nèi)存斷電后會丟失數(shù)據(jù)，因此不能處理需要長期保存的數(shù)據(jù)。Storm在Hadoop的基礎(chǔ)上提供了實時運算的特性，可以實時的處理大數(shù)據(jù)流，它不進行數(shù)據(jù)的收集和存儲工作，直接通過網(wǎng)絡(luò)實時的接受數(shù)據(jù)并且實時的處理數(shù)據(jù)，然后直接通過網(wǎng)絡(luò)實時的傳回結(jié)果。

3.1 大數(shù)據(jù)架構(gòu)平臺技術(shù)分析

大數(shù)據(jù)架構(gòu)主要是針對一個集群而言，通過集群才能體現(xiàn)出大數(shù)據(jù)架構(gòu)應(yīng)用的優(yōu)勢，一個大數(shù)據(jù)架構(gòu)平臺是多項新技術(shù)應(yīng)用的組合，技術(shù)比較全面的架構(gòu)平臺（見圖5）。底層主要是HDFS（分布式文件系統(tǒng)）的應(yīng)用，統(tǒng)一管理分布在集群上的文件系統(tǒng)，提供了一個高度容錯性和高吞吐量的海量數(shù)據(jù)存儲解決方案。YARN（Yet Another Resource Negotiator另一種資源協(xié)調(diào)者，也就是群集資源管理系統(tǒng)），可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。

圖4 大數(shù)據(jù)處理架構(gòu)

MapReduce分布式離線計算框架：MapReduce采用“分而治之”的思想，把對大規(guī)模數(shù)據(jù)集的操作，分發(fā)給一個主節(jié)點管理下的各個分節(jié)點共同完成，然后通過整合各個節(jié)點的中間結(jié)果，得到最終結(jié)果[1]。Tez DAG計算框架：是基于Hadoop Yarn之上的DAG（有向無環(huán)圖，Directed Acyclic Graph）計算框架，它把MapReduce過程拆分成若干個子過程，同時可以把多個Map-Reduce任務(wù)組合成一個較大的DAG任務(wù)，減少了MapReduce之間的文件存儲，同時合理組合其子過程，也可以減少任務(wù)的運行時間[2]。Storm（流式計算框架）：是一個免費開源、分布式、高容錯的實時計算系統(tǒng)。Storm令持續(xù)不斷的流計算變得容易，彌補了Hadoop批處理所不能滿足的實時要求。

Flume（日志收集工具）：是一個分布式、可靠和高可用的海量日志聚合的系統(tǒng)，支持在系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，F(xiàn)lume提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力[3]。Sqoop（數(shù)據(jù)庫ETL工具）：Sqoop是一個用來將Hadoop和關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)相互轉(zhuǎn)移的工具，可以將一個關(guān)系型數(shù)據(jù)庫（例如：MySQL、Oracle、Postgres等）中的數(shù)據(jù)導(dǎo)進到Hadoop的HDFS中，也可以將HDFS的數(shù)據(jù)導(dǎo)進到關(guān)系型數(shù)據(jù)庫中[4]。

Hive是基于Hadoop的一個數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供完整的SQL查詢功能，可以將SQL語句轉(zhuǎn)換為Map-Reduce任務(wù)進行運行。其優(yōu)點是學(xué)習成本低，可以通過類SQL語句快速實現(xiàn)簡單的MapReduce統(tǒng)計，不必開發(fā)專門的MapReduce應(yīng)用，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。Pig（數(shù)據(jù)流處理）：Hadoop上的數(shù)據(jù)流執(zhí)行引擎，利用HDFS存儲數(shù)據(jù)，利用MapReduce處理數(shù)據(jù)。Mahout（數(shù)據(jù)挖掘庫）：是Apache基金支持的頂級項目，其目標在于建立可伸縮的用于機器學(xué)習算法庫。Mahout支持數(shù)據(jù)挖掘的三個領(lǐng)域：（1）Recommendation mining，推薦引擎（協(xié)同過濾）；（2）Clustering，聚類；（3）Classification，分類。HBase（實時分布式數(shù)據(jù)庫）：是建立在HDFS之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的分布式列存儲的開源數(shù)據(jù)庫系統(tǒng)。HBase中每張表的記錄數(shù)（行數(shù)）可多達幾十億條，甚至更多，每條記錄可以擁有多達上百萬的字段。而這樣的存儲能力卻不需要特別的硬件，普通的服務(wù)器集群就可以勝任。

Zookeeper（分布式協(xié)作服務(wù)）：是一個用于分布式應(yīng)用程序的分布式開源協(xié)調(diào)服務(wù)。它使用一組簡單的操作原語，使得分布式應(yīng)用可以實現(xiàn)更高層次的服務(wù)—如同步、配置維護、群組和命名管理等。它以易于編程為基本設(shè)計理念，并使用了一個類似于文件系統(tǒng)目錄結(jié)構(gòu)風格的數(shù)據(jù)模型[5]。

3.2 基于大數(shù)據(jù)應(yīng)用的數(shù)據(jù)標準化建設(shè)

目前應(yīng)用系統(tǒng)多而雜，每套系統(tǒng)數(shù)據(jù)相互獨立，存在數(shù)據(jù)格式不統(tǒng)一，數(shù)據(jù)建設(shè)不規(guī)范、數(shù)據(jù)字典不標準等問題，嚴重阻礙了數(shù)據(jù)在各部門和各軟件系統(tǒng)中的流動和共享，導(dǎo)致重復(fù)投資建設(shè)和信息資源浪費，降低采集、處理數(shù)據(jù)的成本、增加數(shù)據(jù)錄入的工作量。以大數(shù)據(jù)應(yīng)用為方向，建立數(shù)據(jù)倉庫，最終實現(xiàn)信息的全面性和數(shù)據(jù)的規(guī)范性、數(shù)據(jù)字典的統(tǒng)一性、數(shù)據(jù)建設(shè)的標準化。在統(tǒng)一數(shù)據(jù)源的過程中，主要包括三個步驟，第一數(shù)據(jù)抽取，把不同數(shù)據(jù)源的數(shù)據(jù)統(tǒng)一采集到一個平臺；第二數(shù)據(jù)轉(zhuǎn)化，當要實現(xiàn)某類業(yè)務(wù)需求時，將從原數(shù)據(jù)源獲取的數(shù)據(jù)按照業(yè)務(wù)需求，轉(zhuǎn)換成目的數(shù)據(jù)源要求的形式；第三數(shù)據(jù)清洗，清洗不符合質(zhì)量要求的數(shù)據(jù)，避免臟數(shù)據(jù)參與后續(xù)數(shù)據(jù)計算。

圖5 大數(shù)據(jù)技術(shù)應(yīng)用架構(gòu)

4 認識與結(jié)論

大數(shù)據(jù)應(yīng)用技術(shù)是未來企業(yè)競爭力的關(guān)鍵，油田企業(yè)隨著數(shù)字化建設(shè)應(yīng)用的深度擴展和發(fā)展戰(zhàn)略的改變，大數(shù)據(jù)技術(shù)應(yīng)用是發(fā)展必然趨勢，但是目前面對大數(shù)據(jù)技術(shù)的應(yīng)用還有諸多難題：首先目前使用的大多數(shù)系統(tǒng)為統(tǒng)推系統(tǒng)，底層數(shù)據(jù)庫復(fù)雜度較高，而且不開放，在利用數(shù)據(jù)上存在數(shù)據(jù)提取難度高，整合困難等問題。其次目前應(yīng)用的業(yè)務(wù)系統(tǒng)架構(gòu)已經(jīng)成型，如果要升級改變架構(gòu)，或更換數(shù)據(jù)庫等，需要對業(yè)務(wù)系統(tǒng)的邏輯層編寫代碼進行修改實現(xiàn)其功能，由于技術(shù)的更新，原參與開發(fā)技術(shù)人員的流動等問題造成升級的困難。再次大數(shù)據(jù)的架構(gòu)反映出它的復(fù)雜性，大數(shù)據(jù)不是一個單獨的產(chǎn)品或技術(shù)，而是眾多技術(shù)的整合，傳統(tǒng)企業(yè)幾乎不可能獨立進行大數(shù)據(jù)項目的建設(shè)，這不僅僅是資金投入的問題，主要是專業(yè)技術(shù)人員的缺失。作為廠級企業(yè)今后在數(shù)據(jù)、信息化系統(tǒng)建設(shè)方面必須要做到以下幾點：架構(gòu)設(shè)計不能以實現(xiàn)當前需求功能為目標，要充分考慮系統(tǒng)架構(gòu)的后續(xù)可擴展性和可伸縮性，同時要考慮系統(tǒng)的處理能力在一定的時間內(nèi)能夠滿足業(yè)務(wù)增長帶來的處理能力增長的需要。數(shù)據(jù)庫設(shè)計一定要遵從標準化和規(guī)范化設(shè)計原則，同時根據(jù)數(shù)據(jù)類型、事務(wù)類型、數(shù)據(jù)讀寫頻率等選用最適合的數(shù)據(jù)庫。大數(shù)據(jù)技術(shù)是數(shù)據(jù)應(yīng)用的趨勢，但目前情況距應(yīng)用此技術(shù)仍有距離，應(yīng)該選一專業(yè)化比較強的技術(shù)團隊進行探討，以需求結(jié)合實際應(yīng)用為原則，探討構(gòu)建大數(shù)據(jù)分析平臺的適宜性和必要性。