基于SQL-on-Hadoop查詢引擎的日志挖掘及其應(yīng)用

何明，常盟盟，劉郭洋，顧程祥，彭繼克

(1.北京工業(yè)大學(xué) 信息學(xué)部,北京 100124； 2. 海通證券股份有限公司 信息技術(shù)管理部，上海 200001)

基于SQL-on-Hadoop查詢引擎的日志挖掘及其應(yīng)用

何明1，常盟盟1，劉郭洋2，顧程祥2，彭繼克2

(1.北京工業(yè)大學(xué) 信息學(xué)部,北京 100124； 2. 海通證券股份有限公司 信息技術(shù)管理部，上海 200001)

隨著計(jì)算機(jī)和網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展以及數(shù)據(jù)獲取手段的不斷豐富，海量數(shù)據(jù)的實(shí)時(shí)處理需求日益增多，傳統(tǒng)的日志分析技術(shù)在處理海量數(shù)據(jù)時(shí)存在計(jì)算瓶頸。大數(shù)據(jù)時(shí)代下，隨著開放式處理平臺的發(fā)展，能夠處理大規(guī)模且多樣化數(shù)據(jù)的大數(shù)據(jù)處理系統(tǒng)應(yīng)運(yùn)而生。為了讓原有的業(yè)務(wù)能夠充分利用Hadoop的優(yōu)勢，本文首先研究了基于大數(shù)據(jù)技術(shù)的網(wǎng)絡(luò)日志分析方法，構(gòu)建了網(wǎng)絡(luò)日志分析平臺以實(shí)現(xiàn)萬億級日志采集、解析、存儲和高效、靈活的查詢與計(jì)算。對比分析了Hive、Impala和Spark SQL這3種具有代表性的SQL-on-Hadoop查詢系統(tǒng)實(shí)例，并展示了這類系統(tǒng)的性能特點(diǎn)。采用TPC-H測試基準(zhǔn)對它們的決策支持能力進(jìn)行測試及評估，通過對實(shí)驗(yàn)數(shù)據(jù)的分析和解釋得到了若干有益的結(jié)論。實(shí)現(xiàn)了海量日志數(shù)據(jù)計(jì)算與分析在證券領(lǐng)域的幾種典型應(yīng)用，為進(jìn)一步的研究工作奠定了基礎(chǔ)。

大數(shù)據(jù)；日志分析；數(shù)據(jù)挖掘；Hadoop；查詢引擎；數(shù)據(jù)采集；索引存儲；證券行業(yè)

隨著互聯(lián)網(wǎng)的飛速發(fā)展和逐層推進(jìn)，企業(yè)內(nèi)部的規(guī)模和業(yè)務(wù)量也不斷增加，致使數(shù)據(jù)量猛增。企業(yè)網(wǎng)絡(luò)中的計(jì)算機(jī)設(shè)備和網(wǎng)絡(luò)組件持久地記錄著海量的網(wǎng)絡(luò)日志。日志文件是系統(tǒng)軟硬件信息和用戶行為信息記錄的載體，通過日志分析能夠?qū)崟r(shí)獲取設(shè)備、網(wǎng)絡(luò)運(yùn)行狀態(tài)和用戶行為交易等信息，有利于保證系統(tǒng)的穩(wěn)定運(yùn)行和來往業(yè)務(wù)的安全性。目前，較為成熟的日志集中管理系統(tǒng)解決了各類設(shè)備、服務(wù)器和應(yīng)用日志的采集與格式統(tǒng)一問題，日志分析也從最初簡單的正則匹配向結(jié)構(gòu)化查詢、報(bào)表和預(yù)測演進(jìn)[1]。越來越多的行業(yè)領(lǐng)域面臨海量(volume)、高速(velocity)和多樣(variety)等多V挑戰(zhàn)，大數(shù)據(jù)時(shí)代已真正到來[2-4]。

互聯(lián)網(wǎng)中海量的信息為證券領(lǐng)域日志分析提供了豐富的數(shù)據(jù)支撐，如何利用大數(shù)據(jù)分析技術(shù)進(jìn)行實(shí)時(shí)準(zhǔn)確的日志分析成為重要的科學(xué)問題。在大型證券公司的內(nèi)部網(wǎng)絡(luò)中，隨著網(wǎng)絡(luò)帶寬的迅速擴(kuò)容日志量急劇增長且日志源眾多，包括網(wǎng)上交易日志、移動證券日志和網(wǎng)站日志等主要系統(tǒng)的日志。以海通證券為例，目前在全國設(shè)有幾十個(gè)節(jié)點(diǎn)，幾百臺服務(wù)器，峰值在線用戶約幾十萬，每個(gè)節(jié)點(diǎn)各部署了1臺負(fù)載均衡設(shè)備。網(wǎng)上交易應(yīng)用服務(wù)器全天24小時(shí)將客戶請求數(shù)據(jù)與應(yīng)答數(shù)據(jù)實(shí)時(shí)或小批量定時(shí)寫入磁盤日志文件，每臺交易應(yīng)用服務(wù)器的日志文件大小為100 MB～3 GB，總計(jì)在100 GB左右。同時(shí)，每臺網(wǎng)上交易應(yīng)用服務(wù)器還會生成一份發(fā)送給柜臺程序的網(wǎng)關(guān)日志數(shù)據(jù)。此外，各節(jié)點(diǎn)負(fù)載均衡設(shè)備的日志采用SNMP協(xié)議進(jìn)行采集，采集每個(gè)站點(diǎn)的網(wǎng)絡(luò)流量、用戶連接數(shù)據(jù)。每日合計(jì)有3億多條日志，總量共計(jì)約300 GB。僅上述3類日志存儲一年就將產(chǎn)生約108 TB數(shù)據(jù)，若接入更多設(shè)備、操作系統(tǒng)、業(yè)務(wù)平臺日志，數(shù)據(jù)規(guī)模則更大。傳統(tǒng)的日志處理方法在面對海量大數(shù)據(jù)時(shí)，其存儲方式和計(jì)算能力都受到了限制，因此分布式存儲和并行計(jì)算成為了新的發(fā)展趨勢。如何采集、傳輸、存儲、分析及應(yīng)用大規(guī)模的日志數(shù)據(jù)，已成為證券行業(yè)在大數(shù)據(jù)時(shí)代下面臨的重大挑戰(zhàn)。

Hadoop[5]分布式處理平臺為大數(shù)據(jù)存儲和分析提供了有效的解決方案。在大數(shù)據(jù)應(yīng)用方面，雖然學(xué)術(shù)界和工業(yè)界對大數(shù)據(jù)的關(guān)注各有側(cè)重，但有一個(gè)共同的認(rèn)識：大數(shù)據(jù)只有和具體的行業(yè)深入結(jié)合才能落到實(shí)處，才能產(chǎn)生真正的價(jià)值。通過前期的積累和算法的升級，大數(shù)據(jù)應(yīng)用將對證券行業(yè)產(chǎn)生革命性影響。

本文的主要貢獻(xiàn)如下：

