hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-10349) overflow in stats
Date Wed, 15 Apr 2015 22:25:59 GMT

     [ https://issues.apache.org/jira/browse/HIVE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sergey Shelukhin updated HIVE-10349:
------------------------------------
    Description: 
Discovered while running q17 in LLAP.

{noformat}
        Reducer 2 
            Execution mode: llap
            Reduce Operator Tree:
              Merge Join Operator
                condition map:
                     Inner Join 0 to 1
                keys:
                  0 _col28 (type: int), _col27 (type: int)
                  1 cs_bill_customer_sk (type: int), cs_item_sk (type: int)
                outputColumnNames: _col1, _col2, _col6, _col8, _col9, _col22, _col27, _col28,
_col34, _col35, _col45, _col51, _col63, _col66, _col82
                Statistics: Num rows: 1047651367827495040 Data size: 9223372036854775807 Basic
stats: COMPLETE Column stats: PARTIAL
                Map Join Operator
                  condition map:
                       Inner Join 0 to 1
                  keys:
                    0 _col22 (type: int)
                    1 d_date_sk (type: int)
                  outputColumnNames: _col1, _col2, _col6, _col8, _col9, _col22, _col27, _col28,
_col34, _col35, _col45, _col51, _col63, _col66, _col82, _col86
                  input vertices:
                    1 Map 7
                  Statistics: Num rows: 1152416529588199552 Data size: 9223372036854775807
Basic stats: COMPLETE Column stats: NONE

{noformat}

Data size overflows and row count also looks wrong. I wonder if this is why it generates 1009
reducers for this stage on 6 machines

  was:
Discovered while running q17 in LLAP.

{noformat}
        Reducer 2 
            Execution mode: llap
            Reduce Operator Tree:
              Merge Join Operator
                condition map:
                     Inner Join 0 to 1
                keys:
                  0 _col28 (type: int), _col27 (type: int)
                  1 cs_bill_customer_sk (type: int), cs_item_sk (type: int)
                outputColumnNames: _col1, _col2, _col6, _col8, _col9, _col22, _col27, _col28,
_col34, _col35, _col45, _col51, _col63, _col66, _col82
                Statistics: Num rows: 1047651367827495040 Data size: 9223372036854775807 Basic
stats: COMPLETE Column stats: PARTIAL
                Map Join Operator
                  condition map:
                       Inner Join 0 to 1
                  keys:
                    0 _col22 (type: int)
                    1 d_date_sk (type: int)
                  outputColumnNames: _col1, _col2, _col6, _col8, _col9, _col22, _col27, _col28,
_col34, _col35, _col45, _col51, _col63, _col66, _col82, _col86
                  input vertices:
                    1 Map 7
                  Statistics: Num rows: 1152416529588199552 Data size: 9223372036854775807
Basic stats: COMPLETE Column stats: NONE

{noformat}

Data size overflows and row count also looks wrong. I wonder if this is why it generates 1009
reducers for this stage on 6 containers


> overflow in stats
> -----------------
>
>                 Key: HIVE-10349
>                 URL: https://issues.apache.org/jira/browse/HIVE-10349
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Sergey Shelukhin
>            Assignee: Prasanth Jayachandran
>
> Discovered while running q17 in LLAP.
> {noformat}
>         Reducer 2 
>             Execution mode: llap
>             Reduce Operator Tree:
>               Merge Join Operator
>                 condition map:
>                      Inner Join 0 to 1
>                 keys:
>                   0 _col28 (type: int), _col27 (type: int)
>                   1 cs_bill_customer_sk (type: int), cs_item_sk (type: int)
>                 outputColumnNames: _col1, _col2, _col6, _col8, _col9, _col22, _col27,
_col28, _col34, _col35, _col45, _col51, _col63, _col66, _col82
>                 Statistics: Num rows: 1047651367827495040 Data size: 9223372036854775807
Basic stats: COMPLETE Column stats: PARTIAL
>                 Map Join Operator
>                   condition map:
>                        Inner Join 0 to 1
>                   keys:
>                     0 _col22 (type: int)
>                     1 d_date_sk (type: int)
>                   outputColumnNames: _col1, _col2, _col6, _col8, _col9, _col22, _col27,
_col28, _col34, _col35, _col45, _col51, _col63, _col66, _col82, _col86
>                   input vertices:
>                     1 Map 7
>                   Statistics: Num rows: 1152416529588199552 Data size: 9223372036854775807
Basic stats: COMPLETE Column stats: NONE
> {noformat}
> Data size overflows and row count also looks wrong. I wonder if this is why it generates
1009 reducers for this stage on 6 machines



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message