基于DCMM的集團級全域數據管理與共享平臺研究與應用

段瑞永

(湖南大唐先一科技有限公司 北京100033)

對于當前很多企業大量數據分散在不同信息系統中且缺乏標準化，“數據煙囪”林立的現狀[1-2]，本文總結提煉了中國大唐集團有限公司(以下簡稱公司)基于《數據管理能力成熟度評估模型》(GB/T 36073-2018，簡稱DCMM)國家標準，系統梳理和全面分析數據現狀、制定數據標準，統一“數據方言”，打通數據孤島，實現集團級全域數據匯聚、雙向實時交換等提升企業數據管理能力的主要做法；提出了建設數據匯聚共享交換平臺的總體架構、技術架構，分析研究了在對不同數據源進行聯合查詢時采用統一SQL路由引擎屏蔽多種引擎SQL方言、實現統一SQL語法和統一入口技術，為提高接入數據質量、采用的基于邊界閾值的數據校驗技術，以及以促進用戶擴大數據共享范圍的數據分析技術等關鍵技術。

1 深度融合DCMM國家標準

1.1 DCMM數據管理能力成熟度評估模型介紹

DCMM是針對一個組織數據管理、應用能力的評估框架，通過數據能力成熟度模型，組織可以清楚地知道自身所處的發展階段以及未來的發展方向。DCMM定義了數據戰略、數據治理、數據架構、數據應用、數據安全、數據質量、數據標準和數據生存周期8個核心能力域及數據戰略規劃、數據戰略實施、數據戰略評估等28個能力項，并以組織、制度、流程和技術作為8個核心域的評價維度。DCMM評價維度及能力域如圖1所示，DCMM所包含的8個能力域及28個能力項如表1所示。

表1 DCMM的8個能力域及28個能力項Tab.1 8 capability domains and 28 capability items for DCMM

DCMM將數據管理能力成熟度劃分為5個等級，自低向高依次為初始級、受管理級、穩健級、量化管理級和優化級，不同等級代表企業數據管理和應用的成熟度水平不同。DCMM5個等級劃分及主要特征如圖2所示。

圖2 DCMM等級劃分及主要特征Fig.2 Classification and key features of DCMM

1.2 基于DCMM的做法

通過對業務部門、相關系統承建商等的調研訪談，調研問卷、資料研讀等手段，歸納總結公司在數據管理，尤其是在數據匯聚共享交換方面存在的問題。根據DCMM數據管理能力域的具體要求，對公司規劃、工程、生產、經營、海外、資本運營等業務領域和黨建、決策、風險管控、法律、綜合辦公等管理事項進行詳細梳理分析，并以此為基礎，制定印發了數據共享管理規定、大數據指標手冊(發電主要指標)、數據資產管理辦法、數據安全管理辦法等制度、標準。

主要的做法如下：

(1)明確基礎數據來源，對于組織機構與人員、投資項目代碼與名稱、投產前后機組基礎信息、生產運營等基礎數據明確了唯一系統來源，其他系統逐步引用。

(2)建立數據管理責任制，理順數據責任部門、使用部門、歸口管理部門職責界面。數據責任部門指數據開發、提供、維護部門，對數據質量負主體責任；數據使用部門是根據授權使用數據的部門，對數據使用的合法合規及使用所造成的影響負責；數據歸口管理部門為信息化部門，負責數據統一管理工作。

(3)建立數據質量缺陷報警機制，數據匯聚共享交換平臺將用戶發現或系統分析所得到的數據質量缺陷推送至各業務系統，由數據責任部門組織整改，建立數據質量管理常態化機制，提高數據的完整性、準確性、及時性。

(4)建立數據共享開發機制，數據使用部門可將新增共享數據需求報送至數據匯聚共享交換平臺，數據責任部門確認后，由業務系統、數據匯聚共享交換平臺技術人員進行數據配置或開發，上線后由數據使用部門確認是否滿足需求。

2 建設數據匯聚共享交換平臺

2.1 平臺總體架構

平臺的整體架構由數據采集層、數據存儲層、數據分析層和平臺展示4部分組成[3-8]。如圖3所示。

圖3 數據匯聚共享交換平臺總體架構Fig.3 Overall architecture of data aggregation shared switching platform