1)研究基于SQL-on-Hadoop查詢系統(tǒng)的性能特點(diǎn)，對比分析了Hive、Impala和Spark SQL這3種具有代表性的SQL-on-Hadoop查詢系統(tǒng)實(shí)例，構(gòu)建了海量日志采集與實(shí)時(shí)計(jì)算分析平臺；

2)采用TPC-H測試基準(zhǔn)對它們的決策支持能力進(jìn)行測試及評估，通過對實(shí)驗(yàn)數(shù)據(jù)的分析和解釋得到了若干有益的結(jié)論；

3)實(shí)現(xiàn)了大規(guī)模網(wǎng)絡(luò)日志數(shù)據(jù)分析與計(jì)算在證券領(lǐng)域的幾種典型應(yīng)用。

1 相關(guān)工作

大數(shù)據(jù)技術(shù)在互聯(lián)網(wǎng)領(lǐng)域海量網(wǎng)絡(luò)日志分析和處理過程中得到了廣泛的應(yīng)用，日志分析系統(tǒng)主要包括日志同步、數(shù)據(jù)存儲、分布式計(jì)算和數(shù)據(jù)倉庫等相關(guān)技術(shù)。開源的日志分析系統(tǒng)如Facebook的Scribe[6]，Apache的Chukwa[7]，LinkedIn的Kafka[8]，Cloudera的Flume[9]等。Facebook公司龐大的用戶群體產(chǎn)生了大量的信息與社交數(shù)據(jù)，現(xiàn)有8億多用戶的信息需要處理，產(chǎn)生了大規(guī)模的數(shù)據(jù)和日志；同時(shí)，離線的大規(guī)模數(shù)據(jù)分析計(jì)算已無法滿足實(shí)時(shí)數(shù)據(jù)分析的用戶需求， Scribe結(jié)合了Google的分布式文件系統(tǒng)GFS[10](google file system，GFS)。操作流程是收集異構(gòu)數(shù)據(jù)源上的日志，集中存儲到分布式文件系統(tǒng)，從而在此基礎(chǔ)上進(jìn)行統(tǒng)計(jì)分析。Amazon基于S3和EC2，開發(fā)了Amazon EMR來提供大數(shù)據(jù)處理服務(wù)，可以將數(shù)據(jù)分布在可重新調(diào)整大小的EC2集群中進(jìn)行處理，包括日志分析、索引、數(shù)據(jù)倉庫和機(jī)器學(xué)習(xí)等。阿里巴巴集團(tuán)使用目前國內(nèi)最大的Hadoop集群“云梯”進(jìn)行各部門產(chǎn)品的線上數(shù)據(jù)備份、系統(tǒng)日志以及爬蟲數(shù)據(jù)分析，并建設(shè)開放平臺為個(gè)人和企業(yè)提供各種增值服務(wù)。騰訊微信等應(yīng)用產(chǎn)品擁有上億級別的用戶，產(chǎn)生了海量的個(gè)人用戶日志數(shù)據(jù)，這些數(shù)據(jù)中蘊(yùn)藏著巨大的商業(yè)價(jià)值，并提出“大數(shù)據(jù)營銷”的概念。人人網(wǎng)基于Hadoop的Hive[11]、HBase[12]和Streaming[13]組件，構(gòu)建了SNS推薦平臺進(jìn)行分析計(jì)算、內(nèi)容推薦等工作。百度的高性能計(jì)算系統(tǒng)規(guī)劃中的架構(gòu)將有超過1萬個(gè)節(jié)點(diǎn)，每天的數(shù)據(jù)生成量在10 PB以上，主要用于日志的存儲分析以及統(tǒng)計(jì)挖掘等功能。Wei等設(shè)計(jì)了Analysis Farm摒棄了傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(relational database management system，RDBMS)，利用NoSQL(not only SQL)數(shù)據(jù)庫MongoDB構(gòu)建了可橫向擴(kuò)展的日志分析平臺，以支撐NetFlow日志存儲和查詢[14]。Rabkin等設(shè)計(jì)了基于Hadoop的日志收集和分析系統(tǒng)Chukwa，日志處理程序在MapReduce框架上開發(fā)[15]。文獻(xiàn)[16-17]從原位分析的角度出發(fā)，分別實(shí)現(xiàn)了針對大規(guī)模日志分析的MapReduce(In-situ MapReduce)和Continuous處理機(jī)制， 但MapReduce模型計(jì)算代價(jià)很大，并不能很好地支持迭代運(yùn)算。

然而HDFS[18]和MapReduce[19]大數(shù)據(jù)處理架構(gòu)主要是針對靜態(tài)數(shù)據(jù)的批處理，在運(yùn)算過程中產(chǎn)生的大量I/O操作無法保證處理過程的實(shí)時(shí)性。針對上述問題，本文將研究基于SQL-on-Hadoop查詢引擎構(gòu)建網(wǎng)絡(luò)日志分析平臺，通過使用廣泛的標(biāo)準(zhǔn)SQL語言來實(shí)現(xiàn)快速、靈活的查詢性能。通過利用TB級日志數(shù)據(jù)對存儲、查詢性能進(jìn)行測試、優(yōu)化和比較，構(gòu)建具有穩(wěn)定性、高性能、可擴(kuò)展性、易用性和安全性的網(wǎng)絡(luò)日志統(tǒng)一采集查詢和監(jiān)控平臺，以滿足對TB或PB級容量和萬億日志管理的應(yīng)用需求，為面向證券行業(yè)的日志大數(shù)據(jù)分析及其應(yīng)用提供技術(shù)支撐。

2 基于Hadoop的結(jié)構(gòu)化數(shù)據(jù)處理

網(wǎng)絡(luò)日志源的種類具有多樣性的特點(diǎn)，包括結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)。不同類型的日志存儲方式有所不同。日志管理系統(tǒng)的采集器對不同格式的日志進(jìn)行標(biāo)準(zhǔn)化處理，從而以結(jié)構(gòu)化的形式進(jìn)行日志存儲和分析。本文所采用的源數(shù)據(jù)主要分為文本數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)和實(shí)時(shí)/準(zhǔn)實(shí)時(shí)數(shù)據(jù)等。

2.1 HDFS數(shù)據(jù)采集

網(wǎng)絡(luò)日志的生成是分布式的，與傳統(tǒng)的日志管理系統(tǒng)一樣，日志采集是本文平臺的基礎(chǔ)。本文平臺采集的日志直接存儲在Hadoop文件系統(tǒng)(HDFS)中，由于平臺構(gòu)建于Hadoop之上，能夠處理海量分布式存儲的日志數(shù)據(jù)，同時(shí)易于水平擴(kuò)展，本文的日志數(shù)據(jù)基本流程按功能可劃分為5層，如圖1所示。

1)原始數(shù)據(jù)層：業(yè)務(wù)上完成日志格式梳理，系統(tǒng)運(yùn)行日志支持實(shí)時(shí)訪問和采集接口。

2)數(shù)據(jù)采集層：主要負(fù)責(zé)通用的日志數(shù)據(jù)解析、高效采集和安全可控。

