基于數據中臺的數據資產管理體系①

崔恒志,王 翀,吳 健

1(國網江蘇省電力有限公司,南京 211106)

2(國網江蘇省電力有限公司 信息通信分公司,南京 211106)

3(江蘇瑞中數據股份有限公司,南京 210012)

電力企業作為國家能源安全的重要一環,在經過多年的信息化沉淀后,已經積攢了海量的數據,而數據作為各種經營活動所不可缺少的關鍵信息,也讓之成為現代社會最富含隱性價值的資產,隨著大數據時代的來臨,各行各業都開始對數據信息的價值進行深度挖掘[1-5].2019年起國網公司以《泛在電力物聯網建設大綱》為基礎,開展泛在電力物聯網相關建設工作,其中一項關鍵核心目標為對內業務和數據共享,即開展企業級數據中臺和客戶服務、電網資源兩類業務中臺試點建設.國網公司明確以應用需求為導向,沉淀共性數據服務能力,打造“數據可見、組件成熟、體系規范”的數據中臺,面向公司各專業、各基層單位和外部合作伙伴提供敏捷開放的數據分析和共享服務,提升公司智慧運營和新業務創新能力.

而在長期的信息化建設過程中,國網公司在數據資產方面尚未形成完善的企業級主數據管理體系,缺乏統一的數據質量管理體系,部分單位在數據質量檢查工作中引入了數據檢查工具,但數據質量評估體系及流程仍不完善.同樣在數據資產管理工作過程中,缺乏對數據資產的全壽命管控,導致其價值被無端浪費.因此電力企業迫切需要通過切實可行的管理、分析運用源源不斷產生的數據,挖掘其價值.數據資產管理體系是數據對外共享、提升數據質量、促進企業規模化運營的核心前提.

本文從數據資產全壽命管理建設、數據質量管理、數據資產共享服務建設3 個角度出發,對基于數據中臺的資產管理體系的建設思路進行詳細闡述.

1 數據資產管理

1.1 數據資產對象管理

數據資產管理過程中,主要涉及對實體表、指標模型、系統接口、外部應用、操作環境等對象的管理.實體表是計算存儲過程中以數據庫表結構展現的;系統接口是指依托數據中臺組件,在數據接入上傳環節生成的系統接口;外部應用是指在中臺應用層所涉及到的應用;操作環境是指與數據資產管理相關聯的操作系統信息、數據庫版本等信息;指標模型是數據分析過程中產生的典型的數據衡量標準.

1.2 數據資產全生命周期管理

數據資產的全生命是指數據的接入、分析使用、后期維護、數據資源下架的整個過程[6,7].其中包含數據設計、數據采集、數據運行維護、數據分析利用、數據歸檔、數據遷移、數據資源下架等7 個階段.結合電力企業的數據資產特點和大數據時代的發展前景,現代企業需要建立起完備的數據資產全生命周期管理體系,促進企業進行成本優化.

1.2.1 數據資產全生命周期管理現狀

資產全生命周期管理工作是一項跨業務、跨部門的工作,有別于條塊化的專業管理,具有很大的挑戰性.國網公司為全面推進資產全生命周期管理工作,總部組織開展體系設計工作,形成了包括資產全生命周期管理規范、評價標準、數據全過程在線監測等在內的一系列成果;而各單位由于資產構成、管理基礎、地域差異等因素,在前期的資產管理探索和實踐中開展了各具特色的工作.為全面繼承公司總部及各省(市)公司前期資產全生命周期管理工作成果,提升工作效率和管理水平,穩步推進資產全生命周期管理工作,亟需在原有的數據全生命管理基礎上,另建立一個企業級資產全生命周期管理評價案例庫,以便經驗積累、資源共享和優勢互補,促進各單位資產全生命周期管理工作開展.

1.2.2 資產全生命周期體系建設提升

構建資產全生命周期管理體系建設評價系統,實現公司針對各單位資產全生命周期管理體系建設工作的評價[8].評價管理體系的建立助于下屬單位開展自評工作,幫助發現并解決資產管理進程中出現的疑難問題,為后續工作提供可靠的改進建議[9].同時助力于總部與受評單位的兩級融會貫通,總部可依照該體系對下屬單位的評價材料進行審核打分、評價分數的分析匯總、對審核人員的業務能力的評判等多維度審核.構建資產全生命周期評價案例庫,固化體系設計成果及工作經驗,通過整合電網不同企業、不同部門的評價案例資源入庫,實現企業級別的案例共享.

1.2.3 評價案例系統業務架構

本系統所涵蓋業務范圍,根據需求分析可抽象、歸納、總結如圖1所示.

圖1 業務架構圖

1.2.4 評價案例系統數據架構

