主页 > 案例大全 > 论文相关方法-面向舆情分析的存储系统优化

论文相关方法-面向舆情分析的存储系统优化

2021-04-30 15:58:33

  互联网时代,数据成为企业最为宝贵的财产,微博、贴吧、论坛等各种网站则是舆情数据的主要生产者。对舆情数据分析处理,实现对网络舆情的有效监控和管理成为重中之重。数据存储离不开数据库,对于数据库技术的研究国外发展极为迅猛,而国内许多公司更偏向于应用,不注重产品性能的优化研究。在现有的研究进展中,大多数是针对某一款数据库的性能研究。但是由于目前数据库产品的层出不穷,如何根据业务需求和数据特点选择合适的数据库产品,如何优化数据库提升查询效率,就成为各行各业研究的焦点。

  本文根据网络舆情数据特点,选取MySQL、MongoDB、Hive三种数据库,进行优化实验。对于MySQL,主要从存储引擎、索引策略、配置参数三方面进行优化;对于MongoDB,主要从集群模式和索引进行优化;对于Hive,根据计算引擎和列式存储格式,并结合Hive中索引特点和参数设计,进行查询性能的相关优化。

  对比三者实验结果,可以发现:当数据量在千万级别且查询分析涉及表连接操作时,MySQL难以短时间内获取查询结果;MongoDB会将索引读入内存,对返回指定列的SQL查询时间可以优化到毫秒级,但MySQL的MyISAM内置了一个计数器,count时直接从计数器中读取,因此在涉及count的聚合操作时,MongoDB的查询性能明显弱于MySQL;Hive的列式存储在查询时只有涉及到的列会被读取,可以同MongoDB一样,将返回指定列的SQL查询效率优化到毫秒级;在带有count的聚合查询中,Hive的优化性能明显高于MongoDB,接近于MySQL;对于关联查询,也不存在MySQL中长时间无法得到结果集的问题。三者相比,优化后的Hive查询效率更高,更适合作为当前舆情分析的存储平台。

  1.1选题背景及意义

  在大数据时代,数据已成为企业最有价值的资产,企业竞争力的核心已逐渐转向提高企业数据的收集和分析能力。尤其是在互联网行业中,面对市场的快速变化,在日益激烈的市场竞争中,掌握数据就意味着抓住机遇,迅速扩大相关业务并扩大市场份额。通过收集与分析用户行为数据,企业可以及时掌握用户需求的变化,根据用户需求对服务和应用进行优化升级,不断提高服务质量并满足不同用户的需求,提高用户满意度,去达到增加用户黏度、减少用户流失的目的。其次,对收集到的各类用户数据进行挖掘,企业能从这些数据中获取到更多有重要价值的信息,进而找出各类用户的行为规律,针对不同类型的用户制定不同策略,为每位用户提供更加个性化的服务,确保用户的满意度,最终提高企业的经济效益。

  当前,中国进入了互联网的新时代,有关政府部门更加重视网络舆论,微博、贴吧等平台相应地成为网民了解和掌握网络舆情的主要渠道,而且关注度日益高涨。据悉,2019年某省级舆情中心共发布各类民意信息产品近700期,获得省领导批准300余项,其中省委,省政府领导批准100余项,有效地促进了一些政策和措施出台。例如,公众报道了一些热门的舆论活动:“城市中学生违反规定”、“县养老院虐待老人”、“沿江城市垃圾地带”等。经过各地舆论信息产品反映,各级党委政府迅速作出决定,问题得到有效解决。因此,对于各级政府来说,舆论分析已成为掌握实时情况,判断现状,做出科学决策,净化网络环境,改善社会氛围的重要途径。但是随着移动互联网应用和服务的广泛应用,其产生的数据量呈指数增长,对这些海量数据进行处理的任务也日益增多。如何高效存储和处理海量数据,从中获取信息并产生商业价值,成为相关企业亟待解决的难题。

  对舆情数据收集、分析、处理,做出预警和决策,实现对网络舆情的有效监控和管理已成为重中之重。然而数据存储都离不开数据库,为此,如何根据业务需求选择合适的数据库产品,如何优化数据库提升查询效率,减少查询所需要的时间,就成为各行各业研究的焦点。

  1.2国内外研究现状

  数据查询性能优化是一个久远却一直保持热度的研究领域,从上世纪80年代初的数据库大规模使用开始,如何优化数据库的查询性能就一直是数据库领域研究的热点。直到现在,都能在各类数据和相关知识管理领域的顶级期刊与国际会议上看到数据库性能优化的研究成果。

  1.2.1国外研究现状

  国外对数据库查询优化的研究起步较早,主要集中在四个方面:

  1.配置参数调优

  在数据库领域,参数调优一直是一个研究问题,同时也是难题[1,2]。参数配置主要面临三个困难:(1)参数名称不标准,在同一个参数上不同的数据库系统具有不同的名称;(2)参数功能不独立,更改一个参数会影响其他参数的配置性能;(3)参数调优的适用范围不通用,一个应用程序中的优化参数通常不适用于另一系统[3]。优化数据库系统参数对于系统性能至关重要。数据库系统的默认配置通常不能令人满意,随着数据库系统的发展,现代数据库系统具有大量的参数[4-6]。面对数据库系统和应用程序规模的增长,良好的参数配置至关重要。在21世纪初期,开始进行参数自动配置调优的研究。几乎所有的数据库供应商都有自己的调优工具[7,8]。由数据库管理员决定这些优化是否正确以及何时部署这些配置。典型的研究工作包括IBM为DB2构建自动组件,例如LEO[9],SASH[10]等。在自动调整数据库系统参数方面已经完成了许多工作。Narayanan等人[11]提出了资源顾问,该方法用于基于细粒度和低开销的数据库性能跟踪,并自动回答“假设”资源问题,同时准确预测在线交易处理,改变工作负载性能,以更好地了解系统性能。Dias等人[12]提供了一种执行性能自动诊断和调整的方法,设计了数据库自动监视程序,自动诊断会影响数据库瓶颈的总吞吐量,并应用于Oracle 10 g[13]。Sullivan等人[14]使用称为影响图的概率推理模型来实现有效的自动化软件调优方法。Tran等人[15]提出了一种基于缓冲区损耗方程的缓冲区优化方法,该方法将可用数据与损耗方程拟合以进行最优计算。Duan等人[16]提出了iTuned,它是一种自动推荐数据库配置参数的工具,并结合自适应采样技术,使用计划实验来查找对设置有更大影响和高性能的参数。

  2.索引结构

  在数据库系统中,有效的数据访问查询与索引结构密不可分。数据库系统中有多种索引结构可以满足不同访问模式的需求[17,18]。B树索引最适合范围请求;对于单个关键字的搜索,哈希索引效果最佳;布隆过滤器适用于确定记录是否存在。作为一种访问模式,索引在数据库系统中起着重要的作用,可以加速对一个或多个属性的特定值的查询[19]。索引是一种数据结构,可以将一个或多个字段的值作为输入,并快速找到其对应的数据项,具有此值的记录索引结构对数据库系统非常重要,因此索引结构优化具有一直是数据库领域研究的重点。传统数据库系统的索引结构是通用数据结构,不对基础数据的分布进行任何假设。实际上,在许多情况下数据的分布是有规律的,Kraska等人[20]将索引结构视为模型;Darshana等人提出了一种自适应索引方法,该方法在后台不断进行动态的小规模增量重组,可避免在重组索引时,因索引不可用而导致数据库性能下降的问题。

  3.查询优化算法

  查询优化算法仍然是优化研究领域中的关键和难点。其中,最难优化的是JOIN[21,22]。因为多个连接会产生不同的连接方式,从而导致巨大的空间开销。当前的查询优化通常引入启发式搜索和随机算法来处理更多关系数据的情况[23,24]。随着数据规模的增加,高性能分布式数据库系统逐渐取代传统的独立系统,因此查询优化将并行查询的优化作为研究重点之一,包括代价模型的评估和计划空间搜索算法的增加。并行查询的代价模型不仅要考虑传统CPU和I/O的成本,还必须考虑资源竞争和划分的成本[25]。并行执行计划会增加系统执行时间和空间,为了减少并行计划的数量,通常使用启发式算法[26]。

  4.查询重用机制

  具有相同结构的SQL语句通常具有相同的优化效果,只需要一次语法分析和优化,甚至只需要执行一次即可。查询重用机制可以缓存这些查询语句,从而避免了多次语法分析和结果优化的过程[27-29]。对查询重用的研究主要集中在执行结果的重用和执行计划的重用。

  1.2.2国内研究现状

  国内数据库系统技术研究起步较晚,国产数据库系统很少,与国外相比,数据查询性能优化还存在一定差距。在国内数据库系统的查询优化方面,主要取决于数据库管理员根据数据库管理系统中一些可调整的资源参数进行动态调整,结合自己的经验和当前机器的负载特性,来实现性能优化的目的[30,31],但是这种方法对数据库开发人员有更高的要求。为此,一些数据库制造商根据大量的仿真实验和实际应用开发总结了一些典型案例数据库参数建议,具有一定的参考价值,这种方法被称为基于案例的调优[32,33]。其中人大金仓的Kingbase ES[34]减少了运行期间CPU,内存和其他资源的消耗,并灵活地调整了系统资源进行优化。东软集团的OpenBASE[35]使用基于统计的查询优化算法,使用统计信息自动选择存储路径,并优化B+树索引,通过限制高度来缩短查询路径。北京航天神舟的OSCAR[36]设计了一个基于I/O和CPU开销的成本估算算法,以解决运行过程中系统开销大的问题。但是,OSCAR不支持查询重写,这在一定程度上影响系统的查询性能。

  迄今为止,有关数据库查询性能优化的研究仍面临许多挑战。国外数据库技术发展非常迅速,国内许多公司使用的数据库更多偏重于应用,而不是专注于产品性能的优化研究。在当前的研究进展中,大多数是针对某一款数据库的性能研究,但是由于数据库产品的层出不穷,如何根据数据特性选择合适的数据库产品变得极为困难。因此,针对数据库系统的优化对比实验就极为重要。

  1.3研究内容

  针对网络舆情数据特点,设计相关SQL查询分析,选取MySQL、MongoDB、Hive三种数据库,进行查询优化的对比实验。

  1.MySQL优化:根据舆情分析特点选取合适的数据存储引擎作为底层存储,并通过SQL过滤条件指定索引策略,最后结合机器资源进行有关存储引擎的参数调优。

  2.MongoDB优化:选取集群模式,并根据索引策略进行查询优化。

  3.Hive优化:首先选取当前流行的计算引擎,结合Hive的列式存储格式,分析查询效率,并根据Hive中索引特点,创建索引表,最后进行查询性能相关的参数优化。

  对比分析三种数据库查询优化实验的结果,找出最适合作为当前舆情分析的存储平台并说明原因。

  1.4论文组织结构

  本文主要围绕MySQL、MongoDB、Hive的查询优化技术进行研究,结构如下:

  第一章绪论。介绍存储系统优化的的选题背景、研究现状和内容。

  第二章相关技术概述。重点介绍了MySQL、MongoDB、Hive三种数据库及所涉及的大数据处理系统,包括HDFS存储系统及MapReduce编程模型。为后续优化设计提供理论基础。

  第三章MySQL优化。主要阐述了MySQL优化实验的环境、数据和优化的方式,主要包括存储引擎优化、索引优化、配置参数优化,并结合舆情数据的特点进行查询。分析结果表明,MySQL通过优化,使大部分SQL的查询性能得到明显提升,但对于Q7却无法在短时间内获取目标结果,得出MySQL不适合当前业务场景的结论。

  第四章MongoDB优化。主要讲述了MongoDB优化的集群环境、SQL语句的设计和索引优化。优化结果表明,MongoDB能快速得到所有SQL的返回结果,并且对于返回指定列的SQL查询,查询时间可以达到毫秒级。

  第五章Hive优化。主要介绍了Hive支持的计算引擎和文件存储格式,接着说明Hive优化实验的集群环境、数据加载和优化的具体操作。通过索引建立和参数调优,结合文件的列式存储格式,得到最优查询效率。最后对三种数据库优化实验进行对比分析,得出Hive更适合当前业务场景的结论。

  第六章结论。本章对面向舆情分析的存储系统优化工作进行总结,并展望下一步的研究方向。

  2相关技术概述

  2.1 MySQL

  MySQL是由瑞典MySQL AB公司开发的关系数据库系统。与SQL Server或Oracle不同,它将数据放置在大型仓库中,这大大提高了灵活性和速度。MySQL架构如图2-1所示:

  图2-1 MySQL架构图

  MySQL的核心功能主要存在于第二层体系结构中,例如查询,分析,优化,缓存以及所有内置函数。大多数跨存储引擎功能也可以在此层实现。它体积小,总成本低,并且是开源代码,更适合业务开发。MySQL是对SQL标准的补充,它增加了一些扩展功能以使其更符合中小型企业系统的需求,但与需要大量数据支持的大型企业相比,MySQL的限制很大。

  MySQL是一个多用户多线程的SQL数据库,也是Client/Server结构的实现。它的主要目标是快速和易于使用,并且提供API接口,例如C,C++和Java,具有多平台支持。

  2.2 MongoDB

  MongoDB是一个基于分布式文件存储的数据库,由C++语言编写,MongoDB有三种集群部署模式,即:主从模式(Master-Slaver)、副本模式(Replica Set)和分片模式(Sharding)。其中Replica Set集群模式架构如图2-2所示:

  图2-2 MongoDB架构图

  MongoDB(Master)代表主节点,Mongodb(Slaver)代表备用节点,Mongodb(Arbiter)代表仲裁节点。Master和Slaver节点存储数据,Arbiter节点不存储数据。客户端同时连接Master和Slaver节点,但不连接Arbiter节点。默认设置下,Master节点提供所有添加,删除和修改服务,而Slaver节点不提供任何服务。但是可以将Slaver节点设置为提供查询服务,这可以减轻对Master节点的压力,客户端执行数据查询时,请求将自动传输到Slaver节点。Arbiter节点是一种特殊的节点,主要功能是确定在Master节点挂断后将哪个Slaver节点提升为主节点。

  MongoDB使用文档作为处理的基本对象单元。与传统的关系数据库相比,MongoDB不基于关系代数理论,具有丰富的查询支持,索引支持和地理查询。相对于传统关系型数据库中的数据库、表格、记录的概念,MongoDB对应于数据库,集合和文档。

  2.3 Hadoop

  说起Hive,不得不提到Hadoop。随着数据量的增加,传统技术在处理海量数据方面达到瓶颈,但Hadoop为代表的大数据处理框架因其高效性越受重视。Hadoop是Apache基金会下的一个开源分布式项目,包括分布式文件系统HDFS用于解决海量数据存储与数据容错问题,MapReduce计算框架用于进行数据计算和分析问题。因其高可靠性和高扩展性的特点,使用计算机集群之间的资源进行分布式计算,并方便从单个服务器扩展到数千个服务器。

  2.3.1 HDFS

  HDFS是集群中数据存储管理的基础,也是Apache Hadoop核心子工程之一,系统架构图如图2-3所示:

  图2-3 HDFS架构图

  HDFS通常采用主从架构,一个NameNode节点和若干个DataNode节点。NameNode主要负责接收客户端请求,管理集群配置信息、数据块映射以及命名空间;DataNode主要负责海量数据存储。存储在HDFS中的数据将被分割为若干个数据块Block,并且每个数据块都将被备份(默认3份)存储在不同DataNode节点上,与传统的文件存储方式不同,如果其中一份出现问题,可以通过备份继续访问。

  2.3.2 MapReduce

  MapReduce是一种分布式计算框架,其核心算法思想是将要解决的问题分为两部分:map和reduce。程序将输入文件分割为Splits,作为算法程序的输入将它们随机分配给某个DataNode节点启动Map任务进行计算,最后以键值对的形式输出;Reduce端将接受已完成的不同Map任务,进行数据聚合并作为最终结果输出,架构图如图2-4所示:

  图2-4 MapReduce框架

  MapReduce包含两个重要进程:作业跟踪器(JobTracker)和任务跟踪器(TaskTracker)。JobTracker进程的主要功能是接受用户任务提交、监视作业节点的运行状况、计划任务执行以及任务进度的管理等;TaskTracker进程的主要作用是执行JobTracker节点分配的作业,并定期主动向JobTracker节点报告其工作状态。但是,伴随着群集规模和作业任务的增加,MapReduce计算框架的缺陷慢慢暴露出来,一方面是JobTracker存在单点故障,集群事务的集中处理点JobTracker只有一个;另一方面是JobTracker节点的资源过度消耗问题,因其同时维护Job状态和Task状态;而TaskTracker节点方面,也容易出现资源浪费和内存溢出的问题。

  为解决上述缺陷,Hadoop2.0改进了MapReduce框架,并把新的框架称作Yarn。基本原理是将原本的JobTracker替换为一个全局ResourceManager(RM)用来进行资源管理并且每个应用程序都有一个ApplicationMaster(AM)用来进行作业调度管理。其中RM进行调度的资源包括CPU、内存、磁盘、网络等,AM在运行Job或Task之前都要主动向RM请求资源分配,提交Task,运行Task,杀死Task,跟踪和监视Job情况等。

  2.4 Hive

  Hive是一套基于Hadoop的数据仓库分析系统,,它提供了丰富的SQL查询方法来分析存储在Hadoop分布式系统中的数据文件。Hive把结构化的数据文件与数据库中表进行映射,提供完整的SQL查询功能并将其转换为MapReduce任务运行,以便不熟悉MapReduce的用户可以使用SQL语言查询,汇总和分析数据。MapReduce开发人员可以使用自己写的mapper和reducer作为插件来支持Hive进行更复杂的数据分析。它与关系型数据库的SQL稍有不同,但是它支持大多数的语句如DDL、DML和聚合函数。

  Hive也是开源的,可免费使用,并且它的构建门槛和成本相对较低,其架构如图2-5所示:

  图2-5 Hive架构图

  Hive的系统架构可分为以下三个部分:

  1.用户接口包括CLI,Client、WUI、JDBC。其中CLI(Hive Shell)最为常用。当使用CLI方式启动Hive时,会同时启动一个Hive副本;若用户使用Client方式启动Hive会连接到Hive Server,需要手动指明Hive Server所在节点,并在Hive Server所在节点上启动Server进程;WUI是用户通过浏览器方式进行Hive访问,不常用;JDBC是Java开发人员经常使用的一种访问方式。

  2.Hive元数据默认存储在derby数据库,由于它只支持单用户的访问,因此开发中常常将其替换为mysql。

  3.HQL语句通过解释器、编译器、优化器处理,生成查询计划存储在HDFS中,并转化为MapReduce任务执行。

  Hive继承了HDFS的高可扩展性、高可用性和安全性,更适合互联网结构化大数据集的统计分析。

  3 MySQL优化

  3.1优化方案

  MySQL应该是最流行的WEB后端数据库,它广泛用于PHP,Ruby,Python,Java和其他Web语言开发项目。即使优化也是程序级别的,例如不编写消耗过多资源的SQL语句。但是除此之外,在整个系统上还有许多可以优化的地方。

  为提高MySQL查询效率,结合MySQL架构特点,选取存储引擎、索引策略、参数设计三方面进行优化,优化模型如图3-1所示:

  图3-1 MySQL优化模型图

  3.1.1存储引擎优化

  存储引擎决定存储机制和数据存储功能,选择适当的存储引擎,可以大幅度提高查询效率。MySQL存储引擎包括InnoDB、Memory、MyISAM、Merge等。性能特点如下:

  1.InnoDB

  InnoDB是MySQL中唯一具有事务控制功能的存储引擎。它支持全文索引和外键并作为系统的默认存储引擎。它的优势在于并发控制能力以及系统崩溃的修复功能,并且能够进行事务处理,安全性高。InnoDB的数据文件就是一个索引文件,与MyISAM相比,其读写效率较低,占用的数据空间较大。

  2.Memory

  Memory将数据存储在内存中,类似于Redis,memcached的思想,支持哈希索引,快速访问。但是其数据安全性非常低,因为数据保存在内存中,断电消失且不能恢复。

  3.MyISAM

  MyISAM存储引擎支持静态类型、动态类型和压缩类型三种存储格式,占用空间小,处理速度快,缺点是无法执行事务处理。当系统为静态类型时,字段长度固定;当系统为动态类型时,长度字段可变;当系统为压缩类型时,需要myisampack工具进行压缩。MyISAM存储引擎以读和插入为主对表进行操作,支持全文索引,且索引数据和表数据分开存储。

  4.Merge

  Merge存储引擎本身不存储数据,可以用作对象,类似于视图,是由一组MyISAM表组成的逻辑结构。

  结合当前应用场景,选择InnoDB与MyISAM存储引擎进行实验,通过查询时间的对比,发现MyISAM更适合以读操作为主,且不需要事务处理的业务情形。为此,选择MyISAM作为MySQL的数据存储引擎。

  3.1.2索引优化

  1.普通索引

  使用表中的普通列构建的索引,没有任何限制。

  2.唯一索引

  唯一索引列的值必须唯一,但允许为空值。如果是组合索引,则列值组合必须唯一。

  3.主键索引

  基于主键创建索引,不允许重复,也不允许空值。

  4.全文索引

  仅用于MyISAM表,对于大数据,生成全文索引非常耗时。生成全文索引时,将为该文本生成单词列表,并且将根据该单词列表进行索引。

  5.组合索引

  也称为联合索引。用多列组合构成的索引,这多个列中的值不允许为空,可以在创建表时指定,也可以修改表结构。为了进一步提高MySQL的效率,可以遵循“最左前缀”原则来建立复合索引。创建复合索引时,应将最常用作约束条件的列放在左侧,依次递减。

  根据SQL语句的设计特点,选取post表的floor和time字段建立索引,通过普通索引和联合索引的创建,找出最适合当前业务场景的索引方式,之后,为了进一步提高查询效率,对author字段建立全文索引。

  3.1.3参数优化

  1.调优参数介绍

  作为数据库性能优化的关键部分,调优参数选择的适当与否将直接决定查询性能。首先遵循从大到小原则,优先选取对系统性能影响较大的参数,与此同时选取性能影响较小的参数,若参数选择不当,将会造成系统抖动,不利于性能优化。有关参数调优的许多文章成果为调整提供了思路,大部分都将问题集中在影响DBMS性能上:内存管理,锁控制,索引建立,缓冲区分配和物理视图设计。DBMS根据数据的存储位置确定其查询计划。本文主要选择MySQL内存缓冲区中的数据缓冲区进行优化。

  2.调优参数的选择

  数据缓冲区是数据写入磁盘之前和从磁盘块读取数据之后用来存储数据的区域,为MySQL的内存区域之一,与设置大小有关。如果设置的太小,则会导致缓冲区中数据块的命中率降低,造成频繁磁盘I/O,大量消耗系统资源;如果设置太大,将导致操作系统自身程序出现内存争抢问题。以下是一些会影响数据缓冲区中查询性能的参数:

  (1)key_buffer_size

  索引缓冲区。所有数据库共享一个存储空间,存储空间最大值为4GB,实际使用时设置为空闲内存的25%。

  (2)join_buffer_size

  全连接缓冲区。主要用作执行笛卡尔积全连接操作的缓冲区空间分配,系统会把参与连接的每个表进行缓冲。

  (3)read_buffer_size

  全表扫描缓冲区。数据库系统会为每张表分配缓冲区缓冲表中数据,用于进行全表扫描操作。

  (4)sort_buffer_size

  排序缓冲区。系统为排序和分组操作分配的缓冲区大小。

  (5)query_cache_size

  重用查询执行结果缓冲区。用于开启MySQL查询重用的功能。若启用查询重用功能,MySQL会将相同查询直接将缓存到该缓冲区中,并将查询结果返回给客户端。该参数默认值为0不开启,需要根据实际使用情况进行调整。

  根据MyISAM存储引擎,本文选取key_buffer_size和query_cache_size作为调优参数,并与调优前的查询效率进行对比,分析其特点。

  3.2优化实验

  3.2.1实验环境

  本章的实验环境由一台服务器组成,其硬件详细配置信息如表3-1所示:

  表3-1服务器配置表

  服务器IP操作系统CPU内存磁盘

  10.10.111.106 CentOS 7 8核48G 200G

  实验环境软件信息如表3-2所示:

  表3-2软件信息表

  软件名称版本号

  MySQL mysql-5.6.31

  3.2.2实验数据

  本文收集了百度贴吧热度排名前二十的贴吧数据,包括帖子的基本信息thread表及其各楼层的详细情况post表,如表3-3所示:

  表3-3实验数据表

  表名thread post

  表含义帖子的基本信息楼层的基本信息

  数据量24w 1000w

  字段详细信息,如表3-4、3-5所示:

  表3-4 thread字段详解

  属性含义

  id作者ID

  title标题名称

  author作者名称

  reply_num回复数量

  good是否为精品帖

  表3-5 post字段详解

  属性含义

  id楼层ID

  floor楼层编号

  author楼层作者

  content楼层内容

  time发布时间

  comment_num楼中楼回复数量

  thread_id楼层的主体帖子ID

  3.2.3对比方法

  结合网络舆情数据特点,设计如下SQL语句,进行查询效率的分析。

  Q1:结构化数据量统计

  描述:根据where条件进行数据量的聚合统计

  统计楼层编号在1-29且发布时间在2004-01-01和2020-01-01之间的帖子数量

  SELECT count(*)

  FROM post

  WHERE floor>0 AND floor<30

  AND time>"2004-01-01"AND time<"2020-01-01";

  Q2:结构化数据查询

  描述:根据等值条件进行数据查询

  查询楼层为6,且在2019-12-31 20:41:00帖子的id,author,content

  SELECT id,author,content,time

  FROM post

  WHERE floor=6

  AND time="2019-12-31 20:41:00";

  Q3:结构化数据查询

  描述:根据where条件进行数据查询

  查询楼层编号在1-29且发布时间在2004-01-01和2020-01-01之间帖子的id,author,floor,time

  SELECT id,author,floor,time

  FROM post

  WHERE floor>0 AND floor<30

  AND time>"2004-01-01"AND time<"2020-01-01";

  Q4:结构化数据查询

  描述:根据where,group by条件进行数据查询统计

  统计楼层编号为1-29且发布时间在2004-01-01和2020-01-01之间每天的帖子数量

  SELECT count(*),date(time)

  FROM post

  WHERE floor>0 AND floor<30

  AND time>"2004-01-01"AND time<"2020-01-01"

  GROUP BY date(time);

  Q5:复杂数据量统计

  描述:根据等值、大于等条件与模糊匹配进行数据量的聚合统计

  统计楼层编号在1-29,发布时间在2004-01-01和2020-01-01之间,author中带鼠的帖子数量

  SELECT count(*)

  FROM post

  WHERE floor>0 AND floor<30

  AND time>"2004-01-01"AND time<"2020-01-01"

  AND author LIKE"%鼠%";

  Q6:复杂数据查询

  描述:根据等值、大于等条件与模糊匹配的条件进行数据查询

  查询楼层编号在1-29,发布时间在2004-01-01和2020-01-01之间,author中带鼠的帖子id,author,floor,time

  SELECT id,author,floor,time

  FROM post

  WHERE floor>0 AND floor<30

  AND time>"2004-01-01"AND time<"2020-01-01"

  AND author LIKE"%鼠%";

  Q7:表连接查询

  描述:根据join、where等条件进行数据查询

  查询楼层编号在1-29且发布时间在2004-01-01和2020-01-01之间帖子的title,author,content

  SELECT t1.title,t2.author,t2.content

  FROM thread t1

  JOIN post t2 ON t1.id=t2.thread_id

  WHERE t2.floor>0 AND t2.floor<30

  AND t2.time>"2004-01-01"AND t2.time<"2020-01-01";

  3.3优化结果及分析

  3.3.1存储引擎对比

  根据实验数据与SQL语句特点,选取InnoDB与MyISAM存储引擎进行实验。首先查看MySQL的默认存储引擎,进行查询分析,接着将存储引擎改为MyISAM,进行对比实验。实验结果如图3-2所示:

  图3-2存储引擎优化图

  MyISAM下Q1-Q6的查询效率比InnoDB下的查询效率提升1倍左右,而Q7在MyISAM和InnoDB下的查询时间都在2小时以上。实验结果表明:在不需要事务支持,以读为主的应用场景中,MyISAM具有更高的查询效率,性能更高。而InnoDB是事务安全型的,系统会分配一定资源去维护事务的安全性,造成查询性能相对较低。

  3.3.2索引对比

  为了进一步提高MySQL的查询效率,结合SQL语句where条件特点,选取post表的floor和time字段建立索引,为了比较普通索引与联合索引的区别,首先对floor和time字段分别创建普通索引,进行查询分析,之后删除原索引创建组合索引,进行对比实验。实验结果如图3-3所示:

  图3-3索引优化图

  通过图3-3发现,在MyISAM存储引擎下组合索引性能更高,尤其对点查询和带count函数的查询,查询效率提升4到6倍,但对于Q7来说没有明显提高。实验结果表明:当where后跟不止一个筛选条件时,组合索引效率要高于普通单个索引,但需要注意的是,MySQL组合索引遵循最左前缀匹配原则,首先根据联合索引中最左边的、也就是第一个字段进行排序,在第一个字段排序的基础上,再对联合索引中后面的第二个字段进行排序,以此类推。为此,在创建组合索引时,需要特别注意。

  之后,为了进一步提高Q5、Q6的查询效率,对author字段建立全文索引。实验结果如表3-6所示:

  表3-6索引对比表

  查询语句Q5 Q6

  索引前4.15s 4.18s

  索引后3.97s 3.78s

  通过表3-6可以看出,FULLTEXT INDEX的建立,会优化含有like模糊查询的查询时间,为毫秒级的优化,但是仍然没有解决Q7的查询耗时问题。为此,深入MySQL的配置文件my.cnf,进行参数优化。

  3.3.3参数对比

  根据MyISAM数据存储引擎,本文选取key_buffer_size和query_cache_size作为调优参数。首先根据实验机器内存大小设置key_buffer_size为471859200(450M),语法:SET GLOBAL key_buffer_size=471859200,之后把post中的所有的索引加载进缓存load index into cache post。实验结果如图3-4所示:

  图3-4参数优化图

  通过图3-4发现,调整key_buffer_size大小,可以得到更好处理的索引。它决定索引处理的速度,尤其是索引读的速度。接着,调整query_cache_size与query_cache_type的大小,query_cache_size用于缓存结果集的内存大小,query_cache_type用于设置是否使用Query Cache,并修改配置文件my.cnf。

  发现除Q3、Q7外,其余SQL查询都能达到0s,Q3查询效率却大幅下降,为15s,依然得不到Q7的查询结果。实验结果表明:query_cache_size主要用来缓存MySQL中SQL语句执行的结果集,对于Q1-Q2、Q4-Q6,MySQL会直接根据哈希算法将接受到查询语句select进行字符串hash,然后到Query Cache中查找结果集是否已被缓存。上述过程表明,如果查询语句已经被缓存,则select查询请求就会直接得到数据结果,不会进行后面所有的步骤(包括SQL语句的解析、编译、优化等),极大的提升性能。而Q3的结果集达到100w,不会被Cache,但MySQL预先不知道ResultSet的长度,所以只能等到ResultSet在Cache添加到临界值query_cache_limit之后才会简单的把这个Cache丢弃,这个过程就会造成大量的时间消耗。

  由上述实验可知,MySQL通过存储引擎、索引、参数优化后,Q1-Q6的查询性能明显提升,但Q7查询却始终无法获取结果集。因此,当数据量在千万级别,查询分析涉及表连接操作时,MySQL就难以满足当前需求,不适合作为底层存储系统。

  4 MongoDB优化

  4.1优化方案

  MongoDB是一个高性能、高可用、可自动伸缩的开源文档型数据库。MongoDB数据库将文档存储在集合中。集合中的文档一般来说具有不同的架构,也使得MongoDB比传统的关系型数据库系统更为灵活。MongoDB通常通过explain来诊断一些执行缓慢的语句,MongoDB的优化更多地反映在SQL语句的设计和集群的构建中。

  为提高MongoDB中舆情分析效率,结合MongoDB集群架构特点,选取Replica Set集群模式,并结合索引策略对MongoDB进行优化,优化模型如图4-1所示:

  图4-1 MongoDB优化模型图

  4.1.1集群模式

  1.Replica Set副本集:

  简而言之,集群包含多个数据副本,以确保当主节点挂断时,备用节点可以继续提供数据服务。提供的前提是数据需要与主节点一致。

  2.Sharding分片:

  Sharding和Replica Set相似,都需要仲裁节点,但Sharding还需要配置节点和路由节点。就三种集群构建方法而有,它是最复杂的。

  3.Master-Slaver主从:

  最简答的集群构建,但确切地说,不能将其视为集群,只能视为主从。

  为此,结合集群搭建复杂程度和实验环境要求,选取Replica Set作为MongoDB集群模式,进一步优化查询效率。

  4.1.2索引优化

  1.单字段索引

  最简单和最常用的索引类型,通常MongoDB会自动为文档插入'_id'字段,并且已经按升序索引,如果插入的文档包含'_id'字段,MongoDB就不会自动创建'_id'字段,但是需要保证唯一性以唯一地标识文档。

  2.复合索引

  MongoDB支持用户在多个字段上定义索引,即复合索引。复合索引中字段的顺序很重要。对于复合索引和排序操作,索引键的排序顺序可以确定索引是否可以支持排序操作。

  3.多key索引

  主要用于数据类型是数组类型。MongoDB使用多键索引来索引存储在数组中的内容,从而为数组的每个元素创建一个单独的索引条目。这些多键索引允许查询通过匹配数组中的元素来获取包含数组的文档。如果索引字段包含数组值,则MongoDB将自动确定是否有必要创建多键索引,而无需显式指定多键类型。

  根据数据表字段类型特点,建立复合索引,对比索引前后查询效率,分析实验结果。

  4.2优化实验

  4.2.1实验环境

  本章中实验环境是由三台服务器组成Replica Set集群,硬件配置如表4-1所示:其中100号机器为主节点,106号机器为从节点,111号机器为仲裁节点。

  表4-1服务器配置表

  服务器IP操作系统CPU内存磁盘用途

  10.10.111.100 CentOS 7 8核48G 200G Master

  10.10.111.106 CentOS 7 8核48G 200G Slaver

  10.10.111.111 CentOS 7 8核48G 200G Arbiter

  实验环境软件信息如表4-2所示:

  表4-2软件信息表

  软件名称版本号

  MongoDB mongodb-3.4.18

  4.2.2对比方法

  实验数据采用3.3.2中的贴吧数据,将post表中time字段数据类型转为Date。由于MongoDB的时间类型为格林尼治时间,中国是+8时区,也就是时差相差8,结合MongoDB语法,将Q1-Q7改写如下:

  Q1:结构化数据量统计

  db.getCollection('post').find({$and:[{"floor":{"$gt":0,"$lt":30}},{"time":{"$gt":ISODate("2003-12-31T16:00:00Z"),"$lt":ISODate("2019-12-31T16:00:00Z")}}]}).count();

  Q2:结构化数据查询

  db.post.find({"floor":6,"time":ISODate("2019-12-31T12:41:00Z")},{"id":1,"author":1,"content":1,"_id":0});

  Q3:结构化数据查询

  db.getCollection('post').find({$and:[{"floor":{"$gt":0,"$lt":30}},{"time":{"$gt":ISODate("2003-12-31T16:00:00Z"),"$lt":ISODate("2019-12-31T16:00:00Z")}}]},{"id":1,"author":1,"floor":1,"time":1,"_id":0});

  Q4:结构化数据查询

  db.getCollection('post').aggregate([{$match:{$and:[{"floor":{"$gt":0,"$lt":30}},{"time":{"$gt":ISODate("2003-12-31T16:00:00Z"),"$lt":ISODate("2019-12-31T16:00:00Z")}}]}},{$project:{day:{$substr:["$time",0,10]}}},{$group:{_id:"$day",number:{$sum:1}}},{$sort:{_id:-1}}]);

  Q5:复杂数据量统计

  db.getCollection('post').find({$and:[{'author':/鼠/},{"floor":{"$gt":0,"$lt":30}},{"time":{"$gt":ISODate("2003-12-31T16:00:00Z"),"$lt":ISODate("2019-12-31T16:00:00Z")}}]}).count();

  Q6:复杂数据查询

  db.getCollection('post').find({$and:[{'author':/鼠/},{"floor":{"$gt":0,"$lt":30}},{"time":{"$gt":ISODate("2003-12-31T16:00:00Z"),"$lt":ISODate("2019-12-31T16:00:00Z")}}]},{"id":1,"author":1,"floor":1,"time":1,"_id":0});

  Q7:表连接查询

  db.post.aggregate([{$match:{$and:[{"floor":{"$gt":0,"$lt":30}},{"time":{"$gt":ISODate("2003-12-31T16:00:00Z"),"$lt":ISODate("2019-12-31T16:00:00Z")}}]}},{$lookup:{from:"thread",localField:"thread_id",foreignField:"id",as:"info"}},{$unwind:"$info"},{$project:{"_id":0,"author":1,"content":1,"info.title":1}}]);

  4.3优化结果及分析

  结合MongoDB索引创建原则,选取post表的floor和time字段建立联合索引。语法如下:

  db.post.ensureIndex({"floor":1,"time":1});实验结果如表4-3所示:

  表4-3索引对比表

  查询语句Q1 Q2 Q3 Q4 Q5 Q6 Q7

  索引前7.87s 6.76s 0s 9.52s 8.27s 2.46s 11.18s

  索引后3.52s 0s 0s 5.54s 3.89s 0.19s 10.86s

  通过表4-3可以看出,MongoDB中创建索引,对于返回指定列的SQL查询,所需时间可以优化到毫秒级,对于其余SQL查询,性能也有明显提高。与MySQL优化相比,MongoDB也能在短时间内得到带有关联查询Q7的结果集,并且整体查询耗时也有显著提高,但在带有count的聚合操作时,MongoDB的查询性能明显弱于MySQL。进一步分析发现,MongoDB会将索引读入内存中,而MySQL的索引存放在磁盘中,因此保证了高速。但MySQL的MyISAM内置了一个计数器,count(*)时它直接从计数器中读取,因此在涉及count的操作中,MySQL性能更高。

  5 Hive优化

  5.1优化方案

  Hive的本质是将HQL转化为MapReduce程序,因此,在以前的研究工作中,大多数是对Hadoop进行调优,从MapReduce的操作角度去优化性能。对于Hive系统的内部调优,也是从配置角度优化,根据Hive针对不同查询预设的优化方法,调整配置进行控制。但是,由于MapReduce计算框架的局限性,优化效果并不理想,为此,从底层出发优化计算性能。

  为提高Hive查询效率,结合Hive架构特点,选取计算引擎、存储格式、索引策略、参数设置四个方面进行优化,优化模型如图5-1所示:

  图5-1 Hive优化模型图

  5.1.1计算引擎优化

  Hive支持三种计算引擎,分别是MapReduce、Tez、Spark,它们的性能特点如下:

  1.MapReduce

  MapReduce是三者中最早,最著名的分布式计算框架。它最初是由Google Lab开发的,在世界各地都有用户。它主要适用于大型集群任务,是一个基于磁盘的离线计算框架,将算法抽象为两个阶段:Map和Reduce进行处理。由于是批量执行,因此时效性很低。

  2.Tez

  Tez是支持DAG作业的开源计算框架,它直接从MapReduce框架派生并在Hadoop Yarn上运行。核心思想是进一步将Map和Reduce两个操作细分,并将分解后的元操作灵活地组合以生成新的操作,由一些控制程序将这些操作组装而成,形成一个大型DAG作业,从而减少Map/Reduce之间的文件存储。同时,子流程的合理组合也可以减少任务的运行时间。

  3.Spark

  Spark是基于MapReduce算法实现的分布式计算,具有Hadoop MapReduce的优势。但是与MapReduce不同,Job中间输出和结果可以存储在内存中,是基于内存的计算框架。它将数据尽可能多地存储在内存中,以提高迭代应用程序和交互式应用程序的计算效率,从而不再需要读写HDFS。

  5.1.2存储格式优化

  Hive支持的存储数据的格式主要有:TEXTFILE、RCFILE、ORC、PARQUET,它们的性能特点如下:

  1.TEXTFILE格式

  Hive中默认存储格式,磁盘空间开销大,数据不进行压缩且解析慢。使用这种方式,Hive不会拆分数据,从而无法对数据进行并行操作。

  2.RCFILE格式

  RCFile:RCFile是一种行列式存储格式,即将文件水平切分成相同大小的块(Row Group),默认大小为4MB,然后每个块内按列存储。列式存储的优点在于每个列的类型相同,可以使用高效的编码方法对其进行编码,以减少磁盘空间占用。RCFile文件由一系列Row Group组成,每个Row Group由Header和数据组成,Header是数据的元信息,主要保存每个列的存储偏移量与列中每个值的偏移量,数据为按列存储的各列数据。

  3.ORC格式

  ORC(Optimized Row Columnar)是Hive 0.11版本中引入的新存储格式。每个Orc文件由一个或多个stripe组成,每个stripe大小为250MB,Stripe实际相当于RowGroup概念,但其大小由4MB增加到250MB,来提高顺序读取的吞吐量。每个Stripe中包含三个部分,即Index Data,Row Data,Stripe Footer:

  (1)Index Data:轻量级索引。默认为每1W行做一次索引。此处创建的索引应仅记录数据行的每个字段在Row Data中的偏移量。

  (2)Row Data:存储具体数据。先获取部分行,然后再按列存储这些行。每列都被编码并分成多个Stream来存储。

  (3)Stripe Footer:存储Stream的类型、长度等信息。每个文件都有一个File Footer,用于存储每个Stripe的行数,每个Column的数据类型信息等;每个文件的尾部是一个PostScript,它记录了整个文件的压缩类型以及FileFooter的长度信息等。读取文件时,它先尝试读取文件末尾的PostScript,从内部到长度进行解析。再读FileFooter,从内部解析每个Stripe信息,然后读取每个Stripe,即从后往前读。

  4.PARQUET格式

  Parquet是Twitter和Cloudera之间合作开发的面向分析型业务的列式存储格式。Parquet文件无法直接读取并且为自解析的,因为它以二进制方式进行存储且文件中包括文件的数据和元数据。通常情况下,存储Parquet数据时,会根据Block大小设置行组的大小。由于每个Mapper任务的最小数据处理单位通常是一个Block,因此每个行组都可以由一个Mapper任务处理,增加任务执行并行度。

  一个文件中可以存储多个行组,除了文件中每个行组的元数据外,页面的元数据还存储在每个页面的开头。在Parquet中,有三种类型的页:数据页、字典页和索引页。数据页用于存储当前行组中列的值,字典页存储列值的编码字典,每个列块中最多包含一个字典页。

  5.1.3索引优化

  与传统数据库相比,Hive仅提供有限的索引功能,并通过在某些字段上建立索引来加速某些操作。Compact Index压缩列中相同值的字段,以减少存储并加快访问时间。应该注意的是,当Hive创建压缩索引时,索引数据也存储在Hive表中。

  5.1.4参数优化

  1.矢量化查询执行

  Hive的默认查询执行引擎一次只处理一行,而矢量化查询执行是一项Hive功能,其目的是批量读取1024行数据并将其一次应用于整个记录的应用操作。

  2.查询执行计划

  Hive驱动程序将SQL语句转换为目标执行引擎的执行计划,步骤是:解析器解析SQL语句生成抽象语法树AST,描述诸如SELECT、JOIN之类的逻辑操作,然后是规划器从Hive Metastore中检索表的元数据,包括HDFS文件位置、存储格式,最后是查询优化器使用先前的AST和检索表的元数据,生成物理运算树,即所谓的执行计划,描述为检索数据所需的所有物理操作,例如循环连接、排序合并连接。

  查询优化器生成的执行计划最终确定将在Hadoop集群上执行的任务。基于代价的优化(CBO)引擎使用Hive Metastore统计信息生成查询计划。

  5.2优化实验

  5.2.1实验环境

  本章中实验环境由三台服务器组成,硬件配置如表5-1所示:

  表5-1服务器配置表

  服务器IP操作系统CPU内存磁盘

  10.10.111.100 CentOS 7 8核48G 200G

  10.10.111.106 CentOS 7 8核48G 200G

  10.10.111.111 CentOS 7 8核48G 200G

  实验环境软件信息如表5-2所示:

  表5-2软件信息表

  软件名称版本号

  Hadoop hadoop-2.7.6

  Hive hive-2.3.3

  JDK jdk-1.8.0

  TEZ tez-0.9.1

  Spark spark-2.0.0

  Scala scala-2.11.8

  Sqoop sqoop-1.4.7

  Maven maven-3.5.3

  MySQL mysql-5.6.31

  ZooKeeper zookeeper-3.4.12

  集群环境部署如表5-3所示:其中100号服务器为NameNode节点,106、111号服务器为DataNode节点,Hive部署在服务器100上。

  表5-3集群部署表

  IP地址10.10.111.100 10.10.111.106 10.10.111.111

  HDFS NameNode DataNode DataNode

  YARN ResourceManager NodeManager NodeManager

  ZooKeeper QuorumPeerMain QuorumPeerMain QuorumPeerMain

  5.2.2对比方法

  使用3.3.2中的舆情数据,并根据Hive保留关键字特点,将post表的floor字段改为floors。结合Sqoop,完成数据拉取。SQL查询语句同3.3.3,根据存储格式不同,建立不同的数据表,语法如下:

  create table if not exists tieba.新建表名(

  id bigint,

  floors int,

  author string,

  content string,

  time string,

  comment_num int,

  thread_id bigint

  )

  STORED AS文件类型;

  insert overwrite table新建表名select*from已有表名;

  5.3优化结果及分析

  5.3.1计算引擎对比

  通过set hive.execution.engine进行Hive计算引擎的切换。实验结果如图5-2所示:

  图5-2计算引擎对比图

  对比Hive支持的三种计算引擎,可以看出:Hive on Tez和Hive on Spark的计算效率比Hive默认的MapReduce计算引擎提高30%-50%,Hive on Tez与Hive on Spark相比,总体上Hive on Spark的执行性能更高。实验结果表明:Hive on MR虽然可以实现所有查询,但性能低下。Hive on Tez是Yarn之上支持DAG作业的计算框架,通过MapReduce任务的拆分重组,将多个子过程组合成一个较大的DAG任务,从而大幅提升MapReduce作业的性能。但相对基于内存计算的Hive on Spark来说,其查询效率略有不足。

  5.3.2存储格式对比

  为进一步提高Hive的查询效率,结合列式文件存储,充分发挥Hive优势。实验结果如图5-3所示:

  图5-3存储格式对比图

  对比Hive支持的文件存储格式,可以看出:总体上,ORC File的查询性能更高,尤其在执行某些查询指定列的SQL中,查询时间达到毫秒级。实验结果表明:与行式存储TextFile相比,列式存储可以充分利用数据和SQL查询特点,查询性能显著提高。三种列式存储文件格式相比,RCFile的默认行组大小为4M,所以IO开销更大,而ORC File在一定程度上扩展了RCFile,在其基础上引申出Stripe和Footer等。每个stripe默认的大小是250MB,相对于RCFile默认的行组大小更高效。Parquet文件格式,它和ORC文件格式类似,也是将每列的所有数据连续存储在磁盘上,可以跳过某些不需要的列,避免查询出这些不必要的结果。不过相对于ORC文件格式,还是ORC文件格式的优化效果更好。但是对于Q7来说,ORC File的查询效率比较低。为了进一步提高ORC File的查询效率,引入Compact Index。

  5.3.3索引对比

  结合SQL语句where过滤条件特点,选取post表的floor和time字段建立联合索引Compact Index。因为原数据表中已有数据,执行rebuild操作,并进一步设置索引在查询时生效。实验结果如表5-4所示:

  表5-4索引对比表

  查询语句Q1 Q2 Q3 Q4 Q5 Q6 Q7

  索引前6.22s 0.15s 0.13s 7.23s 9.26s 0.13s 92.55s

  索引后5.26s 0.13s 0.14s 6.40s 7.42s 0.14s 15.537s

  通过表中时间对比,可以清楚看出Q7查询效率有了明显提高,Q1-Q6查询时间也有不同程度的缩小。实验结果表明:Compact Index通过过滤无关的block块,来提升查询效率。Compact Index的实现原理不是传统数据库中的B树,而是类似一个查找表。当你创建索引时,就会产生一个索引文件表,表中包含3个字段,分别为索引列的枚举值,每个值对应的数据文件位置,以及该值所在文件中的偏移量。索引表以全表方式进行读取,通过这种方式,可以减少查询时需要读取的block块数量,减少Map任务和系统资源的消耗。

  5.3.4参数对比

  为了进一步优化Hive,结合ORC数据存储格式,选择vectorized.execution与CBO作为优化参数。首先设置矢量化查询执行,语法如下:

  set hive.vectorized.execution.enabled=true;

  set hive.vectorized.execution.reduce.enabled=true;

  实验结果如表5-5所示:

  表5-5参数(Vectorized query)优化表

  查询语句Q1 Q2 Q3 Q4 Q5 Q6 Q7

  调优前5.26s 0.13s 0.14s 6.40s 7.42s 0.14s 15.537s

  调优后2.34s 0.14s 0.14s 3.35s 3.26s 0.14s 10.35s

  实验结果表明:通过矢量查询(Vectorized query)的设置,将原来每次一行一行的数据处理方式转变成每次将1024行数据组成一个batch的批处理,能够显著提高执行速度,进而提升查询效率。

  接着,调整以下属性启用查询执行计划CBO,语法如下:

  set hive.cbo.enable=true;

  set hive.compute.query.using.stats=true;

  set hive.stats.fetch.column.stats=true;

  set hive.stats.fetch.partition.stats=true;

  实验结果如表5-6所示:

  表5-6参数(CBO)优化表

  查询语句Q1 Q2 Q3 Q4 Q5 Q6 Q7

  调优前2.34s 0.14s 0.14s 3.35s 3.26s 0.14s 10.35s

  调优后2.27s 0.14s 0.14s 2.28s 2.28s 0.13s 9.46s

  实验结果表明:经过以上设置,查询使用基于代价的优化引擎,利用Hive Metastore的统计数据来产生的查询计划,减少从磁盘读取和处理的数据量,提升查询效率。

  5.4三种数据库优化实验对比

  对比结果如表5-7所示:

  表5-7数据库优化结果对比表

  查询语句Q1 Q2 Q3 Q4 Q5 Q6 Q7

  MySQL 0.93s 0s 4.57s 1.41s 3.85s 3.78s 2h以上

  MongoDB 3.52s 0s 0s 5.54s 3.89s 0.19s 10.86s

  Hive 2.27s 0.14s 0.14s 2.28s 2.28s 0.13s 9.46s

  结论:针对网络舆情数据和SQL分析查询的特点,选取以上三种数据库进行测试,根据它们的特点结合存储引擎、计算引擎、索引策略、配置参数等方式进行不同程度的优化。实验结果表明:Hive最适合作为当前舆情数据的存储平台。从优化后的查询效率可以看出,对于返回指定列的SQL查询(Q3、Q6),Hive的列式存储可以同MongoDB一样,将查询时间优化到毫秒级;对于带有count的聚合查询(Q1、Q4),优化性能明显高于MongoDB,接近于MySQL;对于关联查询(Q7),不存在MySQL中长时间无法得到结果集的问题;其余SQL(Q2、Q5)的查询效率,也为三者之中最优。分析发现,行式存储下一张表的数据都是放在一起的,但列式存储下都被分开保存,查询时只有涉及到的列会被读取,投影更高效。因此,三者相比,优化后的Hive查询效率更高,更适合作为当前舆情分析的存储平台。