3)數(shù)據(jù)處理層：主要包括對日志數(shù)據(jù)的批量式處理和實(shí)時(shí)處理。

4)數(shù)據(jù)服務(wù)層：主要提供標(biāo)準(zhǔn)的數(shù)據(jù)訪問接口ODBC、JDBC、HIVE等。

5)數(shù)據(jù)展示層：實(shí)現(xiàn)實(shí)時(shí)監(jiān)控類和報(bào)表類數(shù)據(jù)的展示。

圖1 日志數(shù)據(jù)處理基本流程Fig.1 Basic log data processing framework

根據(jù)應(yīng)用需求，本文日志的采集方式分為以下3種。

1)文件導(dǎo)入：對已分布在個(gè)服務(wù)器磁盤的日志文件，經(jīng)網(wǎng)絡(luò)文件系統(tǒng)掛載，直接將日志文件導(dǎo)入HDFS。該方式允許日志文件批量可靠導(dǎo)入，可在網(wǎng)絡(luò)利用率低谷時(shí)段進(jìn)行傳送。

2)流數(shù)據(jù)導(dǎo)入：基于Apache Flume[20]構(gòu)建，實(shí)現(xiàn)多個(gè)日志源數(shù)據(jù)實(shí)時(shí)匯聚，接收網(wǎng)上交易應(yīng)用服務(wù)器和網(wǎng)絡(luò)設(shè)備發(fā)送的日志。

3)RDBMS導(dǎo)入：為實(shí)現(xiàn)與現(xiàn)有日志系統(tǒng)兼容，基于Apache Sqoop[21]，實(shí)現(xiàn)與Oracle、MySQL和PostgreSQL等RDBMS對接，支持直接導(dǎo)入存儲在上述數(shù)據(jù)庫中的數(shù)據(jù)記錄。Sqoop同時(shí)可以將SQL-on-Hadoop處理結(jié)果輸出到RDBMS，供現(xiàn)有的日志分析系統(tǒng)進(jìn)行報(bào)表及可視化處理。

2.2 SQL-on-Hadoop查詢引擎

SQL是結(jié)構(gòu)化數(shù)據(jù)的查詢語言，SQL-on-Hadoop是構(gòu)建在Hadoop之上的SQL查詢系統(tǒng)，利用Hadoop能夠進(jìn)行海量數(shù)據(jù)(TB級別以上)的處理。目前已有的SQL-on-Hadoop系統(tǒng)大致可以分為兩大類：第一類將SQL查詢轉(zhuǎn)換為Map-Reduce job；第二類系統(tǒng)基于MPP(massively parallel processing)的設(shè)計(jì)方式，僅僅使用Hadoop作為存儲引擎，上層自行實(shí)現(xiàn)分布式查詢的邏輯。第一類系統(tǒng)的代表是Facebook的Hive。Hive是原始的SQL-on-Hadoop解決方案。它是一個(gè)開源的Java項(xiàng)目，能夠?qū)QL轉(zhuǎn)換成一系列可以在標(biāo)準(zhǔn)的Hadoop TaskTrackers上運(yùn)行的MapReduce任務(wù)。如圖2中的Hive架構(gòu)部分所示，Hive通過一個(gè)metastore(本身就是一個(gè)數(shù)據(jù)庫)存儲表模式、分區(qū)和位置以期提供像MySQL一樣的功能。它支持大部分MySQL語法，同時(shí)使用相似的 database/table/view約定組織數(shù)據(jù)集。Hive內(nèi)部機(jī)制是基于MapReduce，從而導(dǎo)致了計(jì)算過程中消耗大量的I/O，降低了運(yùn)行效率。Impala[22]是由Cloudera構(gòu)建的一個(gè)針對Hadoop的開源的MPP(massively parallel processing)“交互式”SQL查詢引擎。Impala同樣提供了一種SQL查詢方法，如圖2中的Impala架構(gòu)部分所示，與Hive不同的是，Impala并沒有使用MapReduce執(zhí)行查詢，而是使用了自己的執(zhí)行守護(hù)進(jìn)程操作本地磁盤文件。由于沒有MapReduce開銷以及磁盤I/O、查詢語句編譯等一系列優(yōu)化，Impala通常要比Hive具有更快的數(shù)據(jù)訪問性能[23]。Impala共享Hive的metastore，可直接與Hive管理的數(shù)據(jù)互操作。Spark[24]使用輕量級的線程作為執(zhí)行器，減少了執(zhí)行作業(yè)的開銷，同時(shí)提高了調(diào)度的響應(yīng)速度，如圖2中的Spark部分所示。Spark SQL是在Spark之上搭建的SQL查詢引擎，支持在Spark中使用Sql、HiveSql、Scala中的關(guān)系型查詢表達(dá)式。

圖2 Hadoop、Hive、Impala與Spark執(zhí)行結(jié)構(gòu)圖Fig.2 Structure for implementation of Hadoop, Hive, Impala and Spark

2.3 結(jié)構(gòu)化數(shù)據(jù)存儲與壓縮

目前，很多研究者提出了在Hadoop中優(yōu)化結(jié)構(gòu)化數(shù)據(jù)存儲的方法。He等[25]提出的RCFile格式旨在提高數(shù)據(jù)導(dǎo)入和處理效率。它首先將數(shù)據(jù)水平分割為多個(gè)行組(row-group)，然后對每個(gè)組內(nèi)的數(shù)據(jù)垂直分割成列存儲。列存儲將數(shù)據(jù)表同一列的數(shù)據(jù)連續(xù)存放，當(dāng)查詢只涉及部分列時(shí)，可大幅減少所需讀取的數(shù)據(jù)量。ORC(optimized RCFile)是對RCFile的改進(jìn)，解決其在數(shù)據(jù)類型和性能上的多個(gè)局限性，改善查詢和空間利用效率。Parquet是Hadoop生態(tài)圈中一種新型列式存儲格式，靈感來自于2010年Google發(fā)表的Dremel論文[26]，它可以兼容Hadoop生態(tài)圈中大多數(shù)生態(tài)框架(Hadoop、Spark等)，被多種查詢引擎支持(Hive、Impala、Spark SQL、Drill等)，并且它與語言和平臺無關(guān)的。表1比較了本文2.2節(jié)描述的3種查詢引擎從HDFS上讀取多種格式的數(shù)據(jù)格式的支持。Text是原始的文本數(shù)據(jù)，通常為CSV或其他特定字符分隔。Hive的格式支持更為全面，由于Impala和Hive共享metastore，因此本文平臺實(shí)際應(yīng)用中通常由Hive導(dǎo)入數(shù)據(jù)而后臺使用Spark SQL查詢。

表1Hive、Impala和SparkSQL數(shù)據(jù)格式支持比較

Table1DataformatcomparisonofHive,ImpalaandSparkSQL

數(shù)據(jù)格式HiveImpalaSparkSQL查詢插入查詢插入查詢插入Text√√√√√√RCFile√√√———ORC√√————Parquet√√√√√√

