【智能系统】基于SQL-on-Hadoop查询引擎的日志挖掘及其应用

团购合买资源类别：文库，文档格式：PDF，文档页数：12，文件大小：5.15MB

第12卷第5期智能系统学报 Vol.12 No.5 2017年10月 CAAI Transactions on Intelligent Systems 0ct.2017 D0I:10.11992/is.201706016 网络出版地址：htp:/kns.cmki.net/kcms/detail/23.1538.TP.20171021.1350.014.html 基于SQL-on-Hadoop查询引擎的日志挖掘及其应用何明，常盟盟，刘郭洋2，顾程祥2，彭继克2 (1.北京工业大学信息学部，北京100124：2.海通证券股份有限公司信息技术管理部，上海200001) 摘要：随着计算机和网络技术的迅猛发展以及数据获取手段的不断丰富，海量数据的实时处理需求日益增多，传统的日志分析技术在处理海量数据时存在计算瓶颈。大数据时代下，随着开放式处理平台的发展，能够处理大规模且多样化数据的大数据处理系统应运而生。为了让原有的业务能够充分利用Hop的优势，本文首先研究了基于大数据技术的网络日志分析方法，构建了网络日志分析平台以实现万亿级日志采集、解析、存储和高效、灵活的查询与计算。对比分析了Hiwe、Impala和Spark SOL这3种具有代表性的SQL-om-Hadoop查询系统实例.并展示了这类系统的性能特点。采用TPCH测试基准对它们的决策支持能力进行测试及评估，通过对实验数据的分析和解释得到了若干有益的结论。实现了海量日志数据计算与分析在证券领域的几种典型应用，为进一步的研究工作奠定了基础。关键词：大数据；日志分析：数据挖掘；Hadoop:查询引擎；数据采集：索引存储；证券行业中图分类号：TP391文献标志码：A文章编号：1673-4785(2017)05-0717-12 中文引用格式：何明，常盟盟，刘郭洋，等.基于SQL-on-Hadoop查询引擎的日志挖掘及其应用[J].智能系统学报，2017,12(5)： 717-728. 英文引用格式：HE Ming,CHANG Mengmeng,LIU Guoyang,etal.Log mining and application based on sql-on-hadoop query engine[J].CAAI transactions on intelligent systems,2017,12(5):717-728. Log mining and application based on sql-on-hadoop query engine HE Ming',CHANG Mengmeng',LIU Guoyang?,GU Chengxiang?,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) Abstract: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. Keywords:big data;log analysis;data mining;Hadoop;query engine;data collection;indexed storage; securities business 随着互联网的飞速发展和逐层推进，企业内部业网络中的计算机设备和网络组件持久地记录着的规模和业务量也不断增加，致使数据量猛增。企海量的网络日志。日志文件是系统软硬件信息和用户行为信息记录的载体，通过日志分析能够实时收稿日期：2017-06-07.网络出版日期：2017-10-21. 基金项目：国家自然科学基金项目(91646201.91546111,60803086)：国家科获取设备、网络运行状态和用户行为交易等信息，技支撑计划子课题(2013BAH2IB02-01)；北京市自然科学基金项目(4153058,4113076)：北京市教委重点项目有利于保证系统的稳定运行和来往业务的安全性。 (KZ20160005009):北京市教委面上项目(KM201710005023). 通信作者：何明.E-mail:heming(@bjut.cdu.cn. 目前，较为成熟的日志集中管理系统解决了各类设

第１２卷第５期智能系统学报Ｖｏｌ．１２ №．５２０１７年１０月ＣＡＡＩＴｒａｎｓａｃｔｉｏｎｓｏｎＩｎｔｅｌｌｉｇｅｎｔＳｙｓｔｅｍｓＯｃｔ．２０１７ＤＯＩ：１０．１１９９２／ｔｉｓ．２０１７０６０１６网络出版地址：ｈｔｔｐ：／／ｋｎｓ．ｃｎｋｉ．ｎｅｔ／ｋｃｍｓ／ｄｅｔａｉｌ／２３．１５３８．ＴＰ．２０１７１０２１．１３５０．０１４．ｈｔｍｌ基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎的日志挖掘及其应用何明１，常盟盟１，刘郭洋２，顾程祥２，彭继克２（１．北京工业大学信息学部，北京１００１２４；２．海通证券股份有限公司信息技术管理部，上海２００００１）摘要：随着计算机和网络技术的迅猛发展以及数据获取手段的不断丰富，海量数据的实时处理需求日益增多，传统的日志分析技术在处理海量数据时存在计算瓶颈。大数据时代下，随着开放式处理平台的发展，能够处理大规模且多样化数据的大数据处理系统应运而生。为了让原有的业务能够充分利用Ｈａｄｏｏｐ的优势，本文首先研究了基于大数据技术的网络日志分析方法，构建了网络日志分析平台以实现万亿级日志采集、解析、存储和高效、灵活的查询与计算。对比分析了Ｈｉｖｅ、Ｉｍｐａｌａ和ＳｐａｒｋＳＱＬ这３种具有代表性的ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询系统实例，并展示了这类系统的性能特点。采用ＴＰＣ⁃Ｈ测试基准对它们的决策支持能力进行测试及评估，通过对实验数据的分析和解释得到了若干有益的结论。实现了海量日志数据计算与分析在证券领域的几种典型应用，为进一步的研究工作奠定了基础。关键词：大数据；日志分析；数据挖掘；Ｈａｄｏｏｐ；查询引擎；数据采集；索引存储；证券行业中图分类号：ＴＰ３９１文献标志码：Ａ文章编号：１６７３－４７８５（２０１７）０５－０７１７－１２中文引用格式：何明，常盟盟，刘郭洋，等．基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎的日志挖掘及其应用［Ｊ］．智能系统学报，２０１７，１２（５）：７１７－７２８．英文引用格式：ＨＥＭｉｎｇ，ＣＨＡＮＧＭｅｎｇｍｅｎｇ，ＬＩＵＧｕｏｙａｎｇ，ｅｔａｌ．Ｌｏｇｍｉｎｉｎｇａｎｄａｐｐｌｉｃａｔｉｏｎｂａｓｅｄｏｎｓｑｌ⁃ｏｎ⁃ｈａｄｏｏｐｑｕｅｒｙｅｎｇｉｎｅ［Ｊ］．ＣＡＡＩｔｒａｎｓａｃｔｉｏｎｓｏｎｉｎｔｅｌｌｉｇｅｎｔｓｙｓｔｅｍｓ，２０１７，１２（５）：７１７－７２８．Ｌｏｇｍｉｎｉｎｇａｎｄａｐｐｌｉｃａｔｉｏｎｂａｓｅｄｏｎｓｑｌ⁃ｏｎ⁃ｈａｄｏｏｐｑｕｅｒｙｅｎｇｉｎｅＨＥＭｉｎｇ１，ＣＨＡＮＧＭｅｎｇｍｅｎｇ１，ＬＩＵＧｕｏｙａｎｇ２，ＧＵＣｈｅｎｇｘｉａｎｇ２，ＰＥＮＧＪｉｋｅ２（１．ＦａｃｕｌｔｙｏｆＩｎｆｏｒｍａｔｉｏｎＴｅｃｈｎｏｌｏｇｙ，ＢｅｉｊｉｎｇＵｎｉｖｅｒｓｉｔｙｏｆＴｅｃｈｎｏｌｏｇｙ，Ｂｅｉｊｉｎｇ１００１２４，Ｃｈｉｎａ；２．ＩｎｆｏｒｍａｔｉｏｎＴｅｃｈｎｏｌｏｇｙＭａｎａｇｅｍｅｎｔＤｅｐａｒｔｍｅｎｔ，ＨａｉｔｏｎｇＳｅｃｕｒｉｔｉｅｓＣｏ．，Ｌｔｄ．，Ｓｈａｎｇｈａｉ２００００１，Ｃｈｉｎａ）Ａｂｓｔｒａｃｔ：Ｗｉｔｈｔｈｅｒａｐｉｄｄｅｖｅｌｏｐｍｅｎｔｏｆｃｏｍｐｕｔｉｎｇａｎｄｎｅｔｗｏｒｋｉｎｇｔｅｃｈｎｏｌｏｇｉｅｓ，ａｎｄｔｈｅｉｎｃｒｅａｓｅｉｎｔｈｅｎｕｍｂｅｒｏｆｄａｔａａｃｑｕｉｓｉｔｉｏｎｍｅｔｈｏｄｓ，ｔｈｅｄｅｍａｎｄｆｏｒｒｅａｌ⁃ｔｉｍｅｐｒｏｃｅｓｓｉｎｇｏｆｍａｓｓｉｖｅａｍｏｕｎｔｓｏｆｌｏｇｄａｔａｉｓｉｎｃｒｅａｓｉｎｇｅｖｅｒｙｄａｙ，ａｎｄｔｈｅｒｅｉｓａｃａｌｃｕｌａｔｉｏｎｂｏｔｔｌｅｎｅｃｋｗｈｅｎｔｒａｄｉｔｉｏｎａｌｌｏｇａｎａｌｙｓｉｓｔｅｃｈｎｏｌｏｇｙｉｓｕｓｅｄｔｏｐｒｏｃｅｓｓｍａｓｓｉｖｅａｍｏｕｎｔｓｏｆｄａｔａ．Ｗｉｔｈｔｈｅｄｅｖｅｌｏｐｍｅｎｔｏｆｏｐｅｎｐｒｏｃｅｓｓｉｎｇｐｌａｔｆｏｒｍｓｉｎｔｈｅｅｒａｏｆｂｉｇｄａｔａ，ａｎｕｍｂｅｒｏｆｂｉｇｄａｔａｐｒｏｃｅｓｓｉｎｇｓｙｓｔｅｍｓｈａｖｅｅｍｅｒｇｅｄｆｏｒｄｅａｌｉｎｇｗｉｔｈｌａｒｇｅ⁃ｓｃａｌｅａｎｄｄｉｖｅｒｓｅｄａｔａ．ＴｏｅｆｆｅｃｔｉｖｅｌｙａｐｐｌｙｔｈｅａｄｖａｎｔａｇｅｓｏｆＨａｄｏｏｐｔｏｔｈｅｏｒｉｇｉｎａｌｂｕｓｉｎｅｓｓｅｓ，ｉｎｔｈｉｓｓｔｕｄｙ，ｗｅｆｉｒｓｔｉｎｖｅｓｔｉｇａｔｅｄｎｅｔｗｏｒｋｌｏｇａｎａｌｙｓｉｓｍｅｔｈｏｄｓｂａｓｅｄｏｎｂｉｇｄａｔａｔｅｃｈｎｏｌｏｇｙａｎｄｃｏｎｓｔｒｕｃｔｅｄａｎｅｔｗｏｒｋｌｏｇａｎａｌｙｓｉｓｐｌａｔｆｏｒｍｆｏｒｔｈｅａｃｑｕｉｓｉｔｉｏｎ，ａｎａｌｙｓｉｓ，ｓｔｏｒａｇｅ，ｈｉｇｈ⁃ ｅｆｆｉｃｉｅｎｃｙａｎｄｆｌｅｘｉｂｌｅｑｕｅｒｉｅｓ，ａｎｄｔｈｅｃａｌｃｕｌａｔｉｏｎｏｆｔｒｉｌｌｉｏｎｓｏｆｌｏｇｅｎｔｒｉｅｓ．Ｉｎａｄｄｉｔｉｏｎ，ｗｅｃｏｍｐａｒｅｄａｎｄａｎａｌｙｚｅｄｔｈｒｅｅｒｅｐｒｅｓｅｎｔａｔｉｖｅＳＱＬ⁃ｏｎ⁃ＨａｄｏｏｐｑｕｅｒｙｓｙｓｔｅｍｓｉｎｃｌｕｄｉｎｇＨｉｖｅ，Ｉｍｐａｌａ，ａｎｄＳｐａｒｋＳＱＬ，ａｎｄｉｄｅｎｔｉｆｉｅｄｔｈｅｐｅｒｆｏｒｍａｎｃｅｃｈａｒａｃｔｅｒｉｓｔｉｃｓｏｆｔｈｉｓｔｙｐｅｏｆｓｙｓｔｅｍ．ＷｅｕｓｅｄｔｈｅＴＰＣ⁃Ｈｔｅｓｔｉｎｇｒｅｆｅｒｅｎｃｅｔｏｔｅｓｔａｎｄａｓｓｅｓｓｔｈｅｉｒｄｅｃｉｓｉｏｎ⁃ｍａｋｉｎｇｓｕｐｐｏｒｔａｂｉｌｉｔｉｅｓ．Ｗｅｄｒｅｗｓｏｍｅｕｓｅｆｕｌｃｏｎｃｌｕｓｉｏｎｓｆｒｏｍｔｈｅａｎａｌｙｓｉｓｏｆｔｈｅｅｘｐｅｒｉｍｅｎｔａｌｄａｔａ．Ｗｅａｌｓｏｓｕｇｇｅｓｔａｆｅｗｔｙｐｉｃａｌａｐｐｌｉｃａｔｉｏｎｓｆｏｒｔｈｉｓａｎａｌｙｓｉｓａｎｄｐｒｏｃｅｓｓｉｎｇｓｙｓｔｅｍｆｏｒｍａｓｓｉｖｅｌｏｇｄａｔａｉｎｔｈｅｓｅｃｕｒｉｔｉｅｓｆｉｅｌｄｓ，ｗｈｉｃｈｐｒｏｖｉｄｅｓａｓｏｌｉｄｆｏｕｎｄａｔｉｏｎｆｏｒｆｕｒｔｈｅｒｒｅｓｅａｒｃｈ．Ｋｅｙｗｏｒｄｓ：ｂｉｇｄａｔａ；ｌｏｇａｎａｌｙｓｉｓ；ｄａｔａｍｉｎｉｎｇ；Ｈａｄｏｏｐ；ｑｕｅｒｙｅｎｇｉｎｅ；ｄａｔａｃｏｌｌｅｃｔｉｏｎ；ｉｎｄｅｘｅｄｓｔｏｒａｇｅ；ｓｅｃｕｒｉｔｉｅｓｂｕｓｉｎｅｓｓ收稿日期：２０１７－０６－０７．网络出版日期：２０１７－１０－２１．基金项目：国家自然科学基金项目（９１６４６２０１，９１５４６１１１，６０８０３０８６）；国家科技支撑计划子课题（２０１３ＢＡＨ２１Ｂ０２－０１）；北京市自然科学基金项目（４１５３０５８，４１１３０７６）；北京市教委重点项目（ＫＺ２０１６０００５００９）；北京市教委面上项目（ＫＭ２０１７１０００５０２３）．通信作者：何明．Ｅ⁃ｍａｉｌ：ｈｅｍｉｎｇ＠ｂｊｕｔ．ｅｄｕ．ｃｎ．随着互联网的飞速发展和逐层推进，企业内部的规模和业务量也不断增加，致使数据量猛增。企业网络中的计算机设备和网络组件持久地记录着海量的网络日志。日志文件是系统软硬件信息和用户行为信息记录的载体，通过日志分析能够实时获取设备、网络运行状态和用户行为交易等信息，有利于保证系统的稳定运行和来往业务的安全性。目前，较为成熟的日志集中管理系统解决了各类设

·718· 智能系统学报第12卷备、服务器和应用日志的采集与格式统一问题，日得到了若干有益的结论：志分析也从最初简单的正则匹配向结构化查询、报 3)实现了大规模网络日志数据分析与计算在证表和预测演进山。越来越多的行业领域面临海量券领域的几种典型应用。 (volume)、高速(velocity)和多样(variety)等多V挑 1 相关工作战，大数据时代已真正到来[2-)。互联网中海量的信息为证券领域日志分析提大数据技术在互联网领域海量网络日志分析和供了丰富的数据支撑，如何利用大数据分析技术进处理过程中得到了广泛的应用，日志分析系统主要行实时准确的日志分析成为重要的科学问题。在包括日志同步、数据存储、分布式计算和数据仓库等大型证券公司的内部网络中，随着网络带宽的迅速相关技术。开源的日志分析系统如Facebook的扩容日志量急剧增长且日志源众多，包括网上交易 Scribet6],Apache Chukwat7],LinkedIn Kafkats], 日志、移动证券日志和网站日志等主要系统的日 Cloudera的Flume)等。Facebook公司庞大的用户群志。以海通证券为例，目前在全国设有几十个节体产生了大量的信息与社交数据，现有8亿多用户点，几百台服务器，峰值在线用户约几十万，每个节的信息需要处理，产生了大规模的数据和日志：同点各部署了1台负载均衡设备。网上交易应用服务时，离线的大规模数据分析计算已无法满足实时数器全天24小时将客户请求数据与应答数据实时或据分析的用户需求，Scribe结合了Google的分布式小批量定时写入磁盘日志文件，每台交易应用服务文件系统GFS[10](google file system,GFS)。操作流器的日志文件大小为100MB~3GB,总计在100GB 程是收集异构数据源上的日志，集中存储到分布式左右。同时，每台网上交易应用服务器还会生成一文件系统，从而在此基础上进行统计分析。Amazon 份发送给柜台程序的网关日志数据。此外，各节点基于S3和EC2,开发了Amazon EMR来提供大数据负载均衡设备的日志采用SNMP协议进行采集，采处理服务，可以将数据分布在可重新调整大小的集每个站点的网络流量、用户连接数据。每日合计 EC2集群中进行处理，包括日志分析、索引、数据仓有3亿多条日志，总量共计约300GB。仅上述3类库和机器学习等。阿里巴巴集团使用目前国内最日志存储一年就将产生约108TB数据，若接入更多大的Hadoop集群“云梯”进行各部门产品的线上数设备、操作系统、业务平台日志，数据规模则更大。据备份、系统日志以及爬虫数据分析，并建设开放传统的日志处理方法在面对海量大数据时，其存储平台为个人和企业提供各种增值服务。腾讯微信方式和计算能力都受到了限制，因此分布式存储和等应用产品拥有上亿级别的用户，产生了海量的个并行计算成为了新的发展趋势。如何采集、传输、人用户日志数据，这些数据中蕴藏着巨大的商业价存储、分析及应用大规模的日志数据，已成为证券值，并提出“大数据营销”的概念。人人网基于行业在大数据时代下面临的重大挑战。 Hadoop的Hive)、HBase[12]和Streamingl]组件， Hadoop)分布式处理平台为大数据存储和分析构建了SNS推荐平台进行分析计算、内容推荐等工提供了有效的解决方案。在大数据应用方面，虽然作。百度的高性能计算系统规划中的架构将有超学术界和工业界对大数据的关注各有侧重，但有一过1万个节点，每天的数据生成量在10PB以上，主个共同的认识：大数据只有和具体的行业深入结合要用于日志的存储分析以及统计挖掘等功能。Wi 才能落到实处，才能产生真正的价值。通过前期的等设计了Analysis Farm摒弃了传统的关系型数据积累和算法的升级，大数据应用将对证券行业产生 (relational database management system,RDBMS), 革命性影响。利用NoSQL(not only SQL)数据库MongoDB构建了本文的主要贡献如下：可横向扩展的日志分析平台，以支撑NetFlow日志 1)研究基于SQL-on-Hadoop查询系统的性能特存储和查询4。Rabkin等设计了基于Hadoop的日点，对比分析了Hive、Impala和Spark SQL这3种具志收集和分析系统Chukwa,日志处理程序在有代表性的SQL-on-Hadoop查询系统实例，构建了 MapReduce框架上开发。文献[l6-17]从原位海量日志采集与实时计算分析平台：分析的角度出发，分别实现了针对大规模日志分析 2)采用TPC-H测试基准对它们的决策支持能的MapReduce(In-situ MapReduce)和Continuous处力进行测试及评估，通过对实验数据的分析和解释理机制，但MapReduce模型计算代价很大，并不能

