基于Kudu 的電力輔助設(shè)備實(shí)時(shí)監(jiān)控業(yè)務(wù)解決方案

曹 成，陶繼群，鄭 湃

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

1 概述

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

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

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

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

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

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

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

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

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

方案1：Strom

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

方案2：Spark Streaming

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

3 Kudu 解決方案

3.1 Kudu 存儲(chǔ)系統(tǒng)

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

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

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

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

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

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

3.2 Kudu 實(shí)時(shí)數(shù)據(jù)查詢(xún)

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

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

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

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

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

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

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

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

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

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

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

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

3.4 Kudu API 接口服務(wù)

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

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

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

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

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

4 結(jié)束語(yǔ)

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