數(shù)據(jù)壓縮是另一種性能優(yōu)化方法。壓縮一方面節(jié)省存儲空間，另一方面在相同磁盤I/O速度可讀寫更多記錄。Hive、Impala和Spark SQL均支持直接查詢壓縮的數(shù)據(jù)文件，常用壓縮算法有Gzip/Zlib和側(cè)重于解壓縮速度的Snappy。ORC格式本身已內(nèi)嵌輕量級的壓縮機(jī)制。

2.4 結(jié)構(gòu)化數(shù)據(jù)處理算法

RDD數(shù)據(jù)集包含對父RDD的一組依賴，這種依賴描述了RDD之間的傳承關(guān)系。RDD將操作分為兩類：Transformation與Action。Transformation操作不執(zhí)行運(yùn)算，只有當(dāng)Action操作時(shí)才觸發(fā)運(yùn)算。在RDD的實(shí)現(xiàn)機(jī)制中，基于迭代器的接口實(shí)現(xiàn)原理使得數(shù)據(jù)的訪問更加高效，同時(shí)避免了大量中間結(jié)果對內(nèi)存的消耗。Spark SQL包含了結(jié)構(gòu)化數(shù)據(jù)和數(shù)據(jù)之上進(jìn)行運(yùn)算的更多信息，Spark SQL使用這些信息進(jìn)行優(yōu)化，使得結(jié)構(gòu)化數(shù)據(jù)的操作更加高效和方便，基于Spark SQL的數(shù)據(jù)操作流程如下。

算法1 SparkSQLonRdd(lt;inputgt;,lt;contextgt;)

輸入Kafka輸入數(shù)據(jù)流input，Spark上下文context;

輸出分布式集合dataframe。

1)DStream line:Kafka-gt;DStream(input)；

2)獲取Kafka流數(shù)據(jù)輸入；

3)SqlContext sc = new SqlContext(context)；

4)DStreamlt;Rowgt; rdd=line.map；

5)new Function；

6)public Row call(T) {}；

7)創(chuàng)建Row對象；

8)Listlt;StructFieldgt; sf= new；Listlt;StructFieldgt;()；

9)Struct Fields.add(CreateDataType(lt;Columngt;))；

10)重復(fù)步驟9)創(chuàng)建邏輯表結(jié)構(gòu)；

11)Struct Type st: DataTypes.CreateStructType(sf)；

12)DataFrame df :

13)sc-gt;DataFrame(rdd, st)；

14)df.RegisterTable(lt;Table Namegt;)；

15)DataFrame dataframe=sc.sql(lt;Sql Querygt;)；

16)Return dataframe。

算法2 RddProcessing(lt;inputgt;)

輸入Kafka輸入數(shù)據(jù)流input；

輸出數(shù)據(jù)集對象record。

1)數(shù)據(jù)采集與預(yù)處理

①SparkConf conf = new SparkConf()；

②創(chuàng)建上下文對象；

③StreamingContext(conf, Interval)；

④Maplt;E,Tgt; Offsets=kafka.getOffset()；

⑤獲取kafka讀取偏移量；

⑥D(zhuǎn)Stream stream；

⑦KafkaUtils.createDStream(input)；

⑧Return stream。

2)RDD數(shù)據(jù)處理

①stream.foreachRDD；

②new VoidFunctionlt;RDDgt;gt;()；

③call(RDDlt;MessageAndMetadatagt; rdd)；

④HasOffsetRanges offrange = rdd.rdd()；

⑤合并請求應(yīng)答，并解析存儲數(shù)據(jù)；

⑥r(nóng)dd.mapPartitionsToPair；

⑦ new FlumeKafkaFunction()；

⑧foreachPartition(ProceFunction())；

⑨kafka.setOffset(offrange)；

⑩保存kafka讀取偏移量。

3)ProceFunction數(shù)據(jù)后處理

①Iteratorlt;Tuple2lt;T, KafkaDatagt;gt; iter；

②while (iter.hasNext())；

③KafkaData data = iter.next()._2()；

④json = data.getData()；

⑤Record record =Object(json, class)；

⑥r(nóng)ecord.setCollect_time；

⑦data.getExtData(TIME))；

⑧Utils.save(item_topic, record)；

⑨Return record。

其中，RDD根據(jù)數(shù)據(jù)記錄的key對結(jié)構(gòu)進(jìn)行分區(qū)。分片數(shù)據(jù)采用迭代器Iterator流式訪問，hasNext方法是由RDD lineage上各個(gè)Transformation攜帶的閉包函數(shù)復(fù)合而成,使得對象被序列化，通過網(wǎng)絡(luò)傳輸?shù)狡渌?jié)點(diǎn)上進(jìn)行裝載運(yùn)算。Iterator每訪問一個(gè)元素，就對該元素應(yīng)用相應(yīng)的復(fù)合函數(shù)，得到的結(jié)果再流式地存儲。

3 平臺架構(gòu)與集群環(huán)境部署

3.1 平臺架構(gòu)與處理框架

本文基于Hadoop，構(gòu)建證券交易應(yīng)用服務(wù)器和網(wǎng)絡(luò)設(shè)備海量日志采集、解析、存儲與實(shí)時(shí)計(jì)算分析平臺，平臺的核心架構(gòu)如下。

1)數(shù)據(jù)采集層：負(fù)責(zé)實(shí)時(shí)采集來自通達(dá)信、恒生、核新的網(wǎng)上交易應(yīng)用服務(wù)器全天24小時(shí)的客戶請求應(yīng)答數(shù)據(jù)以及網(wǎng)絡(luò)設(shè)備日志數(shù)據(jù)，為大數(shù)據(jù)分析平臺提供數(shù)據(jù)源。

2)數(shù)據(jù)匯集層：將各個(gè)數(shù)據(jù)采集節(jié)點(diǎn)的日志數(shù)據(jù)源源不斷地匯集到各自的集群。

3)數(shù)據(jù)緩沖層：根據(jù)不同的Topic對海量日志數(shù)據(jù)進(jìn)行緩沖，有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。

4)數(shù)據(jù)分發(fā)與解析處理層：負(fù)責(zé)數(shù)據(jù)的解析、勾對、計(jì)算和分發(fā)。

5)數(shù)據(jù)存儲與計(jì)算層：用于存儲、管理日志數(shù)據(jù)，支持多維檢索、統(tǒng)計(jì)分析和查詢處理。

6)應(yīng)用層：負(fù)責(zé)面向終端用戶提供日志分析與管理的泛在接入，提供實(shí)時(shí)運(yùn)維監(jiān)控、實(shí)時(shí)預(yù)警、明細(xì)毫秒級查詢以及實(shí)時(shí)報(bào)表輸出等應(yīng)用。

可以看到，在這個(gè)大數(shù)據(jù)分析體系結(jié)構(gòu)中，系統(tǒng)支持TB級、PB級或者更大規(guī)模數(shù)據(jù)的分析和處理；系統(tǒng)可以處理結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，有良好的擴(kuò)展性?；谏鲜銎脚_結(jié)構(gòu)，本文設(shè)計(jì)了能夠有效地利用大數(shù)據(jù)技術(shù)解決海量系統(tǒng)訪問日志多條件實(shí)時(shí)快速查詢的處理框架，如圖3所示。

