淺談石油行業開發生產數據集成架構設計

李婧璇

（中國石油大港油田信息中心，天津 300280）

1 數據集成架構研究背景

隨著專業研究不斷深入和信息技術快速發展，石油領域的企業往往存在多個涉及開發生產的業務系統。這些系統建設于企業發展的不同階段，針對不同的業務側重點進行開發，其中沉淀的大量數據足夠為主營業務的輔助決策提供可靠而豐富的數據支撐。然而，這些系統的底層數據存在如下問題。

（1）數據存儲問題：業務系統大多相互獨立，導致數據的存儲位置分散，難以實現數據集成。

（2）數據質量問題：缺乏有效的數據管理規劃和規范的標準流程，出現業務對象定義不一致、編碼格式不同、數據冗余或數據缺失、管理責任主體不明確等情況。此外，跨系統數據口徑不一致，使得數據關聯性無法保障。

（3）數據應用問題：從用戶提出需求一直到交付成果的過程中，存在數據源頭取數難，跨部門數據共享性差、時效性低等缺點，需要花費大量時間來打破壁壘。

這些問題都導致數據資源無法及時滿足業務人員的個性化分析需求，阻礙了企業智能化發展的進程。因此，如何對數據進行集中化、統一化、標準化的管理，并借助快速構建主題分析模型的手段，形成系統化的協同應用成為研究的方向。

2 生產數據集成架構開發

企業的發展除帶來規模的擴張，還必然伴隨著業務數據量的激增。為了管理好這些數據“金礦”，更好地針對用戶需求提供服務，企業就需要設計一套完善的數據集成架構，作為指導數據集成管理的基礎。數據集成架構的思路是：首先，根據實際業務場景需要進行數據集成，然后依托維度建模技術建立數據模型和數據倉庫，最后通過統一的數據服務管理支撐數據應用。文章以石油行業的開發生產數據為例進行說明，架構由底至頂依次包括5 個層級。

2.1 數據源層

在數據源層，企業需要基于現有的開發生產應用系統開展數據體系建設，這是為業務提供全面、穩定、高效的數據支撐的基礎。這個環節的主要工作是明確業務指標的數據來源，確保每個指標源頭的唯一性，同時盡可能全面覆蓋現有數據資源，將在用系統，尤其是高頻使用的系統數據都納入管理。

數據源層的構建主要考慮兩方面的因素：一是數據標準的相對獨立性，二是現有數據資源的集成性。目前，中石油的統建系統經過多年推廣和應用，已經具備相當豐富的數據資源，尤其是數據量大、采集頻度高的生產數據。因為基于這部分數據的日常應用較多，數據質量和及時性都有保障，所以幾乎不需要開展數據質量檢驗和數據整理方面的工作，就可以對其直接使用。另外，還存在部分企業自建的數據，如生產運行數據庫、工程基礎數據庫等，應用時也會涉及這些系統的部分數據，因此要納入數據源層的組織中。

2.2 數據集成層

數據集成層主要承擔數據ETL任務，負責從數據源層讀取數據，將數據本地化，并定期將相關數據加載到數據倉庫中。這個環節的主要工作是，基于用戶制定的規則，實現各類數據資源的數據識別、數據抽取、數據清洗、映射轉換、定時遷移及版本控制，從而達到整合來源于多個系統的業務數據的目的。其中涉及的幾個方面如下所述。

①數據識別是從數據源中獲取結構化、非結構化數據的組織方式的過程。②數據抽取是從數據源中抽取數據的過程，具體來說，就是全局搜索數據源，挑選其中符合標準的數據，并把這些數據傳送到目的文件中。③數據清洗需要針對“臟數據”的產生原因和存在形式進行分析，利用現有技術手段和方法來清洗“臟數據”，從而將原本不符合要求的數據轉化為滿足數據質量或應用要求的數據，達到提升數據質量的目的。數據清洗是數據集成層必不可少的一個環節，能夠防止無用數據占用存儲空間，進而優化數據架構。數據清洗通常由格式內容清洗、邏輯錯誤清洗、非需求數據清洗及關聯性驗證幾方面內容組成。④映射轉換主要指從一個數據庫將字段匹配到另一個數據庫，或將數據從源格式轉換為目標格式的過程。映射轉換中的一個錯誤可能引發連鎖反應，并且因重復的錯誤和不準確的分析造成企業損失。⑤定時遷移是指對系統之間批量移動數據的行為制訂時間計劃，按照周期自動執行數據遷移任務。⑥版本控制是指對ETL 過程中各種元數據、配置文件、說明文檔等文件變更的管理。ETL 環節的每一部分都要確定一個主版本號，以便當某天執行的版本有嚴重錯誤時，可以快速恢復到之前的一個正確版本。

