周維琴,趙文博,李 峰,李錄兵,寧 瑩
(中國石油長慶油田分公司第三采油廠,寧夏銀川 750006)
截至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)出來。
采油三廠目前數(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)
油井采集數(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ù)存儲。
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)生。
大數(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é)果。
大數(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]。
目前應(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)
大數(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ù)分析平臺的適宜性和必要性。