(1)數據采集層。實現對各類數據的采集，同時對各類數據進行預處理。采集業務系統的各類監測數據，例如配置數據、性能數據、告警數據、日志數據，實現個性化數據采集設置，并且將收集到的監控數據儲存在數據庫中。

(2)數據存儲層。提供數據集中處理中心，包括告警數據處理，性能數據處理，配置數據處理，日志數據處理，實現對不同格式的數據存儲。

(3)數據分析層。實現對當前數據的實時關聯分析和歷史數據的統計分析，并建立相關分析模型。

(4)平臺展示層。對實時指標數據通過各種圖形進行可視化展示，同時與外部第三方應用進行信息集成與共享。

2.2 平臺技術架構

系統采用大數據核心技術進行組建。外部數據通過采集代理，按照平臺序列化規范，接入并存儲到kafka中。Kafka中的數據通過數據加載引擎，存儲到指定的數據存儲中。系統支持關系型數據庫、分布式檢索引擎和分布式文件系統。同時，kafka中的數據可以對接Spark Streaming實時計算引擎，進行實時處理和分析。

系統具備統一資源管理，支持多種計算框架。對于存儲后的數據，系統提供MapReduce和Spark兩種計算框架，進行數據處理和分析。系統通過分布式檢索引擎，對外提供結構化和半結構化數據檢索；通過Presto、Hive、SparkSQL對外提供結構化和半結構化數據統計、關聯等OLAP操作；通過Spark計算框架，提供機器學習等復雜數據分析算法[9-11]。平臺的技術架構如圖4所示。

圖4 數據匯聚共享交換平臺技術架構Fig.4 Technology architecture of data aggregation sharing exchange platform

2.3 關鍵技術研究

2.3.1 統一SQL路由多引擎技術

當前，存儲與管理數據的數據管理系統種類繁多，包括關系型數據庫、NoSQL 數據庫、文檔數據庫、key-value數據庫、對象存儲系統等，這些數據管理系統基于ANSI SQL逐漸發展成具有自身特點的SQL方言，并且差異愈加明顯，因此，在對不同數據源進行聯合查詢時，就需要使用不同的客戶端去連接不同的數據源，整個分析過程復雜、編程入口多、系統集成困難，對于涉及海量數據的數據分析將會異常困難。數據匯聚共享交換平臺通過采用SQL多引擎路由技術實現了統一SQL語法和統一入口，屏蔽了多種引擎SQL方言切換，根據各引擎集群空閑負載情況、SQL復雜度及開銷成本等路由到合適的引擎執行，為元數據管理，動態字段級血緣關系的數據地圖提供了基礎支撐[12-14]。SQL路由方案設計如圖5所示。

圖5 智能引擎:SQL路由方案設計架構Fig.5 Smart engine: design architecture of SQL routing scheme

統一SQL路由多引擎方案可通過改寫Presto的詞法文件、訪問器模式、函數適配等完成。

(1)改寫Presto詞法文件

Presto語法是在標準SQL基礎上實現的，通過對Presto詞法文件源碼語法進行改寫使其滿足HQL語法，作為統一SQL引擎的HQL詞法文件。改寫內容包括改寫刪除語法、添加clusterBy語法規則、添加Hive語法中TABLESAMPLE關鍵字取樣的相關語法規則、添加lateral:LATERAL VIEW語法規則等方面內容。此處以添加clusterBy語法規則以滿足完整的HQL語法的部分源碼為示例，其SQL語句如下：

querySpecification

:SELECT setQuantifier selectItem (',' selectItem)*

(FROM relation (',' relation)*)

(WHERE where=booleanExpression)

(GROUP BY groupBy)

(HAVING having=booleanExpression)

(ORDER BY sortItem (',' sortItem)*)

(clusterBy)

(LIMIT limit=INTEGER_VALUE );

clusterBy語法規則：

clusterBy

:((CLUSTER BY expression (',' expression)*)| ((DISTRIBUTE BY expression (',' expression)*) (SORT BY sortItem (',' sortItem)*)) );

(2)實現訪問器模式