备、服务器和应用日志的采集与格式统一问题，日志分析也从最初简单的正则匹配向结构化查询、报表和预测演进［１］。越来越多的行业领域面临海量（ｖｏｌｕｍｅ）、高速（ｖｅｌｏｃｉｔｙ）和多样（ｖａｒｉｅｔｙ）等多Ｖ挑战，大数据时代已真正到来［２－４］。互联网中海量的信息为证券领域日志分析提供了丰富的数据支撑，如何利用大数据分析技术进行实时准确的日志分析成为重要的科学问题。在大型证券公司的内部网络中，随着网络带宽的迅速扩容日志量急剧增长且日志源众多，包括网上交易日志、移动证券日志和网站日志等主要系统的日志。以海通证券为例，目前在全国设有几十个节点，几百台服务器，峰值在线用户约几十万，每个节点各部署了１台负载均衡设备。网上交易应用服务器全天２４小时将客户请求数据与应答数据实时或小批量定时写入磁盘日志文件，每台交易应用服务器的日志文件大小为１００ＭＢ～３ＧＢ，总计在１００ＧＢ左右。同时，每台网上交易应用服务器还会生成一份发送给柜台程序的网关日志数据。此外，各节点负载均衡设备的日志采用ＳＮＭＰ协议进行采集，采集每个站点的网络流量、用户连接数据。每日合计有３亿多条日志，总量共计约３００ＧＢ。仅上述３类日志存储一年就将产生约１０８ＴＢ数据，若接入更多设备、操作系统、业务平台日志，数据规模则更大。传统的日志处理方法在面对海量大数据时，其存储方式和计算能力都受到了限制，因此分布式存储和并行计算成为了新的发展趋势。如何采集、传输、存储、分析及应用大规模的日志数据，已成为证券行业在大数据时代下面临的重大挑战。Ｈａｄｏｏｐ［５］分布式处理平台为大数据存储和分析提供了有效的解决方案。在大数据应用方面，虽然学术界和工业界对大数据的关注各有侧重，但有一个共同的认识：大数据只有和具体的行业深入结合才能落到实处，才能产生真正的价值。通过前期的积累和算法的升级，大数据应用将对证券行业产生革命性影响。本文的主要贡献如下：１）研究基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询系统的性能特点，对比分析了Ｈｉｖｅ、Ｉｍｐａｌａ和ＳｐａｒｋＳＱＬ这３种具有代表性的ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询系统实例，构建了海量日志采集与实时计算分析平台；２）采用ＴＰＣ⁃Ｈ测试基准对它们的决策支持能力进行测试及评估，通过对实验数据的分析和解释得到了若干有益的结论；３）实现了大规模网络日志数据分析与计算在证券领域的几种典型应用。１相关工作大数据技术在互联网领域海量网络日志分析和处理过程中得到了广泛的应用，日志分析系统主要包括日志同步、数据存储、分布式计算和数据仓库等相关技术。开源的日志分析系统如Ｆａｃｅｂｏｏｋ的Ｓｃｒｉｂｅ［６］，Ａｐａｃｈｅ的Ｃｈｕｋｗａ［７］，ＬｉｎｋｅｄＩｎ的Ｋａｆｋａ［８］，Ｃｌｏｕｄｅｒａ的Ｆｌｕｍｅ［９］等。Ｆａｃｅｂｏｏｋ公司庞大的用户群体产生了大量的信息与社交数据，现有８亿多用户的信息需要处理，产生了大规模的数据和日志；同时，离线的大规模数据分析计算已无法满足实时数据分析的用户需求，Ｓｃｒｉｂｅ结合了Ｇｏｏｇｌｅ的分布式文件系统ＧＦＳ［１０］（ｇｏｏｇｌｅｆｉｌｅｓｙｓｔｅｍ，ＧＦＳ）。操作流程是收集异构数据源上的日志，集中存储到分布式文件系统，从而在此基础上进行统计分析。Ａｍａｚｏｎ基于Ｓ３和ＥＣ２，开发了ＡｍａｚｏｎＥＭＲ来提供大数据处理服务，可以将数据分布在可重新调整大小的ＥＣ２集群中进行处理，包括日志分析、索引、数据仓库和机器学习等。阿里巴巴集团使用目前国内最大的Ｈａｄｏｏｐ集群“云梯”进行各部门产品的线上数据备份、系统日志以及爬虫数据分析，并建设开放平台为个人和企业提供各种增值服务。腾讯微信等应用产品拥有上亿级别的用户，产生了海量的个人用户日志数据，这些数据中蕴藏着巨大的商业价值，并提出 “ 大数据营销” 的概念。人人网基于Ｈａｄｏｏｐ的Ｈｉｖｅ［１１］、ＨＢａｓｅ［１２］和Ｓｔｒｅａｍｉｎｇ［１３］组件，构建了ＳＮＳ推荐平台进行分析计算、内容推荐等工作。百度的高性能计算系统规划中的架构将有超过１万个节点，每天的数据生成量在１０ＰＢ以上，主要用于日志的存储分析以及统计挖掘等功能。Ｗｅｉ等设计了ＡｎａｌｙｓｉｓＦａｒｍ摒弃了传统的关系型数据库（ｒｅｌａｔｉｏｎａｌｄａｔａｂａｓｅｍａｎａｇｅｍｅｎｔｓｙｓｔｅｍ，ＲＤＢＭＳ），利用ＮｏＳＱＬ（ｎｏｔｏｎｌｙＳＱＬ）数据库ＭｏｎｇｏＤＢ构建了可横向扩展的日志分析平台，以支撑ＮｅｔＦｌｏｗ日志存储和查询［１４］。Ｒａｂｋｉｎ等设计了基于Ｈａｄｏｏｐ的日志收集和分析系统Ｃｈｕｋｗａ，日志处理程序在ＭａｐＲｅｄｕｃｅ框架上开发［１５］。文献［１６－１７］从原位分析的角度出发，分别实现了针对大规模日志分析的ＭａｐＲｅｄｕｃｅ（Ｉｎ⁃ｓｉｔｕＭａｐＲｅｄｕｃｅ）和Ｃｏｎｔｉｎｕｏｕｓ处理机制，但ＭａｐＲｅｄｕｃｅ模型计算代价很大，并不能 ·７１８· 智能系统学报第１２卷

