曹 成，陶繼群，鄭 湃

（江蘇中科院智能科學(xué)技術(shù)應(yīng)用研究院，江蘇 常州213164）

1 概述

江蘇中科院智能科學(xué)技術(shù)應(yīng)用研究院基于Hadoop架構(gòu)的分布式大數(shù)據(jù)平臺已經(jīng)搭建完成，以T+1 形式處理數(shù)據(jù)，目前已成功運行各類數(shù)據(jù)應(yīng)用和業(yè)務(wù)需求。但這種離線處理數(shù)據(jù)的方式已無法滿足目前的電力輔助設(shè)備的實時數(shù)據(jù)監(jiān)控需要，基于分布式文件存儲系統(tǒng)（HDFS）、分布式的高性能并行計算平臺（MapReduce）和Hive 的Hadoop 架構(gòu)無法實時加載數(shù)據(jù)和提供數(shù)據(jù)查詢分析；雖然可以在該架構(gòu)中添加HBase 存儲系統(tǒng)，HBase存儲系統(tǒng)雖然可以實現(xiàn)數(shù)據(jù)的快速插入和實時更新，但其并不適用于大批量的數(shù)據(jù)掃描工作[1]。目前，我院大數(shù)據(jù)平臺急需能夠?qū)崿F(xiàn)大批量數(shù)據(jù)實時讀寫和實時分析的解決方案。

Kudu 存儲系統(tǒng)是Cloudera 公司開發(fā)的可以實現(xiàn)多種一致性協(xié)議的列式存儲引擎，兼顧了數(shù)據(jù)更新實時性和分析速度，能夠與Hadoop 大數(shù)據(jù)平臺中的Hive、HDFS等組件形成互補。Kudu 存儲系統(tǒng)在滿足電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)實時查詢需求的同時，還能夠滿足監(jiān)控業(yè)務(wù)的實時分析，同時還提供了Kudu-API、Impala-JDBC 等連接方法[2]，向電力輔助設(shè)備的分析系統(tǒng)和展示系統(tǒng)提供快速的查詢和分析類的數(shù)據(jù)共享能力，滿足大數(shù)據(jù)平臺的實時類業(yè)務(wù)處理能力需求。

2 電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)應(yīng)用難點分析和相關(guān)解決方案

2.1 電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)應(yīng)用難點分析

電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)主要包括輸變電系統(tǒng)中的紅外熱成像、避雷器、驅(qū)鳥器、通風(fēng)裝置、端子箱等6大類輔助設(shè)備的數(shù)據(jù)實時采集入庫和實時查詢、實時分析和遠(yuǎn)程控制等。目前大數(shù)據(jù)平臺已對接電力輔助設(shè)備500 余臺，各類終端20000 余個，通過該監(jiān)控業(yè)務(wù)可以有效監(jiān)控變電站各類設(shè)備工作情況和實時報警等。

目前，江蘇中科院智能科學(xué)技術(shù)應(yīng)用研究院基于Hadoop 架構(gòu)的分布式大數(shù)據(jù)平臺主要完成各類工業(yè)離線數(shù)據(jù)的計算和分析工作，每日凌晨定時匯總前一天數(shù)據(jù)至歷史數(shù)據(jù)表單中，按業(yè)務(wù)要求完成離線計算任務(wù)，再將結(jié)果同步到結(jié)果表單中，供前臺系統(tǒng)調(diào)用。然而這種處理方式并不適用于電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)。主要有以下原因: 該監(jiān)控業(yè)務(wù)對底層數(shù)據(jù)庫的響應(yīng)時間要求極高，涉及的電流值、電壓值波動記錄存儲通常為秒級或者毫秒級，輕微的電流值和電壓值波動很可能造成電力設(shè)備供電異?；蚬收?。然而HDFS 存儲數(shù)據(jù)效率無法滿足這一需求，也無法支撐數(shù)據(jù)的動態(tài)更新和插入等數(shù)據(jù)庫DLL 操作[3]；在分析計算實時數(shù)據(jù)時，Hive 的大批量數(shù)據(jù)關(guān)聯(lián)查詢和計算效率偏低，計算時間偏長，達不到實時數(shù)據(jù)的計算需要；外網(wǎng)部署的客戶分析系統(tǒng)和展示系統(tǒng)獲取數(shù)據(jù)需要大數(shù)據(jù)平臺通過數(shù)據(jù)API 接口提供，但Hadoop 平臺提供的HadoopAPI 接口和Hive API 接口快速響應(yīng)的能力差，無法滿足實時性需求[4]?；谝陨戏治?，大數(shù)據(jù)平臺實時數(shù)據(jù)處理和讀取的能力缺陷導(dǎo)致其成為電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)的制約。為了滿足實時應(yīng)用的需要，平臺急需可以實現(xiàn)大批量實時讀寫、實時分析解決方案。