根據資產全生命周期管理體系建設評價系統的應用功能定位,資產全生命周期管理體系建設評價系統實現對公司各單位資產全生命周期管理體系建設工作的評價及體系建設工作案例庫的支撐.基于中臺的總體數據架構圖如圖2所示.

實現資產全生命周期管理體系建設評價各類應用功能,需要不同類型數據的支撐[9].如管理全體業務所需的業務源系統數據,包含明細數據、指標模型數據、分析模型數據,由此類業務數據構成評價對象.另外包含支撐具體應用的功能性數據,如審核方式、審核對象、審核結果、評價案例級別代碼、評價問題類型等.

為支撐資產全生命周期管理體系評價建設業務開展,可從以上兩類數據的存儲和管理需求出發,對數據架構進行設計,作為在后續設計過程中邏輯模型及物理模型設計的依據[9].

圖2 數據架構圖

2 數據質量監測

2.1 數據質量現狀

現階段國網公司建設的數據中臺普遍采用OGG數據復制方式實現源端業務系統數據接入,但存在數據接入后與源端不一致的現象.綜合分析存在以下幾方面的問題:一是源端業務系統檢修使得數據表結構發生變化后沒有及時反饋數據中心進行聯動處理,導致數據接入中斷;二是部分源端業務系統OGG 配置進程仍由源業務系統運維廠家負責,數據中心無法對源端進程進行實時監控,一旦發生進程故障問題,無法及時準確定位,影響數據接入質量.且部分源端業務系統數據庫并未對數據中心開放,數據接入后無法進行數據接入一致性、準確性核查.鑒于此情況在數據后續應用過程中,一旦發現跟源端生產庫數據不一致情況,只能對源業務系統的數據重新接入,嚴重降低用戶體驗與數據共享應用水平[10-12].

除數據中臺本身的問題,源端業務系統數據庫在設計初期僅考慮滿足本專業部門重點關注的數據信息,沒有站在公司整體全局層面進行設計實現.隨著公司業務的持續發展,大量業務數據的跨專業共享應用,源端數據庫設計的不合理問題就顯得愈發突出,公司其他專業關注的部分數據信息在源業務系統中可能尚未涉及,或者該部分數據信息為源業務部門不涉及的,從而導致數據質量差影響數據分析應用效果.另一方面,國網公司之前通過建設全業務統一數據中心實現數據的統一歸集和共享應用,支撐了電力交易動態可視化系統、班組透視窗等一批創新應用的構建.但由于源端業務系統大量采用ORACLE 數據庫設計實現,而數據中心貼源層采用的是基于MySQL 封裝的SG-RDB實現,且SG-RDB 性能與穩定性較差,因此在數據統一匯聚過程中需要通過將存量歷史數據和增量數據進行合并后以保證接入數據與源端數據的一致,由于數據庫性能無法滿足快速計算需求,只能支撐離線分析型業務應用的構建.而目前源端業務系統在數據庫設計階段存在大量無主鍵、無唯一鍵的數據表,因此在數據匯聚整合過程中需要耗費大量的時間和服務器資源進行數據同步與校驗,數據數據接入的準確性與時效性無法保障.

2.2 數據質量體系優化

2.2.1 針對中臺數據鏈路傳輸質量

從數據源端抓起,圍繞應用場景需求,利用阿里數據中臺DataWorks、DataQ 等組件的相關功能,對數據流轉全過程進行監控,重點監控數據完整性、一致性、準確性、及時性等,制定并動態配置數據質量核查規則,逐步動態構建企業級數據質量核查規則庫;同時利用DataWorks、DataQ 組件的相關功能,動態創建質量核查任務,根據調度策略,執行核查任務,生成數據質量分析報告和改進建議.通過對數據質量情況的定期通報,及各階段數據質量問題的原因分析,動態更新數據校驗規則,循序漸進地推進數據治理工作開展.

2.2.2 針對源端系統數據質量問題

針對于源端系統出現的數據質量問題,企業需充分調動部門的積極性,借助財務多維、供服指揮平臺等跨專業應用應用、數據中臺建設的機會對源端系統數據質量加以改進,確保源端防控.

2.3 數據質量提升落地實施方法

2.3.1 建立源端數據質量評價體系

1)收集各業務系統數據治理規則,形成數據核查規則庫.

數據資產盤點成果涵蓋了各業務系統元數據信息,即業務元數據(如字段業務描述)、技術元數據(如字段類型)、管理元數據(如數據產生崗位).下一步針對不同的數據對象,基于元數據配置數據質量規則,包括但不限于:數據唯一性、數據準確性、數據完整性、數據一致性、數據關聯性、數據及時性等.通過收集、提煉、沉淀數據質量規則[13,14],形成數據核查規則庫,在數據中臺DataWorks 組件中配置數據質量檢查任務,設置成手動執行或定期自動執行的系統任務,通過執行檢查任務對存量數據和增量數據進行檢查,形成數據質量問題清單.