第5期何明，等：基于SQL-on-Hadoop查询引擎的日志挖掘及其应用 ·719· 很好地支持迭代运算。主要分为文本数据、数据库数据和实时/准实时数然而HDFS1]和MapReducet]大数据处理架构据等。主要是针对静态数据的批处理，在运算过程中产生 2.1HDS数据采集的大量/O操作无法保证处理过程的实时性。针对网络日志的生成是分布式的，与传统的日志管上述问题，本文将研究基于SQL-on-Hadoop查询引理系统一样，日志采集是本文平台的基础。本文平擎构建网络日志分析平台，通过使用广泛的标准台采集的日志直接存储在Hadoop文件系统 SQL语言来实现快速、灵活的查询性能。通过利用 (HDFS)中，由于平台构建于Hadoop之上，能够处 TB级日志数据对存储、查询性能进行测试、优化和理海量分布式存储的日志数据，同时易于水平扩比较，构建具有稳定性、高性能、可扩展性、易用性展，本文的日志数据基本流程按功能可划分为5层，和安全性的网络日志统一采集查询和监控平台，以如图1所示。满足对TB或PB级容量和万亿日志管理的应用需 1)原始数据层：业务上完成日志格式梳理，系统求，为面向证券行业的日志大数据分析及其应用提运行日志支持实时访问和采集接口。供技术支撑。 2)数据采集层：主要负责通用的日志数据解析 2基于Hadoop的结构化数据处理高效采集和安全可控。 3)数据处理层：主要包括对日志数据的批量式网络日志源的种类具有多样性的特点，包括结处理和实时处理。构化、半结构化和非结构化的数据。不同类型的日 4)数据服务层：主要提供标准的数据访问接口志存储方式有所不同。日志管理系统的采集器对 ODBC、JDBC、HIVE等。不同格式的日志进行标准化处理，从而以结构化的 5)数据展示层：实现实时监控类和报表类数据形式进行日志存储和分析。本文所采用的源数据的展示。数据处理原始数据层存储后处理 External Database HDFS Map/Reduce 数据服务层 :数据展示层 ”””””” ODBC Statistics Report Textfile 数据采集层 JDBC 实时处理 HIVE OLAP Network Sprak Data Cache Streaming 图1日志数据处理基本流程 Fig.1 Basic log data processing framework 根据应用需求，本文日志的采集方式分为以下on-Hadoop处理结果输出到RDBMS,供现有的日志 3种。分析系统进行报表及可视化处理。 1)文件导人：对已分布在个服务器磁盘的日志 2.2SQL-on-Hadoop查询引擎文件，经网络文件系统挂载，直接将日志文件导入 SQL是结构化数据的查询语言，SQL-on-Hadoop HDFS。该方式允许日志文件批量可靠导入，可在网是构建在Hadoop之上的SQL查询系统，利用络利用率低谷时段进行传送。 Hadoop能够进行海量数据(TB级别以上)的处理。 2)流数据导入：基于Apache Flume[2o]构建，实目前已有的SQL-on-Hadoop系统大致可以分为两大类：第一类将SQL查询转换为Map-Reduce job;第二现多个日志源数据实时汇聚，接收网上交易应用服类系统基于MPP(massively parallel processing)的设务器和网络设备发送的日志。计方式，仅仅使用Hadoop作为存储引擎，上层自行 3)RDBMS导人：为实现与现有日志系统兼容，实现分布式查询的逻辑。第一类系统的代表是基于Apache Sqoop2,实现与Oracle、MSQL和 Facebook的Hive。Hive是原始的SQL-on-Hadoop解 PostgreSQL等RDBMS对接，支持直接导入存储在上决方案。它是一个开源的Java项目，能够将SQL转述数据库中的数据记录。Sqoop同时可以将SQL 换成一系列可以在标准的Hadoop TaskTrackers上运

很好地支持迭代运算。然而ＨＤＦＳ［１８］和ＭａｐＲｅｄｕｃｅ［１９］大数据处理架构主要是针对静态数据的批处理，在运算过程中产生的大量Ｉ／Ｏ操作无法保证处理过程的实时性。针对上述问题，本文将研究基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎构建网络日志分析平台，通过使用广泛的标准ＳＱＬ语言来实现快速、灵活的查询性能。通过利用ＴＢ级日志数据对存储、查询性能进行测试、优化和比较，构建具有稳定性、高性能、可扩展性、易用性和安全性的网络日志统一采集查询和监控平台，以满足对ＴＢ或ＰＢ级容量和万亿日志管理的应用需求，为面向证券行业的日志大数据分析及其应用提供技术支撑。２基于Ｈａｄｏｏｐ的结构化数据处理网络日志源的种类具有多样性的特点，包括结构化、半结构化和非结构化的数据。不同类型的日志存储方式有所不同。日志管理系统的采集器对不同格式的日志进行标准化处理，从而以结构化的形式进行日志存储和分析。本文所采用的源数据主要分为文本数据、数据库数据和实时／准实时数据等。２．１ＨＤＦＳ数据采集网络日志的生成是分布式的，与传统的日志管理系统一样，日志采集是本文平台的基础。本文平台采集的日志直接存储在Ｈａｄｏｏｐ文件系统（ＨＤＦＳ）中，由于平台构建于Ｈａｄｏｏｐ之上，能够处理海量分布式存储的日志数据，同时易于水平扩展，本文的日志数据基本流程按功能可划分为５层，如图１所示。１）原始数据层：业务上完成日志格式梳理，系统运行日志支持实时访问和采集接口。２）数据采集层：主要负责通用的日志数据解析、高效采集和安全可控。３）数据处理层：主要包括对日志数据的批量式处理和实时处理。４）数据服务层：主要提供标准的数据访问接口ＯＤＢＣ、ＪＤＢＣ、ＨＩＶＥ等。５）数据展示层：实现实时监控类和报表类数据的展示。图１日志数据处理基本流程Ｆｉｇ．１Ｂａｓｉｃｌｏｇｄａｔａｐｒｏｃｅｓｓｉｎｇｆｒａｍｅｗｏｒｋ根据应用需求，本文日志的采集方式分为以下３种。１）文件导入：对已分布在个服务器磁盘的日志文件，经网络文件系统挂载，直接将日志文件导入ＨＤＦＳ。该方式允许日志文件批量可靠导入，可在网络利用率低谷时段进行传送。２）流数据导入：基于ＡｐａｃｈｅＦｌｕｍｅ［２０］构建，实现多个日志源数据实时汇聚，接收网上交易应用服务器和网络设备发送的日志。３）ＲＤＢＭＳ导入：为实现与现有日志系统兼容，基于ＡｐａｃｈｅＳｑｏｏｐ［２１］，实现与Ｏｒａｃｌｅ、ＭｙＳＱＬ和ＰｏｓｔｇｒｅＳＱＬ等ＲＤＢＭＳ对接，支持直接导入存储在上述数据库中的数据记录。Ｓｑｏｏｐ同时可以将ＳＱＬ⁃ ｏｎ⁃Ｈａｄｏｏｐ处理结果输出到ＲＤＢＭＳ，供现有的日志分析系统进行报表及可视化处理。２．２ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎ＳＱＬ是结构化数据的查询语言，ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ是构建在Ｈａｄｏｏｐ之上的ＳＱＬ查询系统，利用Ｈａｄｏｏｐ能够进行海量数据（ＴＢ级别以上）的处理。目前已有的ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ系统大致可以分为两大类：第一类将ＳＱＬ查询转换为Ｍａｐ⁃Ｒｅｄｕｃｅｊｏｂ；第二类系统基于ＭＰＰ（ｍａｓｓｉｖｅｌｙｐａｒａｌｌｅｌｐｒｏｃｅｓｓｉｎｇ）的设计方式，仅仅使用Ｈａｄｏｏｐ作为存储引擎，上层自行实现分布式查询的逻辑。第一类系统的代表是Ｆａｃｅｂｏｏｋ的Ｈｉｖｅ。Ｈｉｖｅ是原始的ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ解决方案。它是一个开源的Ｊａｖａ项目，能够将ＳＱＬ转换成一系列可以在标准的ＨａｄｏｏｐＴａｓｋＴｒａｃｋｅｒｓ上运第５期何明，等：基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎的日志挖掘及其应用 ·７１９·

