淺談智慧電科院數(shù)據(jù)中臺建設及關鍵技術

尹春林 楊政

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

關鍵詞：供電企業(yè);電科院;數(shù)據(jù)中臺

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

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

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

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

1 數(shù)據(jù)中臺建設

1.1 數(shù)據(jù)中臺的內涵

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

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

1.2 數(shù)據(jù)中臺的建設目標

電科院的目標是：建成“模型規(guī)范統(tǒng)一、數(shù)據(jù)完整全面、分析靈活智能”的數(shù)據(jù)中臺，實現(xiàn)多維度數(shù)據(jù)的統(tǒng)一存儲、管理與服務。

1.3 數(shù)據(jù)中臺設計的總體思路

企業(yè)中臺主要包括業(yè)務中臺、數(shù)據(jù)中臺和技術中臺以及企業(yè)中臺穩(wěn)定、安全、規(guī)范運行的保障體系。

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

2 數(shù)據(jù)中臺應用架構設計

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

2.1 應用架構

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

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

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

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

2.2 功能架構

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

處理域維護標準業(yè)務數(shù)據(jù)，提供給未來業(yè)務系統(tǒng)共享使用;

分析域完成數(shù)據(jù)分析所需的所有數(shù)據(jù)準備工作。

2.3技術架構

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

處理域為未來業(yè)務系統(tǒng)提供標準業(yè)務數(shù)據(jù)共享服務，處理域的數(shù)據(jù)可以發(fā)布到分析域供數(shù)據(jù)分析使用;

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

3 構建數(shù)據(jù)中臺的關鍵技術

3.1 構建數(shù)據(jù)中臺所需關鍵技術

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

3.2 數(shù)據(jù)采集傳輸

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

目前市面針對日志采集的有 Flume，Logstash，F(xiàn)ilebeat，F(xiàn)luentd ，rsyslog 幾種常見的框架，我們挑應用較廣泛的前兩者介紹下：

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

1）日志采集如何工作

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

2）數(shù)據(jù)傳輸 Kafka

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

3.3 數(shù)據(jù)存儲

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

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

3.4 數(shù)據(jù)計算&查詢

1）批計算和流計算

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

僅批處理框架：Hadoop MapReduce

僅流處理框架：Storm，Samza

混合框架：Spark，F(xiàn)link

篇幅所限，除了上文已經(jīng)提到的 Hadoop 生態(tài)外，我們再簡單科普下 Spark：

2）Spark 和 Flink

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

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

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

3）數(shù)據(jù)查詢

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

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

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

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

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

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

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

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

3.5 數(shù)據(jù)可視化及分析

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

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

可視化框架：

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

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

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

4 結語

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

參考文獻：

[1] 蔡菁菁.淺談利用數(shù)據(jù)中臺實現(xiàn)通信企業(yè)數(shù)字化轉型[J].中國新通信，2020，22（12）：1.

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

[3] 李巍巍.數(shù)據(jù)中臺技術在業(yè)務系統(tǒng)中的應用研究[J].現(xiàn)代信息科技，2019，3（21）：108-110.

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

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

【通聯(lián)編輯：李雅琪】