其中治理規則的具體定義涉及到預警規則、接入規則、監測規則.監測規則是定義如何對數據進行質量監測的規則,完備的監測規則有助于研發人員發現可能出現問題的數據.研發人員可以在數據表中添加如監測對象類型、監測對象維度、監測規則名、規則概述、監測對象元數據名等字段,對數據監測加以輔助.預警規則是在數據分析處理階段若出現數據異常情況,系統發出預警信息時所遵循的準則.接入規則是獲取數據的方式方法,可分為常駐進程或者任務形式的調度.任務調度模式不需要額外配置,而常駐進程則需要配置服務器相關信息、數據接入時段、數據接入周期等.圖3中在規則配置界面中配置質量監控的模板規則或自定義規則,具體可選擇一致性監測、準確性監測等(本圖所示為數據重復性監測規則配置).

2)按照數據責任清單,開展質量評價,推動源端數據治理.

通過數據資產盤點工作,已形成公司級數據責任清單,并在數據中臺發布數據資源目錄.可根據建立的數據校驗規則庫規則,對源端數據質量進行評價,結合數據責任清單形成數據質量評價報告,遵循“誰產生、誰提供、誰負責”的原則推動源端數據治理,進而全面提升公司數據質量.

圖3 DataWorks 組件數據質量監控功能

2.3.2 數據源端治理

依托數據血緣圖,開展數據流向倒查,追蹤源頭問題.通過對基于數據中臺構建的業務應用開展評價反饋信息收集、數據質量問題分析等工作,從分析結果反向溯源,發現源頭問題.業務方面主要關注數據的完整性、準確性和跨業務一致性,主要結合業務應用使用數據過程中出現的數據缺失、數據不準確等問題;技術方面結合DataWorks、Datahub、DataQ 等組件的數據流轉鏈路臺賬,深挖造成數據質量問題的技術細節,進一步提升數據質量.

具體的鏈路分析方法采用解析MaxCompute 中Information Schema 提供的作業歷史視圖,查詢到當前項目內的一段時間的作業歷史信息,解析出對應的輸入表和輸出表以及對應的任務代碼片段進行實現.

(1)輸出結果表的編譯與創建.

結果表部分編譯代碼如下:

CREATE TABLE `in_out_tb_relation` (

‘start_time’ datetime comment,

‘end_time’ datetime,

‘input_table’ string,

‘inst_id’ string,

‘output_table’ string,

‘operation_text’ string);

控制臺創建該表如圖4所示.

圖4 創建輸出結果表

(2)在創建完輸出結果表,創建MaxComputer SQL任務,如圖5所示.

結果表部分編譯代碼如下:

(3)查詢輸出結果

input_table和output_table 字段即為輸入和輸出表的數據鏈路,以此信息為基礎進行表級別數據鏈路的分析工作,operation_text為執行的任務代碼片段,通過解析代碼片段,實現輸入表字段和輸出表字段字段級別的數據鏈路分析需求,達到數據血緣鏈路管控的目的.

圖5 MaxComputer SQL 任務

3 數據資產共享服務體系構建

數據資產整合與服務的實現需經過源端數據接入、數據萃取融合、數據服務設計與發布等幾個關鍵環節,實現數據中臺的數據資產能力輸出,對外提供基于指標、標簽,畫像、主題分析等數據服務.

3.1 數據溯源接入

數據中臺數據溯源融合工作主要是明確分析主題需要的數據范圍,數據處理要求,實現基于服務主題的數據按需完整接入與整合工作.歷史數據采用一次性全量接入方式,增量數據接入可采用Ogg+Datahub+Maxcomputer 融合方式與數據集成方式.

3.1.1 Ogg+DataHub+MaxComputer 融合方式

本方法適用于Oracle 中數據表不帶有增量數據標識符,對于增量數據不能很好的進行捕獲的場景.文中遵循國網信息保密原則,部分表名用“--”隱性表示.SQL 代碼部分省去了詳細的字段代碼部分.其中全量表與增量表的建表規則分別為:

(1)全量表:表名 ods_源表名_df 分區字段 ds 格式yyyymmdd 生命周期 7 天.

(2)增量表:表名 ods_源表名_di 分區字段 ds、hh、mm 格式 yyyymmdd、hh、mm (每5 分鐘同步一次)生命周期永久.

使用場景1.Ogg+Datahub+Maxcomputer

1)假設日期號為X的當天數據庫存儲的為全量數據.

2)X+1 號抽取增量數據同步至增量表中.

3)在X+2 號凌晨開啟定時任務融合X號當天的全量數據與X+1 號當天的增量數據.

4)查看表中是否存在主鍵,并找出主鍵字段名.

5)增量表中含有若干系統字段以及源數據主鍵復制字段,此類字段只負責處理邏輯,不參與融合操作.