·720 智能系统学报第12卷行的MapReduce任务。如图2中的Hive架构部分 Impala并没有使用MapReduce执行查询，而是使用所示，Hive通过一个metastore(本身就是一个数据了自己的执行守护进程操作本地磁盘文件。由于库)存储表模式、分区和位置以期提供像MySQL一没有MapReduce开销以及磁盘/O、查询语句编译样的功能。它支持大部分MySQL语法，同时使用相等一系列优化，Impala通常要比Hive具有更快的数似的database/able/view约定组织数据集。Hive内据访问性能[s]。Impala共享Hive的metastore,可直部机制是基于MapReduce,从而导致了计算过程中接与Hive管理的数据互操作。Spark[24]使用轻量级消耗大量的/0，降低了运行效率。Impala2]是由的线程作为执行器，减少了执行作业的开销，同时 Cloudera构建的一个针对Hadoop的开源的MPP 提高了调度的响应速度，如图2中的Spark部分所 (massively parallel processing)“交互式”SQL查询引示。Spark SQL是在Spark之上搭建的SQL查询引擎。Impala同样提供了一种SQL查询方法，如图2 擎，支持在Spark中使用Sql、HiveSql、Scala中的关中的Impala架构部分所示，与Hive不同的是，系型查询表达式。 Impala Hive SQL APP JDBC Statestore Catalog CLI JDBC/ODBC HUE ODBC Impalad Impalad Impalad Query Planner Query Planner Query Planner Thrift Server MetaStore Query Coordinator Query Coordinator Query Coordinator Query Executor Query Executor Query Executor Compiler Optimizer Executor Hadoop Spark Standalone Job Tracker Name Node Spark Context Spark Master 1 Data Node Data Node Data Node Spark Worker Spark Worker Spark Worker 'ask Tracker Task Tracker Task Tracker kecutor Backenc Executor Backend Executor Backend 图2 Hadoop、Hive、Impala与Spark执行结构图 Fig.2 Structure for implementation of Hadoop,Hive,Impala and Spark 2.3结构化数据存储与压缩多种格式的数据格式的支持。Text是原始的文本数目前，很多研究者提出了在Hadoop中优化结构据，通常为CSV或其他特定字符分隔。Hive的格式化数据存储的方法。He等[2]提出的RCFile格式旨支持更为全面，由于Impala和Hive共享metastore, 在提高数据导人和处理效率。它首先将数据水平因此本文平台实际应用中通常由Hive导入数据而分割为多个行组(ov-group),然后对每个组内的数后台使用Spark SQL查询。据垂直分割成列存储。列存储将数据表同一列的表1Hive、Impala和Spark SOL数据格式支持比较数据连续存放，当查询只涉及部分列时，可大幅减 Table 1 Data format comparison of Hive,Impala and 少所需读取的数据量。ORC(optimized RCFile)是对 Spark SQL RCFile的改进，解决其在数据类型和性能上的多个数据 Hive Impala Spark SQL 局限性，改善查询和空间利用效率。Parquet是格式查询插入查询插人查询插入 Hadoop生态圈中一种新型列式存储格式，灵感来自于2010年Google发表的Dremel论文[2]，它可以兼 Text 容Hadoop生态圈中大多数生态框架(Hadoop、Spark RCFile 等)，被多种查询引擎支持(Hive、Impala、Spark SQL、 ORC Dill等)，并且它与语言和平台无关的。表1比较了本文2.2节描述的3种查询引擎从HDFS上读取 Parquet

行的ＭａｐＲｅｄｕｃｅ任务。如图２中的Ｈｉｖｅ架构部分所示，Ｈｉｖｅ通过一个ｍｅｔａｓｔｏｒｅ（本身就是一个数据库）存储表模式、分区和位置以期提供像ＭｙＳＱＬ一样的功能。它支持大部分ＭｙＳＱＬ语法，同时使用相似的ｄａｔａｂａｓｅ／ｔａｂｌｅ／ｖｉｅｗ约定组织数据集。Ｈｉｖｅ内部机制是基于ＭａｐＲｅｄｕｃｅ，从而导致了计算过程中消耗大量的Ｉ／Ｏ，降低了运行效率。Ｉｍｐａｌａ［２２］是由Ｃｌｏｕｄｅｒａ构建的一个针对Ｈａｄｏｏｐ的开源的ＭＰＰ（ｍａｓｓｉｖｅｌｙｐａｒａｌｌｅｌｐｒｏｃｅｓｓｉｎｇ）“交互式” ＳＱＬ查询引擎。Ｉｍｐａｌａ同样提供了一种ＳＱＬ查询方法，如图２中的Ｉｍｐａｌａ架构部分所示，与Ｈｉｖｅ不同的是，Ｉｍｐａｌａ并没有使用ＭａｐＲｅｄｕｃｅ执行查询，而是使用了自己的执行守护进程操作本地磁盘文件。由于没有ＭａｐＲｅｄｕｃｅ开销以及磁盘Ｉ／Ｏ、查询语句编译等一系列优化，Ｉｍｐａｌａ通常要比Ｈｉｖｅ具有更快的数据访问性能［２３］。Ｉｍｐａｌａ共享Ｈｉｖｅ的ｍｅｔａｓｔｏｒｅ，可直接与Ｈｉｖｅ管理的数据互操作。Ｓｐａｒｋ［２４］使用轻量级的线程作为执行器，减少了执行作业的开销，同时提高了调度的响应速度，如图２中的Ｓｐａｒｋ部分所示。ＳｐａｒｋＳＱＬ是在Ｓｐａｒｋ之上搭建的ＳＱＬ查询引擎，支持在Ｓｐａｒｋ中使用Ｓｑｌ、ＨｉｖｅＳｑｌ、Ｓｃａｌａ中的关系型查询表达式。图２Ｈａｄｏｏｐ、Ｈｉｖｅ、Ｉｍｐａｌａ与Ｓｐａｒｋ执行结构图Ｆｉｇ．２ＳｔｒｕｃｔｕｒｅｆｏｒｉｍｐｌｅｍｅｎｔａｔｉｏｎｏｆＨａｄｏｏｐ，Ｈｉｖｅ，ＩｍｐａｌａａｎｄＳｐａｒｋ２．３结构化数据存储与压缩目前，很多研究者提出了在Ｈａｄｏｏｐ中优化结构化数据存储的方法。Ｈｅ等［２５］提出的ＲＣＦｉｌｅ格式旨在提高数据导入和处理效率。它首先将数据水平分割为多个行组（ｒｏｗ⁃ｇｒｏｕｐ），然后对每个组内的数据垂直分割成列存储。列存储将数据表同一列的数据连续存放，当查询只涉及部分列时，可大幅减少所需读取的数据量。ＯＲＣ（ｏｐｔｉｍｉｚｅｄＲＣＦｉｌｅ）是对ＲＣＦｉｌｅ的改进，解决其在数据类型和性能上的多个局限性，改善查询和空间利用效率。Ｐａｒｑｕｅｔ是Ｈａｄｏｏｐ生态圈中一种新型列式存储格式，灵感来自于２０１０年Ｇｏｏｇｌｅ发表的Ｄｒｅｍｅｌ论文［２６］，它可以兼容Ｈａｄｏｏｐ生态圈中大多数生态框架（Ｈａｄｏｏｐ、Ｓｐａｒｋ等），被多种查询引擎支持（Ｈｉｖｅ、Ｉｍｐａｌａ、ＳｐａｒｋＳＱＬ、Ｄｒｉｌｌ等），并且它与语言和平台无关的。表１比较了本文２．２节描述的３种查询引擎从ＨＤＦＳ上读取多种格式的数据格式的支持。Ｔｅｘｔ是原始的文本数据，通常为ＣＳＶ或其他特定字符分隔。Ｈｉｖｅ的格式支持更为全面，由于Ｉｍｐａｌａ和Ｈｉｖｅ共享ｍｅｔａｓｔｏｒｅ，因此本文平台实际应用中通常由Ｈｉｖｅ导入数据而后台使用ＳｐａｒｋＳＱＬ查询。表１Ｈｉｖｅ、Ｉｍｐａｌａ和ＳｐａｒｋＳＱＬ数据格式支持比较Ｔａｂｌｅ１ＤａｔａｆｏｒｍａｔｃｏｍｐａｒｉｓｏｎｏｆＨｉｖｅ，ＩｍｐａｌａａｎｄＳｐａｒｋＳＱＬ数据格式ＨｉｖｅＩｍｐａｌａＳｐａｒｋＳＱＬ查询插入查询插入查询插入Ｔｅｘｔ √ √ √ √ √ √ ＲＣＦｉｌｅ √ √ √ — — — ＯＲＣ √ √ — — — — Ｐａｒｑｕｅｔ √ √ √ √ √ √ ·７２０· 智能系统学报第１２卷