圖1 大數(shù)據(jù)平臺總體架構(gòu)圖

2.2 相關(guān)解決方案

為處理電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)，前期嘗試采用的解決方式有Strom 和Spark Streaming 兩種，但兩種方案最終均被證明無法滿足業(yè)務(wù)需求。

方案1：Strom

Storm 是毫秒級的流處理實時計算體系，Storm 的流處理過程是將實時應(yīng)用的計算任務(wù)寫好topology（拓?fù)洌┙Y(jié)構(gòu)然后等待數(shù)據(jù)進來分析，相似于Hadoop 的MapReduce 任務(wù)。其優(yōu)點是全內(nèi)存計算[5]，所以Storm 的速度相比Hadoop 非?？欤ㄆ款i是計算機內(nèi)存和CPU），缺點就是不夠靈活，數(shù)據(jù)吞吐量低，不能在中間執(zhí)行SQL 交互式查詢、復(fù)雜的轉(zhuǎn)換等[6]。對于電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)中的OLTP 場景并不適用。

方案2：Spark Streaming

Spark Streaming 是可以實現(xiàn)高吞吐量的、具備容錯機制的實時流數(shù)據(jù)的處理，Spark Streaming 的處理機制是接收實時的輸入數(shù)據(jù)流，并根據(jù)一定的時間間隔（秒級）拆分成一批批的數(shù)據(jù)，然后通過SparkEngine 處理批數(shù)據(jù)，最終得到處理后的結(jié)果[7]。但Spark Streaming 只是準(zhǔn)實時的，事務(wù)機制不夠完善，也不支持動態(tài)調(diào)整[8]。對于電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)來說，準(zhǔn)實時的存儲和分析數(shù)據(jù)并不能滿足實時需求。

3 Kudu 解決方案

3.1 Kudu 存儲系統(tǒng)

Kudu 的定位是在更新更加及時的基礎(chǔ)上實現(xiàn)更快的數(shù)據(jù)分析，HBASE 不適用于基于SQL 的數(shù)據(jù)分析方向，大批量數(shù)據(jù)獲取時的性能較差；HDFS 適合離線分析，不支持單條紀(jì)錄級別的update 操作，隨機讀寫性能差[9]，正因為HDFS 與HBASE 有以上缺點，Kudu 較好的解決了HDFS 與HBASE 的這些缺點，它不及HDFS 批處理快，也不及HBase 隨機讀寫能力強，但是反過來它比HBase 批處理快（適用于OLAP 的分析場景），而且比HDFS 隨機讀寫能力強（適用于實時寫入或者更新的場景），在更新更加及時的基礎(chǔ)上實現(xiàn)更快的數(shù)據(jù)分析。通過在Hadoop 大數(shù)據(jù)平臺中加入Kudu 存儲系統(tǒng)，江蘇中科院智能科學(xué)技術(shù)應(yīng)用研究院大數(shù)據(jù)平臺實現(xiàn)了對實時業(yè)務(wù)處理的能力。且Kudu 存儲系統(tǒng)可以和已有的Hive、Kafka、Impala 等組件無縫對接，從而服務(wù)上層中的數(shù)據(jù)應(yīng)用和ETL 流程[10]。引入Kudu 后的大數(shù)據(jù)平臺總體架構(gòu)如圖1 所示。