圖3 處理框架Fig.3 Processing framework

該處理框架能夠保證平臺系統(tǒng)如下的幾個(gè)特性。

1)實(shí)時(shí)性：實(shí)時(shí)采集Agent包，從產(chǎn)生時(shí)刻起到實(shí)時(shí)采集，再到傳輸?shù)綌?shù)據(jù)中心，整個(gè)時(shí)間間隔控制在1 s內(nèi)實(shí)時(shí)勾對、解析等計(jì)算，并保存到數(shù)據(jù)中心的集群，這個(gè)過程的時(shí)間間隔控制在3～5 s。

2)準(zhǔn)確性和完整性：傳輸通道實(shí)現(xiàn)不重傳、不漏傳、斷點(diǎn)續(xù)傳，保證數(shù)據(jù)完整性。

3)安全性：非對稱加密算法對傳輸?shù)娜罩緮?shù)據(jù)進(jìn)行加密，使用SSL/TLS協(xié)議，保障網(wǎng)絡(luò)傳輸通道的安全性。

4)穩(wěn)定性和可靠性：基于成熟的、經(jīng)過實(shí)踐驗(yàn)證穩(wěn)定可靠的Hadoop技術(shù)組件服務(wù)器節(jié)點(diǎn)非常容易實(shí)現(xiàn)橫向擴(kuò)展，分布式環(huán)境保障集群中的任意一臺服務(wù)器出現(xiàn)宕機(jī)時(shí)不影響系統(tǒng)的穩(wěn)定可靠運(yùn)行。

3.2 環(huán)境部署

基于Hadoop的網(wǎng)絡(luò)日志分析平臺在海通證券網(wǎng)絡(luò)信息中心的搭建部署，如圖4所示。共42臺服務(wù)器，其中11臺是Flume匯聚節(jié)點(diǎn)(256 GB內(nèi)存，2×600 GB，RAID1陣列)，5臺Kafka節(jié)點(diǎn)(256 GB內(nèi)存，2×600 GB，RAID1陣列)，3臺Couchbase節(jié)點(diǎn)(512 GB內(nèi)存，2×600 GB，RAID1陣列)，5臺Zookeeper節(jié)點(diǎn)(256 GB內(nèi)存，2×600 GB，RAID1陣列)，2臺作為Namenode(256 GB內(nèi)存，2×600 GB，RAID1陣列)，14臺是Datanode節(jié)點(diǎn)(256 GB內(nèi)存，2×600 GB，RAID1陣列，2×600 GB，RAID1陣列 +6×2 TB，RAID0陣列)，2臺Tomcat(256 GB內(nèi)存，2×600 GB，RAID1陣列)。

圖4 集群拓?fù)鋱DFig.4 Cluster topology

所有節(jié)點(diǎn)通過10 GB以太網(wǎng)互聯(lián)。Hadoop部署采用Cloudera的發(fā)行版，版本為CDH5.5.0，HDFS總?cè)萘拷?0 TB。接入日志分析平臺的數(shù)據(jù)來自網(wǎng)上交易應(yīng)用服務(wù)器日志數(shù)據(jù)和網(wǎng)絡(luò)設(shè)備日志數(shù)據(jù)。網(wǎng)上交易日志每天產(chǎn)生的記錄數(shù)約1.2億條，體積約100 GB；網(wǎng)絡(luò)設(shè)備日志數(shù)據(jù)日志每天的記錄數(shù)約650萬條，體積約6 GB。

4 實(shí)驗(yàn)與性能評估

4.1 實(shí)驗(yàn)環(huán)境與數(shù)據(jù)集

我們采用的實(shí)驗(yàn)環(huán)境為7臺物理測試機(jī)構(gòu)建的集群，選取2臺機(jī)器作為主節(jié)點(diǎn)，其余作為計(jì)算節(jié)點(diǎn)進(jìn)行SQL-on-Hadoop實(shí)驗(yàn)，測試集群拓?fù)淙鐖D5所示。

圖5 測試環(huán)境拓?fù)鋱DFig.5 Test environment topology

實(shí)驗(yàn)采用針對OLAP應(yīng)用的TPC-H測試基準(zhǔn)來評估執(zhí)行引擎的性能。TPC-H面向商務(wù)采購應(yīng)用，其數(shù)據(jù)庫模式遵循第三范式。性能評測基準(zhǔn)定義了22個(gè)復(fù)雜SELECT語句和2個(gè)更新數(shù)據(jù)語句，遵循SQL-92標(biāo)準(zhǔn)。數(shù)據(jù)庫的規(guī)模由自帶的擴(kuò)展因子(scale factor，SF)決定，有10個(gè)級別，從1 GB到100 TB不等供用戶選擇。TPC-H 基準(zhǔn)以每小時(shí)內(nèi)執(zhí)行的查詢數(shù)作為度量標(biāo)準(zhǔn)，在工業(yè)和科研領(lǐng)域當(dāng)中應(yīng)用廣泛。

文獻(xiàn)[23]討論了ORCFile和Parquet兩種列式存儲格式的性能差別，通過空間使用和查詢性能比較，認(rèn)為Parquet針對文本文件壓縮率較高，從而節(jié)省了HDFS的存儲空間，同時(shí)減小了磁盤I/O的開銷，但是解壓縮會占用部分計(jì)算資源，對性能有一定影響。因此，本文采用Parquet 緊湊的列存儲格式，并選用了壓縮比和解壓速度較為均衡的Snappy，相對原始文本日志節(jié)省了近70%的空間。

本文實(shí)驗(yàn)使用TPC-H 作為測試數(shù)據(jù)集，在SF=300的數(shù)據(jù)規(guī)模上進(jìn)行測試，其描述和相關(guān)壓縮處理如表2所示。

表2 實(shí)驗(yàn)數(shù)據(jù)集

4.2 性能評估

本文選擇SQL-on-Hadoop作為基礎(chǔ)查詢引擎，對3個(gè)引擎的處理時(shí)效性進(jìn)行分析。從表3中各個(gè)引擎的總運(yùn)行時(shí)間可以看出，Impala比Hive快了1.5倍，Spark SQL 比Hive快了2.7倍。

表3 查詢執(zhí)行時(shí)間比較

實(shí)驗(yàn)結(jié)果表明，Impala在Q1、Q6、Q12、Q15上的性能優(yōu)于Hive，查詢語句結(jié)構(gòu)如下：

SELECT

{

field1, field12,

SUM(field3) as alias1,

SUM(field4) as alias2,

……,

AVG(field5) as alias3,

……，

COUNT(*) as alias4

}

FROM TableExpression

WHERE

[field6 lt;= date′yyyy-mm-dd′-interval ′[DELTA]′ day (3)]

GROUP BY [field6, field7]

ORDER BY [field6, field7]