第5期何明，等：基于SQL-on-Hadoop查询引擎的日志挖掘及其应用 ·721. 数据压缩是另一种性能优化方法。压缩一方 DSparkConf conf new SparkConf(); 面节省存储空间，另一方面在相同磁盘/0速度可 ②创建上下文对象；读写更多记录。Hive、Impala和Spark SQL均支持直 3StreamingContext(conf,Interval); 接查询压缩的数据文件，常用压缩算法有Gzip/ZIib 4MapOffsets=kafka.getOffset(); 和侧重于解压缩速度的Snappy。ORC格式本身已 ⑤获取kafka读取偏移量；内嵌轻量级的压缩机制。 ⑥DStream stream; 2.4结构化数据处理算法 7KafkaUtils.createDStream(input); RDD数据集包含对父RDD的一组依赖，这种依 ⑧Return streamo 赖描述了RDD之间的传承关系。RDD将操作分为 2)RDD数据处理两类：Transformation与Action。Transformation操作 ①stream.foreachRDD; 不执行运算，只有当Action操作时才触发运算。在 2new VoidFunction>(); RDD的实现机制中，基于迭代器的接口实现原理使 3call(RDDrdd); 得数据的访问更加高效，同时避免了大量中间结果 4HasOffsetRanges offrange rdd.rdd(); 对内存的消耗。Spark SQL包含了结构化数据和数 ⑤合并请求应答，并解析存储数据：据之上进行运算的更多信息，Spark SQL使用这些信 6rdd.mapPartitionsToPair; 息进行优化，使得结构化数据的操作更加高效和方 7 new FlumeKafkaFunction(); 便，基于Spark SQL的数据操作流程如下。 8foreachPartition(ProceFunction()); 算法1 SparkSQLonRdd(,:) 9kafka.setOffset(offrange); 输入Kafka输入数据流input,Spark上下文 ①保存kafka读取偏移量。 context; 3)ProceFunction数据后处理输出分布式集合dataframe。 DIterator>iter; 1)DStream line:Kafka->DStream(input); 2while (iter.hasNext()); 2)获取Kaka流数据输入； 3KafkaData data iter.next()._2(); 3)SglContext sc new SqlContext(context); 4json =data.getData(); 4)DStreamrdd=line.map; 5Record record =Object(json,class); 5)new Function: 6record.setCollect_time; 6)public Row call(T); 7data.getExtData(TIME)); 7)创建Row对象； 8Utils.save(item_topic,record); 8)List ⑨Return record.. (): 其中，RDD根据数据记录的key对结构进行分 9)Struct Fields.add CreateDataType (Column 区。分片数据采用迭代器Iterator流式访问，hasNext >)): 方法是由RDD lineage上各个Transformation携带的 10)重复步骤9)创建逻辑表结构：闭包函数复合而成，使得对象被序列化，通过网络 11)Struct Type st:DataTypes.CreateStructType 传输到其他节点上进行装载运算。Iterator每访问 (sf); 一个元素，就对该元素应用相应的复合函数，得到 12)DataFrame df 的结果再流式地存储。 13)sc->DataFrame(rdd,st); 3平台架构与集群环境部署 14)df.RegisterTable(); 15)DataFrame dataframe=sc.sql(); 3.1平台架构与处理框架 16)Return dataframe. 本文基于Hadoop,构建证券交易应用服务器和算法2 RddProcessing() 网络设备海量日志采集、解析、存储与实时计算分输入Kafka输入数据流input 析平台，平台的核心架构如下。输出数据集对象record。 1)数据采集层：负责实时采集来自通达信、恒 1)数据采集与预处理生、核新的网上交易应用服务器全天24小时的客户

数据压缩是另一种性能优化方法。压缩一方面节省存储空间，另一方面在相同磁盘Ｉ／Ｏ速度可读写更多记录。Ｈｉｖｅ、Ｉｍｐａｌａ和ＳｐａｒｋＳＱＬ均支持直接查询压缩的数据文件，常用压缩算法有Ｇｚｉｐ／Ｚｌｉｂ和侧重于解压缩速度的Ｓｎａｐｐｙ。ＯＲＣ格式本身已内嵌轻量级的压缩机制。２．４结构化数据处理算法ＲＤＤ数据集包含对父ＲＤＤ的一组依赖，这种依赖描述了ＲＤＤ之间的传承关系。ＲＤＤ将操作分为两类：Ｔｒａｎｓｆｏｒｍａｔｉｏｎ与Ａｃｔｉｏｎ。Ｔｒａｎｓｆｏｒｍａｔｉｏｎ操作不执行运算，只有当Ａｃｔｉｏｎ操作时才触发运算。在ＲＤＤ的实现机制中，基于迭代器的接口实现原理使得数据的访问更加高效，同时避免了大量中间结果对内存的消耗。ＳｐａｒｋＳＱＬ包含了结构化数据和数据之上进行运算的更多信息，ＳｐａｒｋＳＱＬ使用这些信息进行优化，使得结构化数据的操作更加高效和方便，基于ＳｐａｒｋＳＱＬ的数据操作流程如下。算法１ＳｐａｒｋＳＱＬｏｎＲｄｄ（＜ｉｎｐｕｔ＞，＜ｃｏｎｔｅｘｔ＞）输入Ｋａｆｋａ输入数据流ｉｎｐｕｔ，Ｓｐａｒｋ上下文ｃｏｎｔｅｘｔ；输出分布式集合ｄａｔａｆｒａｍｅ。１）ＤＳｔｒｅａｍｌｉｎｅ：Ｋａｆｋａ－＞ＤＳｔｒｅａｍ（ｉｎｐｕｔ）；２）获取Ｋａｆｋａ流数据输入；３）ＳｑｌＣｏｎｔｅｘｔｓｃ＝ｎｅｗＳｑｌＣｏｎｔｅｘｔ（ｃｏｎｔｅｘｔ）；４）ＤＳｔｒｅａｍ＜Ｒｏｗ＞ｒｄｄ＝ｌｉｎｅ．ｍａｐ；５）ｎｅｗＦｕｎｃｔｉｏｎ；６）ｐｕｂｌｉｃＲｏｗｃａｌｌ（Ｔ）｛｝；７）创建Ｒｏｗ对象；８）Ｌｉｓｔ＜ＳｔｒｕｃｔＦｉｅｌｄ＞ｓｆ＝ｎｅｗ；Ｌｉｓｔ＜ＳｔｒｕｃｔＦｉｅｌｄ＞（）；９）ＳｔｒｕｃｔＦｉｅｌｄｓ．ａｄｄ（ＣｒｅａｔｅＤａｔａＴｙｐｅ（＜Ｃｏｌｕｍｎ＞））；１０）重复步骤９）创建逻辑表结构；１１）ＳｔｒｕｃｔＴｙｐｅｓｔ：ＤａｔａＴｙｐｅｓ．ＣｒｅａｔｅＳｔｒｕｃｔＴｙｐｅ（ｓｆ）；１２）ＤａｔａＦｒａｍｅｄｆ：１３）ｓｃ－＞ＤａｔａＦｒａｍｅ（ｒｄｄ，ｓｔ）；１４）ｄｆ．ＲｅｇｉｓｔｅｒＴａｂｌｅ（＜ＴａｂｌｅＮａｍｅ＞）；１５）ＤａｔａＦｒａｍｅｄａｔａｆｒａｍｅ＝ｓｃ．ｓｑｌ（＜ＳｑｌＱｕｅｒｙ＞）；１６）Ｒｅｔｕｒｎｄａｔａｆｒａｍｅ。算法２ＲｄｄＰｒｏｃｅｓｓｉｎｇ（＜ｉｎｐｕｔ＞）输入Ｋａｆｋａ输入数据流ｉｎｐｕｔ；输出数据集对象ｒｅｃｏｒｄ。１）数据采集与预处理 ①ＳｐａｒｋＣｏｎｆｃｏｎｆ＝ｎｅｗＳｐａｒｋＣｏｎｆ（）； ②创建上下文对象； ③ＳｔｒｅａｍｉｎｇＣｏｎｔｅｘｔ（ｃｏｎｆ，Ｉｎｔｅｒｖａｌ）； ④Ｍａｐ＜Ｅ，Ｔ＞Ｏｆｆｓｅｔｓ＝ｋａｆｋａ．ｇｅｔＯｆｆｓｅｔ（）； ⑤获取ｋａｆｋａ读取偏移量； ⑥ＤＳｔｒｅａｍｓｔｒｅａｍ； ⑦ＫａｆｋａＵｔｉｌｓ．ｃｒｅａｔｅＤＳｔｒｅａｍ（ｉｎｐｕｔ）； ⑧Ｒｅｔｕｒｎｓｔｒｅａｍ。２）ＲＤＤ数据处理 ①ｓｔｒｅａｍ．ｆｏｒｅａｃｈＲＤＤ； ②ｎｅｗＶｏｉｄＦｕｎｃｔｉｏｎ＜ＲＤＤ＞＞（）； ③ｃａｌｌ（ＲＤＤ＜ＭｅｓｓａｇｅＡｎｄＭｅｔａｄａｔａ＞ｒｄｄ）； ④ＨａｓＯｆｆｓｅｔＲａｎｇｅｓｏｆｆｒａｎｇｅ＝ｒｄｄ．ｒｄｄ（）； ⑤合并请求应答，并解析存储数据； ⑥ｒｄｄ．ｍａｐＰａｒｔｉｔｉｏｎｓＴｏＰａｉｒ； ⑦ ｎｅｗＦｌｕｍｅＫａｆｋａＦｕｎｃｔｉｏｎ（）； ⑧ｆｏｒｅａｃｈＰａｒｔｉｔｉｏｎ（ＰｒｏｃｅＦｕｎｃｔｉｏｎ（））； ⑨ｋａｆｋａ．ｓｅｔＯｆｆｓｅｔ（ｏｆｆｒａｎｇｅ）； ⑩保存ｋａｆｋａ读取偏移量。３）ＰｒｏｃｅＦｕｎｃｔｉｏｎ数据后处理 ①Ｉｔｅｒａｔｏｒ＜Ｔｕｐｌｅ２＜Ｔ，ＫａｆｋａＤａｔａ＞＞ｉｔｅｒ； ②ｗｈｉｌｅ（ｉｔｅｒ．ｈａｓＮｅｘｔ（））； ③ＫａｆｋａＤａｔａｄａｔａ＝ｉｔｅｒ．ｎｅｘｔ（）．＿２（）； ④ｊｓｏｎ＝ｄａｔａ．ｇｅｔＤａｔａ（）； ⑤Ｒｅｃｏｒｄｒｅｃｏｒｄ＝Ｏｂｊｅｃｔ（ｊｓｏｎ，ｃｌａｓｓ）； ⑥ｒｅｃｏｒｄ．ｓｅｔＣｏｌｌｅｃｔ＿ｔｉｍｅ； ⑦ｄａｔａ．ｇｅｔＥｘｔＤａｔａ（ＴＩＭＥ））； ⑧Ｕｔｉｌｓ．ｓａｖｅ（ｉｔｅｍ＿ｔｏｐｉｃ，ｒｅｃｏｒｄ）； ⑨Ｒｅｔｕｒｎｒｅｃｏｒｄ。其中，ＲＤＤ根据数据记录的ｋｅｙ对结构进行分区。分片数据采用迭代器Ｉｔｅｒａｔｏｒ流式访问，ｈａｓＮｅｘｔ方法是由ＲＤＤｌｉｎｅａｇｅ上各个Ｔｒａｎｓｆｏｒｍａｔｉｏｎ携带的闭包函数复合而成，使得对象被序列化，通过网络传输到其他节点上进行装载运算。Ｉｔｅｒａｔｏｒ每访问一个元素，就对该元素应用相应的复合函数，得到的结果再流式地存储。３平台架构与集群环境部署３．１平台架构与处理框架本文基于Ｈａｄｏｏｐ，构建证券交易应用服务器和网络设备海量日志采集、解析、存储与实时计算分析平台，平台的核心架构如下。１）数据采集层：负责实时采集来自通达信、恒生、核新的网上交易应用服务器全天２４小时的客户第５期何明，等：基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎的日志挖掘及其应用 ·７２１·