通過引入Kudu 存儲系統(tǒng)，江蘇中科院智能科學(xué)技術(shù)應(yīng)用研究院大數(shù)據(jù)平臺在保留現(xiàn)有離線業(yè)務(wù)的前提下，可以實現(xiàn)平臺對實時業(yè)務(wù)的處理能力。同時支持Python、JAVA 等語言開發(fā)人員直接調(diào)用Kudu API 數(shù)據(jù)接口，極大的拓展了大數(shù)據(jù)平臺的使用范圍[11]；同時Kudu 存儲系統(tǒng)還具備眾多優(yōu)點，如下：

我院使用的Kudu 存儲系統(tǒng)為開源版本，無版權(quán)費用支出，降低了項目開發(fā)成本。

數(shù)據(jù)開發(fā)工程師只需要向大數(shù)據(jù)平臺提交一份SQL腳本就可以同時處理和HDFS 和Kudu 存儲系統(tǒng)中的數(shù)據(jù)，不需要同時在兩個系統(tǒng)中都存儲數(shù)據(jù)，節(jié)省硬盤空間，方便快捷[12]。

Kudu 存儲系統(tǒng)可以和現(xiàn)有平臺中的租戶共用，不需要重新申請創(chuàng)建新的租戶，其主持多用租戶操作環(huán)境，有效避免了不同賬號的多源管理問題[13]。

Kudu 存儲系統(tǒng)開發(fā)門檻低，數(shù)據(jù)開發(fā)工程師無需掌握Kudu 底層原理，只需掌握SQL 語言和大數(shù)據(jù)平臺運維原理就可以快速上手，大大節(jié)約了學(xué)習(xí)成本。

3.2 Kudu 實時數(shù)據(jù)查詢

電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)對數(shù)據(jù)的實時性要求極高，從數(shù)據(jù)采集到數(shù)據(jù)入庫分析再到數(shù)據(jù)讀取整個數(shù)據(jù)流程不能超過2 秒，終端設(shè)備的電流值和電壓值入庫后需要再次和其他業(yè)務(wù)表單進行多表聯(lián)合查詢，并將結(jié)果及時反饋到分析系統(tǒng)和展示系統(tǒng)中。少量數(shù)據(jù)可以通過傳統(tǒng)型數(shù)據(jù)庫或HBase 進行處理。該方案無法滿足電力輔助設(shè)備監(jiān)控業(yè)務(wù)的大批量數(shù)據(jù)查詢的實時響應(yīng)要求。

使用Kudu 存儲系統(tǒng)+Impala 交互式SQL 解析引擎可以有效滿足電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)實時查詢的業(yè)務(wù)需求。Impala 是Cloudera 公司開發(fā)的一種高效率的SQL 查詢工具，采用內(nèi)存計算模型，對于分布式Shuffle，最大限度的利用服務(wù)器的內(nèi)存和CPU 資源。同時，Impala也有預(yù)處理和分析技術(shù)，表數(shù)據(jù)插入之后可以用COMPUTESTATS 指令來讓Impala 對行列數(shù)據(jù)深度分析，具有實時，批處理，多并發(fā)等優(yōu)點，其也允許開發(fā)人員使用Impala 的SQL 語法對Kudu 存儲系統(tǒng)中的tablets 插入、查詢、更新和刪除數(shù)據(jù)[14]。

對于電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)中的電流值和電壓值查詢業(yè)務(wù)，涉及跨數(shù)據(jù)庫多表關(guān)聯(lián)查詢、消除取值重復(fù)行查詢、大小比較查詢和分組聚集函數(shù)查詢、嵌套查詢等；其中分組聚集函數(shù)查詢和跨數(shù)據(jù)庫多表關(guān)聯(lián)查詢兩種業(yè)務(wù)最為典型，測試結(jié)果見表1，表2。

從表1、表2 測試結(jié)果可以看出，基于Kudu 和Impala 結(jié)合使用的解決方案完全能夠支撐電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)需要，跨數(shù)據(jù)庫大批量的數(shù)據(jù)查詢和分組聚集函數(shù)查詢響應(yīng)時間都達秒級，分析系統(tǒng)和展示系統(tǒng)展示的數(shù)據(jù)查詢結(jié)果和實時數(shù)據(jù)相差也為秒級，滿足精度要求極高的電流監(jiān)控和電壓監(jiān)控等需求。