根據(jù)該語句的執(zhí)行計(jì)劃，可以判斷查詢時(shí)對整個(gè)表進(jìn)行了遍歷。對于Spark SQL而言，其在大多數(shù)查詢上的表現(xiàn)優(yōu)于Hive和Impala。由于Spark的接口豐富和SQL優(yōu)勢，在執(zhí)行查詢時(shí)的速度較快。

4.3 Q22資源消耗情況

Q22的查詢語句如下：

SELECT

cntrycode, COUNT(*) as numcust, sum(c_acctbal) as totacctbal

FROM (

SELECT substring(c_phone from 1 for 2) as cntrycode,

c_acctbal FROM customer

WHERE substring(c_phone from 1 for 2) in

(′[I1]′,′[I2]′,′[I3]′,′[I4]′,′[I5]′,′[16]′,′[I7]′)

and c_acctbal gt; (

SELECT AVG (c_acctbal)

FROM customer WHERE c_acctbal gt; 0.00

and substring (c_phone from 1 for 2) in

(′[1]′,′[12]′,′[13]′,′[14]′,′[15]′,′[16]′,′[I7]′))

and not exists (SELECT * FROM orders where o_custkey=c_custkey)

) as custsale

Group BY cntrycode ORDER BY cntrycode;

如圖6所示，Q22中作業(yè)由3個(gè)子查詢組成。子查詢S1對customer表進(jìn)行掃描并將結(jié)果保存到臨時(shí)表Temp1中；子查詢S2對Temp1進(jìn)行聚集操作AGG1后將結(jié)果保存到臨時(shí)表Temp2中；子查詢S3在與表Orders執(zhí)行聚集操作AGG2后依次與Temp1和Temp2進(jìn)行關(guān)聯(lián)操作求笛卡爾乘積AGG3然后排序。

圖6 Implementation of Q22Fig.6 Q22的執(zhí)行過程

實(shí)驗(yàn)分析對比了不同的查詢方式在運(yùn)行Q22時(shí)集群資源使用情況(如圖7～11所示)，包括CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤I/O。注意到，在查詢Q22執(zhí)行過程中，Impala對集群資源的占用是最少的，其次是Hive，Spark SQL占用資源最多。由于Spark SQL是基于內(nèi)存計(jì)算的框架，所以在內(nèi)存占用方面和磁盤讀取上更為明顯。

圖7 集群平均CPU使用率Fig.7 Average cluster CPU usage

由于Hive和Spark SQL均在JVM之上運(yùn)行，對CPU 和內(nèi)存的使用依賴于JVM。如圖7所示，Impala的CPU占用時(shí)間要明顯少于Hive和Spark SQL，這是由于Impala在執(zhí)行查詢過程中，在每個(gè)計(jì)算節(jié)點(diǎn)上運(yùn)行只占用一個(gè)CPU線程。而Hive和Spark SQL在CPU使用上的優(yōu)化完全依賴于JVM。如圖8所示，Impala和Hive內(nèi)存使用率明顯小于Spark SQL，同時(shí)使用線程來執(zhí)行耗費(fèi)資源較多的Executor Backend進(jìn)程。

圖8 集群內(nèi)存平均使用量Fig.8 Average cluster memory usage

在磁盤性能方面，Impala和Hive的磁盤讀取速率優(yōu)于Spark SQL。從圖9可以看出，Hive和Impala數(shù)據(jù)訪問量在S1時(shí)相對一致，高于SparkSQL。在S2中，Impala數(shù)據(jù)訪問量較小，Hive次之，SparkSQL最高。在圖10中，Impala在S1和S2執(zhí)行結(jié)束后將結(jié)果寫入HDFS時(shí)，對磁盤的寫入速率迅速增加。

圖9 集群磁盤讀取總速率Fig.9 Cluster disk read speed

圖10 集群磁盤寫入總速率Fig.10 Cluster disk write speed

在圖11中，Impala在最后一個(gè)階段的網(wǎng)絡(luò)流量迅速增長，主要由于執(zhí)行過程中的內(nèi)部表連接產(chǎn)生的結(jié)果通過網(wǎng)絡(luò)傳輸給其他節(jié)點(diǎn)導(dǎo)致。

圖11 集群網(wǎng)絡(luò)流量Fig.11 Cluster network traffic

綜上所述，Spark SQL執(zhí)行效率相對較快，它的查詢速度比Hive要快2.7倍。然而，當(dāng)查詢總大小超過內(nèi)存大小時(shí)，Impala則無法查詢。Hive處理的結(jié)果準(zhǔn)確率較高，處理速度較慢。因此，Hive比較適用于批處理應(yīng)用；Impala適合交互式查詢，系統(tǒng)的穩(wěn)定性還有待提高；Spark SQL能夠降低Hive的延遲，比較適合多并發(fā)和流數(shù)據(jù)處理場景。

通過以上的實(shí)驗(yàn)分析和比較，從文件格式角度來講，本文選擇能夠更好地適配Spark SQL的 Parquet列式存儲格式，以便快速地從HDFS中掃描找到相應(yīng)的數(shù)據(jù)；從壓縮角度來看，本文采用Snappy壓縮方式，以減少數(shù)據(jù)輸入量和加快查詢速度；從Spark SQL自身特性分析，Spark SQL基于內(nèi)存計(jì)算執(zhí)行速度快，可以操作Hadoop上多樣化格式的數(shù)據(jù)并進(jìn)行高效的結(jié)構(gòu)化分析與處理，提供可用性更好的API進(jìn)行數(shù)據(jù)分析，更加靈活且易擴(kuò)展。鑒于此，綜合考慮以上幾個(gè)方面并結(jié)合應(yīng)用驅(qū)動的大數(shù)據(jù)分析與計(jì)算實(shí)際需求，本文選擇Spark SQL作為SQL-on-Hadoop查詢系統(tǒng)，以適應(yīng)快速證券大數(shù)據(jù)分析與計(jì)算場景下的高并發(fā)實(shí)時(shí)查詢應(yīng)用需求。

5 實(shí)際應(yīng)用

在本文實(shí)現(xiàn)基于SQL-on-Hadoop網(wǎng)上交易日志實(shí)時(shí)分析與計(jì)算平臺上，目前已存儲約60 TB的網(wǎng)上交易日志，并開發(fā)和移植了實(shí)時(shí)監(jiān)控、統(tǒng)計(jì)分析、明細(xì)查詢等實(shí)際應(yīng)用。

5.1 實(shí)時(shí)運(yùn)維監(jiān)控

對分布在全國各個(gè)節(jié)點(diǎn)和服務(wù)器的狀態(tài)實(shí)時(shí)監(jiān)控并對各種狀態(tài)進(jìn)行及時(shí)判斷和處理，能夠?qū)φ麄€(gè)系統(tǒng)的使用狀況有宏觀的把控。實(shí)時(shí)運(yùn)維監(jiān)控主要包括技術(shù)指標(biāo)監(jiān)控、業(yè)務(wù)指標(biāo)監(jiān)控和客戶分布。

