淺談智慧電科院數據中臺建設及關鍵技術

尹春林 楊政

摘要：本文主要是通過智慧電科院中臺建設的概念入手，指出電科院中臺建設的目標是建成“模型規范統一、數據完整全面、分析靈活智能”的數據中臺，對于數據中臺的建設采用創新型的建設思路，基于知識圖譜、模型管理、深度學習算法給出中臺應用架構設計，包括：應用架構、功能架構、技術架構和數據架構。同時對構建數據中臺所需關鍵技術進行闡述。以滿足中臺建設不同架構的技術需求，從而對電科院的數字化轉型中臺建設，提供一定的研究對策，達到更好的電科院管理。

關鍵詞：供電企業;電科院;數據中臺

中圖分類號：TP311? ? ? 文獻標識碼：A

文章編號：1009-3044（2021）16-0213-02

開放科學（資源服務）標識碼（OSID）：

面對電科院數據發展的現狀與存在的不足，需要將沒有采集的信息采集起來，沒有共享的數據即時共享出來，形成跨專業數據共享共用的生態，把過去沒有用好的數據價值挖掘出來，快速體現數據價值。在專注數據標準化等基礎工作的同時，數據建設要改變以往梳理好了再用的方法和習慣，提升至以用促建、以建助用、用建一體，以數據價值挖掘、發展數字經濟為導向。

1 數據中臺建設

1.1 數據中臺的內涵

數據中臺的定位是為許多專業和單位提供數據共享和分析應用服務。在信息分析和管理領域的支持下，它催生了共同的知識服務能力，并通過知識服務滿足橫向的跨專業和縱向的跨不同層次的知識共享、價值挖掘、分析和應用以及整合的需求。

構建企業級的標準數據，數據統一存儲，形成大數據資產層，通過統一的數據服務接口為客企業內外部客戶提供高效、共享的數據服務。數據中臺的主要特點歸納為三點：首先是創造流量;其次是跨界分析;第三是整合資源。

1.2 數據中臺的建設目標

電科院的目標是：建成“模型規范統一、數據完整全面、分析靈活智能”的數據中臺，實現多維度數據的統一存儲、管理與服務。

1.3 數據中臺設計的總體思路

企業中臺主要包括業務中臺、數據中臺和技術中臺以及企業中臺穩定、安全、規范運行的保障體系。

其中，對于數據中臺的建設采用創新型的建設思路，基于知識圖譜、模型管理、深度學習算法，在保持原有系統數據體系不變的情況下，采用自動發現數據資源關系、動態感知數據變化及影響范圍、自主分析技術;利用數據云圖全局展現企業數據資產圖譜實現多維數據目錄搜索與定位。

2 數據中臺應用架構設計

構建數據中臺，需要充分應用“云大物移智鏈”等現代信息技術和先進通信技術，實現電力系統各個環節萬物互聯、人機交互，大力提升數據自動采集、自動獲取、靈活應用能力，實現“數據一個源、電網一張圖、業務一條線”，“一網通辦、全程透明” 。堅持統一數據管理，系統建設必須嚴格遵循電網企業統一的信息數據模型和數據采集、定義、編碼、應用等標準，建成統一標準、統一模型的數據中臺，確保數據共享。

2.1 應用架構

數據中臺主要包括基礎管理域、處理域、分析域三部分。

基礎管理域的核心是編碼標準化、組織機構標準化，通過定義統一編碼字典和組織機構，為業務數據的融合與標準化提供基礎支撐。目的是建立標準編碼，解決當前業務數據編碼不一致、編碼粒度不一致的問題，為業務數據標準化提供基礎支持;建立標準組織機構，解決當前業務數據組織機構體系不一致的問題，為業務數據標準化提供基礎支持;

處理域是公司未來業務系統的各類業務數據存儲、處理的中心，解決了當前業務系統業務數據冗余分散雜亂的問題，為公司未來各業務應用提供唯一的、標準的業務數據。

分析域總體設計：包含標準物理模型和指標體系設計，標準物理模型依據YNCIM模型進行設計。分析域完成業務數據融合、貫通、標準化轉換、匯總、構建知識圖譜、提取非結構化數據中蘊含的業務實體等功能，為數據挖掘和數據分析進行數據準備。

2.2 功能架構

基礎管理域為其他兩個域提供業務概念、標準編碼、標準組織機構;

處理域維護標準業務數據，提供給未來業務系統共享使用;

分析域完成數據分析所需的所有數據準備工作。

2.3技術架構