先根據不同引擎語法實現不同的監聽器邏輯或訪問器邏輯多種語法翻譯功能，從而實現統一SQL多引擎執行的支持。以Hive引擎為例，繼承Hive Sql Base Base Visitor返回類型為String類型，深度優先遍歷語法樹，在使用Visitor訪問器模式，對語法樹進行遍歷時，把HQL語法轉換為目標引擎的語法如Presto語法，最終實現訪問器模式。

(3)函數適配

通過預寫映射模版，調換參數順序，轉換參數的數據類型，填充默認的參數，轉換返回的數據類型來滿足統一SQL引擎實現時解決的函數適配的問題。函數適配配置主要SQL語句如下：

//presto函數適配配置

multiFunc.put("date_add",Arrays.asList("date_add('day',p4,cast(p2 as date))"));

multiFunc.put("date_sub",Arrays.asList("date_add('day',-p4,cast(p2 as date))"));

multiFunc.put("add_months",Arrays.asList("date_add('month',p4,cast(p2 as date))"));

2.3.2 大數據控制集群技術

控制集群在設計上包含三大主要模塊，分別是請求處理器(Worker)、調度器(Scheduler)和作業執行管理器(Executor)，它們分別實現不同的邏輯[15]。

Worker處理所有的RESTful請求，它可以本地處理一些作業，如對用戶空間、表、資源、作業等的管理；而對于需要執行分布式計算的作業，Worker會進一步把它提交給Scheduler處理。

Scheduler負責Instance的調度，它會維護一個Instance列表，并把Instance分解成各個Task，生成這些Task的工作流——DAG圖(Directed Acyclic Graph，有向無環圖)，把可以運行的Task放到TaskPool中。此外，Scheduler還可以查詢計算集群的資源狀況。

Executor根據自身資源情況，如果資源滿足，則會主動輪詢Scheduler的TaskPool請求獲取下一個Task，TaskPool會根據Task的優先級和計算集群的資源情況，把相應Task提交給Executor，Executor獲取到Task后，生成計算層的分布式作業描述文件，提交給計算層，監控這些任務的運行狀態，并定時把狀態匯報給Scheduler。

簡單地說，當用戶提交一個作業請求時，接入層先進行用戶認證，然后發送給控制層的Worker，Worker判斷是否為同步請求，如果為同步請求，則本地執行并返回。如果是異步請求，Worker會先做些檢查，生成InstanceID，把請求進一步發送給Scheduler，并返回給客戶端。Scheduler把作業分解成各個Task，Executor主動輪詢Scheduler，獲取相應Task，提交給計算層執行，并定時將自己持有的Task的狀態匯報給Scheduler。大數據計算任務調度過程如圖6所示。

圖6 大數據計算任務調度Fig.6 Big data computing task scheduling

2.3.3 跨集群數據復制技術

跨集群數據復制技術克服了數據的準實時跨集群復制、動態配置作業對跨集群數據的依賴，根據任務的優先級等合理管理和分配資源，為未來數據業務長期發展打下堅實的基礎。跨集群數據復制主要具有以下優點。

(1)突破了單集群的數據存儲上限。由于目前主流分布式系統Master/Slave的結構，單集群受限于Master的內存和處理能力上限，而現在數據可以存儲在多個集群上，不再受單集群的限制。

(2)可以實現多機房數據容災，將來可以動態的跨機房備份重要數據。

(3)實現跨數據中心動態負載均衡，將熱點集群上的數據和作業動態遷移到空閑集群，緩解熱點集群的壓力，提高空閑集群的使用率。

(4)對于響應速度要求比較高的請求，可以在多個集群同時調度這個作業，將響應最快的請求返回給用戶。

2.3.4 基于邊界閾值的數據校驗技術

數據匯聚共享交換平臺將眾多相關業務系統數據統一匯聚進行共享管理，以便提供全方位、全生命周期的數據共享。只是在當前，由于復雜的數據來源和系統間采用的統計口徑不一，以及數據匯聚過程中可能存在的數據轉換與處理問題，所以需要對接入數據進行適當的校驗，以保證數據的可靠性和準確性。結合電力數據專業特性，并考慮海量數據的校驗效率，提出通過閾值校驗實現多種數據的有效匯聚[16-20]。