1)如圖12所示，技術(shù)指標(biāo)監(jiān)控主要針對實(shí)時(shí)的請求延遲、成功率、系統(tǒng)冗余(帶寬流量/在線數(shù))等指標(biāo)進(jìn)行監(jiān)控。數(shù)據(jù)從千萬級別的當(dāng)日日志數(shù)據(jù)中實(shí)時(shí)提取，從采集到存儲達(dá)到秒級實(shí)現(xiàn)。延遲情況主要包括登錄、委托、查詢(資金查詢)和轉(zhuǎn)賬這4類業(yè)務(wù)單位時(shí)間段內(nèi)的平均耗時(shí)和峰值情況。系統(tǒng)冗余用于指示系統(tǒng)的資源使用情況，包括系統(tǒng)容量情況和系統(tǒng)帶寬使用情況，能實(shí)時(shí)展示系統(tǒng)當(dāng)前冗余，有助于系統(tǒng)管理員及時(shí)掌握當(dāng)前系統(tǒng)的使用情況。成功率主要包括登錄、委托、轉(zhuǎn)賬這幾類業(yè)務(wù)單位時(shí)間段內(nèi)的處理成功率情況。

圖12 技術(shù)指標(biāo)監(jiān)控Fig.12 Technical index monitor

2)如圖13所示，業(yè)務(wù)指標(biāo)監(jiān)控主要針對登錄情況、轉(zhuǎn)賬情況、委托情況和實(shí)時(shí)在線人數(shù)等指標(biāo)進(jìn)行監(jiān)控?？梢詮那f級別的當(dāng)日數(shù)據(jù)中實(shí)時(shí)觀察當(dāng)前系統(tǒng)的客戶登陸數(shù)、系統(tǒng)發(fā)生的交易數(shù)量和轉(zhuǎn)賬金額等情況，整個(gè)過程實(shí)現(xiàn)秒級響應(yīng)。

圖13 業(yè)務(wù)指標(biāo)監(jiān)控Fig.13 Business index monitor

3)如圖14所示，客戶分布主要針對實(shí)時(shí)在線客戶與委托分布，站點(diǎn)和來源省份的分布。在線分布從千萬級別的數(shù)據(jù)中指示一段時(shí)間客戶的登陸來源和委托來源分布。系統(tǒng)通過登陸和委托源IP關(guān)聯(lián)全球IP分布區(qū)域得出客戶的分布情況， IP分布來自10億級別的IP分布數(shù)據(jù)源。

圖14 客戶分布Fig.14 Customer distribution

5.2 客戶交易行為監(jiān)控

日志分析更有價(jià)值的應(yīng)用在于發(fā)現(xiàn)客戶的異常行為。如圖15、16所示，通過大數(shù)據(jù)平臺，可以實(shí)時(shí)掌握不同區(qū)域和營業(yè)部活躍用戶的分布，為業(yè)務(wù)部門做績效考核、精準(zhǔn)營銷等提供數(shù)據(jù)支撐。

圖15 活躍用戶分布Fig.15 Active user distribution

圖16 行為軌跡分析Fig.16 Behavioral traces analysis

5.3 業(yè)務(wù)統(tǒng)計(jì)查詢與分析

1)統(tǒng)計(jì)報(bào)表：如圖17所示，統(tǒng)計(jì)報(bào)表是實(shí)際日志處理中的一項(xiàng)重要需求和應(yīng)用，對計(jì)算的性能和實(shí)時(shí)性要求更高。根據(jù)具體業(yè)務(wù)功能需求，按照指定周期完成系統(tǒng)資源、登錄、委托和業(yè)務(wù)監(jiān)控等統(tǒng)計(jì)任務(wù)。統(tǒng)計(jì)報(bào)表主要是提供給系統(tǒng)管理員分析系統(tǒng)的資源使用情況和系統(tǒng)健康狀態(tài)，以便做好相應(yīng)的措施和規(guī)劃，同時(shí)為管理者決策提供數(shù)據(jù)支撐和參考依據(jù)。

圖17 業(yè)務(wù)報(bào)表Fig.17 Business report

2)明細(xì)查詢：如圖18所示，對網(wǎng)上交易日志的明細(xì)查詢，實(shí)現(xiàn)千億級數(shù)據(jù)秒級查詢響應(yīng)。主要用于實(shí)時(shí)明細(xì)查詢，根據(jù)時(shí)間、系統(tǒng)、站點(diǎn)等多維條件查詢從TB級別的日志數(shù)據(jù)中快速準(zhǔn)確地找到所需數(shù)據(jù)，查詢時(shí)效均能達(dá)到秒級響應(yīng)。極大地方便了運(yùn)維管理人員的工作，在節(jié)約大量的時(shí)間的同時(shí)提高了問題排查效率。

圖18 明細(xì)查詢Fig.18 Query details

6 結(jié)束語

本文研究了SQL-on-Hadoop技術(shù)在網(wǎng)絡(luò)日志分析中的應(yīng)用。我們選取了其中最有代表性的3種SQL查詢引擎——Hive、Impala和Spark SQL，并使用TPC-H的測試基準(zhǔn)對它們的決策支持能力進(jìn)行測試及評估。構(gòu)建面向證券行業(yè)的網(wǎng)絡(luò)日志分析平臺，實(shí)現(xiàn)萬億級日志存儲和高效、靈活的查詢系統(tǒng)，為海量日志集中分析與管理系統(tǒng)應(yīng)用提供支持。目前SQL-on-Hadoop系統(tǒng)還存在若干問題有待解決，在有限的資源使用情況下和特定數(shù)據(jù)分布場景下提高查詢處理效率等問題都有待進(jìn)一步的研究。

[1]OLINER A, GANAPATHI A, XU W. Advances and challenges in log analysis [J]. Communications of the ACM, 2012, 55(2): 55-61.

[2]李國杰，程學(xué)旗. 大數(shù)據(jù)研究：未來科技及經(jīng)濟(jì)社會發(fā)展的重大戰(zhàn)略領(lǐng)域——大數(shù)據(jù)的研究現(xiàn)狀與科學(xué)思考[J]. 中國科學(xué)院院刊，2012， 27(6)： 647-657.

LI Guojie, CHENG Xueqi. Research status and scientific thinking of big data[J]. Bulletin of Chinese academy of sciences, 2012, 27(6): 647-657.

[3]王元卓，靳小龍，程學(xué)旗. 網(wǎng)絡(luò)大數(shù)據(jù)：現(xiàn)狀與展望[J]. 計(jì)算機(jī)學(xué)報(bào), 2013, 36(6)： 1125-1138.

WANG Yuanzhuo, JIN Xiaolong, CHENG Xueqi. Network big data: present and future[J]. Chinese journal of computer, 2013, 36(6): 1125-1138.

[4]孟小峰，慈祥. 大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn)[J]. 計(jì)算機(jī)研究與發(fā)展， 2013， 50(1)： 146-149.

MENG Xiaofeng, CI Xiang. Big data management: Concepts, techniques and challenges [J]. Journal of computer research and development, 2013, 50(1): 146-149.

[5]JOSHI S B. Apache hadoop performance-tuning methodologies and best practices[C]//Proceedings of the 3rd ACM/SPEC International Conference on Performance Engineering. New York, USA, 2012: 241-242.