基礎管理域管理業務域、業務模型、標準編碼、標準組織機構，這些信息具有唯一性，處理域和分析域共享;

處理域為未來業務系統提供標準業務數據共享服務，處理域的數據可以發布到分析域供數據分析使用;

分析域提供大數據存儲和大數據計算，完成數據匯總、非結構化數據信息獲取、圖構建、數據提煉工作。

3 構建數據中臺的關鍵技術

3.1 構建數據中臺所需關鍵技術

如表1所示，數據中臺的關鍵技術可以概括為五個類別，即：信息采集、信息存儲與管理、信息共享與交流、信息的展示。

3.2 數據采集傳輸

這個一般對應于公司的日志平臺，任務是將數據采集后緩存在某個地方，供后續的計算流程進行消費使用。

目前市面針對日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 幾種常見的框架，我們挑應用較廣泛的前兩者介紹下：

從兩者的設計思想來看，Flume 最初并不是為了采集日志而設計，而是定位在把數據傳入 HDFS 中，這和 Logstash 有根本的區別。所以它理所應當側重于數據的傳輸和安全，且需要更多的二次開發和配置工作。而 Logstash 明顯側重先對日志數據進行預處理，為后續的解析做鋪墊。它搭配 ELK 技術棧使用起來比較簡單，更像是為你準備好的便當，開盒即食。

1）日志采集如何工作

Flume 由三個部分組成：Source，Channel 和 Sink，對應于采集，緩存和保存三個環節。其中，Source 組件用來采集各種類型的數據源，如 directory、http、kafka 等。Channel 組件用來緩存數據，有 memory channel，JDBC channel和 kafka channel 三種。最后再通過 Sink 組件進行保存，分別支持 HDFS，HBase，Hive 和 Kafka 四種存儲方式。

2）數據傳輸 Kafka

Kafka 最初是由領英開發，并隨后于 2011 年初開源， 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。該項目的目標是為流程性知識提供一個統一的、高吞吐量、低延遲的平臺。持久層基本上是一個 "遵循分布式交易工作架構的大規模發布/訂閱消息隊列"，這使得它作為企業級基礎設施對過程流知識具有價值。

3.3 數據存儲

數據庫存儲方面，有單機/分布式、關系型/非關系型、列式存儲/行式存儲三個維度的劃分，各種維度交叉下都有對應產品來解決某個場景下的需求。

在數據量較小的情況下，一般采取單機數據庫，如應用非常廣泛，技術成熟的 MySQL。數據量大到一定程度后，就必須采取分布式系統了。目前業界最知名的就是 Apache 基金會名下的 Hadoop 系統，它基本可以作為大數據時代存儲計算的經典模型。

3.4 數據計算&查詢

1）批計算和流計算

大數據處理場景可分為批處理和流處理兩個，分別對應離線分析和實時分析。常見框架分類有：

僅批處理框架：Hadoop MapReduce

僅流處理框架：Storm，Samza

混合框架：Spark，Flink

篇幅所限，除了上文已經提到的 Hadoop 生態外，我們再簡單科普下 Spark：

2）Spark 和 Flink

Apache Spark 是一種包含流處理能力的下一代批處理框架。

批處理模式下，Spark 與 MapReduce 不同，它將數據處理工作全部在內存中進行，計算性能大幅改善。流處理模式下，Spark 主要通過 Spark Streaming 實現了一種叫做微批（Micro-batch）的概念。這種技術將信息流視為一系列可怕的小 "批次"，可由批處理引擎的本地語言學處理。這在應用中是正確的，但與真正的流處理框架相比，在性能方面仍有差距。

而 Flink 作為更新一代的處理框架，擁有更快的計算能力，更低的延遲，已經慢慢嶄露頭角。不過一個框架的應用，特別是開源框架，需要足夠長的時間進行運行，測試和優化。大數據技術在開源社區的推動下，迭代日新月異。在不久的將來，相信 Flink 會像 Spark 取代 Storm 一樣，逐漸成為大數據處理技術的主流。

3）數據查詢

經過處理后的數據，還需要有高效的查詢引擎才能被用戶接觸和使用。目前 OLAP 的查詢技術框架大致可分為三類：

基于 HBase 做預聚合：如 Opentsdb， Kylin 等，均需指定預聚合的指標，在數據接入的時候進行聚合運算，適合相對固定，維度較多的業務報表類需求。