·722. 智能系统学报第12卷请求应答数据以及网络设备日志数据，为大数据分 4)稳定性和可靠性：基于成熟的、经过实践验证析平台提供数据源。稳定可靠的Hadoop技术组件服务器节点非常容易 2)数据汇集层：将各个数据采集节点的日志数实现横向扩展，分布式环境保障集群中的任意一台据源源不断地汇集到各自的集群。服务器出现宕机时不影响系统的稳定可靠运行。 3)数据缓冲层：根据不同的Topic对海量日志数 3.2环境部署据进行缓冲，有助于控制和优化数据流经过系统的基于Hadoop的网络日志分析平台在海通证券速度。网络信息中心的搭建部署，如图4所示。共42台服 4)数据分发与解析处理层：负责数据的解析、勾务器，其中11台是Flume汇聚节点(256GB内存，对、计算和分发。 2×600GB,RAID1阵列)，5台Kafka节点(256GB 5)数据存储与计算层：用于存储、管理日志数内存，2×6O0GB,RAID1阵列)，3台Couchbase节点据，支持多维检索、统计分析和查询处理。 (512GB内存，2×600GB,RAID1阵列)，5台 6)应用层：负责面向终端用户提供日志分析与 Zookeeper节点(256GB内存，2×600GB,RAD1阵管理的泛在接入，提供实时运维监控、实时预警、明列)，2台作为Namenode(256GB内存，2×600GB, 细毫秒级查询以及实时报表输出等应用。 RAID1阵列)，14台是Datanode节点(256GB内存，可以看到，在这个大数据分析体系结构中，系统 2×600GB,RAID1阵列，2×600GB,RAID1阵列+6× 支持TB级、PB级或者更大规模数据的分析和处 2TB,RAID0阵列)，2台Tomeat(256GB内存，2× 理：系统可以处理结构化数据、非结构化和半结构 600GB,RAID1阵列)。化数据，有良好的扩展性。基于上述平台结构，本文设计了能够有效地利用大数据技术解决海量系统访问日志多条件实时快速查询的处理框架，如图交易应用 Tomeat集群服务器 3所示。 Node I 了通 Fume集群Kafka集群 Zookeeper集群计算节点集群Hbase、Spark) 交易应用交易应用服务器集群服务器 Node I 汇消息队列集群 Node 2 Kafka topic Spark Flume Kafka topic 2 Streaming NameNode DataNode Flume CouchBase集群 Kafka topic 3 交易应用 Flume 丁Tomcat集群服务器集群 Kafka topic Node 2 交易应用服务器 Hbase Hive Elasticsearch Node n ZooKeeper集群交易应用图4集群拓扑图服务器集群 Node N Fig.4 Cluster topology 图3处理框架所有节点通过I0GB以太网互联。Hadoop部署 Fig.3 Processing framework 采用Cloudera的发行版，版本为CDH5.5.0,HDFS总容量近60TB。接入日志分析平台的数据来自网上该处理框架能够保证平台系统如下的几个交易应用服务器日志数据和网络设备日志数据。特性。网上交易日志每天产生的记录数约1.2亿条，体积 1)实时性：实时采集Agent包，从产生时刻起到约100GB:网络设备日志数据日志每天的记录数约实时采集，再到传输到数据中心，整个时间间隔控 650万条，体积约6GB。制在1s内实时勾对、解析等计算，并保存到数据中心的集群，这个过程的时间间隔控制在3~5s。 4实验与性能评估 2)准确性和完整性：传输通道实现不重传、不漏 4.1实验环境与数据集传、断点续传，保证数据完整性。我们采用的实验环境为7台物理测试机构建的 3)安全性：非对称加密算法对传输的日志数据集群，选取2台机器作为主节点，其余作为计算节点进行加密，使用SSL/TLS协议，保障网络传输通道进行SQL-on-Hadoop实验，测试集群拓扑如图5 的安全性。所示

请求应答数据以及网络设备日志数据，为大数据分析平台提供数据源。２）数据汇集层：将各个数据采集节点的日志数据源源不断地汇集到各自的集群。３）数据缓冲层：根据不同的Ｔｏｐｉｃ对海量日志数据进行缓冲，有助于控制和优化数据流经过系统的速度。４）数据分发与解析处理层：负责数据的解析、勾对、计算和分发。５）数据存储与计算层：用于存储、管理日志数据，支持多维检索、统计分析和查询处理。６）应用层：负责面向终端用户提供日志分析与管理的泛在接入，提供实时运维监控、实时预警、明细毫秒级查询以及实时报表输出等应用。可以看到，在这个大数据分析体系结构中，系统支持ＴＢ级、ＰＢ级或者更大规模数据的分析和处理；系统可以处理结构化数据、非结构化和半结构化数据，有良好的扩展性。基于上述平台结构，本文设计了能够有效地利用大数据技术解决海量系统访问日志多条件实时快速查询的处理框架，如图３所示。图３处理框架Ｆｉｇ．３Ｐｒｏｃｅｓｓｉｎｇｆｒａｍｅｗｏｒｋ该处理框架能够保证平台系统如下的几个特性。１）实时性：实时采集Ａｇｅｎｔ包，从产生时刻起到实时采集，再到传输到数据中心，整个时间间隔控制在１ｓ内实时勾对、解析等计算，并保存到数据中心的集群，这个过程的时间间隔控制在３～５ｓ。２）准确性和完整性：传输通道实现不重传、不漏传、断点续传，保证数据完整性。３）安全性：非对称加密算法对传输的日志数据进行加密，使用ＳＳＬ／ＴＬＳ协议，保障网络传输通道的安全性。４）稳定性和可靠性：基于成熟的、经过实践验证稳定可靠的Ｈａｄｏｏｐ技术组件服务器节点非常容易实现横向扩展，分布式环境保障集群中的任意一台服务器出现宕机时不影响系统的稳定可靠运行。３．２环境部署基于Ｈａｄｏｏｐ的网络日志分析平台在海通证券网络信息中心的搭建部署，如图４所示。共４２台服务器，其中１１台是Ｆｌｕｍｅ汇聚节点（２５６ＧＢ内存，２×６００ＧＢ，ＲＡＩＤ１阵列），５台Ｋａｆｋａ节点（２５６ＧＢ内存，２×６００ＧＢ，ＲＡＩＤ１阵列），３台Ｃｏｕｃｈｂａｓｅ节点（５１２ＧＢ内存，２ × ６００ＧＢ，ＲＡＩＤ１阵列），５台Ｚｏｏｋｅｅｐｅｒ节点（２５６ＧＢ内存，２×６００ＧＢ，ＲＡＩＤ１阵列），２台作为Ｎａｍｅｎｏｄｅ（２５６ＧＢ内存，２×６００ＧＢ，ＲＡＩＤ１阵列），１４台是Ｄａｔａｎｏｄｅ节点（２５６ＧＢ内存，２×６００ＧＢ，ＲＡＩＤ１阵列，２×６００ＧＢ，ＲＡＩＤ１阵列＋６× ２ＴＢ，ＲＡＩＤ０阵列），２台Ｔｏｍｃａｔ（２５６ＧＢ内存，２× ６００ＧＢ，ＲＡＩＤ１阵列）。图４集群拓扑图Ｆｉｇ．４Ｃｌｕｓｔｅｒｔｏｐｏｌｏｇｙ所有节点通过１０ＧＢ以太网互联。Ｈａｄｏｏｐ部署采用Ｃｌｏｕｄｅｒａ的发行版，版本为ＣＤＨ５．５．０，ＨＤＦＳ总容量近６０ＴＢ。接入日志分析平台的数据来自网上交易应用服务器日志数据和网络设备日志数据。网上交易日志每天产生的记录数约１．２亿条，体积约１００ＧＢ；网络设备日志数据日志每天的记录数约６５０万条，体积约６ＧＢ。４实验与性能评估４．１实验环境与数据集我们采用的实验环境为７台物理测试机构建的集群，选取２台机器作为主节点，其余作为计算节点进行ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ实验，测试集群拓扑如图５所示。 ·７２２· 智能系统学报第１２卷

第5期何明，等：基于SQL-on-Hadoop查询引擎的日志挖掘及其应用 ·723. 31图 4.2性能评估千兆网交换机本文选择SQL-on-Hadoop作为基础查询引擎，对 3个引擎的处理时效性进行分析。从表3中各个引擎的总运行时间可以看出，Impala比Hive快了l.S 倍，Spark SQL比Hive快了2.7倍。表3查询执行时间比较主节点1 主节点2 工作节点1 工作节点5 Name Node Name Node Data Node Data Node Table 3 Comparison of query runtime 图5测试环境拓扑图 TPC-H 执行时间/s Fig.5 Test environment topology 查询子句 Hive Impala Spark SQL 实验采用针对OLAP应用的TPC-H测试基准来 Q1 115 25 14 评估执行引擎的性能。TPC-H面向商务采购应用， Q2 161 146 18 其数据库模式遵循第三范式。性能评测基准定义 Q3 274 173 83 了22个复杂SELECT语句和2个更新数据语句，遵循SQL-92标准。数据库的规模由自带的扩展因子 Q4 152 211 126 (scale factor,SF)决定，有10个级别，从1GB到100TB Q5 342 326 64 不等供用户选择。TPC-H基准以每小时内执行的 Q6 46 38 12 查询数作为度量标准，在工业和科研领域当中应用 Q7 678 339 87 广泛。文献[23]讨论了ORCFile和Parquet两种列式 Q8 468 331 90 存储格式的性能差别，通过空间使用和查询性能比 Q9 735 467 较，认为Parquet针对文本文件压缩率较高，从而节 Q10 298 163 40 省了HDFS的存储空间，同时减小了磁盘/O的开 Q11 246 35 30 销，但是解压缩会占用部分计算资源，对性能有一定影响。因此，本文采用Parquet紧凑的列存储格 Q12 126 22 14 式，并选用了压缩比和解压速度较为均衡的 Q13 29 142 66 Snappy,相对原始文本日志节省了近70%的空间。 Q14 101 21 本文实验使用TPC-H作为测试数据集，在SF= Q15 27 16 300的数据规模上进行测试，其描述和相关压缩处 12 理如表2所示。 Q16 4 267 54 表2实验数据集 Q17 523 428 254 Table 2 Experimental dataset Q18 449 549 121 Table Rows Volume Parquet/Snappy Q19 243 226 283 Lineitem 1799989091 187.8GB 50.8GB Q20 419 170 91 Order 450000000 43.6GB 15.8GB Q21 681 713 792 Partsupp 240000000 32.2GB 12.2GB Q22 82 67 92 Part 60000000 8.7GB 2.3GB Total 7592 5223 2831 Customer 45000000 7.5GB 3.9GB 实验结果表明，Impala在Q1、Q6、Q12、Q15上 Supplier 3000000 0.4GB 0.23GB 的性能优于Hive,查询语句结构如下： Nation 25 3.1KB 2.1KB SELECT Region 620B 390B fieldl,field12, 总计 2597989121 280.2GB 85.2GB SUM(field3)as alias1