表1 Kudu 存儲系統(tǒng)跨數(shù)據(jù)庫多表關(guān)聯(lián)查詢

3.3 Kudu 實時數(shù)據(jù)入庫和增量更新

電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)數(shù)據(jù)采集周期設(shè)置為實時采集，每秒采集各類終端設(shè)備20000 余個，電流值、電壓值、溫濕度、風(fēng)速、聲波值等各類數(shù)值500 多項，約1.5 萬余條數(shù)據(jù)。Hadoop 大數(shù)據(jù)平臺通過結(jié)合Kafka 流式處理平臺與分布式文件存儲系統(tǒng)對接采集實時數(shù)據(jù)。Kafka 通過O（1）的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對于即使數(shù)以TB 的消息存儲能夠保持長時間的穩(wěn)定性能[15]。

Kudu 數(shù)據(jù)存儲系統(tǒng)可以和Kafka 實時消息系統(tǒng)進行對接，從而實現(xiàn)電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)數(shù)據(jù)的加裝。Kudu 作為列式存儲引擎，滿足數(shù)據(jù)逐條采集，因此Kudu 適用于Kafka 的實時寫入要求，數(shù)據(jù)入庫效率極高，大數(shù)據(jù)平臺每秒可入庫約10 萬余條?；贙udu 的流式數(shù)據(jù)實時入庫測試結(jié)果見表3。由此可見，使用Kudu 結(jié)合Kafka，電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)數(shù)據(jù)每秒2 萬余條數(shù)據(jù)采集至Kudu 存儲系統(tǒng)中的時間完全可以達到秒級，滿足監(jiān)控業(yè)務(wù)的實時性要求。

表2 Kudu 存儲系統(tǒng)分組聚集函數(shù)查詢

表3 基于Kudu 的流式數(shù)據(jù)入庫測試結(jié)果

Hadoop 大數(shù)據(jù)平臺的離線數(shù)據(jù)倉庫Hive，在數(shù)據(jù)的提取、裝載和轉(zhuǎn)化等方面具有優(yōu)勢，但Hive 的執(zhí)行效率偏低、調(diào)優(yōu)困難、粒度較粗、每次執(zhí)行Hive 都會自動生成Mapreduce 作業(yè)，通常情況下不夠智能化，每次都會產(chǎn)生大量的I/O 開銷、平臺內(nèi)存被長期占用，因此Hive 無法支持批量數(shù)據(jù)的增量更新和修改。Kudu 存儲系統(tǒng)可以用以下方式實現(xiàn)數(shù)據(jù)增量更新：每張Kudu 表都會被分成若干個tablet，每個tablet 包括MetaData 元信息及若干個RowSet。執(zhí)行數(shù)據(jù)寫入操作時，系統(tǒng)都會在Tablet 中的所有RowSet 中進行查找，驗證等待寫入數(shù)據(jù)相同主鍵的記錄是否沖突。如果master 校驗通過，則返回表的分區(qū)、tablet 與其對應(yīng)的tserver 給client；如果校驗失敗則報錯給client，再次經(jīng)過一致性算法校驗通過后，tserver 會將寫入請求預(yù)寫到WAL 日志，用來server 服務(wù)器宕機后的恢復(fù)操作。插入的數(shù)據(jù)寄存在Tablet 的MemRowSet 中，一旦MemRowSet 的大小達到1G 或120s 后，MemRowSet會flush 成一個或DiskRowSet，用來將數(shù)據(jù)持久化存儲，同時再次生成MemRowSet 繼續(xù)接收新的數(shù)據(jù)請求，如此循環(huán)[16]。Kudu 寫入數(shù)據(jù)的工作機制如圖2 所示。

圖2 Kudu 寫入數(shù)據(jù)的工作機制

3.4 Kudu API 接口服務(wù)

