目录
1 hive的参数配置(了解)
1 配置文件
- hive-site.xml 用户自定义的配置文件,我们对于hive修改都写在改文件中，当前环境文件在
/export/server/hive/conf/hive-site.xml - hive-default.xml 系统的默认配置文件,运行服务时会优先读取hive-site.xml
- hive服务的java进程中有默认的配置信息
- 在启动服务时,优先读取hive-site.xml文件,如果这个文件中没有的配置信息读取hive-default.xml,如果都没有读取hive进程中的默认配置信息
- 命令行配置参数
hive --service hiveserver2 --hiveconf hive.root.logger=DEBUG,console
# 配置了日志级别为debug 将数据输出到控制台中
# 日志级别
debug -- 开发调试过程中的日志信息
info -- 服务正常执行时的日志信息
warn -- 服务与预期执行效果不一致时的日志信息
error -- 服务出现异常而停止运行时的日志信息
- 使用参数声明进行配置
- 这种配置方式,只有当前链接中生效,更换或退出连接后,设置失效
set mapreduce.job.reduces = 3;
三种配置方式的优先级(其实就是运行的先后顺序,后执行的覆盖先执行的)
配置文件 < 命令行配置参数 < 参数声明
三种配置方式的影响范围:
配置文件 > 命令行配置参数 > 参数声明
配置文件: 影响该文件目录启动的任何hive服务
命令行配置参数: 影响本次启动的hive服务
参数声明: 当前使用的连接connect
我们更希望用户使用参数声明进行hive配置,因为hive鼓励 谁使用谁声明
每个人在处理不同的也许需求时,需要进行的配置是不相同的,如果使用前两种配置方式,则需要使用大量的配置文件,而参数声明可以使我们不同需求的人进行不同的配置
2 hive 表设计
1、采用分区表，减少全表扫描；2、采用列式存储
3 Hive的数据存储格式(了解)
hive支持的数据存储格式有TextFile（默认） SequenceFile Parquet ORC，但是尽量使用Parquet和ORC文件存储格式
TextFile和 SequenceFile 的存储格式都是基于行存储的
ORC 和 Parquet 是基于列式存储的
Hive行式存储和列式存储的优缺点
（1）行式存储：
优点：以整条记录为单位查询效率更高，insert和update更加容易
缺点：如果查询只涉及某几个列，它会把整行数据都读取出来，无法跳过不必要的列读取，压缩比例偏低,使用时消耗的内存和cpu资源比较多
（2）列式存储：
优点：最大的优势是查询时可以快速跳过没必要的列，从而避免全表扫描,压缩比例高,资源消耗少；支持编码压缩；谓词下推、映射下推
缺点：insert/update会比较麻烦并且不适合扫描小量的数据，列式存储一般都是二进制存储格式,无法直接通过文件查询内容
列式存储数据每一列的数据类型相同,压缩时压缩比例较高.
在hive中,我们基本不进行增删改的操作,我们90都是在查询和计算,所以使用列式存储格式效率更高
Parquet&ORC
相同点：
均为二进制列式存储，均有行组、列块的概念（二进制列式存储，可以快速跳过没有涉及到的列，从而避免全表扫描）
均支持基本数据类型、复杂数据类型（复杂数据类型不等同嵌套数据类型）
均支持压缩
均支持谓词下推、映射下推
orc和parquet格式的区别:
- orc格式不支持修改,而parquet支持修改
- orc格式不支持事务,而parquet支持事务
- orc格式的压缩效率更高,parquet相比于orc稍有不足
- orc格式的插入效率较高, parquet插入效率稍低
选择parquet原因：
支持嵌套数据类型（eg：json字符串），ORC不支持。 虽然ORC不支持嵌套数据类型（eg：json字符串），但可以通过复杂数据类型（eg：array和struct）把嵌套类型给表达出来
Parquet 存储格式对Spark非常友好
选择ORC原因：
（1）比Parquet 的压缩效率高（eg：snappy）
（2）ORC存储格式对hive非常友好
（3）支持事务ACID（支持事务的表必须为分桶表）
ACID就是常见数据库事务的四大特性：Atomicity(原子性)、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）
（4）支持不同的索引索引机制（意味着orc查询速度快）
ORC为我们提供了两种索引机制：Row Group Index（行组索引） 和 Bloom Filter Index（布隆过滤器）
Row Group Index（行组索引）
在stripe（行组）记录了每个字段的最大最小值，当查询中有<,>,=的操作时，会根据最大最小值，跳过扫描不包含的stripes
Bloom Filter Index（布隆过滤器）
判读数据在不在，当它说一个值不存在的时候，一定不存在，当它说一个值存在的时候，可能存在
优点：由于存放的不是完整的数据，所以占用的内存很少，而且新增，查询速度够快
缺点： 无法做到删除数据；只能精准的判断数据不存在问题，而无法精准的判断数据存在问题，并且随着数据的增加，误判率也随之增加
4 hive 数据压缩
在数据规模很大和工作负载密集的情况下，采用数据压缩对磁盘I/O操作、网络数据传输有极大的帮助
hive 中的压缩就是使用了hadoop中的压缩实现的，所以hadoop中支持的压缩在hive 中都可以直接使用
hadoop中支持的压缩算法：
压缩方式选择时重点考虑：解压缩速度、压缩率、压缩后是否可以支持切片
mr压缩方案建议
lzo压缩算法的缺点：需要手动为文件创建索引，没有索引不支持文件切片
所有压缩算法的缺点：加重CPU负荷，算法越复杂，解压时间越长
参数设置：设置map后输出压缩
-- 设置Hive的中间压缩 也就是map的输出压缩
-- 1）开启 hive 中间传输数据压缩功能
set hive.exec.compress.intermediate=true;
-- 2）开启 mapreduce 中 map 输出压缩功能
set mapreduce.map.output.compress=true;
-- 3）设置 mapreduce 中 map 输出数据的压缩方式
set mapreduce.map.output.compress.codec = org.apache.hadoop.io.compress.SnappyCodec;
-- 设置Hive的最终输出压缩，也就是Reduce输出压缩
-- 1）开启 hive 最终输出数据压缩功能
set hive.exec.compress.output=true;
-- 2）开启 mapreduce 最终输出数据压缩
set mapreduce.output.fileoutputformat.compress=true;
-- 3）设置 mapreduce 最终数据输出压缩方式
set mapreduce.output.fileoutputformat.compress.codec =org.apache.hadoop.io.compress.SnappyCodec;
-- 4）设置 mapreduce 最终数据输出压缩为块压缩 还可以指定RECORD
set mapreduce.output.fileoutputformat.compress.type=BLOCK;
推荐使用snappy格式,因为压缩和解压效率极高
5 Fetch抓取机制
- 功能：在执行sql的时候，能不走MapReduce程序处理就尽量不走MapReduce程序处理。
- 尽量直接去操作数据文件。
- 设置： hive.fetch.task.conversion= more。 默认设置
--在下述4种情况下 sql不走mr程序
-- more 模式下如下内容不需要走mr程序
--全局查找
select * from student;
--字段查找
select num,name from student;
--limit 查找
select num,name from student limit 2;
-- 简单的条件过滤
select num,name from student where num > 2;
-- minimal 模式下如下内容不需要走mr程序
--全局查找
select * from student;
--字段查找
select num,name from student;
--limit 查找
select num,name from student limit 2;
-- none 模式下所有的操作都需要走mr程序
注意: 以上情况不是绝对不走mr 例如 现在读取一个30T的表,无论是否筛选过滤分组聚合,都必须走mr
6 mapreduce本地模式 (开发中建议开启)
开启本地模式
原因：有时候数据量不大的表用本地计算模式处理，时间会很短，但是默认情况下会将任务提交到集群，等待资源分配，这个过程不仅繁琐，而且更浪费时间
限制条件：如果以下任意一个条件不满足，那么即使开启了本地模式，将依旧会提交给YARN集群运行
处理的数据量不超过128M
MapTask的个数不超过4个
ReduceTask的个数不超过1个
什么情况下可以本地执行呢? 本地需要有内存和cpu资源
mapreduce.framework.name = local 本地模式
mapreduce.framework.name = yarn 集群模式
Hive提供了一个参数，自动切换MapReduce程序为本地模式，如果不满足条件，就执行yarn模式。
开启本地模式后要注意: 我们满足如下条件后会走本地模式, 但是本地服务器中资源一定足够么? 不一定
有时候看上去还有空间但是空间已经分配给yarn了
开启本地模式后要注意: 我们满足如下条件后会走本地模式, 但是本地服务器中资源一定足够么? 不一定
set hive.exec.mode.local.auto = true;
--3个条件必须都满足 自动切换本地模式
The total input size of the job is lower than: hive.exec.mode.local.auto.inputbytes.max (128MB by default) --数据量小于128M
The total number of map-tasks is less than: hive.exec.mode.local.auto.tasks.max (4 by default) --maptask个数少于4个
The total number of reduce tasks required is 1 or 0. --reducetask个数是0 或者 1
select * from hive_day04.log_text order by track_time; -- 47秒
set hive.exec.mode.local.auto = true;
select * from hive_day04.log_text order by track_time; -- 8秒
7 表的优化
1、表之间的Join
Hive实现Join时，为了提高性能，提供了多种Join方案，例如适合小表Join大表的Map Join，大表Join大表的Reduce Join，以及大表Join的优化方案Bucket Join等
- 底层还是MapReduce的join优化。
- MapReduce中有两种join方式。指的是join的行为发生什么阶段。
- map端join
- reduce端join
优化1：Hive自动尝试选择map端join提高join的效率 省去shuffle的过程。
- 这个优化策略在小表和小表的连接过程中使用
开启 mapjoin 参数设置：
（1）设置自动选择 mapjoin
set hive.auto.convert.join = true; --默认为 true
（2）大表小表的阈值设置： -- 默认是20M
set hive.mapjoin.smalltable.filesize= 25000000;
优化2：大表join大表
--背景：
大表join大表本身数据就十分具体，如果join字段存在null空值 如何处理它？
任何数据和null进行连接,都无法连接成功,所以此时我们会进行空值处理
--方式1：空key的过滤 此行数据不重要 where is not null
参与join之前 先把空key的数据过滤掉
SELECT a.* FROM (SELECT * FROM nullidtable WHERE id IS NOT NULL ) a JOIN ori b ON a.id =b.id;
--方式2：空Key转换
CASE WHEN a.id IS NULL THEN 'xxx任意字符串' ELSE a.id END -- 如果给空值赋值默认值空值数量太大,会造成某个桶的数据量过大
CASE WHEN a.id IS NULL THEN concat('hive', rand()) ELSE a.id --避免转换之后数据倾斜 随机分布打散
优化3：关联优化器,桶表join提高优化效率。bucket mapjoin
1.1 条件
1） set hive.optimize.bucketmapjoin = true;
2） 一个表的bucket数是另一个表bucket数的整数倍 第一个表分为4桶,第二个表可以是 1桶 2桶 4桶 8桶…
3） bucket列 == join列
4） 必须是应用在map join的场景中
1.2 注意
1）如果表不是bucket的，只是做普通join。
join连接优化参数
-- 开启map端join
set hive.auto.convert.join=true;
-- 修改大小表阈值
set hive.auto.convert.join.noconditionaltask.size=512000000;
-- 开启强排序
set hive.enforce.sorting=true;
-- 开启SMBmapjoin
set hive.auto.convert.sortmerge.join=true;
set hive.auto.convert.sortmerge.join.noconditionaltask=true;
set hive.optimize.bucketmapjoin.sortedmerge = true;
使用限制:
left join 的左表必须是大表
right join 的右表必须是大表
inner join 无要求
full join 不能使用 map join
map join 支持小表为子查询
使用 map join 时，若引用小表或子查询时，需要引用别名
在map join 中，可以使用不等值连接或者使用or连接多个条件
在 map join 中最多支持指定6张小表，否则报语法错误
原理：
小表数据首会分发给每个MapTask的内存一份，然后逐次取出大表部分数据和小表进行join，底层不需要经过shuffle
如果2个表都是大表且频繁join，则可以选择Bucket Join
Bucket Join（桶表join又分为2种）
普通的Bucket Join
排序的Bucket Join，简称SMB Join（不仅分桶了，而且在桶内进行了排序）
注意：分桶字段 = Join字段 ，桶的个数相等或者成倍数
如果实在没有办法避免大表之间的join，且无法使用Bucket Join，则老老实实的使用 Reduce Join
原理:经shuffle分组后，将key相同的数据分发到同一个reducer，实现大表之间的join
注意：Hive会自动判断是否满足Map Join，如果不满足Map Join，则自动执行Reduce Join
2、列裁剪和分区裁剪
列裁剪(在列式存储中效果最明显)
只读取我们指定的列,其余列不查看,提高查询效率,减小检索范围
Hive在读数据的时候，可以只读取查询中所需要用到的列，而忽略其他列。例如，若有以下查询：
在实施此项查询中，Q表有5列（a，b，c，d，e），Hive只读取查询逻辑中真实需要的3列a、b、e， 而忽略列c，d；这样做节省了读取开销，中间表存储开销和数据整合开销。
注意:Hive自动执行这种裁剪优化
裁剪对应的参数项为：
–默认值为真 在hive 2.x中无需在配置了, 直接为固定值: true
hive.optimize.cp=true;
分区裁剪
只读取我们指定的分区数据,其余分区不查看,提高查询效率,减小检索范围
在join中必须书写on 尽量不要使用where 如果一定要使用在连接之前使用where
注意: join时 已经将数据读取完成了,所以在连接之前就要对于表使用where进行分区裁剪,join 裁剪没有任何意义
执行查询SQL的时候, 能在join之前提前过滤的操作, 一定要提前过滤, 不要在join后进行过滤操作
如果操作的表是一张分区表, 那么建议一定要带上分区字段, 以减少扫描的数据量, 从而提升效率,
例如，若有以下查询：
注意:Hive自动执行这种裁剪优化
分区参数为：
– 默认为就是true (在hive 2.x中无需在配置了, 直接为固定值: true)
hive.optimize.pruner=true;
3、group by 数据倾斜优化
数据倾斜 : 我们开启map任务时会将同一个key的数据读取到一个map任务中,如果有一个key里边的数据量过大,而其他的key 数据量极少此时就会出现数据倾斜.(分工不均)
开启Map端聚合参数设置：
--（1）是否在Map端进行聚合，默认为True
set hive.map.aggr = true;
--（2）在Map端进行聚合操作的条目数目
set hive.groupby.mapaggr.checkinterval = 100000;
--（3）有数据倾斜的时候进行负载均衡（默认是false）
set hive.groupby.skewindata = true;
--Q:在hive中数据倾斜开启负载均衡之后 底层执行机制是什么样？
--step1:启动一个MapReduce程序 将倾斜的数据随机发送到各个reduce中 进行打散 负载均衡
每个reduce进行聚合都是局部聚合
--step2:再启动第二个MapReduce程序 将上一步局部聚合的结果汇总起来进行最终的聚合
数据倾斜只能优化不能解决
4、count优化
注意: 尽量不使用count(*) 尤其是列式存储格式
-- 一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换：
SELECT count(DISTINCT id) FROM bigtable;
-- 结果
SELECT count(id) FROM (SELECT id FROM bigtable GROUP BY id) a;
5、笛卡儿积
笛卡尔积: 在进行join的时候, 两个表乘积之后结果就是笛卡尔积的结果
什么时候会产生笛卡尔积呢? 在多表join的时候, 关联条件缺少或者使用错误的关联条件以及将关联条件放置在where中都会导致笛卡尔积
- 避免join的时候不加on条件，或者无效的on条件
- 关联条件不要放置在where语句, 因为底层, 先产生笛卡尔积 然后基于where进行过滤 , 建议放置on条件上
- 如果实际开发中无法确定表与表关联条件 建议与数据管理者重新对接, 避免出现问题
6、动态分区 与 静态分区
往hive分区表中插入数据时，hive提供了一个动态分区功能，其可以基于查询参数的位置去推断分区的名称，从而建立分区。使用Hive的动态分区，需要进行相应的配置。
Hive的动态分区是以第一个表的分区规则，来对应第二个表的分区规则，将第一个表的所有分区，全部拷贝到第二个表中来，第二个表在加载数据的时候，不需要指定分区了，直接用第一个表的分区即可
重点参数:
set hive.exec.dynamic.partition.mode=nonstrict; -- 开启非严格模式 默认为 strict(严格模式)
set hive.exec.dynamic.partition=true; -- 开启动态分区支持, 默认就是true
可选参数:主要是为了避免分区过多造成服务器崩溃
-- 在所有执行MR的节点上，最大一共可以创建多少个动态分区。
set hive.exec.max.dynamic.partitions=1000;
-- 每个执行MR的节点上，最大可以创建多少个动态分区
set hive.exec.max.dynamic.partitions.pernode=100;
-- 整个MR Job中，最大可以创建多少个HDFS文件
set hive.exec.max.created.files=100000;
-- 可选参数主要是为了避免分区过多,文件过多造成服务崩溃
-- 分区严格模式strict : 可以使用动态分区,但使用时最少有一个静态分区字段
举例: 分区表,分区时,使用的是年,月,日分区,此时我们根据年月日动态分区,会报错,但是如果年份为静态分区,则使用动态分区对于月,日指定
-- 分区非严格模式nonstrict : 可以随意动态分区
正常开发中,一般当天处理当天数据,且该数据都在一个分区中,所以我们开发时,使用动态分区的前提是我们能够知道分区数量不多,否则不建议使用。
语法：insert into 分区表 partition(分区字段) select *,分区字段 from 表1;;
# 静态分区/动态分区 建表语句都一样
CREATE TABLES 数据表（
xxx
）
partitioned by(role string) role角色(上、中、下、野、辅）
# 导入数据时候不一样，工作中常用动态导入
# 静态分区：
load data local inpath '/root/archer.txt' into table 数据表 partition by (role='sheshou'）
load data local inpath '/root/tank.txt' into table 数据表 partition by (role='tank')
# 静态分区好处，可以人为指定数据属于哪个分区。适合场景: 数据量较少情况
# 动态分区=> insert + select 准备原始表，使用insert + select把原始数据表中的数据导入到分区表
insert into table xxx partition(role)
select 字段,role main
from 原始表;
# 动态分区好处,不需要手工指定数据属于哪个分区，所有数据都是自动分区的。适合场景: 数据量大的情况
#动态分区注意: 必须设置为非严格模式
思考:动态分区表和静态分区表的建表语句有什么不同???
没有动态分区表和静态分区表的概念,只有动态加载和静态加载
换句话说,我们的建表语句是完全相同的,但是插入数据的方式不同分为动态(自动判断分区), 静态(手动指定分区)两种加载数据的方式.
8 map和reduce数量调整
1、是不是map数越多越好？
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m），则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限的。
2、是不是保证每个map处理接近128m的文件块，就高枕无忧了？
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。
3、是不是reduce数越多越好？
答案是否定的。如果reduce设置的过大，对整个作业会产生一定的影响。
①过多的启动和初始化reduce也会消耗时间和资源；
②另外，有多少个reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；
Maptask个数调整
map任务获取文件的大小和block大小相同时128M
hive中获取数据时，可以将文件合并为一个大文件再写入到map任务中
-- 小文件场景
-- 每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size=112345600;
-- 一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=112345600;
-- 一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack=112345600;
-- 执行Map前进行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
-- 大文件场景, 增加Map数
set mapred.reduce.tasks=10;
Reducetask个数调整
-- 总共受3个参数控制：
-- 每个Reduce处理的数据量默认是256MB
hive.exec.reducers.bytes.per.reducer=256123456
-- 每个任务最大的reduce数，默认为999
hive.exec.reducers.max=999
-- mapreduce.job.reduces
-- 该值默认为-1，由hive自己根据任务情况进行判断。也可以手动控制
set mapreduce.job.reduces = 8;
注意: 以下几种, 不管如何设置, 最终翻译后reduce只能有一个
- 执行order by操作
- 执行不需要group by直接聚合的操作
- 执行笛卡尔积
9 开启JVM重用
原理： Java虚拟机, 也就是java运行的环境。JVM指代一个Java进程，假设一个mr程序中有100个MapTask，那么Hadoop默认会为每个MapTask启动一个JVM(共100个)，JVM频繁的创建和销毁，会导致内存开销较大，为了解决上述问题，Hadoop中提供了JVM重用机制来，JVM重用机制可以使得一个JVM实例在同一个job中被使用N次（不同mr job中不可以），即当一个MapTask运行结束以后，JVM不会进行释放，而是继续供让一个MapTask使用，直到运行了N个以后，就会释放，N的值可以在Hadoop的mapred-site.xml文件中进行配置，通常在10-20之间，也可以再hive中直接进行设置
map任务和reduce任务都是在JVM上运行的,且每创建一个map或者reduce任务,创建一个jvm程序
JVM重用是Hadoop调优参数的内容，其对Hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或task特别多的场景，这类场景大多数执行时间都很短。
Hadoop的默认配置通常是使用派生JVM来执行map和Reduce任务的。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成百上千task任务的情况。
此操作, 在hive2.x默认支持已经不需要配置了
默认情况下, container资源容器 只能使用一次,不能重复使用, 开启JVM重用, 运行container容器可以被重复使用,在hive2.x已经默认支持了
10 推测机制和执行计划
执行计划explain，通过执行计划可以看出hive接下来是如何打算执行这条sql的。
执行计划只是最初的一个计划模板,在运行过程中驱动会根据数据以及配置参数不同,不断的调整优化执行计划,最初的执行计划仅供参考
语法：explain + sql语句
eg查看hive接下来是如何执行select * from student语句的:
explain select * from student;
+----------------------------------------------------+
| Explain |
+----------------------------------------------------+
| STAGE DEPENDENCIES: |
| Stage-0 is a root stage |
| |
| STAGE PLANS: |
| Stage: Stage-0 |
| Fetch Operator |
| limit: -1 |
| Processor Tree: |
| TableScan |
| alias: student |
| Statistics: Num rows: 1 Data size: 5260 Basic stats: COMPLETE Column stats: NONE |
| Select Operator |
| expressions: num (type: int), name (type: string), sex (type: string), age (type: int), dept (type: string) |
| outputColumnNames: _col0, _col1, _col2, _col3, _col4 |
| Statistics: Num rows: 1 Data size: 5260 Basic stats: COMPLETE Column stats: NONE |
| ListSink |
| |
+----------------------------------------------------+
并行执行机制
- 如果hivesql的底层某些stage阶段可以并行执行，就可以提高执行效率。
- 前提是stage之间没有依赖 并行的弊端是瞬时服务器压力变大。
- 参数
set hive.exec.parallel=true; --是否并行执行作业。适用于可以并行运行的MapReduce作业，例如在多次插入期间移动文件以插入目标
set hive.exec.parallel.thread.number=16; --最多可以并行执行多少个作业。默认为8,不建议更改。
Hive的严格模式：避免执行效率低下的语句影响服务器性能
注意。不要和动态分区的严格模式搞混淆。
这里的严格模式指的是开启之后 hive会禁止一些用户都影响不到的错误包括效率低下的操作，不允许运行一些有风险的查询。
设置
set hive.mapred.mode = strict --默认是非严格模式 nonstrict
解释
1、如果是分区表，没有where进行分区裁剪 禁止执行
2、order by语句必须+limit限制
推测执行机制
- MapReduce中task的一个机制。
- 功能：
一个job底层可能有多个task执行，如果某些拖后腿的task执行慢，可能会导致最终job失败。
所谓的推测执行机制就是通过算法找出拖后腿的task,为其启动备份的task。
两个task同时处理一份数据，谁先处理完，谁的结果作为最终结果。
- 推测执行机制默认是开启的，但是在企业生产环境中建议关闭，商业版hadoop中一般默认关闭。
745
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