图５测试环境拓扑图Ｆｉｇ．５Ｔｅｓｔｅｎｖｉｒｏｎｍｅｎｔｔｏｐｏｌｏｇｙ实验采用针对ＯＬＡＰ应用的ＴＰＣ⁃Ｈ测试基准来评估执行引擎的性能。ＴＰＣ⁃Ｈ面向商务采购应用，其数据库模式遵循第三范式。性能评测基准定义了２２个复杂ＳＥＬＥＣＴ语句和２个更新数据语句，遵循ＳＱＬ－９２标准。数据库的规模由自带的扩展因子（ｓｃａｌｅｆａｃｔｏｒ，ＳＦ）决定，有１０个级别，从１ＧＢ到１００ＴＢ不等供用户选择。ＴＰＣ⁃Ｈ基准以每小时内执行的查询数作为度量标准，在工业和科研领域当中应用广泛。文献［２３］讨论了ＯＲＣＦｉｌｅ和Ｐａｒｑｕｅｔ两种列式存储格式的性能差别，通过空间使用和查询性能比较，认为Ｐａｒｑｕｅｔ针对文本文件压缩率较高，从而节省了ＨＤＦＳ的存储空间，同时减小了磁盘Ｉ／Ｏ的开销，但是解压缩会占用部分计算资源，对性能有一定影响。因此，本文采用Ｐａｒｑｕｅｔ紧凑的列存储格式，并选用了压缩比和解压速度较为均衡的Ｓｎａｐｐｙ，相对原始文本日志节省了近７０％的空间。本文实验使用ＴＰＣ⁃Ｈ作为测试数据集，在ＳＦ＝３００的数据规模上进行测试，其描述和相关压缩处理如表２所示。表２实验数据集Ｔａｂｌｅ２ＥｘｐｅｒｉｍｅｎｔａｌｄａｔａｓｅｔＴａｂｌｅＲｏｗｓＶｏｌｕｍｅＰａｒｑｕｅｔ／ＳｎａｐｐｙＬｉｎｅｉｔｅｍ１７９９９８９０９１１８７．８ＧＢ５０．８ＧＢＯｒｄｅｒ４５０００００００４３．６ＧＢ１５．８ＧＢＰａｒｔｓｕｐｐ２４０００００００３２．２ＧＢ１２．２ＧＢＰａｒｔ６０００００００８．７ＧＢ２．３ＧＢＣｕｓｔｏｍｅｒ４５００００００７．５ＧＢ３．９ＧＢＳｕｐｐｌｉｅｒ３０００００００．４ＧＢ０．２３ＧＢＮａｔｉｏｎ２５３．１ＫＢ２．１ＫＢＲｅｇｉｏｎ５６２０Ｂ３９０Ｂ总计２５９７９８９１２１２８０．２ＧＢ８５．２ＧＢ４．２性能评估本文选择ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ作为基础查询引擎，对３个引擎的处理时效性进行分析。从表３中各个引擎的总运行时间可以看出，Ｉｍｐａｌａ比Ｈｉｖｅ快了１．５倍，ＳｐａｒｋＳＱＬ比Ｈｉｖｅ快了２．７倍。表３查询执行时间比较Ｔａｂｌｅ３ＣｏｍｐａｒｉｓｏｎｏｆｑｕｅｒｙｒｕｎｔｉｍｅＴＰＣ⁃Ｈ查询子句执行时间／ｓＨｉｖｅＩｍｐａｌａＳｐａｒｋＳＱＬＱ１１１５２５１４Ｑ２１６１１４６１８Ｑ３２７４１７３８３Ｑ４１５２２１１１２６Ｑ５３４２３２６６４Ｑ６１４６３８１２Ｑ７６７８３３９８７Ｑ８４６８３３１９０Ｑ９１１０４７３５４６７Ｑ１０２９８１６３４０Ｑ１１２４６３５３０Ｑ１２１２６２２１４Ｑ１３２９３１４２６６Ｑ１４１０７１０１２１Ｑ１５２７７１６１２Ｑ１６４０８２６７５４Ｑ１７５２３４２８２５４Ｑ１８４４９５４９１２１Ｑ１９２４３２２６２８３Ｑ２０４１９１７０９１Ｑ２１６８１７１３７９２Ｑ２２８２６７９２Ｔｏｔａｌ７５９２５２２３２８３１实验结果表明，Ｉｍｐａｌａ在Ｑ１、Ｑ６、Ｑ１２、Ｑ１５上的性能优于Ｈｉｖｅ，查询语句结构如下：ＳＥＬＥＣＴ｛ｆｉｅｌｄ１，ｆｉｅｌｄ１２，ＳＵＭ（ｆｉｅｌｄ３）ａｓａｌｉａｓ１，第５期何明，等：基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎的日志挖掘及其应用 ·７２３·

ＳＵＭ（ｆｉｅｌｄ４）ａｓａｌｉａｓ２， ……，ＡＶＧ（ｆｉｅｌｄ５）ａｓａｌｉａｓ３， ……，ＣＯＵＮＴ（∗）ａｓａｌｉａｓ４｝ＦＲＯＭＴａｂｌｅＥｘｐｒｅｓｓｉｏｎＷＨＥＲＥ［ｆｉｅｌｄ６＜＝ｄａｔｅ′ｙｙｙｙ⁃ｍｍ⁃ｄｄ′⁃ｉｎｔｅｒｖａｌ ′［ＤＥＬＴＡ］′ ｄａｙ（３）］ＧＲＯＵＰＢＹ［ｆｉｅｌｄ６，ｆｉｅｌｄ７］ＯＲＤＥＲＢＹ［ｆｉｅｌｄ６，ｆｉｅｌｄ７］根据该语句的执行计划，可以判断查询时对整个表进行了遍历。对于ＳｐａｒｋＳＱＬ而言，其在大多数查询上的表现优于Ｈｉｖｅ和Ｉｍｐａｌａ。由于Ｓｐａｒｋ的接口丰富和ＳＱＬ优势，在执行查询时的速度较快。４．３Ｑ２２资源消耗情况Ｑ２２的查询语句如下：ＳＥＬＥＣＴｃｎｔｒｙｃｏｄｅ，ＣＯＵＮＴ（ ∗）ａｓｎｕｍｃｕｓｔ，ｓｕｍ（ｃ＿ａｃｃｔｂａｌ）ａｓｔｏｔａｃｃｔｂａｌＦＲＯＭ（ＳＥＬＥＣＴｓｕｂｓｔｒｉｎｇ（ｃ＿ｐｈｏｎｅｆｒｏｍ１ｆｏｒ２）ａｓｃｎｔｒｙｃｏｄｅ，ｃ＿ａｃｃｔｂａｌＦＲＯＭｃｕｓｔｏｍｅｒＷＨＥＲＥｓｕｂｓｔｒｉｎｇ（ｃ＿ｐｈｏｎｅｆｒｏｍ１ｆｏｒ２）ｉｎ（′［Ｉ１］′，′［Ｉ２］′，′［Ｉ３］′，′［Ｉ４］′，′［Ｉ５］′，′［１６］′， ′［Ｉ７］′）ａｎｄｃ＿ａｃｃｔｂａｌ＞（ＳＥＬＥＣＴＡＶＧ（ｃ＿ａｃｃｔｂａｌ）ＦＲＯＭｃｕｓｔｏｍｅｒＷＨＥＲＥｃ＿ａｃｃｔｂａｌ＞０．００ａｎｄｓｕｂｓｔｒｉｎｇ（ｃ＿ｐｈｏｎｅｆｒｏｍ１ｆｏｒ２）ｉｎ（′［１］′，′［１２］′，′［１３］′，′［１４］′，′［１５］′，′［１６］′， ′［Ｉ７］′））ａｎｄｎｏｔｅｘｉｓｔｓ（ＳＥＬＥＣＴ ∗ ＦＲＯＭｏｒｄｅｒｓｗｈｅｒｅｏ＿ｃｕｓｔｋｅｙ＝ｃ＿ｃｕｓｔｋｅｙ））ａｓｃｕｓｔｓａｌｅＧｒｏｕｐＢＹｃｎｔｒｙｃｏｄｅＯＲＤＥＲＢＹｃｎｔｒｙｃｏｄｅ；如图６所示，Ｑ２２中作业由３个子查询组成。子查询Ｓ１对ｃｕｓｔｏｍｅｒ表进行扫描并将结果保存到临时表Ｔｅｍｐ１中；子查询Ｓ２对Ｔｅｍｐ１进行聚集操作ＡＧＧ１后将结果保存到临时表Ｔｅｍｐ２中；子查询Ｓ３在与表Ｏｒｄｅｒｓ执行聚集操作ＡＧＧ２后依次与Ｔｅｍｐ１和Ｔｅｍｐ２进行关联操作求笛卡尔乘积ＡＧＧ３然后排序。图６ＩｍｐｌｅｍｅｎｔａｔｉｏｎｏｆＱ２２Ｆｉｇ．６Ｑ２２的执行过程实验分析对比了不同的查询方式在运行Ｑ２２时集群资源使用情况（如图７～１１所示），包括ＣＰＵ、内存、网络、磁盘Ｉ／Ｏ。注意到，在查询Ｑ２２执行过程中，Ｉｍｐａｌａ对集群资源的占用是最少的，其次是Ｈｉｖｅ，ＳｐａｒｋＳＱＬ占用资源最多。由于ＳｐａｒｋＳＱＬ是基于内存计算的框架，所以在内存占用方面和磁盘读取上更为明显。图７集群平均ＣＰＵ使用率Ｆｉｇ．７ＡｖｅｒａｇｅｃｌｕｓｔｅｒＣＰＵｕｓａｇｅ由于Ｈｉｖｅ和ＳｐａｒｋＳＱＬ均在ＪＶＭ之上运行，对ＣＰＵ和内存的使用依赖于ＪＶＭ。如图７所示，Ｉｍｐａｌａ的ＣＰＵ占用时间要明显少于Ｈｉｖｅ和ＳｐａｒｋＳＱＬ，这是由于Ｉｍｐａｌａ在执行查询过程中，在每个计算节点上运行只占用一个ＣＰＵ线程。而Ｈｉｖｅ和ＳｐａｒｋＳＱＬ在ＣＰＵ使用上的优化完全依赖于ＪＶＭ。如图８所示，Ｉｍｐａｌａ和Ｈｉｖｅ内存使用率明显小于ＳｐａｒｋＳＱＬ，同时使用线程来执行耗费资源较多的ＥｘｅｃｕｔｏｒＢａｃｋｅｎｄ进程。图８集群内存平均使用量Ｆｉｇ．８Ａｖｅｒａｇｅｃｌｕｓｔｅｒｍｅｍｏｒｙｕｓａｇｅ ·７２４· 智能系统学报第１２卷