2.3 數據倉庫層

數據倉庫的定義是，在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合。這里的數據倉庫層主要用于將開發生產指標按照不同業務主題進行劃分，通過維度與事實建模，快速搭建主題分析模型，從而建立起若干數據集市。具體地說，這個過程主要分為以下5 個步驟。

①明確數據分析主題。主題能夠體現出分析角度和統計數據之間的關系。它通常來源于相應的數據集市，如生產動態分析就是一個主題。②確定量度。根據分析主題選擇的統計指標即量度，通常取數值型數據。③確定最小數據粒度。由于量度在不同維度下的聚合程度不同，因此需采用“最小粒度原則”，將量度的數據粒度設置到最小，以便向上聚合匯總。④確定維度。維度是指不同的分析角度。基于不同的維度，可以考察各量度的匯總情況，也可以基于維度的組合進行交叉分析。對開發生產數據分析而言，常見的維度包括時間維度、井維度、單元維度、單位維度等。⑤創建事實表。將原始表與維度表相關聯，原始表包含量度數據，維度表包含維度代理鍵，根據主題建立事實表。事實表作為數據倉庫的核心，需要精心維護。當事實表的記錄數比較多時，可以為其設置復合主鍵和索引，以實現優化數據的完整性和基于數據倉庫的查詢性。

事實表與維度表共同存放于數據倉庫中，通過分析維度和指標量度的多種組合，就能滿足用戶多層次、多角度的數據分析需求。

2.4 數據處理層

數據處理層主要承擔數據計算任務，負責定時執行數據加工處理任務，完成相關數據處理和計算。如果前端提出連接數據倉庫的要求，還可以在該層建立一些中間匯總表或物化視圖，以便查詢。經過數據處理層的數據既能面向用戶、貼近業務，也能快速響應分析需求，直接用來進行服務開發。

2.5 數據應用層

基于數據處理層的輸出結果，數據應用層可以形成數據服務和應用服務，從而實現數據的綜合應用分析。數據應用層直接面向用戶需求，可以結合業務數據多角度、個性化、精細化的分析特點，自由選取分析維度和關注指標，迅速完成分主題圖表定制與數據分析；也可以利用商業智能（Business Intelligence，BI）自助分析工具來開發支持業務和分析場景的應用。常見應用包括管理駕駛艙、多維分析、數據挖掘、圖表協同等。

對開發生產數據集成架構進行管理，能夠提升企業數據的共享性、一致性及完整性，實現數據互融互通，滿足業務人員多角度、個性化的應用需求，最終形成需求完善數據模型、模型引導數據集市、集市支撐業務分析、分析引導業務需求的良性循環。

3 數據集成架構策略

3.1 避免數據主體對象的重復建設

①油田生產中的業務對象主體應與其他系統的描述對等。例如，井號在任何一個系統中，無論以何種形式來描述，實際上指代的都是同一業務對象主體。因此，業務對象的主體數據和之間的關系描述不能重復建設。②必要的數據需在本系統內進行采集。通常情況下，避免數據重復建設，不僅指現有數據資源不能重復錄入，還要考慮到今后其他系統擴大應用范圍后，數據建設內容的完善性。一般來說，某項業務內容的擴展，需要盡量在原有系統中進行，但由于架構等方面的歷史問題，必然會建設新的、更先進的應用系統替代舊的應用模式。

3.2 最大限度協調數據交換

針對部分已經在現有系統中完成建設的數據，需要充分協調，避免數據形成“孤島”，實現信息共享。