電力數據的特性使得相關數據通常具有合理有效的邊界范圍，比如電站的發電出力具有非負性，且一般小于裝機容量，部分特殊情形會超出裝機，但幅度不會太大；再如機組的發電流量應該小于等于其最大過流能力；針對這類數據，可以預先定義合理的邊界范圍閾值進行校驗，并對超限數據進行異常預警和相應的處理。具體的校驗公式如下。

(1)

2.3.5 以促進用戶擴大數據共享范圍的數據分析
技術

數據匯聚共享交換平臺建設初期，根據需求，梳理匯總了近萬個數據指標，并由多個業務應用系統匯聚至數據共享交換平臺，出于各種理由，在平臺上線應用時，僅開放共享不到5000個指標，一些相對重要的生產經營指標也沒有實現完全共享交換，個別部門“本位主義”思想嚴重影響了數據的深度應用，致使數據匯聚后再次成為另一種形式的數據煙囪。為了解決這個問題，公司從管理上出臺了相關管理規定，從技術上基于貝葉斯平均法計算熱門搜索指標Top10(每周)并以詞云圖的形式展現給所有用戶，并以數據質量周報的形式呈公司領導、各部門閱。管理手段的約束以及技術手段的倒逼，讓這些部門認識并感受到數據管理、數據質量、數據應用的重要性，并逐步同意共享了原先不同意共享的數據指標，擴大了數據共享指標的范圍。貝葉斯平均法如公式(2)所示。

(2)

公式(2)中BA(score)表示指標的點擊搜索熱度，值越大，表明熱度越高。a表示指標點擊量，m表示指標點擊用戶數，r表示指標平均點擊量，n表示歷史點擊平均用戶數。

通過點擊率、正樣本頻次等算法對大量的用戶行為進行偏好類統計，進行用戶精準畫像設計。點擊率算法如公式(3)所示。

(3)

公式(3)中，m和C是平滑系數。通過用戶精準畫像設計，使用戶體驗度大幅提升，更加促進了各部門數據匯聚共享交換的積極性，進一步擴大了數據共享的范圍[21-24]。

3 平臺實施應用

3.1 平臺實施

數據匯聚共享交換平臺實施過程當中，除了平臺前后端的分離部署配置，達到數據字段級別的權限配置等實施工作以外。平臺的實施工作著重在與多個業務系統的數據集成上展開[25]。

從采集的數據量、數據頻率要求、安全穩定性等多種因素考慮，確定了從OA系統接入數據采用webservice方式，從財務、物資、項目、燃料等業務系統接入數據采用JDBC方式；向數字化作戰室、生產調度中心等系統輸出數據采用webAPI方式；與國資委數據交互按照要求采用雙向SM2方式加密上傳下達db文件至央企前置機。平臺對所有接口任務開發了可視化的界面并內含異常告警配置，實時掌握數據動態[26-28]。

3.2 平臺應用

平臺在數據存儲與管理方面采用了Click House+MySQL模式。ClickHouse是基于列存儲的數據庫，比傳統行式存儲數據庫速度更快，性能更好，長于實時數據分析，用于海量業務數據的存儲分析。MySQL是傳統的基于行存儲的數據庫，系統運維操作相對簡單，人機交互體驗更加友好，用于流程、權限配置等系統本身數據的存儲管理。Click House+MySQL模式兼顧了系統性能及系統運維兩個方面，提高了普通用戶和系統運維人員的使用體驗。

目前，數據匯聚共享交換平臺已在公司總部及下屬100余家企業上線應用，應用效果良好。截至目前平臺已匯聚近4000萬條數據，滿足了公司總部各部門及下屬企業的數據共享需求，并與數字化作戰室、生產調度中心等十幾個應用系統實現實時雙向交互。大額資金、三重一大、第三方服務機構數據通過平臺與國資委統一數據采集平臺進行對接。9000多件專利、4000多項成果論文、400多項國行標供系統企業查看學習。

4 總結

當前，數據是企業的核心資產已是共識，積極推動數據的匯聚共享交換、加強基于大數據的分析應用已是各大企業正在實施或計劃實施的重要工作。本文所提出的集團級全域數據管理的相關做法、數據匯聚共享交換平臺關鍵技術的研究與應用，對于大型企業集團數據管理、數據匯聚共享交換、數據中臺的建設，具有較大的借鑒參考價值。