[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361967#comment-16361967
]
Zoltan Haindrich commented on HIVE-14285:
-
sorry; I've misunderstood...yes they are executed in parallel; and I think
there is an option to even execute tasks in parallel(EXECPARALLEL ; but it
seems thats probably mr related)
afaik: the vertices which are independent may run in parallel (not just map
phases) - as long as the dag dependencies are satisifed
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361692#comment-16361692
]
liyunzhang commented on HIVE-14285:
---
[~kgyrtkirk]:
{code}
I'm starting to remember...I think prior to this patch the order was the
same...I just needed to flatten the keys if they were more complex objects
(like: Path)
{code}
yes, prior to the patch， it also uses TreeMap and TreeMap will order the key.
Your patch does not modify the order.
Here my *question* is whether the Maps in the same Stage are executed parallel
in the runtime?
in following example, {{Ｍap1}} and {{Map4}} are both in the Stage-1, in
runtime , they are starting together so we don't care which({{Map1}} or
{{Map4}}) is first in the explain.
{code}
STAGE DEPENDENCIES:
Stage-1 is a root stage
Stage-0 depends on stages: Stage-1
STAGE PLANS:
Stage: Stage-1
Tez
A masked pattern was here
Edges:
Reducer 2 <- Map 1 (SIMPLE_EDGE), Map 4 (SIMPLE_EDGE)
Reducer 3 <- Reducer 2 (CUSTOM_SIMPLE_EDGE)
A masked pattern was here
Vertices:
Map 1
Map Operator Tree:
TableScan
alias: srcpart
filterExpr: ds is not null (type: boolean)
Statistics: Num rows: 2000 Data size: 389248 Basic stats:
COMPLETE Column stats: COMPLETE
Select Operator
expressions: ds (type: string)
outputColumnNames: _col0
Statistics: Num rows: 2000 Data size: 368000 Basic stats:
COMPLETE Column stats: COMPLETE
Reduce Output Operator
key expressions: _col0 (type: string)
sort order: +
Map-reduce partition columns: _col0 (type: string)
Statistics: Num rows: 2000 Data size: 368000 Basic stats:
COMPLETE Column stats: COMPLETE
Execution mode: llap
LLAP IO: no inputs
Map 4
Map Operator Tree:
TableScan
alias: srcpart_date
filterExpr: ((date = '2008-04-08') and ds is not null) (type:
boolean)
Statistics: Num rows: 2 Data size: 736 Basic stats: COMPLETE
Column stats: NONE
Filter Operator
predicate: ((date = '2008-04-08') and ds is not null)
(type: boolean)
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Select Operator
expressions: ds (type: string)
outputColumnNames: _col0
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Reduce Output Operator
key expressions: _col0 (type: string)
sort order: +
Map-reduce partition columns: _col0 (type: string)
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Select Operator
expressions: _col0 (type: string)
outputColumnNames: _col0
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Group By Operator
keys: _col0 (type: string)
mode: hash
outputColumnNames: _col0
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Dynamic Partitioning Event Operator
Target column: ds (string)
Target Input: srcpart
Partition key expr: ds
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Target Vertex: Map 1
Execution mode: llap
LLAP IO: no inputs
Reducer 2
Execution mode: llap
Reduce Operator Tree:
Merge Join Operator
condition map:
Inner Join 0 to 1
keys:
0 _col0 (type: string)
1 _col0 (type: string)
Statistics: Num rows: 2200 Data size: 404800 Basic stats:
COMPLETE Column stats: NONE
Group By Operator
aggregations: count()
mode: hash
outputColumnNames: _col0
Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE
Column stats: NONE
Reduce Output Operator
sort order:
Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE
Column stats: NONE
value expressions: _col0
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360734#comment-16360734
]
Zoltan Haindrich commented on HIVE-14285:
-
I'm starting to remember...I think prior to this patch the order was the
same...I just needed to flatten the keys if they were more complex objects
(like: Path)
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360729#comment-16360729
]
Zoltan Haindrich commented on HIVE-14285:
-
[~kellyzly] it would probably make sense to change the order...iirc before this
patch the ordering was dependent on the jvm hasmap order...so I would prefer to
have something which has the ordering defined somehow (eg: not HashMap).
q.out-s has these contents in there; and sometimes they are just changing
places; and make comparision problematic...
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360203#comment-16360203
]
liyunzhang commented on HIVE-14285:
---
[~kgyrtkirk]: I want to ask a question that the works in 1 Stage(like Map1,
Map4 in Stage-1) are executed in parallel although Map4 is after Map1 in
explain.
{code}
STAGE DEPENDENCIES:
Stage-1 is a root stage
Stage-0 depends on stages: Stage-1
STAGE PLANS:
Stage: Stage-1
Tez
A masked pattern was here
Edges:
Reducer 2 <- Map 1 (SIMPLE_EDGE), Map 4 (SIMPLE_EDGE)
Reducer 3 <- Reducer 2 (CUSTOM_SIMPLE_EDGE)
A masked pattern was here
Vertices:
Map 1
Map Operator Tree:
TableScan
alias: srcpart
filterExpr: ds is not null (type: boolean)
Statistics: Num rows: 2000 Data size: 389248 Basic stats:
COMPLETE Column stats: COMPLETE
Select Operator
expressions: ds (type: string)
outputColumnNames: _col0
Statistics: Num rows: 2000 Data size: 368000 Basic stats:
COMPLETE Column stats: COMPLETE
Reduce Output Operator
key expressions: _col0 (type: string)
sort order: +
Map-reduce partition columns: _col0 (type: string)
Statistics: Num rows: 2000 Data size: 368000 Basic stats:
COMPLETE Column stats: COMPLETE
Execution mode: llap
LLAP IO: no inputs
Map 4
Map Operator Tree:
TableScan
alias: srcpart_date
filterExpr: ((date = '2008-04-08') and ds is not null) (type:
boolean)
Statistics: Num rows: 2 Data size: 736 Basic stats: COMPLETE
Column stats: NONE
Filter Operator
predicate: ((date = '2008-04-08') and ds is not null)
(type: boolean)
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Select Operator
expressions: ds (type: string)
outputColumnNames: _col0
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Reduce Output Operator
key expressions: _col0 (type: string)
sort order: +
Map-reduce partition columns: _col0 (type: string)
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Select Operator
expressions: _col0 (type: string)
outputColumnNames: _col0
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Group By Operator
keys: _col0 (type: string)
mode: hash
outputColumnNames: _col0
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Dynamic Partitioning Event Operator
Target column: ds (string)
Target Input: srcpart
Partition key expr: ds
Statistics: Num rows: 2 Data size: 736 Basic stats:
COMPLETE Column stats: NONE
Target Vertex: Map 1
Execution mode: llap
LLAP IO: no inputs
Reducer 2
Execution mode: llap
Reduce Operator Tree:
Merge Join Operator
condition map:
Inner Join 0 to 1
keys:
0 _col0 (type: string)
1 _col0 (type: string)
Statistics: Num rows: 2200 Data size: 404800 Basic stats:
COMPLETE Column stats: NONE
Group By Operator
aggregations: count()
mode: hash
outputColumnNames: _col0
Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE
Column stats: NONE
Reduce Output Operator
sort order:
Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE
Column stats: NONE
value expressions: _col0 (type: bigint)
Reducer 3
Execution mode: llap
Reduce Operator Tree:
Group By Operator
aggregations: count(VALUE._col0)
mode: mergepartial
outputColumnNames: _col0
Statistics: Num rows: 1 Data size: 8 Basic stats: COMPLETE
Column stats: NONE
File Output Operator
compressed: false
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359784#comment-16359784
]
liyunzhang commented on HIVE-14285:
---
[~kgyrtkirk]: I found some problem with {{ExplainTask#getBasictypeKeyedMap}}.
It converts original input(type Map) to a treeMap which will order by the key.
Like an example, the original map
{code}
"Map 6" ->
"Reducer 7" ->
"Reducer 9" ->
"Map 10" ->
"Reducer 11" ->
{code}
After this function, it will be
{code}
"Map 10" ->
"Map 6" ->
"Reducer 11" ->
"Reducer 7" ->
"Reducer 9" ->
{code}
{{Map 10}} is in front of {{Map6}} because "Map 10" is small than "Map 6". But
actually {{Map6}} is executed first then {{Map10}}. It maybe confused in
explain. Here I want to ask whether we don't care the order in explain is
different from execution. If we don't care, it is ok now. If the order of
explain must be same with execution, we can refactor
{{ExplainTask#getBasictypeKeyedMap}}
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15391162#comment-15391162
]
Ashutosh Chauhan commented on HIVE-14285:
-
No worries. On to the next bug :)
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Fix For: 2.2.0
>
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15391158#comment-15391158
]
Zoltan Haindrich commented on HIVE-14285:
-
[~ashutoshc], thank you for adding this change...sorry for being slow with the
qtest updates...i've just got the results - but now i noticed that you have
taken care all of them - and resolved the ticket ;)
thank you! :)
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Fix For: 2.2.0
>
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390795#comment-15390795
]
Ashutosh Chauhan commented on HIVE-14285:
-
+1
> Explain outputs: map-entry ordering of non-primitive objects.
> ---
>
> Key: HIVE-14285
> URL: https://issues.apache.org/jira/browse/HIVE-14285
> Project: Hive
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Minor
> Attachments: HIVE-14285.1.patch
>
>
> In HIVE-12244 I've left behind some ugly backward compatible getters with
> {{@Explain}} decorations to keep the qtests from breaking.
> There were heavy explain plan changes when I used {{Path}} objects as keys in
> {{@Explain}} marked methods.
> I've looked into the causes of this:
> * there is a {{TreeSet}} in there to keep all the keys in order.
> * but: {{org.apache.hadoop.fs.Path}} uses a different sort order (inherited
> from {{java.net.URI}} )...it sorts the paths using
> priorities:[schema,schemeSpecificPart,host,path,query,fragment]
> considering that the output is an explain result(possibly read by humans):
> i don't think this sophisticated sort order can be useful.
> {{ExplainTask#outputMap}} always calls toString() on the keys before using
> them...so the most painless solution would be to change all the keys inside
> the treeset to simple strings (in case it's not a primitive already); this
> would restore the original behaviour for me.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HIVE-14285) Explain outputs: map-entry ordering of non-primitive objects.
[
https://issues.apache.org/jira/browse/HIVE-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390789#comment-15390789
]
Hive QA commented on HIVE-14285:
Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12819626/HIVE-14285.1.patch
{color:green}SUCCESS:{color} +1 due to 1 test(s) being added or modified.
{color:red}ERROR:{color} -1 due to 54 failed/errored test(s), 10344 tests
executed
*Failed tests:*
{noformat}
TestMsgBusConnection - did not produce a TEST-*.xml file
org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver_acid_globallimit
org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver_list_bucket_dml_13
org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver_smb_mapjoin_17
org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver_stats_list_bucket
org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver_subquery_multiinsert
org.apache.hadoop.hive.cli.TestMiniTezCliDriver.testCliDriver_acid_globallimit
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_auto_join18
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_auto_join18_multi_distinct
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_auto_join27
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_auto_smb_mapjoin_14
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_cross_product_check_1
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_dynamic_rdd_cache
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby10
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby11
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby7_noskew_multi_single_reducer
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby_complex_types_multi_single_reducer
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby_cube1
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby_position
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby_rollup1
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby_sort_1_23
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_groupby_sort_skew_1_23
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_join18
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_join18_multi_distinct
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_join_cond_pushdown_2
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_join_cond_pushdown_4
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_join_merging
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_limit_pushdown
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_multi_insert_mixed
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_optimize_nullscan
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_ppd_join2
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_ppd_join3
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_ppd_join_filter
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_ptf
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_skewjoinopt1
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_skewjoinopt14
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_skewjoinopt15
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_skewjoinopt2
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_smb_mapjoin_17
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_smb_mapjoin_25
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_subquery_in
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_subquery_multiinsert
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_tez_join_tests
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_tez_joins_explain
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_union17
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_union25
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_union3
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_union31
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_union_remove_23
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_union_remove_6_subq
org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver_vectorized_ptf
org.apache.hadoop.hive.llap.daemon.impl.TestLlapTokenChecker.testCheckPermissions
org.apache.hadoop.hive.llap.daemon.impl.TestLlapTokenChecker.testGetToken
org.apache.hadoop.hive.metastore.TestMetaStoreMetrics.testConnections
{noformat}
Test results:
https://builds.apache.org/job/PreCommit-HIVE-MASTER-Build/612/testReport
Console output:
https://builds.apache.org/job/PreCommit-HIVE-MASTER-Build/612/console
Test logs:
http://ec2-204-236-174-241.us-west-1.compute.amazonaws.com/logs/PreCommit-HIVE-MASTER-Build-612/
Messages:
{noformat}
Executing org.apache.hive.ptest.execution.TestCheckPhase