[6]LAMB W. The storyteller, the scribe, and a missing man: hidden influences from printed sources in the gaelic tales of duncan and neil macdonald [J]. Oral tradition, 2012, 27(1): 109-160.

[7]Apache.org. Apache Chukwa [EB/OL]. [2017-06-07].http://chukwa.apache.org/

[8]GOODHOPE K, KOSHY J, KREPS J, et al. Building LinkedIn’s real-time activity data pipeline [J]. Data engineering, 2012, 35(2): 33-45.

[9]APACHE ORG. Apache Flume [EB/OL]. [2017-06-07]. https://flume.apache.org.

[10]GHEMAWAAT S, GOBIOFF H, LEUNG S T. The Google file system[C]//Proc of the 19th ACM Symp on Operating Systems Principles. New York, USA, 2003: 29-43.

[11]THUSOO A, SARMA J S, JAIN N, et al. Hive—a petabyte scale data warehouse using Hadoop [C]// Proc of 2010 IEEE 26th International Conference. Piscataway, NJ, 2010: 996-1005.

[12]APACHE ORG. Apache HBase [EB/OL]. [2017-06-07]. https://Hbase.apache.org.

[13]APACHE ORG. Hadoop Streaming [EB/OL]. [2017-06-07].http://hadoop.apache.org/docs/r1.2.1/streaming.html.

[14]WEI J, ZHAO Y, JIANG K, et al. Analysis farm: A cloud-based scalable aggregation and query platform for network log analysis[C]//International Conference on Cloud and Service Computing. Hong Kong, China, 2011: 354-359.

[15]RABKIN A, KATZ R H. Chukwa: a system for reliable large-scale log collection[C]// International Conference on Large Installation System Administration. New York ,USA, 2010: 163-177.

[16]LOGOTHETIS D, TREZZO C, WEBB K, et al. In-situ mapreduce for log processing [C]//Usenix Conference on Hot Topics in Cloud Computing. Berkeley, USA, 2012: 26-26.

[17]TREZZO C J. Continuous mapreduce: an architecture for large-scale in-situ data processing[J]. Dissertations and theses-gradworks, 2010, 126(7): 14.

[18]Apache.org. HDFS Architecture Guide [EB/OL]. [2017-06-07]. http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html.

[19]DEAN J, GHEMAWAT S. Mapreduce: simplified data processing on large culsters[C]//Proc of the 6th Symp on Operating System Design and Implementation. San Francisco, USA, 2004: 137-150.

[20]HAN U G, AHN J. Dynamic load balancing method for apache flume log processing[C]//Information Science and Technology. Shenzhen, China, 2014: 83-86.

[21]Apache.org. Apache sqoop [EB/OL]. [2017-06-07]. http://sqoop.apache.org/.

[22]BITTORF M, BOBROVYTSKY T, ERICKSON CCACJ, et al. Impala: a modern, open-source SQL engine for Hadoop[C]//Proceedings of the 7th Biennial Conference on Innovative Data Systems Research. CA, USA, 2015: 4-7.

[23]FLORATOU A, MINHAS U F, OZCAN F. SQL-on-Hadoop: full circle back to shared-nothing database architectures [J]. Proc of the VLDB endowment, 2014, 7(12): 1199-1208.

[24]ZAHARIA M, CHOWDHURY M, FRANKLIN M J, et al. Spark: cluster computing with working sets [J]. Book of extremes, 2010, 15(1): 1765-1773.

[25]HE Y, LEE R, HUAI Y, et al. RCFile: a fast and space-efficient data placement structure in MapReduce-based warehouse systems. [C]// Proc of 27th IEEE Int Conf on Data Engineering. CA: IEEE Computer Society, 2011:1199-1208.

[26]MELNIK S, GUBAREV A, LONG J J, et al. Dremel: interactive analysis of web-scale datasets[J]. Communications of the Acm, 2011, 3(12):114-123.

何明，男，1975年生，博士，主要研究方向?yàn)榇髷?shù)據(jù)、推薦系統(tǒng)、機(jī)器學(xué)習(xí)。

常盟盟，男，1987年生，碩士研究生，主要研究方向?yàn)閿?shù)據(jù)挖掘、機(jī)器學(xué)習(xí)。

劉郭洋，男，1986年生，碩士研究生，主要研究方向?yàn)榇髷?shù)據(jù)、數(shù)據(jù)挖掘。

Logminingandapplicationbasedonsql-on-hadoopqueryengine

HE Ming1， CHANG Mengmeng1， LIU Guoyang2， GU Chengxiang2， PENG Jike2

(1.Faculty of Information Technology, Beijing University of Technology, Beijing 100124, China; 2.Information Technology Management Department， Haitong Securities Co., Ltd., Shanghai 200001, China)

With the rapid development of computing and networking technologies, and the increase in the number of data acquisition methods, the demand for real-time processing of massive amounts of log data is increasing every day, and there is a calculation bottleneck when traditional log analysis technology is used to process massive amounts of data. With the development of open processing platforms in the era of big data, a number of big data processing systems have emerged for dealing with large-scale and diverse data. To effectively apply the advantages of Hadoop to the original businesses, in this study, we first investigated network log analysis methods based on big data technology and constructed a network log analysis platform for the acquisition, analysis, storage, high-efficiency and flexible queries, and the calculation of trillions of log entries. In addition, we compared and analyzed three representative SQL-on-Hadoop query systems including Hive, Impala, and Spark SQL, and identified the performance characteristics of this type of system. We used the TPC-H testing reference to test and assess their decision-making support abilities. We drew some useful conclusions from the analysis of the experimental data. We also suggest a few typical applications for this analysis and processing system for massive log data in the securities fields, which provides a solid foundation for further research.

big data; log analysis; data mining; Hadoop; query engine; data collection; indexed storage; securities business

10.11992/tis.201706016

http://kns.cnki.net/kcms/detail/23.1538.TP.20171021.1350.014.html

TP391

A

1673-4785(2017)05-0717-12

中文引用格式：何明，常盟盟，劉郭洋，等.基于SQL-on-Hadoop查詢引擎的日志挖掘及其應(yīng)用J.智能系統(tǒng)學(xué)報(bào)， 2017, 12(5): 717-728.

英文引用格式：HEMing，CHANGMengmeng，LIUGuoyang，etal.Logminingandapplicationbasedonsql-on-hadoopqueryengineJ.CAAItransactionsonintelligentsystems, 2017, 12(5): 717-728.

2017-06-07. < class="emphasis_bold">網(wǎng)絡(luò)出版日期

日期：2017-10-21.

國家自然科學(xué)基金項(xiàng)目(91646201, 91546111, 60803086); 國家科技支撐計(jì)劃子課題(2013BAH21B02-01); 北京市自然科學(xué)基金項(xiàng)目(4153058, 4113076); 北京市教委重點(diǎn)項(xiàng)目(KZ20160005009); 北京市教委面上項(xiàng)目(KM201710005023).

何明. E-mail：heming@bjut.edu.cn.