第5期何明，等：基于SQL-on-Hadoop查询引擎的日志挖掘及其应用 ·725· 在磁盘性能方面，Impala和Hive的磁盘读取速找到相应的数据：从压缩角度来看，本文采用率优于Spark SQL。从图9可以看出，Hive和Impala Snappy压缩方式，以减少数据输人量和加快查询速数据访问量在Sl时相对一致，高于SparkSQL。在度；从Spark SQL自身特性分析，Spark SQL基于内 S2中，mpala数据访问量较小，Hive次之，SparkSQL 存计算执行速度快，可以操作Hadoop上多样化格式最高。在图10中，Impala在S1和S2执行结束后将的数据并进行高效的结构化分析与处理，提供可用结果写入HDS时，对磁盘的写入速率迅速增加。性更好的API进行数据分析，更加灵活且易扩展。 1.6.×10 鉴于此，综合考虑以上几个方面并结合应用驱动的 1.4 -Hive --Impala -Spark SQL 大数据分析与计算实际需求，本文选择Spark SQL 作为SQL-on-Hadoop查询系统，以适应快速证券大 0.8 0.6 数据分析与计算场景下的高并发实时查询应用 0.4 0.2 需求。 102030405060708090 时间s 5 实际应用图9集群磁盘读取总速率在本文实现基于SQL-on-Hadoop网上交易日志 Fig.9 Cluster disk read speed 实时分析与计算平台上，目前已存储约60TB的网上交易日志，并开发和移植了实时监控、统计分析、 350 Hive-Impala -Spark SQL 明细查询等实际应用。翻 5.1实时运维监控 150 对分布在全国各个节点和服务器的状态实时监 100 控并对各种状态进行及时判断和处理，能够对整个 50 邂 102030405060708090 系统的使用状况有宏观的把控。实时运维监控主时间/s 要包括技术指标监控、业务指标监控和客户分布。图10集群磁盘写入总速率 1)如图12所示，技术指标监控主要针对实时的 Fig.10 Cluster disk write speed 请求延迟、成功率、系统冗余（带宽流量/在线数）等在图I1中，Impala在最后一个阶段的网络流量指标进行监控。数据从千万级别的当日日志数据迅速增长，主要由于执行过程中的内部表连接产生中实时提取，从采集到存储达到秒级实现。延迟情的结果通过网络传输给其他节点导致。况主要包括登录、委托、查询（资金查询）和转账这4 450 Hive -Impala -Spark SQL 类业务单位时间段内的平均耗时和峰值情况。系 350 统冗余用于指示系统的资源使用情况，包括系统容量情况和系统带宽使用情况，能实时展示系统当前冗余，有助于系统管理员及时掌握当前系统的使用情况。成功率主要包括登录、委托、转账这几类业 2 30 405060708090 务单位时间段内的处理成功率情况。时间s 图11集群网络流量 Fig.11 Cluster network traffic 综上所述，Spark SQL执行效率相对较快，它的查询速度比Hive要快2.7倍。然而，当查询总大小超过内存大小时，mpala则无法查询。Hive处理的结果准确率较高，处理速度较慢。因此，Hive比较适用于批处理应用；mpala适合交互式查询，系统的稳定性还有待提高；Spark SQL能够降低Hive的延迟，比较适合多并发和流数据处理场景。 0% 10 1112 通过以上的实验分析和比较，从文件格式角度来讲，本文选择能够更好地适配Spark SQL的图12技术指标监控 Parquet列式存储格式，以便快速地从HDFS中扫描 Fig.12 Technical index monitor

在磁盘性能方面，Ｉｍｐａｌａ和Ｈｉｖｅ的磁盘读取速率优于ＳｐａｒｋＳＱＬ。从图９可以看出，Ｈｉｖｅ和Ｉｍｐａｌａ数据访问量在Ｓ１时相对一致，高于ＳｐａｒｋＳＱＬ。在Ｓ２中，Ｉｍｐａｌａ数据访问量较小，Ｈｉｖｅ次之，ＳｐａｒｋＳＱＬ最高。在图１０中，Ｉｍｐａｌａ在Ｓ１和Ｓ２执行结束后将结果写入ＨＤＦＳ时，对磁盘的写入速率迅速增加。图９集群磁盘读取总速率Ｆｉｇ．９Ｃｌｕｓｔｅｒｄｉｓｋｒｅａｄｓｐｅｅｄ图１０集群磁盘写入总速率Ｆｉｇ．１０Ｃｌｕｓｔｅｒｄｉｓｋｗｒｉｔｅｓｐｅｅｄ在图１１中，Ｉｍｐａｌａ在最后一个阶段的网络流量迅速增长，主要由于执行过程中的内部表连接产生的结果通过网络传输给其他节点导致。图１１集群网络流量Ｆｉｇ．１１Ｃｌｕｓｔｅｒｎｅｔｗｏｒｋｔｒａｆｆｉｃ综上所述，ＳｐａｒｋＳＱＬ执行效率相对较快，它的查询速度比Ｈｉｖｅ要快２．７倍。然而，当查询总大小超过内存大小时，Ｉｍｐａｌａ则无法查询。Ｈｉｖｅ处理的结果准确率较高，处理速度较慢。因此，Ｈｉｖｅ比较适用于批处理应用；Ｉｍｐａｌａ适合交互式查询，系统的稳定性还有待提高；ＳｐａｒｋＳＱＬ能够降低Ｈｉｖｅ的延迟，比较适合多并发和流数据处理场景。通过以上的实验分析和比较，从文件格式角度来讲，本文选择能够更好地适配ＳｐａｒｋＳＱＬ的Ｐａｒｑｕｅｔ列式存储格式，以便快速地从ＨＤＦＳ中扫描找到相应的数据；从压缩角度来看，本文采用Ｓｎａｐｐｙ压缩方式，以减少数据输入量和加快查询速度；从ＳｐａｒｋＳＱＬ自身特性分析，ＳｐａｒｋＳＱＬ基于内存计算执行速度快，可以操作Ｈａｄｏｏｐ上多样化格式的数据并进行高效的结构化分析与处理，提供可用性更好的ＡＰＩ进行数据分析，更加灵活且易扩展。鉴于此，综合考虑以上几个方面并结合应用驱动的大数据分析与计算实际需求，本文选择ＳｐａｒｋＳＱＬ作为ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询系统，以适应快速证券大数据分析与计算场景下的高并发实时查询应用需求。５实际应用在本文实现基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ网上交易日志实时分析与计算平台上，目前已存储约６０ＴＢ的网上交易日志，并开发和移植了实时监控、统计分析、明细查询等实际应用。５．１实时运维监控对分布在全国各个节点和服务器的状态实时监控并对各种状态进行及时判断和处理，能够对整个系统的使用状况有宏观的把控。实时运维监控主要包括技术指标监控、业务指标监控和客户分布。１）如图１２所示，技术指标监控主要针对实时的请求延迟、成功率、系统冗余（带宽流量／在线数）等指标进行监控。数据从千万级别的当日日志数据中实时提取，从采集到存储达到秒级实现。延迟情况主要包括登录、委托、查询（资金查询）和转账这４类业务单位时间段内的平均耗时和峰值情况。系统冗余用于指示系统的资源使用情况，包括系统容量情况和系统带宽使用情况，能实时展示系统当前冗余，有助于系统管理员及时掌握当前系统的使用情况。成功率主要包括登录、委托、转账这几类业务单位时间段内的处理成功率情况。图１２技术指标监控Ｆｉｇ．１２Ｔｅｃｈｎｉｃａｌｉｎｄｅｘｍｏｎｉｔｏｒ第５期何明，等：基于ＳＱＬ⁃ｏｎ⁃Ｈａｄｏｏｐ查询引擎的日志挖掘及其应用 ·７２５·

·726 智能系统学报第12卷 2)如图13所示，业务指标监控主要针对登录情 ×10 1.2 况、转账情况、委托情况和实时在线人数等指标进。交易活跃用户 ※1.0 在线用户行监控。可以从千万级别的当日数据中实时观察 0.8 0.6 当前系统的客户登陆数、系统发生的交易数量和转 0.4 账金额等情况，整个过程实现秒级响应。 802 北京河北上海江苏浙江福建山东河南湖北广东深圳四川图15活跃用户分布 Fig.15 Active user distribution 特色撤卖委卖登录 130013151330134514:0014151430144515:00 操作时间点/时刻图16行为轨迹分析图13业务指标监控 Fig.16 Behavioral traces analysis Fig.13 Business index monitor 5.3业务统计查询与分析 3)如图14所示，客户分布主要针对实时在线客 1)统计报表：如图17所示，统计报表是实际日志处理中的一项重要需求和应用，对计算的性能和户与委托分布，站点和来源省份的分布。在线分布从千万级别的数据中指示一段时间客户的登陆来实时性要求更高。根据具体业务功能需求，按照指源和委托来源分布。系统通过登陆和委托源P关定周期完成系统资源、登录、委托和业务监控等统联全球P分布区域得出客户的分布情况，P分布计任务。统计报表主要是提供给系统管理员分析来自10亿级别的P分布数据源。系统的资源使用情况和系统健康状态，以便做好相应的措施和规划，同时为管理者决策提供数据支撑和参考依据。 300 登录总数 ≤ 250 失败总数 200 150 100 0 0 周周二周三周四周五 (a)登录报表 300 100% 图14客户分布 250 80% Fig.14 Customer distribution 200 60% 150 5.2客户交易行为监控 100 40% +委托数日志分析更有价值的应用在于发现客户的异常 50 一成功总数 20% +一委托成功率行为。如图15、16所示，通过大数据平台，可以实时周周二周三周四周五 0% 掌握不同区域和营业部活跃用户的分布，为业务部 (b)业务报表门做绩效考核、精准营销等提供数据支撑。图17业务报表 Fig.17 Business report

２）如图１３所示，业务指标监控主要针对登录情况、转账情况、委托情况和实时在线人数等指标进行监控。可以从千万级别的当日数据中实时观察当前系统的客户登陆数、系统发生的交易数量和转账金额等情况，整个过程实现秒级响应。图１３业务指标监控Ｆｉｇ．１３Ｂｕｓｉｎｅｓｓｉｎｄｅｘｍｏｎｉｔｏｒ３）如图１４所示，客户分布主要针对实时在线客户与委托分布，站点和来源省份的分布。在线分布从千万级别的数据中指示一段时间客户的登陆来源和委托来源分布。系统通过登陆和委托源ＩＰ关联全球ＩＰ分布区域得出客户的分布情况，ＩＰ分布来自１０亿级别的ＩＰ分布数据源。图１４客户分布Ｆｉｇ．１４Ｃｕｓｔｏｍｅｒｄｉｓｔｒｉｂｕｔｉｏｎ５．２客户交易行为监控日志分析更有价值的应用在于发现客户的异常行为。如图１５、１６所示，通过大数据平台，可以实时掌握不同区域和营业部活跃用户的分布，为业务部门做绩效考核、精准营销等提供数据支撑。图１５活跃用户分布Ｆｉｇ．１５Ａｃｔｉｖｅｕｓｅｒｄｉｓｔｒｉｂｕｔｉｏｎ图１６行为轨迹分析Ｆｉｇ．１６Ｂｅｈａｖｉｏｒａｌｔｒａｃｅｓａｎａｌｙｓｉｓ５．３业务统计查询与分析１）统计报表：如图１７所示，统计报表是实际日志处理中的一项重要需求和应用，对计算的性能和实时性要求更高。根据具体业务功能需求，按照指定周期完成系统资源、登录、委托和业务监控等统计任务。统计报表主要是提供给系统管理员分析系统的资源使用情况和系统健康状态，以便做好相应的措施和规划，同时为管理者决策提供数据支撑和参考依据。图１７业务报表Ｆｉｇ．１７Ｂｕｓｉｎｅｓｓｒｅｐｏｒｔ ·７２６· 智能系统学报第１２卷

点击进入文档下载页（PDF格式）

共12页，试读已结束，阅读完整版请下载

点击下载（PDF格式）

浏览记录