赵广陆_1.docx

赵广陆s:/1Explain1.1功能HiveQL是一种类SQL的语言，从编程语言标准来讲是一种声明式语言，用户会根据查询需求提交声明式的HQL查询，而Hive会根据底层计算引擎将其转化成Mapreduce/Tez/Spark的job。大多数情况下，用户不需要解析Hive内部是怎样工作的，不过，当用户对于Hive具有越来越多的经历后，尤其是需要在做性能优化的场景下，就要学习下Hive背后的理论知识和底层的一些实现细节，会让用户更加高效地使用Hive。explain命令就可以帮助用户解析一条HQL语句在底层的实现经过explain会解析HQL语句，将整个HQL语句的实现步骤、依赖关系、实现经过都会进展解析返回，可以帮助更好的解析一条HQL语句在底层是怎样实现数据的查询及处理的经过，这样可以辅助用户对Hive进展优化。官网：s:/cwiki.apache.org/confluence/display/Hive/LanguageManual+Explain1.2语法常用语法命令如下：EXPLAINFORMATTED|EXTENDED|DEPENDENCY|AUTHORIZATION|queryFORMATTED：对执行方案进展格式化，返回JSON格式的执行方案EXTENDED：提供一些额外的信息，比方文件的途径信息DEPENDENCY：以JSON格式返回查询所依赖的表以及分区的列表AUTHORIZATION：列出需要被受权的条目，包括输入与输出1.3组成解析后的执行方案一般由三个局部构成，分别是：TheAbstractSyntaxTreeforthequery抽象语法树：Hive使用Antlr解析生成器，可以自动地将HQL生成为抽象语法树ThedependenciesbetweenthedifferentstagesoftheplanStage依赖关系：会列出运行查询所有的依赖和stage的数量ThedescriptionofeachofthestagesStage内容：包含了非常重要的信息，比方运行时的operator以及sortorders等详细的信息4.1.4例如1：过滤explainselectcount(*)ascntfromtb_empwheredeptno=10;组成解释1.5例如2：分组排序explainselectdeptno,count(*)ascntfromtb_empwheresalary2000groupbydeptnoorderbycntdesc;2MapReduce属性优化2.1本地形式使用Hive的经过中，有一些数据量不大的表也会转换为MapReduce处理，提交到集群时，需要申请资源，等待资源分配，启动JVM进程，再运行Task，一系列的经过比拟繁琐，本身数据量并不大，提交到YARN运行返回会导致性能较差的问题。Hive为解析决这个问题，延用了MapReduce中的设计，提供本地计算形式，允许程序不提交给YARN，直接在本地运行，以便于进步小数据量程序的性能。配置开启本地形式sethive.exec.mode.local.auto=true;限制条件Hive为了防止大数据量的计算也使用本地形式导致性能差的问题，所以对本地形式做了以下限制，假如以下任意一个条件不知足，那么即使开启了本地形式，将照旧会提交给YARN集群运行。处理的数据量不超过128MMapTask的个数不超过4个ReduceTask的个数不超过1个2.2JVM重用JVM正常指代一个Java进程，Hadoop默认使用派生的JVM来执行map-reducer，假如一个MapReduce程序中有100个Map，10个Reduce，Hadoop默认会为每个Task启动一个JVM来运行，那么就会启动100个JVM来运行MapTask，在JVM启动时内存开销大，尤其是Job大数据量情况，假如单个Task数据量比拟小，也会申请JVM资源，这就导致了资源紧张及浪费的情况。为解析决上述问题，MapReduce中提供了JVM重用机制来解决，JVM重用可以使得JVM实例在同一个job中重新使用N次，当一个Task运行完毕以后，JVM不会进展释放，而是继续供下一个Task运行，直到运行了N个Task以后，就会释放，N的值可以在Hadoop的mapred-site.xml文件中进展配置，通常在10-20之间。配置Hadoop3之前的配置，在mapred-site.xml中添加以下参数Hadoop3中已不再支持该选项mapreduce.job.jvm.numtasks=102.3并行执行Hive在实现HQL计算运行时，会解析为多个Stage，有时候Stage彼此之间有依赖关系，只能挨个执行，但是在一些别的场景下，很多的Stage之间是没有依赖关系的，例如Union语句，Join语句等等，这些Stage没有依赖关系，但是Hive照旧默认挨个执行每个Stage，这样会导致性能非常差，我们可以通过修改参数，开启并行执行，当多个Stage之间没有依赖关系时，允许多个Stage并行执行，进步性能。配置开启Stage并行化，默认为falseSEThive.exec.parallel=true;指定并行化线程数，默认为8.SEThive.exec.parallel.thread.number=16;注意：线程数越多，程序运行速度越快，但同样更消耗CPU资源3Join优化3.1Hive中的Join方案表的Join是数据分析处理经过中必不可少的操作，Hive同样支持Join的语法，HiveJoin的底层还是通过MapReduce来实现的，Hive实现Join时，为了进步MapReduce的性能，提供了多种Join方案来实现，例如合适小表Join大表的MapJoin，大表Join大表的ReduceJoin，和大表Join的优化方案BucketJoin等。3.2MapJoin应用场景合适于小表join大表或小表Join小表原理将小的那份数据给每个MapTask的内存都放一份完好的数据，大的数据每个局部都可以与小数据的完好数据进展join底层不需要经过shuffle，需要占用内存空间存放小的数据文件使用尽量使用MapJoin来实现Join经过Hive中默认自动开启了MapJoin默认已经开启了MapJoinhive.auto.convert.join=trueHive中判断哪张表是小表及限制LEFTOUTERJOIN的左表必须是大表RIGHTOUTERJOIN的右表必须是大表INNERJOIN左表或者右表均可以作为大表FULLOUTERJOIN不能使用MAPJOINMAPJOIN支持小表为子查询使用MAPJOIN时需要引用小表或者是子查询时，需要引用别名在MAPJOIN中，可以使用不等值连接或使用OR连接多个条件在MAPJOIN中最多支持指定6张小表，否那么报语法错误Hive中小表的大小限制2.0版本之前的控制属性hive.mapjoin.smalltable.filesize=25M2.0版本开场由以下参数控制hive.auto.convert.join.noconditionaltask.size=5120000003.3ReduceJoin应用场景合适于大表Join大表原理将两张表的数据在shuffle阶段利用shuffle的分组来将数据按照关联字段进展合并必须经过shuffle，利用Shuffle经过中的分组来实现关联使用Hive会自动判断是否知足MapJoin，假如不知足MapJoin，那么自动执行ReduceJoin3.4BucketJoin应用场景合适于大表Join大表原理将两张表按照一样的规那么将数据划分，根据对应的规那么的数据进展join，减少了比拟次数，进步了性能使用BucketJoin语法：clusteredbycolName参数开启分桶joinsethive.optimize.bucketmapjoin=true;要求分桶字段=Join字段，桶的个数相等或成倍数SortMergeBucketJoinSMB：基于有序的数据Join语法：clusteredbycolNamesortedby(colName)参数开启分桶SMBjoinsethive.optimize.bucketmapjoin=true;sethive.auto.convert.sortmerge.join=true;sethive.optimize.bucketmapjoin.sortedmerge=true;sethive.auto.convert.sortmerge.join.noconditionaltask=true;要求分桶字段=Join字段=排序字段，桶的个数相等或成倍数4优化器4.1关联优化在使用Hive的经过中经常会遇到一些特殊的问题，例如当一个程序中假如有一些操作彼此之间有关联性，是可以放在一个MapReduce中实现的，但是Hive会不智能的选择，Hive会使用两个MapReduce来完成这两个操作。例如：当我们执行以下SQL语句：selectfromtablegroupbyidorderbyiddesc;该SQL语句转换为MapReduce时，我们可以有两种方案来实现：方案一第一个MapReduce做groupby，经过shuffle阶段对id做分组第二个MapReduce对第一个MapReduce的结果做orderby，经过shuffle阶段对id进展排序方案二因为都是对id处理，可以使用一个MapReduce的shuffle既可以做分组可以以排序在这种场景下，Hive会默认选择用第一种方案来实现，这样会导致性能相对较差，我们可以在Hive中开启关联优化，对有关联关系的操作进展解析时，可以尽量放在同一个MapReduce中实现。配置sethive.optimize.correlation=true;4.2CBO优化器引擎在使用MySQL或Hive等工具时，我们经常会遇到一个问题，默认的优化器在底层解析一些聚合统计类的处理的时候，底层解析的方案有时候不是最正确的方案。例如：当前有一张表【共1000条数据】，id构建了索引，id=100值有900条，我们如今的需求是查询所有id=100的数据，所以SQL语句为：select*fromtablewhereid=100;由于id这一列构建了索引，索引默认的优化器引擎RBO，会选择先从索引中查询id=100的值所在的位置，再根据索引记录位置去读取对应的数据，但是这并不是最正确的执行方案。有id=100的值有900条，占了总数据的90%，这时候是没有必要检索索引以后再检索数据的，可以直接检索数据返回，这样的效率会更高，更节省资源，这种方式就是CBO优化器引擎会选择的方案。使用Hive时，Hive中也支持RBO与CBO这两种引擎，默认使用的是RBO优化器引擎。RBOrulebasicoptimise：基于规那么的优化器根据设定好的规那么来对程序进展优化CBOcostbasicoptimise：基于代价的优化器根据不同场景所需要付出的代价来适宜选择优化的方案对数据的分布的信息【数值出现的次数，条数，分布】来综合判断用哪种处理的方案是最正确方案很明显CBO引擎更加智能，所以在使用Hive时，我们可以配置底层的优化器引擎为CBO引擎。配置sethive.cbo.enable=true;sethivepute.query.using.stats=true;sethive.stats.fetch.column.stats=true;sethive.stats.fetch.partition.stats=true;要求要想使用CBO引擎，必须构建数据的元数据【表行数、列的信息、分区的信息】提早获取这些信息，CBO才能基于代价选择适宜的处理方案所以CBO引擎一般搭配analyze分析优化器一起使用4.3Analyze分析优化器功能用于提早运行一个MapReduce程序将表或分区的信息构建一些元数据【表的信息、分区信息、列的信息】，搭配CBO引擎一起使用语法构建分区信息元数据ANALYZETABLEtablenamePARTITION(partcol1=val1,partcol2=val2,)COMPUTESTATISTICSnoscan;构建列的元数据ANALYZETABLEtablenamePARTITION(partcol1=val1,partcol2=val2,)COMPUTESTATISTICSFORCOLUMNS(columnsname1,columnsname2)noscan;查看元数据DESCFORMATTEDtablenamecolumnname;举例构建表中分区数据的元数据信息ANALYZETABLEtb_login_partPARTITION(logindate)COMPUTESTATISTICS;构建表中列的数据的元数据信息ANALYZETABLEtb_login_partCOMPUTESTATISTICSFORCOLUMNSuserid;查看构建的列的元数据descformattedtb_login_partuserid;5谓词下推PPD5.1根本思想谓词下推PredicatePushdownPPD的思想简单点讲就是在不影响最终结果的情况下，尽量将过滤条件提早执行。谓词下推后，过滤条件在map端执行，减少了map端的输出，降低了数据在集群上传输的量，降低了Reduce端的数据负载，节约了集群的资源，也提升了任务的性能。5.2根本规那么开启参数默认自动开启谓词下推hive.optimize.ppd=true;不同Join场景下的Where谓词下推测试试验结论InnerJoin以及FullouterJoin，条件写在on后面，还是where后面，性能上面没有区别LeftouterJoin时，右侧的表写在on后面，左侧的表写在where后面，性能上有进步RightouterJoin时，左侧的表写在on后面、右侧的表写在where后面，性能上有进步假如SQL语句中出现不确定结果的函数，也无法实现下推6数据倾斜6.1数据倾斜的现象分布式计算中最常见的，最容易遇到的问题就是数据倾斜，数据倾斜的现象是，当我们提交运行一个程序时，我们通过监控发现，这个程序的大多数的Task都已经运行完毕了，只有某一个Task一直在运行，迟迟不能完毕，导致整体的进度卡在99%或100%，这时候我们就可以断定程序出现了数据倾斜的问题。6.2数据倾斜的原因外表上看，发生数据倾斜的原因在于这个Task运行过慢，但是仔细分析我们会发现，这个Task运行过慢的原因在于这个Task的负载要比其他Task的负载要高，所以发生数据倾斜的直观原因在于Task的数据分配不平衡。那为什么会出现多个Task数据分配不平衡的情况呢？从两方面考虑，第一：数据本身就是倾斜的，数据中某种数据出现的次数太多。第二：分区规那么导致这些一样的数据都分配给了同一个Task，导致这个Task拿到了大量的数据，而其他Task拿到的数据比拟少，所以运行起来相比拟于其他Task就比拟慢一些。综上所述，产生数据倾斜的根本原因在于分区规那么。6.3groupBy的数据倾斜当程序中出现groupby或countdistinct等分组聚合的场景时，假如数据本身是倾斜的根据MapReduce的Hash分区规那么，肯定会出现数据倾斜的现象。根本原因是因为分区规那么导致的，所以我们可以通过以下几种方案来解决groupby导致的数据倾斜的问题。方案一：开启Map端聚合开启Map端聚合：Combinerhive.map.aggr=true;通过减少Reduce的输入量，防止每个Task数据差异过大导致数据倾斜方案二：实现随机分区SQL中防止数据倾斜，构建随机分区select*fromtabledistributebyrand();distributeby用于指定底层的MapReduce按照哪个字段作为Key实现分区、分组等默认由Hive自己选择，我们可以通过distributeby自己指定，通过rank函数随机值实现随机分区，防止数据倾斜方案三：自动构建随机分区并自动聚合开启随机分区，走两个MapReducehive.groupby.skewindata=true;开启该参数以后，当前程序会自动通过两个MapReduce来运行第一个MapReduce自动进展随机分区，然后实现聚合第二个MapReduce将聚合的结果再按照业务进展处理，得到结果6.4Join的数据倾斜实际业务需求中往往需要构建两张表的Join实现，假如两张表比拟大，无法实现MapJoin，只能走ReduceJoin，那么当关联字段中某一种值太多的时候照旧会导致数据倾斜的问题，面对Join产生的数据倾斜，我们核心的思想是尽量防止ReduceJoin的产生，优先使用MapJoin来实现，但往往很多的Join场景不知足MapJoin的需求，那么我们可以以下几种方案来解决Join产生的数据倾斜问题：方案一：提早过滤，将大数据变成小数据，实现MapJoin实现两张表的Join时，我们要尽量考虑是否可以使用MapJoin来实现Join经过。有些场景下看起来是大表Join大表，但是我们可以通过转换将大表Join大表变成大表Join小表，来实现MapJoin。例如：如今有两张表订单表A与用户表B，需要实现查询今天所有订单的用户信息，关联字段为userid。A表：今天的订单，1000万条，字段：orderId,userId,produceId,price等B表：用户信息表，100万条，字段：userid,username,age,phone等需求：两张表关联得到今天每个订单的用户信息实现1：直接关联，实现大表Join大表selecta.*,b.*fromAjoinBona.userid=b.userid;由于两张表比拟大，无法走MapJoin，只能走ReduceJoin，容易产生数据倾斜。实现2：将下了订单的用户的数据过滤出来，再Joinselecta.*,d.*from(-获取所有下订单的用户信息select-获取所有下订单的userid(selectdistincta.useridfromAa)cjoinBbonc.userid=b.userid)dAaond.userid=a.userid;100万个用户中，在今天下订单的人数可能只有一小局部，大量数据是不会Join成功的可以提早将订单表中的userid去重，获取所有下订单的用户id再使用所有下订单的用户id关联用户表，得到所有下订单的用户的信息最后再使用下订单的用户信息关联订单表通太多次MapJoin来代替ReduceJoin，性能更好可以以防止数据倾斜方案二：使用BucketJoin假如使用方案一来防止ReduceJoin，有些场景下照旧无法知足，例如过滤后的数据照旧是一张大表，那么最后的Join照旧是一个ReduceJoin这种场景下，我们可以将两张表的数据构建为桶表，实现BucketMapJoin，防止数据倾斜方案三：使用SkewJoinSkewJoin是Hive中一种专门为了防止数据倾斜而设计的特殊的Join经过，这种Join的原理是将MapJoin以及ReduceJoin进展合并，假如某个值出现了数据倾斜，就会将产生数据倾斜的数据单独使用MapJoin来实现，其他没有产生数据倾斜的数据由ReduceJoin来实现，这样就防止了ReduceJoin中产生数据倾斜的问题，最终将MapJoin的结果以及ReduceJoin的结果进展Union合并配置开启运行经过中skewjoinsethive.optimize.skewjoin=true;假如这个key的出现的次数超过这个范围sethive.skewjoin.key=100000;在编译时判断是否会产生数据倾斜sethive.optimize.skewjoinpiletime=true;不合并，提升性能sethive.optimize.union.remove=true;假如Hive的底层走的是MapReduce，必须开启这个属性，才能实现不合并setmapreduce.input.fileinputformat.input.dir.recursive=true;例如图