大连app网站建设,外包公司辞退有赔偿吗,1简述网站建设流程图,调查队网站建设3.8 Join 优化
Join优化整体原则#xff1a; 1、优先过滤后再进行 join 操作#xff0c;最大限度的减少参与 join 的数据量 2、小表 join 大表#xff0c;最好启动 mapjoin#xff0c;hive 自动启用 mapjoin, 小表不能超过25M#xff0c;可以更改 3、Join on的条件相同的…3.8 Join 优化
Join优化整体原则 1、优先过滤后再进行 join 操作最大限度的减少参与 join 的数据量 2、小表 join 大表最好启动 mapjoinhive 自动启用 mapjoin, 小表不能超过25M可以更改 3、Join on的条件相同的话最好放入同一个job并且 join 表的排列顺序从小到大 select a., b., c.* from a join b on a.id b.id join c on a.id c.i 4、如果多张表做 join, 如果多个链接条件都相同会转换成一个JOb • 优先过滤数据 尽量减少每个阶段的数据量对于分区表能用上分区字段的尽量使用同时只选择后面需要使用到的列最大限度的减少参与 Join 的数据量。 • 小表 join 大表原则 小表 join 大表的时应遵守小表 join 大表原则原因是 join 操作的 reduce 阶段位于 join 左边的表内容会被加载进内存将条目少的表放在左边可以有效减少发生内存溢出的几率。join 中执行顺序是从左到右生成 Job应该保证连续查询中的表的大小从左到右是依次增加的。 • 使用相同的连接键 在 hive 中当对 3 个或更多张表进行 join 时如果 on 条件使用相同字段那么它们会合并为一个 MapReduce Job利用这种特性可以将相同的 join on 放入一个 job 来节省执行时间。 • 尽量原子操作 尽量避免一个SQL包含复杂的逻辑可以使用中间表来完成复杂的逻辑。 • 大表 Join 大表 1、 空 key 过滤有时 join 超时是因为某些 key 对应的数据太多而相同key 对应的数据都会发送到相同的 reducer 上从而导致内存不够。此时我们应该仔细分析这些异常的 key很多情况下这些 key 对应的数据是异常数据我们需要在SQL语句中进行过滤。 2、 空 key 转换有时虽然某个 key 为空对应的数据很多但是相应的数据不是异常数据必须要包含在 join 的结果中此时我们可以表a中 key 为空的字段赋一个随机的值使得数据随机均匀地分不到不同的 reducer 上。 3.9 启用 MapJoin
这个优化措施但凡能用就用 大表 join 小表 小表满足需求 小表数据小于控制条件时。
MapJoin 是将 join 双方比较小的表直接分发到各个 map 进程的内存中在 map 进程中进行 join 操作这样就不用进行 reduce 步骤从而提高了速度。只有 join 操作才能启用 MapJoin。
## 是否根据输入小表的大小自动将reduce端的common join 转化为map join将小表刷入内存中。
## 对应逻辑优化器是MapJoinProcessor
set hive.auto.convert.join true;
## 刷入内存表的大小(字节)
set hive.mapjoin.smalltable.filesize 25000000;
## hive会基于表的size自动的将普通join转换成mapjoin
set hive.auto.convert.join.noconditionaltasktrue;
## 多大的表可以自动触发放到内层LocalTask中默认大小10M
set hive.auto.convert.join.noconditionaltask.size10000000;Hive 可以进行多表 Join。Join 操作尤其是 Join 大表的时候代价是非常大的。MapJoin 特别适合大小表join的情况。 在Hive join场景中一般总有一张相对小的表和一张相对大的表小表叫 build table大表叫 probe table。 Hive 在解析带 join 的 SQL 语句时会默认将最后一个表作为 probe table将前面的表作为 build table 并试图将它们读进内存。 如果表顺序写反probe table 在前面引发 OOM 的风险就高了。 在维度建模数据仓库中事实表就是 probe table维度表就是 build table。 这种 Join 方式在 map 端直接完成 join 过程消灭了 reduce效率很高。而且 MapJoin 还支持非等值连接。 当 Hive 执行 Join 时需要选择哪个表被流式传输stream哪个表被缓存cache。 Hive 将JOIN 语句中的最后一个表用于流式传输因此我们需要确保这个流表在两者之间是最大的。 如果要在不同的 key 上 join 更多的表那么对于每个 join 集只需在 ON 条件右侧指定较大的表。 也可以手动开启 mapjoin
--SQL方式在SQL语句中添加MapJoin标记mapjoin hint
--将小表放到内存中省去shffle操作
// 在没有开启mapjoin的情况下执行的是reduceJoin
SELECT /* MAPJOIN(smallTable) */ smallTable.key, bigTable.value FROM
smallTable JOIN bigTable ON smallTable.key bigTable.key;
/*mapjoin(smalltable)*/• Sort-Merge-Bucket(SMB) Map Join
它是另一种 Hive Join 优化技术使用这个技术的前提是所有的表都必须是分桶表bucket和分桶排序的sort。分桶表的优化
具体实现 1、针对参与 join 的这两张做相同的 hash 散列每个桶里面的数据还要排序 2、这两张表的分桶个数要成倍数。 3、开启 SMB join 的开关 一些常见参数设置
## 当用户执行bucket map join的时候发现不能执行时禁止查询
set hive.enforce.sortmergebucketmapjoinfalse;
## 如果join的表通过sort merge join的条件join是否会自动转换为sort merge join
set hive.auto.convert.sortmerge.jointrue;
## 当两个分桶表 join 时如果 join on的是分桶字段小表的分桶数是大表的倍数时可以启用mapjoin 来提高效率。
# bucket map join优化默认值是 false
set hive.optimize.bucketmapjoinfalse;
## bucket map join 优化默认值是 false
set hive.optimize.bucketmapjoin.sortedmergefalse;3.10 Join数据倾斜优化
在编写 Join 查询语句时如果确定是由于 join 出现的数据倾斜那么请做如下设置
# join的键对应的记录条数超过这个值则会进行分拆值根据具体数据量设置
set hive.skewjoin.key100000;
# 如果是join过程出现倾斜应该设置为true
set hive.optimize.skewjoinfalse;如果开启了在 Join 过程中 Hive 会将计数超过阈值 hive.skewjoin.key默认100000的倾斜 key 对应的行临时写进文件中然后再启动另一个 job 做 map join 生成结果。 通过 hive.skewjoin.mapjoin.map.tasks 参数还可以控制第二个 job 的 mapper 数量默认10000。
set hive.skewjoin.mapjoin.map.tasks100003.11 CBO 优化
join 的时候表的顺序的关系前面的表都会被加载到内存中。后面的表进行磁盘扫描。
select a., b., c.*
from a
join b on a.id b.id
join c on a.id c.id;Hive 自 0.14.0 开始加入了一项 “Cost based Optimizer” 来对 HQL 执行计划进行优化这个功能通过 “hive.cbo.enable” 来开启。 在 Hive 1.1.0 之后这个 feature 是默认开启的它可以 自动优化 HQL 中多个 Join 的顺序并选择合适的 Join 算法。 CBO成本优化器代价最小的执行计划就是最好的执行计划。 传统的数据库成本优化器做出最优化的执行计划是依据统计信息来计算的Hive 的成本优化器也一样。 Hive 在提供最终执行前优化每个查询的执行逻辑和物理执行计划。 这些优化工作是交给底层来完成的。 根据查询成本执行进一步的优化从而产生潜在的不同决策如何排序连接执行哪种类型的连接并行度等等。要使用基于成本的优化也称为CBO请在查询开始设置以下参数
set hive.cbo.enabletrue;
set hive.compute.query.using.statstrue;
set hive.stats.fetch.column.statstrue;
set hive.stats.fetch.partition.statstrue;3.12 怎样做笛卡尔积
当 Hive 设定为严格模式hive.mapred.modestrict时不允许在 HQL 语句中出现笛卡尔积这实际说明了 Hive 对笛卡尔积支持较弱。因为找不到 Join keyHive 只能使用 1 个 reducer 来完成笛卡尔积。 当然也可以使用 limit 的办法来减少某个表参与 join 的数据量但对于需要笛卡尔积语义的需求来说经常是一个大表和一个小表的 Join 操作结果仍然很大以至于无法用单机处理这时 MapJoin 才是最好的解决办法。MapJoin顾名思义会在 Map 端完成 Join 操作。这需要将 Join 操作的一个或多个表完全读入内存。 PSMapJoin 在子查询中可能出现未知 BUG。在大表和小表做笛卡尔积时规避笛卡尔积的方法是给 Join 添加一个 Join key原理很简单将小表扩充一列 join key并将小表的条目复制数倍join key 各不相同将大表扩充一列 join key 为随机数。 精髓就在于复制几倍最后就有几个 reduce 来做而且大表的数据是前面小表扩张 key 值范围里面随机出来的所以复制了几倍 n就相当于这个随机范围就有多大 n那么相应的大表的数据就被随机的分为了 n 份。并且最后处理所用的 reduce 数量也是 n而且也不会出现数据倾斜。
3.13 Group By 优化
默认情况下Map 阶段同一个 Key 的数据会分发到一个 Reduce 上当一个 Key 的数据过大时会产生数据倾斜。进行 group by 操作时可以从以下两个方面进行优化。 Map 端部分聚合 事实上并不是所有的聚合操作都需要在 Reduce 部分进行很多聚合操作都可以先在 Map 端进行部分聚合然后在 Reduce 端的得出最终结果。
## 开启Map端聚合参数设置
set hive.map.aggrtrue;
# 设置map端预聚合的行数阈值超过该值就会分拆job默认值100000
set hive.groupby.mapaggr.checkinterval100000有数据倾斜时进行负载均衡 当 HQL 语句使用 group by 时数据出现倾斜时如果该变量设置为 true那么 Hive 会自动进行负载均衡。 策略就是把 MapReduce 任务拆分成两个第一个先做预汇总第二个再做最终汇总。
# 自动优化有数据倾斜的时候进行负载均衡默认是false
set hive.groupby.skewindatafalse;当选项设定为 true 时生成的查询计划有两个 MapReduce 任务。 1、在第一个 MapReduce 任务中map 的输出结果会随机分布到 reduce 中每个 reduce 做部分聚合操作并输出结果这样处理的结果是相同的 group by key 有可能分发到不同的 reduce 中从而达到负载均衡的目的 2、第二个 MapReduce 任务再根据预处理的数据结果按照 group by key 分布到各个 reduce 中最后完成最终的聚合操作 Map 端部分聚合并不是所有的聚合操作都需要在 Reduce 端完成很多聚合操作都可以先在 Map 端进行部分聚合最后在 Reduce 端得出最终结果对应的优化器为 GroupByOptimizer。 那么如何用 group by 方式同时统计多个列
select t.a, sum(t.b), count(t.c), count(t.d) from some_table t group by t.a;下面是解决方法
select t.a, sum(t.b), count(t.c), count(t.d) from (select a, b, null c,null d from some_tableunion allselect a,0 b, c,null d from some_table group by a,cunion allselect a,0 b,null c,d from some_table group by a,d
) t;3.14 Order By 优化
order by 只能是在一个 reduce 进程中进行所以如果对一个大数据集进行 order by 会导致一个reduce 进程中处理的数据相当大造成查询执行缓慢。 1、在最终结果上进行order by不要在中间的大数据集上进行排序。如果最终结果较少可以在一个reduce上进行排序时那么就在最后的结果集上进行order by。 2、如果是取排序后的前N条数据可以使用distribute by和sort by在各个reduce上进行排序后前N条然后再对各个reduce的结果集合合并后在一个reduce中全局排序再取前N条因为参与全局排序的order by的数据量最多是reduce个数 * N所以执行效率会有很大提升。 在 Hive 中关于数据排序提供了四种语法一定要区分这四种排序的使用方式和适用场景。 1、order by全局排序缺陷是只能使用一个reduce 2、sort by单机排序单个reduce结果有序 3、cluster by对同一字段分桶并排序不能和sort by 连用 4、distribute by sort by分桶保证同一字段值只存在一个结果文件当中结合 sort by 保证每个 reduceTask 结果有序 Hive HQL 中的 order by 与其他 SQL 方言中的功能一样就是将结果按某字段全局排序这会导致所有 map 端数据都进入一个 reducer 中在数据量大时可能会长时间计算不完。 如果使用 sort by那么还是会视情况启动多个 reducer 进行排序并且保证每个 reducer 内局部有序。 为了控制map 端数据分配到 reducer 的 key往往还要配合 distribute by 一同使用。 如果不加distribute by 的话map 端数据就会随机分配到 reducer。 提供一种方式实现全局排序两种方式
1、建表导入数据准备
create table if not exists student(id int, name string, sex string, age int,department string) row format delimited fields terminated by ,;
load data local inpath /home/bigdata/students.txt into table student;2、第一种方式
-- 直接使用order by来做。如果结果数据量很大这个任务的执行效率会非常低
select id,name,age from student order by age desc limit 3;3、第二种方式
-- 使用distribute by sort by 多个reduceTask每个reduceTask分别有序
set mapreduce.job.reduces3;
drop table student_orderby_result;
-- 范围分桶 0 18 1 20 2
create table student_orderby_result as select * from student distribute by (case
when age 20 then 0 when age 18 then 2 else 1 end) sort by (age desc)关于分界值的确定使用采样的方式来估计数据分布规律。
3.15 Count Distinct优化
当要统计某一列去重数时如果数据量很大count(distinct) 就会非常慢原因与 order by 类似count(distinct) 逻辑只会有很少的 reducer 来处理。 这时可以用 group by 来改写
-- 先 group by 在 count
select count(1) from (select age from studentwhere department MAgroup by age
) t;再来一个例子 优化前 一个普通的只使用一个reduceTask来进行count(distinct) 操作。
-- 优化前只有一个reduce先去重再count负担比较大
select count(distinct id) from tablename;优化后 但是这样写会启动两个 MR job单纯 distinct 只会启动一个所以要确保数据量大到启动 job 的 overhead 远小于计算耗时才考虑这种方法。 当数据集很小或者 key 的倾斜比较明显时group by 还可能会比 distinct 慢。
-- 优化后启动两个job一个job负责子查询(可以有多个reduce)另一个job负责count(1))
select count(1) from (select distinct id from tablename) tmp;
select count(1) from (select id from tablename group by id) tmp; // 推荐使用这种
3.16 怎样写 in/exists 语句
在Hive的早期版本中in/exists语法是不被支持的但是从 hive-0.8x 以后就开始支持这个语法。但是不推荐使用这个语法。虽然经过测验Hive-2.3.6 也支持 in/exists 操作但还是推荐使用 Hive 的一个高效替代方案left semi join 。
比如说
-- in / exists 实现
select a.id, a.name from a where a.id in (select b.id from b);
select a.id, a.name from a where exists (select id from b where a.id b.id);可以使用 join 来改写
select a.id, a.name from a join b on a.id b.id;应该转换成
-- left semi join 实现
select a.id, a.name from a left semi join b on a.id b.id;3.17 使用 vectorization 技术
在计算类似 scan, filter, aggregation 的时候 vectorization 技术以设置批处理的增量大小为 1024 行单次来达到比单条记录单次获得更高的效率。
set hive.vectorized.execution.enabledtrue ;
set h/ive.vectorized.execution.reduce.enabledtrue;3.18 多重模式
如果你碰到一堆SQL并且这一堆SQL的模式还一样。都是从同一个表进行扫描做不同的逻辑。 有可优化的地方如果有 n 条SQL每个SQL执行都会扫描一次这张表 如果一个 HQL 底层要执行 10 个 Job那么能优化成 8 个一般来说肯定能有所提高多重插入就是一个非常实用的技能。一次读取多次插入有些场景是从一张表读取数据后要多次利用这时可以使用 multi insert 语法。
from sale_detailinsert overwrite table sale_detail_multi partition (sale_date2019,regionchina )select shop_name, customer_id, total_price where .....insert overwrite table sale_detail_multi partition (sale_date2020,regionchina )select shop_name, customer_id, total_price where .....;说明multi insert 语法有一些限制。 1、一般情况下单个SQL中最多可以写128路输出超过128路则报语法错误。 2、在一个multi insert中对于分区表同一个目标分区不允许出现多次。对于未分区表该表不能出现多次。 3、对于同一张分区表的不同分区不能同时有insert overwrite和insert into操作否则报错返回。 Multi-Group by 是 Hive 的一个非常好的特性它使得 Hive 中利用中间结果变得非常方便。例如
FROM (SELECT a.status, b.school, b.gender FROM status_updates a JOIN profiles b ON (a.userid b.userid and a.ds2019-03-20 )) subq1INSERT OVERWRITE TABLE gender_summary PARTITION(ds2019-03-20)SELECT subq1.gender, COUNT(1) GROUP BY subq1.genderINSERT OVERWRITE TABLE school_summary PARTITION(ds2019-03-20)SELECT subq1.school, COUNT(1) GROUP BY subq1.school;上述查询语句使用了 Multi-Group by 特性连续 group by 了 2 次数据使用不同的 Multi-Group by。 这一特性可以减少一次 MapReduce 操作。
3.19 启动中间结果压缩
map 输出压缩
set mapreduce.map.output.compresstrue;
set mapreduce.map.output.compress.codecorg.apache.hadoop.io.compress.SnappyCodec;中间数据压缩 中间数据压缩就是对 hive 查询的多个 Job 之间的数据进行压缩。最好是选择一个节省CPU耗时的压缩方式。 可以采用 snappy 压缩算法该算法的压缩和解压效率都非常高。
set hive.exec.compress.intermediatetrue;
set hive.intermediate.compression.codecorg.apache.hadoop.io.compress.SnappyCodec;
set hive.intermediate.compression.typeBLOCK;结果数据压缩 最终的结果数据Reducer输出数据也是可以进行压缩的可以选择一个压缩效果比较好的可以减少数据的大小和数据的磁盘读写时间。 注常用的 gzipsnappy 压缩算法是不支持并行处理的如果数据源是 gzip/snappy压缩文件大文件这样只会有有个 mapper 来处理这个文件会严重影响查询效率。 所以如果结果数据需要作为其他查询任务的数据源可以选择支持 splitable 的 LZO 算法这样既能对结果文件进行压缩还可以并行的处理这样就可以大大的提高 job 执行的速度了。
set hive.exec.compress.outputtrue;
set mapreduce.output.fileoutputformat.compresstrue;
set mapreduce.output.fileoutputformat.compress.codecorg.apache.hadoop.io.compress.LzoCodec;
set mapreduce.output.fileoutputformat.compress.typeBLOCK;四、Hive 架构层面
4.1 启用本地抓取 Hive 的某些 SQL 语句需要转换成 MapReduce 的操作某些 SQL 语句就不需要转换成 MapReduce 操作但是同学们需要注意理论上来说所有的 SQL 语句都需要转换成 MapReduce 操作只不过Hive 在转换 SQL 语句的过程中会做部分优化使某些简单的操作不再需要转换成 MapReduce例如 1、只是 select * 的时候 2、where 条件针对分区字段进行筛选过滤时 3、带有 limit 分支语句时 Hive 从 HDFS 中读取数据有两种方式启用MapReduce读取 和 直接抓取。 直接抓取数据比 MapReduce 方式读取数据要快的多但是只有少数操作可以使用直接抓取方式。 可以通过 hive.fetch.task.conversion 参数来配置在什么情况下采用直接抓取方式: minimal只有 select * 、在分区字段上 where 过滤、有 limit 这三种场景下才启用直接抓取方式。 more在 select、where 筛选、limit 时都启用直接抓取方式。 查看 Hive 的抓取策略
## 查看
set hive.fetch.task.conversion;设置Hive的抓取策略
## 默认more
set hive.fetch.task.conversionmore;请看 hive-default.xml 中关于这个参数的解释
propertynamehive.fetch.task.conversion/namevaluemore/value
descriptionExpects one of [none, minimal, more].Some select queries can be converted to single FETCH task minimizing latency.Currently the query should be single sourced not having any subquery and should not haveany aggregations or distincts (which incurs RS), lateral views and joins.0. none : disable hive.fetch.task.conversion1. minimal : SELECT STAR, FILTER on partition columns, LIMIT only2. more : SELECT, FILTER, LIMIT only (support TABLESAMPLE and virtual columns)
/description
/property
propertynamehive.fetch.task.conversion.threshold/namevalue1073741824/value
descriptionInput threshold for applying hive.fetch.task.conversion. If target table is native, input length is calculated by summation of file lengths. If its not native, storage handler for the table can optionally implementorg.apache.hadoop.hive.ql.metadata.InputEstimator interface.
/description
/property4.2 本地执行优化
Hive 在集群上查询时默认是在集群上多台机器上运行需要多个机器进行协调运行这种方式很好的解决了大数据量的查询问题。但是在 Hive 查询处理的数据量比较小的时候其实没有必要启动分布式模式去执行因为以分布式方式执行设计到跨网络传输、多节点协调等并且消耗资源。对于小数据集可以通过本地模式在单台机器上处理所有任务执行时间明显被缩短。 启动本地模式涉及到三个参数
## 打开hive自动判断是否启动本地模式的开关
set hive.exec.mode.local.autotrue;
## map任务数最大值不启用本地模式的task最大个数
set hive.exec.mode.local.auto.input.files.max4;
## map输入文件最大大小不启动本地模式的最大输入文件大小
set hive.exec.mode.local.auto.inputbytes.max134217728;4.3 JVM重用
Hive 语句最终会转换为一系列的 MapReduce 任务每一个MapReduce 任务是由一系列的 MapTask和 ReduceTask 组成的默认情况下MapReduce 中一个 MapTask 或者 ReduceTask 就会启动一个JVM 进程一个 Task 执行完毕后JVM 进程就会退出。这样如果任务花费时间很短又要多次启动JVM 的情况下JVM 的启动时间会变成一个比较大的消耗这时可以通过重用 JVM 来解决。
set mapred.job.reuse.jvm.num.tasks5;JVM也是有缺点的开启JVM重用会一直占用使用到的 task 的插槽以便进行重用直到任务完成后才会释放。 如果某个 不平衡的job 中有几个 reduce task 执行的时间要比其他的 reduce task 消耗的时间要多得多的话那么保留的插槽就会一直空闲却无法被其他的 job 使用直到所有的 task 都结束了才会释放。 根据经验一般来说可以使用一个 cpu core 启动一个 JVM假如服务器有 16 个 cpu core 但是这个节点可能会启动 32 个mapTask完全可以考虑启动一个JVM执行两个Task 。
4.4 并行执行
有的查询语句Hive 会将其转化为一个或多个阶段包括MapReduce 阶段、抽样阶段、合并阶段、limit 阶段等。默认情况下一次只执行一个阶段。但是如果某些阶段不是互相依赖是可以并行执行的。多阶段并行是比较耗系统资源的。 一个 Hive SQL 语句可能会转为多个 MapReduce Job每一个 job 就是一个 stage这些 Job 顺序执行这个在 cli 的运行日志中也可以看到。但是有时候这些任务之间并不是是相互依赖的如果集群资源允许的话可以让多个并不相互依赖 stage 并发执行这样就节约了时间提高了执行速度但是如果集群资源匮乏时启用并行化反倒是会导致各个 Job 相互抢占资源而导致整体执行性能的下降。 启用并行化
## 可以开启并发执行。
set hive.exec.paralleltrue;
## 同一个sql允许最大并行度默认为8。
set hive.exec.parallel.thread.number16;4.5 推测执行
在分布式集群环境下因为程序Bug包括Hadoop本身的bug负载不均衡或者资源分布不均等原因会造成同一个作业的多个任务之间运行速度不一致有些任务的运行速度可能明显慢于其他任务比如一个作业的某个任务进度只有50%而其他所有任务已经运行完毕则这些任务会拖慢作业的整体执行进度。
为了避免这种情况发生Hadoop采用了推测执行Speculative Execution机制它根据一定的法则推测出“拖后腿”的任务并为这样的任务启动一个备份任务让该任务与原始任务同时处理同一份数据并最终选用最先成功运行完成任务的计算结果作为最终结果。
# 启动mapper阶段的推测执行机制
set mapreduce.map.speculativetrue;
# 启动reducer阶段的推测执行机制
set mapreduce.reduce.speculativetrue;建议
如果用户对于运行时的偏差非常敏感的话那么可以将这些功能关闭掉。如果用户因为输入数据量很大而需要执行长时间的MapTask或者ReduceTask的话那么启动推测执行造成的浪费是非常巨大大。 设置开启推测执行参数Hadoop 的 mapred-site.xml 文件中进行配置。
propertynamemapreduce.map.speculative/namevaluetrue/valuedescriptionIf true, then multiple instances of some map tasks may be executed in parallel./description
/property
propertynamemapreduce.reduce.speculative/namevaluetrue/valuedescriptionIf true, then multiple instances of some reduce tasks may be executed in parallel./description
/propertyHive 本身也提供了配置项来控制 reduce-side 的推测执行。
propertynamehive.mapred.reduce.tasks.speculative.execution/namevaluetrue/valuedescriptionWhether speculative execution for reducers should be turned on. /description
/property4.6 Hive严格模式
所谓严格模式就是强制不允许用户执行有风险的 HiveQL 语句一旦执行会直接失败。 但是Hive中为了提高SQL语句的执行效率可以设置严格模式充分利用Hive的某些特点。
## 设置Hive的严格模式
set hive.mapred.modestrict;
set hive.exec.dynamic.partition.modenostrict;注意当设置严格模式之后会有如下限制
1、对于分区表必须添加where对于分区字段的条件过滤
select * from student_ptn where age 25
2、order by语句必须包含limit输出限制
select * from student order by age limit 100;
3、限制执行笛卡尔积的查询
select a.*, b.* from a, b;
4、在hive的动态分区模式下如果为严格模式则必须需要一个分区列式静态分区其他参考优化
hive性能优化小结1
hive性能优化小结2
hive优化器2上
hive优化器2下
