Hive配置中有个参数hive.mapred.mode，分为nonstrict，strict，默认是nonstrict
如果设置为strict，会对三种情况的语句在compile环节做过滤：
1. 笛卡尔积Join。这种情况由于没有指定reduce join key，所以只会启用一个reducer，数据量大时会造成性能瓶颈
|
1
2
3
4
5
6
7
8
9
10
|
// Use only 1 reducer in case of cartesian product
if
(reduceKeys.size() ==
0
) {
numReds =
1
;
// Cartesian product is not supported in strict mode
if
(conf.getVar(HiveConf.ConfVars.HIVEMAPREDMODE).equalsIgnoreCase(
"strict"
)) {
throw
new
SemanticException(ErrorMsg.NO_CARTESIAN_PRODUCT.getMsg());
}
}
|
2. order by后面不跟limit。order by会强制将reduce number设置成1，不加limit，会将所有数据sink到reduce端来做全排序。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
if
(sortExprs ==
null
) {
sortExprs = qb.getParseInfo().getOrderByForClause(dest);
if
(sortExprs !=
null
) {
assert
numReducers ==
1
;
// in strict mode, in the presence of order by, limit must be specified
Integer limit = qb.getParseInfo().getDestLimit(dest);
if
(conf.getVar(HiveConf.ConfVars.HIVEMAPREDMODE).equalsIgnoreCase(
"strict"
)
&& limit ==
null
) {
throw
new
SemanticException(generateErrorMessage(sortExprs,
ErrorMsg.NO_LIMIT_WITH_ORDERBY.getMsg()));
}
}
}
|
3. 读取的表是partitioned table，但没有指定partition predicate。
注：如果是多级分区表的话，只要出现任何一个就放行
|
1
2
3
4
5
6
7
8
9
10
|
// If the "strict" mode is on, we have to provide partition pruner for
// each table.
if
(
"strict"
.equalsIgnoreCase(HiveConf.getVar(conf,
HiveConf.ConfVars.HIVEMAPREDMODE))) {
if
(!hasColumnExpr(prunerExpr)) {
throw
new
SemanticException(ErrorMsg.NO_PARTITION_PREDICATE
.getMsg(
"for Alias \""
+ alias +
"\" Table \""
+ tab.getTableName() +
"\""
));
}
}
|
这三种case在数据量比较大的情况下都会造成生成低效的MR Job，影响执行时间和效率，不过直接抛出exception又感觉太forcefully了。
可以在一些非线上生产环境下的ad-hoc查询端中开启strict mode，比如hiveweb，运营工具。
Hive中的排序语法
ORDER BY
Hive中的ORDER BY语句和关系数据库中的sql语法相似。他会对查询结果做全局排序，这意味着所有的数据会传送到一个Reduce任务上，这样会导致在大数量的情况下，花费大量时间。
与数据库中 ORDER BY 的区别在于在模式下，必须指定 limit 否则执行会报错。
hive> set hive.mapred.mode=strict;
hive> select * from test order by id;
FAILED: SemanticException 1:28 In strict mode, if ORDER BY is specified, LIMIT must also be specified. Error encountered near token 'id'
例子：
hive> set hive.mapred.mode=unstrict;
hive> select * from test order BY id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 1 Cumulative CPU: 1.88 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 1 seconds 880 msec
OK
1 a
1 a
2 b
2 b
3 c
3 c
4 d
4 d
Time taken: 24.609 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了一个reduce进行全局排序。
SORT BY
SORT BY不是全局排序，其在数据进入reducer前完成排序，因此在有多个reduce任务情况下，SORT BY只能保证每个reduce的输出有序，而不能保证全局有序。
注意：SORT BY 不受 参数的影响
你可以通过设置的值来控制reduce的数，然后对reduce输出的结果做二次排序。
例子：
hive> set mapred.reduce.tasks=3;
hive> select * from test sort BY id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.48 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 480 msec
OK
1 a
2 b
3 c
4 d
2 b
3 c
4 d
1 a
Time taken: 29.574 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了三个reduce分别排序，最后的结果不是有序的。
DISTRIBUTE BY with SORT BY
DISTRIBUTE BY能够控制map的输出在reduce中如何划分。其可以按照指定的字段对数据进行划分到不同的输出reduce/文件中。
DISTRIBUTE BY和GROUP BY有点类似，DISTRIBUTE BY控制reduce如何处理数据，而SORT BY控制reduce中的数据如何排序。
注意：hive要求DISTRIBUTE BY语句出现在SORT BY语句之前。
例子：
hive> select * from test distribute BY id sort by id asc;
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.24 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 240 msec
OK
3 c
3 c
1 a
1 a
4 d
4 d
2 b
2 b
Time taken: 29.89 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了三个reduce分别排序，最后的结果不是有序的。
CLUSTER BY来代替
当DISTRIBUTE BY的字段和SORT BY的字段相同时，可以用CLUSTER BY来代替 DISTRIBUTE BY with SORT BY。
注意：CLUSTER BY不能添加desc或者asc。
例子：
hive> select * from test cluster by id asc;
FAILED: ParseException line 1:33 extraneous input 'asc' expecting EOF near '<EOF>'
hive> select * from test cluster by id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.58 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 580 msec
OK
3 c
3 c
1 a
1 a
4 d
4 d
2 b
2 b
Time taken: 30.646 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了三个reduce分别排序，最后的结果不是有序的。
怎样让最后的结果是有序的呢？
可以这样做：
hive> select a.* from (select * from test cluster by id ) a order by a.id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.5 sec HDFS Read: 305 HDFS Write: 448 SUCCESS
Job 1: Map: 1 Reduce: 1 Cumulative CPU: 1.96 sec HDFS Read: 1232 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 6 seconds 460 msec
OK
1 a
1 a
2 b
2 b
3 c
3 c
4 d
4 d
Time taken: 118.261 seconds, Fetched: 8 row(s)
总结
- ORDER BY是全局排序，但在数据量大的情况下，花费时间会很长
- SORT BY是将reduce的单个输出进行排序，不能保证全局有序
- DISTRIBUTE BY可以按指定字段将数据划分到不同的reduce中
- 当DISTRIBUTE BY的字段和SORT BY的字段相同时，可以用CLUSTER BY来代替 DISTRIBUTE BY with SORT BY。
Hive配置中有个参数hive.mapred.mode，分为nonstrict，strict，默认是nonstrict
如果设置为strict，会对三种情况的语句在compile环节做过滤：
1. 笛卡尔积Join。这种情况由于没有指定reduce join key，所以只会启用一个reducer，数据量大时会造成性能瓶颈
|
1
2
3
4
5
6
7
8
9
10
|
// Use only 1 reducer in case of cartesian product
if
(reduceKeys.size() ==
0
) {
numReds =
1
;
// Cartesian product is not supported in strict mode
if
(conf.getVar(HiveConf.ConfVars.HIVEMAPREDMODE).equalsIgnoreCase(
"strict"
)) {
throw
new
SemanticException(ErrorMsg.NO_CARTESIAN_PRODUCT.getMsg());
}
}
|
2. order by后面不跟limit。order by会强制将reduce number设置成1，不加limit，会将所有数据sink到reduce端来做全排序。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
if
(sortExprs ==
null
) {
sortExprs = qb.getParseInfo().getOrderByForClause(dest);
if
(sortExprs !=
null
) {
assert
numReducers ==
1
;
// in strict mode, in the presence of order by, limit must be specified
Integer limit = qb.getParseInfo().getDestLimit(dest);
if
(conf.getVar(HiveConf.ConfVars.HIVEMAPREDMODE).equalsIgnoreCase(
"strict"
)
&& limit ==
null
) {
throw
new
SemanticException(generateErrorMessage(sortExprs,
ErrorMsg.NO_LIMIT_WITH_ORDERBY.getMsg()));
}
}
}
|
3. 读取的表是partitioned table，但没有指定partition predicate。
注：如果是多级分区表的话，只要出现任何一个就放行
|
1
2
3
4
5
6
7
8
9
10
|
// If the "strict" mode is on, we have to provide partition pruner for
// each table.
if
(
"strict"
.equalsIgnoreCase(HiveConf.getVar(conf,
HiveConf.ConfVars.HIVEMAPREDMODE))) {
if
(!hasColumnExpr(prunerExpr)) {
throw
new
SemanticException(ErrorMsg.NO_PARTITION_PREDICATE
.getMsg(
"for Alias \""
+ alias +
"\" Table \""
+ tab.getTableName() +
"\""
));
}
}
|
这三种case在数据量比较大的情况下都会造成生成低效的MR Job，影响执行时间和效率，不过直接抛出exception又感觉太forcefully了。
可以在一些非线上生产环境下的ad-hoc查询端中开启strict mode，比如hiveweb，运营工具。
Hive中的排序语法
ORDER BY
Hive中的ORDER BY语句和关系数据库中的sql语法相似。他会对查询结果做全局排序，这意味着所有的数据会传送到一个Reduce任务上，这样会导致在大数量的情况下，花费大量时间。
与数据库中 ORDER BY 的区别在于在模式下，必须指定 limit 否则执行会报错。
hive> set hive.mapred.mode=strict;
hive> select * from test order by id;
FAILED: SemanticException 1:28 In strict mode, if ORDER BY is specified, LIMIT must also be specified. Error encountered near token 'id'
例子：
hive> set hive.mapred.mode=unstrict;
hive> select * from test order BY id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 1 Cumulative CPU: 1.88 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 1 seconds 880 msec
OK
1 a
1 a
2 b
2 b
3 c
3 c
4 d
4 d
Time taken: 24.609 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了一个reduce进行全局排序。
SORT BY
SORT BY不是全局排序，其在数据进入reducer前完成排序，因此在有多个reduce任务情况下，SORT BY只能保证每个reduce的输出有序，而不能保证全局有序。
注意：SORT BY 不受 参数的影响
你可以通过设置的值来控制reduce的数，然后对reduce输出的结果做二次排序。
例子：
hive> set mapred.reduce.tasks=3;
hive> select * from test sort BY id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.48 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 480 msec
OK
1 a
2 b
3 c
4 d
2 b
3 c
4 d
1 a
Time taken: 29.574 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了三个reduce分别排序，最后的结果不是有序的。
DISTRIBUTE BY with SORT BY
DISTRIBUTE BY能够控制map的输出在reduce中如何划分。其可以按照指定的字段对数据进行划分到不同的输出reduce/文件中。
DISTRIBUTE BY和GROUP BY有点类似，DISTRIBUTE BY控制reduce如何处理数据，而SORT BY控制reduce中的数据如何排序。
注意：hive要求DISTRIBUTE BY语句出现在SORT BY语句之前。
例子：
hive> select * from test distribute BY id sort by id asc;
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.24 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 240 msec
OK
3 c
3 c
1 a
1 a
4 d
4 d
2 b
2 b
Time taken: 29.89 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了三个reduce分别排序，最后的结果不是有序的。
CLUSTER BY来代替
当DISTRIBUTE BY的字段和SORT BY的字段相同时，可以用CLUSTER BY来代替 DISTRIBUTE BY with SORT BY。
注意：CLUSTER BY不能添加desc或者asc。
例子：
hive> select * from test cluster by id asc;
FAILED: ParseException line 1:33 extraneous input 'asc' expecting EOF near '<EOF>'
hive> select * from test cluster by id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.58 sec HDFS Read: 305 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 580 msec
OK
3 c
3 c
1 a
1 a
4 d
4 d
2 b
2 b
Time taken: 30.646 seconds, Fetched: 8 row(s)
从上面的日志可以看到：启动了三个reduce分别排序，最后的结果不是有序的。
怎样让最后的结果是有序的呢？
可以这样做：
hive> select a.* from (select * from test cluster by id ) a order by a.id ;
MapReduce Jobs Launched:
Job 0: Map: 1 Reduce: 3 Cumulative CPU: 4.5 sec HDFS Read: 305 HDFS Write: 448 SUCCESS
Job 1: Map: 1 Reduce: 1 Cumulative CPU: 1.96 sec HDFS Read: 1232 HDFS Write: 32 SUCCESS
Total MapReduce CPU Time Spent: 6 seconds 460 msec
OK
1 a
1 a
2 b
2 b
3 c
3 c
4 d
4 d
Time taken: 118.261 seconds, Fetched: 8 row(s)
总结
- ORDER BY是全局排序，但在数据量大的情况下，花费时间会很长
- SORT BY是将reduce的单个输出进行排序，不能保证全局有序
- DISTRIBUTE BY可以按指定字段将数据划分到不同的reduce中
- 当DISTRIBUTE BY的字段和SORT BY的字段相同时，可以用CLUSTER BY来代替 DISTRIBUTE BY with SORT BY。
465
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
