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

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

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

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

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

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

2 系統(tǒng)架構與應用問題分析

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

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

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

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

油井采集數(shù)據(jù)流轉至最終用戶可視經(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ù)速度慢，卡死等情況。

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

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

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

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

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

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

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

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

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

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

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

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

MapReduce分布式離線計算框架：MapReduce采用“分而治之”的思想，把對大規(guī)模數(shù)據(jù)集的操作，分發(fā)給一個主節(jié)點管理下的各個分節(jié)點共同完成，然后通過整合各個節(jié)點的中間結果，得到最終結果[1]。Tez DAG計算框架：是基于Hadoop Yarn之上的DAG（有向無環(huán)圖，Directed Acyclic Graph）計算框架，它把MapReduce過程拆分成若干個子過程，同時可以把多個Map-Reduce任務組合成一個較大的DAG任務，減少了MapReduce之間的文件存儲，同時合理組合其子過程，也可以減少任務的運行時間[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和關系型數(shù)據(jù)庫中的數(shù)據(jù)相互轉移的工具，可以將一個關系型數(shù)據(jù)庫（例如：MySQL、Oracle、Postgres等）中的數(shù)據(jù)導進到Hadoop的HDFS中，也可以將HDFS的數(shù)據(jù)導進到關系型數(shù)據(jù)庫中[4]。

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

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

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

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

圖5 大數(shù)據(jù)技術應用架構

4 認識與結論

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