基于 Parquet 做列式存儲：如 Presto， Drill，Impala 等，基本是完全基于內存的并行計算，Parquet 系能降低存儲空間，提高IO效率，以離線處理為主，很難提高數據寫的實時性，超大表的 Join 支持可能不夠好。

基于 Lucene 做外部索引：如 ElasticSearch，Solr 等，能夠滿足的的查詢場景遠多于傳統的數據庫存儲。

我們以常見的 Presto，Druid，Kylin 三個模型來講講各自的特點：

Presto：由 Facebook 開源，是一個分布式數據查詢框架，原生集成了 Hive、 Hbase 和關系型數據庫。它背后所使用的執行模式與Hive有根本的不同，并沒有使用 MapReduce。因其所有的處理都在內存中完成（與上文的 Spark 類似），大部分場景下要比 Hive 快一個數量級。

Druid：由 MetaMarket 開源，是一個分布式、面向列式存儲的準實時分析數據存儲系統，延遲性最細顆粒度可到 5 分鐘。它能夠在高并發環境下，保證海量數據查詢分析性能，同時又提供海量實時數據的查詢、分析與可視化功能。

Kylin：Cube 預計算技術是其核心，基本思路是預先對數據作多維索引，查詢時只掃描索引而不訪問原始數據從而提速。劣勢在于每次增減維度必須對 Cube 進行歷史數據重算追溯，非常消耗時間。

3.5 數據可視化及分析

在數據可視化這塊，一般會采取三個途徑來進行數據展示。最基礎的利用開源的圖表庫，如國外的 HighCharts、D3，百

度的 ECharts，還有阿里 Antv 的 G2、G6、F2 等。往上一層是各個知名公司開源的可視化框架，如 Airbnb 的 Superset，Redash，Metabase 等等。這些框架一般能夠滿足從數據源接入，自助制作報表和報表整理展示的功能，接入起來更加方便。再往上一層就是商用的可視化軟件，如國外的 Tableau，Qlik ，國內的 FineReport，永洪 BI 等等。這種軟件需要付費，但都具備更豐富的可視化功能并提供一些技術支持，對于那些沒有精力折騰可視化的公司會是個不錯的選擇。

可視化框架：

這里主要介紹下業內比較出名的 Superset 和 Metabase。

前者的方案更加完善，支持集合不同數據源形成對應的指標，再通過豐富的圖表類型進行可視化。在時間序列分析上比較出色，支持移動平均及周期偏移等分析方法。同時與 Druid 深度集成，可以快速解析大規模數據集。劣勢則是不支持分組管理報表，一旦報表多了使用起來很麻煩。且不提供圖表下鉆及聯動功能，權限管理也不夠友好。

Metabase 則比較注重非技術人員（如產品經理和運營人員）的使用體驗，讓他們能自由地探索數據，回答自己的問題，界面相對來講更加美觀。在權限管理上做得較為完善，甚至無需賬號也可以對外共享圖表和數據內容。Dashboard 支持分類，便于管理報表。劣勢在時間序列分析上不支持不同日期對比，還需要自定義SQL 實現。每次查詢僅能針對一個數據庫查詢，操作比較繁瑣。

4 結語

數據中臺改變了業務系統自我收集和自我使用的既定秩序，有效整合了支持現有業務系統的相關信息資源，建立了綜合管理和集中存儲的知識平臺，保證了存儲的安全性和調用的多樣性，擴大了海量信息的創新應用，有效建立了信息 "說話 "的思想，依靠信息科學地分析各部門日常業務工作中的問題，客觀地提出針對性的解決方案。做到數據中臺一定要與業務價值對齊，關鍵技術與架構建設對齊，有效支撐未來的大數據智庫建設。

參考文獻：

[1] 蔡菁菁.淺談利用數據中臺實現通信企業數字化轉型[J].中國新通信，2020，22（12）：1.

[2] 李廣乾.什么是數據中臺？[J].中國信息界，2019（6）：72-75.

[3] 李巍巍.數據中臺技術在業務系統中的應用研究[J].現代信息科技，2019，3（21）：108-110.

[4] 杜棟，楊莉媛，謝炯. 企業中臺戰略研究——以國家電網公司為例[C]. 中國電機工程學會電力信息化專業委員會.生態互聯 數字電力——2019電力行業信息化年會論文集.中國電機工程學會電力信息化專業委員會：人民郵電出版社電信科學編輯部，2019：286-289.

[5] 于浩淼，趙月芳，陳盟，等.企業中臺建設思路與實踐方案[J].電信技術，2019（8）：78-80.

【通聯編輯：李雅琪】