3.3 把握數據對象主體，科學設計以應對環境數據變化

環境數據變化的最理想應對狀態，就是在原應用系統甚至原屬性界面上增加幾個字段，顯然這是過于理想化的情況。當環境數據范圍或結構發生變化，如原來需要錄入的數據在其他或本系統中已經存在，或者原來引用于某系統的數據項在該系統中的命名或存儲表發生了變化，都可能涉及算法調整和引用關系的調整。

①充分把握業務對象主體。不同的應用系統對業務對象主體的描述存在差別，這種差別只是形式上的不同，本質上指的是同一個業務對象。對于地質單元、組織機構、井等主務對象主體的描述要科學準確，與主流系統保持絕對一致。②準備數據錄入界面。對于引用的屬性數據，除建立可維護的數據交換接口程序，還要有相應的錄入界面。在數據交換不能正常進行時，啟動錄入界面進行數據錄入，以備應對。

3.4 及時更新優化數據模型

隨著業務研究逐漸深入，數據模型體量增大，需要對其進行定期維護和觀察，以便能與開發生產數據集成架構相匹配。因此，有必要按照下面的數據模型優化流程進行規范，以最大限度保證數據變化、版本更新不至于對系統的正常運行造成不利影響。

3.4.1 梳理數據字典

開發生產數據集成系統的數據字典設計一定要有前瞻性，要為系統的拓展留有余地。對于已上線的系統，可以從4 個方面進行優化：①明確數據字典。信息系統在建設時應該編寫完整的數據字典，用以詳細說明數據庫現有的用戶和對象。當新版本發布時，需要同步更新數據字典資料。②梳理無用索引、無用表及無用存儲過程。如有必要，可以對系統的索引使用情況進行監控。③清理無用對象。由系統維護人員確認無用數據庫對象并清理，確保庫中不存在業務系統不需要的對象。另外，可以從版本發布定時審閱、數據字典發布版本定期更新、及時存檔系統數據字典等管理角度來保持系統的優化效果和架構的合理性。④梳理、整合系統常用業務數據，使系統架構清晰明了。

3.4.2 優化物理模型

數據量激增、運行系統的增刪改等操作都會導致數據的碎片化程度加劇，并產生大量的垃圾數據，從而威脅開發生產數據系統的正常運行。建議采取以下措施應對：①歷史數據分離。通過合理規劃系統架構，建立一套歷史數據遷移機制，及時將歷史數據從運行數據庫遷移到歷史數據庫，使業務表中所存放的有效期內的數據量不至于太龐大，不會隨時間推移而使系統性能大幅下降。②根據數據表的業務特性，按照時限要求，定期進行數據清理。③表和索引的碎片化會占用大量存儲空間，增加I/O 訪問量，影響系統性能。因此，企業需要定期進行碎片整理，避免碎片化程度過高。

3.4.3 加強系統架構變更管理

在版本發布前，企業需要確保數據結構的變更不會破壞系統整體架構。此外，為了確保系統的穩定性，還要加強對新增或變更結構化查詢語言（Structured Query Language，SQL）語句的審核，如有必要，應對SQL 語句的執行效率和上線之后的性能進行跟蹤評估。

3.4.4 開展日常性能監控

一是通過自動工作負載信息庫（Automatic Workload Repository，AWR）、自動數據庫性能監視器(Automatic Database Diagnostic Monitor AWR，ADDM)對數據庫進行性能監控，保證系統持續健康運行。二是定期檢查消耗資源過多的SQL 語句并及時優化。三是根據業務需求，定期分析特殊業務表的定時任務。數據庫中經常使用定時任務來按周期自動執行存儲過程，當涉及同一個表的多個定時任務同時執行時，有可能會造成死鎖。如何避免資源沖突，合理分配這些定時任務，是優化數據模型的一個方面。

4 結語

探索開發生產數據集成架構設計，構建不同業務主題的數據集市，能夠逐步消滅“信息孤島”，實現海量數據的整合，為項目建設和智能分析提供更加可靠、快速、便捷的底層數據支持，確保數據應用環境可知、可控、可用、可靠，用科學的方法加快企業邁向數字化和智能化的發展步伐。