6)新增和修改數據一起處理:先將增量表中的兩部分數據使用ROW_NUMBER 函數融合提起當天最新修改的數據,然后和全量表數據融合提取最新數據.

部分SQL 代碼如下:

3.1.2 數據集成方式

本方法適用于當數據現場狀態處于離線且業務表中存在時間戳時,可以采用數據集成方式進行增全量同步與對應點融合任務.該方法下全量表與增量表的建表規則分別為:

(1)全量表:表名 ods_源表名_df 分區字段 ds 格式yyyymmdd 生命周期 7 天.

(2)增量表:表名 ods_源表名_di 分區字段 ds 格式yyyymmdd 生命周期 永久.

使用場景2.數據集成

1)假設日期號為X的當天數據庫存儲的為全量數據.

2)X+1 號抽取增量數據同步至增量表中.

3)在X+2 號凌晨開啟定時任務融合X號當天的全量數據與X+1 號當天的增量數據.

4)查看表中是否存在主鍵,并找出主鍵字段名id.

5)本次業務場景中,增量表中create 字段用于抽取新增數據,modify 字段用于抽取修改數據,id 字段用于直接的數據比對融合.

部分數據融合代碼如下:

3.1.3 方法對比與結論

本文通過對以上兩種數據接入方式的實測比較,可得到以下結論,如表1所示.

3.2 數據萃取轉換

資產數據萃取轉換ETL 工作主要完成對接入數據的ETL 抽取設計及質量管理機制,按照SG-CIM 模型標準,通過數據集成組件對貼源層數據進行標準化模型轉換以同步提高數據質量,將數據同步映射至共享層.

在SG_CIM 基礎上(DWD)上構建DWS 形成寬表層,在匯總數據層,采取更多寬表化的手段構建公共指標數據層,提升公共指標的復用性,減少重復加工.在轉換過程中,需要及時對不同數據庫適配的數據類型進行修改.國網公司前期架構的全業務數據中心的標準庫采用的為Gbase8A,現階段基于數據中臺架構的標準庫為MaxComputer,在經過大量測試后,最終得出由Gbase8A 到MaxComputer的數據類型轉換規則.如表2所示.

表1 兩種接入方式比較

表2 數據類型轉換規則

3.3 數據資產共享服務發布

數據中臺使用DataWorks 統一管理對內對外的API 服務,數據服務及應用設計主要完成服務接口的封裝和發布,實現與業務系統的對接,可以提供RESTful等各類形式的API 服務接口的統一注冊、管理和調度,如圖6所示.

圖6 數據資產服務共享發布流程

1)數據服務支持將關系型數據庫和noSQL 數據庫的表(TB 級)通過向導模式生成數據API,也支持自定義SQL的腳本模式通過查詢SQL 自行編寫API.

2)數據服務支持MaxCompute Lightning 服務將項目表(GB 級)數據封裝成API,支持以PostgreSQL 協議及語法連接訪問Maxcompute 項目,通過向導模式,腳本模式快速獲取以標準SQL 查詢分析MaxCompute項目中的數據.

服務發布的技術實現(如圖7至圖12)如下:

(1)使用腳本模式生成API 后配置API 查詢.

(2)配置參數與查詢SQL.

(3)進行本地數據API 測試與發布.

返回數據結果并且狀態返回SUCCESS 表明本地測試成功.

(4)API 信息查看與調用.

(5)使用Postman 工具調用接口進行驗證,返回數據說明API 接口創建成功.

4 實驗數據情況

基于本文提出的數據資產管理體系,利用數據質量治理、數據共享技術對公司的數據表進行監管,取合規上傳率與時效合規率作為兩個主要的評價指標,對系統中6 個自然日的數據表進行監測后(見表3),可明顯發現數據表通過ETL 與相應的數據質量溯源治理后,數據表的上傳合規性可大幅度提升.采用數據共享技術中的兩種數據源端接入方式,也可大幅度提高數據表上傳的時效性,除個別天數會存在負提升情況,其余時段合規率均維持在較高水平,由此可論證對數據資產進行有效管理可極大幅度提高業務運營效率.

圖7 配置API 查詢

圖8 配置參數

圖9 測試發布

圖10 查看API 信息

圖11 調用API

圖12 查看數據返回情況

5 結束語

在電力企業數據資產管理流程體系中,以多維度管理、迭代優化、綜合治理為中心思想,從數據資產全生命管理、數據資產質量管理、數據資產共享服務發布管理三個層面入手,對數據資產進行規范化管理,不斷提高數據質量,在保障運維效率的前提下提高基于數據中臺的服務質量[15,16],幫助企業精準預判數據資產的現有與未來價值,實現優勢成本的合理化利用.

表3 6 個自然日數據表監管情況(%)