電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)不僅需要在分析系統(tǒng)和展示系統(tǒng)中實時展示和應(yīng)用，同時需要為企業(yè)提供數(shù)據(jù)API 服務(wù)，盡管Hadoop 大數(shù)據(jù)平臺通過提供抽象操作和并行編程接口，以Java API 的方式實現(xiàn)了接口的封裝，但由于MapReduce 機制原因，企業(yè)在調(diào)取該類數(shù)據(jù)API 接口時需要等待很長一段時間才能返回結(jié)果[17]，企業(yè)用戶對于這種問題的敏感度極高，無法容忍該響應(yīng)時間過長的問題。

企業(yè)用戶通過調(diào)用平臺的API 數(shù)據(jù)接口和自身系統(tǒng)接口數(shù)據(jù)或數(shù)據(jù)庫數(shù)據(jù)進行對接，通過一定的分析運算后加載在企業(yè)自用系統(tǒng)中，該類需求就需要盡量縮減企業(yè)調(diào)用大數(shù)據(jù)平臺API 接口并返回有效值的響應(yīng)時間。Kudu 存儲系統(tǒng)提供的Kudu API 接口服務(wù)正好可以滿足這類要求響應(yīng)時間短，操作簡潔、修改方便的需求，Kudu官方推薦使用Java API 或Python API 來完成Kudu 存儲系統(tǒng)中的數(shù)據(jù)讀寫操作，且Kudu 每張表單均有主鍵可作為索引進一步縮短了響應(yīng)時間，Kudu API 在進行調(diào)用時運算均在數(shù)據(jù)磁盤上進行，此種方式處理簡單的聯(lián)機事務(wù)（OLTP）時是可行的；單在聯(lián)機分析處理（OLAP）方面，采用Impala-JDBC 的連接方式處理Kudu 存儲系統(tǒng)數(shù)據(jù)更為高效，Impala 自身并沒有存儲系統(tǒng)，在進行數(shù)據(jù)運算時，Impala 會將Kudu 存儲系統(tǒng)和HDFS 存儲系統(tǒng)中的數(shù)據(jù)放入內(nèi)存中進行計算；基于大數(shù)據(jù)平臺512G的運算內(nèi)存，將數(shù)據(jù)放入內(nèi)存中計算的效率遠(yuǎn)高于在數(shù)據(jù)磁盤上運算效率[18]。

為提升企業(yè)用戶調(diào)用大數(shù)據(jù)平臺數(shù)據(jù)的效率和充分利用大數(shù)據(jù)平臺內(nèi)存資源，針對OLAP（聯(lián)機分析處理）和OLTP（聯(lián)機事務(wù)處理）兩種不同的業(yè)務(wù)場景均選擇使用Impala-JDBC 的連接方式與企業(yè)系統(tǒng)進行數(shù)據(jù)交互，其性能測試結(jié)果見表4。

表4 基于Impala-JDBC 的OLAP 和OLTP 接口性能測試結(jié)果

從測試結(jié)果可以看出，基于Impala-JDBC 的OLAP和OLTP 接口性能可以滿足大數(shù)據(jù)平臺對企業(yè)提供電力輔助設(shè)備的實時監(jiān)控業(yè)務(wù)的OLAP（聯(lián)機分析處理）和OLTP（聯(lián)機事務(wù)處理）兩種不同的業(yè)務(wù)場景的需求，達到了快速響應(yīng)、提升企業(yè)用戶使用體驗的要求。

4 結(jié)束語

綜上所述，Kudu 存儲系統(tǒng)解決了Hadoop 大數(shù)據(jù)平臺對實時數(shù)據(jù)的處理短板，Kudu 存儲系統(tǒng)部署以來，高效、穩(wěn)定的完成了實時數(shù)據(jù)入庫、數(shù)據(jù)的增量更新、實時查詢、對外提供高效的API 數(shù)據(jù)接口服務(wù)等工作，在電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)中發(fā)揮了極為重要的作用。后續(xù)在保障數(shù)據(jù)安全的前提下將不斷調(diào)優(yōu)Kudu 存儲系統(tǒng)性能，進一步提升Kudu 存儲系統(tǒng)在電力輔助設(shè)備實時監(jiān)控業(yè)務(wù)中的能力，為后期進行的深度數(shù)據(jù)挖掘做足準(zhǔn)備。