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

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

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

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

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

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

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

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

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

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

本文的主要貢獻如下：

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

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

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

然而HDFS[18]和MapReduce[19]大數(shù)據(jù)處理架構(gòu)主要是針對靜態(tài)數(shù)據(jù)的批處理，在運算過程中產(chǎn)生的大量I/O操作無法保證處理過程的實時性。針對上述問題，本文將研究基于SQL-on-Hadoop查詢引擎構(gòu)建網(wǎng)絡(luò)日志分析平臺，通過使用廣泛的標準SQL語言來實現(xiàn)快速、靈活的查詢性能。通過利用TB級日志數(shù)據(jù)對存儲、查詢性能進行測試、優(yōu)化和比較，構(gòu)建具有穩(wěn)定性、高性能、可擴展性、易用性和安全性的網(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ò)日志源的種類具有多樣性的特點，包括結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)。不同類型的日志存儲方式有所不同。日志管理系統(tǒng)的采集器對不同格式的日志進行標準化處理，從而以結(jié)構(gòu)化的形式進行日志存儲和分析。本文所采用的源數(shù)據(jù)主要分為文本數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)和實時/準實時數(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ù)據(jù)基本流程按功能可劃分為5層，如圖1所示。

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

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

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

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

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

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

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

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

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

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

2.2 SQL-on-Hadoop查詢引擎

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

圖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ù)導入和處理效率。它首先將數(shù)據(jù)水平分割為多個行組(row-group)，然后對每個組內(nèi)的數(shù)據(jù)垂直分割成列存儲。列存儲將數(shù)據(jù)表同一列的數(shù)據(jù)連續(xù)存放，當查詢只涉及部分列時，可大幅減少所需讀取的數(shù)據(jù)量。ORC(optimized RCFile)是對RCFile的改進，解決其在數(shù)據(jù)類型和性能上的多個局限性，改善查詢和空間利用效率。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，因此本文平臺實際應(yīng)用中通常由Hive導入數(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)嵌輕量級的壓縮機制。

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

RDD數(shù)據(jù)集包含對父RDD的一組依賴，這種依賴描述了RDD之間的傳承關(guān)系。RDD將操作分為兩類：Transformation與Action。Transformation操作不執(zhí)行運算，只有當Action操作時才觸發(fā)運算。在RDD的實現(xiàn)機制中，基于迭代器的接口實現(xiàn)原理使得數(shù)據(jù)的訪問更加高效，同時避免了大量中間結(jié)果對內(nèi)存的消耗。Spark SQL包含了結(jié)構(gòu)化數(shù)據(jù)和數(shù)據(jù)之上進行運算的更多信息，Spark SQL使用這些信息進行優(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)進行分區(qū)。分片數(shù)據(jù)采用迭代器Iterator流式訪問，hasNext方法是由RDD lineage上各個Transformation攜帶的閉包函數(shù)復(fù)合而成,使得對象被序列化，通過網(wǎng)絡(luò)傳輸?shù)狡渌?jié)點上進行裝載運算。Iterator每訪問一個元素，就對該元素應(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è)備海量日志采集、解析、存儲與實時計算分析平臺，平臺的核心架構(gòu)如下。

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

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

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

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

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

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

可以看到，在這個大數(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ù)，有良好的擴展性?；谏鲜銎脚_結(jié)構(gòu)，本文設(shè)計了能夠有效地利用大數(shù)據(jù)技術(shù)解決海量系統(tǒng)訪問日志多條件實時快速查詢的處理框架，如圖3所示。

圖3 處理框架Fig.3 Processing framework

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

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

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

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

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

3.2 環(huán)境部署

基于Hadoop的網(wǎng)絡(luò)日志分析平臺在海通證券網(wǎng)絡(luò)信息中心的搭建部署，如圖4所示。共42臺服務(wù)器，其中11臺是Flume匯聚節(jié)點(256 GB內(nèi)存，2×600 GB，RAID1陣列)，5臺Kafka節(jié)點(256 GB內(nèi)存，2×600 GB，RAID1陣列)，3臺Couchbase節(jié)點(512 GB內(nèi)存，2×600 GB，RAID1陣列)，5臺Zookeeper節(jié)點(256 GB內(nèi)存，2×600 GB，RAID1陣列)，2臺作為Namenode(256 GB內(nèi)存，2×600 GB，RAID1陣列)，14臺是Datanode節(jié)點(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 集群拓撲圖Fig.4 Cluster topology

所有節(jié)點通過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 實驗與性能評估

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

我們采用的實驗環(huán)境為7臺物理測試機構(gòu)建的集群，選取2臺機器作為主節(jié)點，其余作為計算節(jié)點進行SQL-on-Hadoop實驗，測試集群拓撲如圖5所示。

圖5 測試環(huán)境拓撲圖Fig.5 Test environment topology

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

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

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

表2 實驗數(shù)據(jù)集

4.2 性能評估

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

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

實驗結(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í)行計劃，可以判斷查詢時對整個表進行了遍歷。對于Spark SQL而言，其在大多數(shù)查詢上的表現(xiàn)優(yōu)于Hive和Impala。由于Spark的接口豐富和SQL優(yōu)勢，在執(zhí)行查詢時的速度較快。

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個子查詢組成。子查詢S1對customer表進行掃描并將結(jié)果保存到臨時表Temp1中；子查詢S2對Temp1進行聚集操作AGG1后將結(jié)果保存到臨時表Temp2中；子查詢S3在與表Orders執(zhí)行聚集操作AGG2后依次與Temp1和Temp2進行關(guān)聯(lián)操作求笛卡爾乘積AGG3然后排序。

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

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

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

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

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

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

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

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

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

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

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

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

5 實際應(yīng)用

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

5.1 實時運維監(jiān)控

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

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

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

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

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

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

圖14 客戶分布Fig.14 Customer distribution

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

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

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

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

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

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

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

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

圖18 明細查詢Fig.18 Query details

6 結(jié)束語

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

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

[2]李國杰，程學旗. 大數(shù)據(jù)研究：未來科技及經(jīng)濟社會發(fā)展的重大戰(zhàn)略領(lǐng)域——大數(shù)據(jù)的研究現(xiàn)狀與科學思考[J]. 中國科學院院刊，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]王元卓，靳小龍，程學旗. 網(wǎng)絡(luò)大數(shù)據(jù)：現(xiàn)狀與展望[J]. 計算機學報, 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]. 計算機研究與發(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年生，博士，主要研究方向為大數(shù)據(jù)、推薦系統(tǒng)、機器學習。

常盟盟，男，1987年生，碩士研究生，主要研究方向為數(shù)據(jù)挖掘、機器學習。

劉郭洋，男，1986年生，碩士研究生，主要研究方向為大數(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)學報， 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.

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

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