hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (Jira)" <j...@apache.org>
Subject [jira] [Work logged] (HIVE-23880) Bloom filters can be merged in a parallel way in VectorUDAFBloomFilterMerge
Date Wed, 26 Aug 2020 12:25:00 GMT

     [ https://issues.apache.org/jira/browse/HIVE-23880?focusedWorklogId=474785&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-474785
]

ASF GitHub Bot logged work on HIVE-23880:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 26/Aug/20 12:24
            Start Date: 26/Aug/20 12:24
    Worklog Time Spent: 10m 
      Work Description: abstractdog closed pull request #1280:
URL: https://github.com/apache/hive/pull/1280


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 474785)
    Time Spent: 8.5h  (was: 8h 20m)

> Bloom filters can be merged in a parallel way in VectorUDAFBloomFilterMerge
> ---------------------------------------------------------------------------
>
>                 Key: HIVE-23880
>                 URL: https://issues.apache.org/jira/browse/HIVE-23880
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: László Bodor
>            Assignee: László Bodor
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: lipwig-output3605036885489193068.svg
>
>          Time Spent: 8.5h
>  Remaining Estimate: 0h
>
> Merging bloom filters in semijoin reduction can become the main bottleneck in case of
large number of source mapper tasks (~1000, Map 1 in below example) and a large amount of
expected entries (50M) in bloom filters.
> For example in TPCDS Q93:
> {code}
> select /*+ semi(store_returns, sr_item_sk, store_sales, 70000000)*/ ss_customer_sk
>             ,sum(act_sales) sumsales
>       from (select ss_item_sk
>                   ,ss_ticket_number
>                   ,ss_customer_sk
>                   ,case when sr_return_quantity is not null then (ss_quantity-sr_return_quantity)*ss_sales_price
>                                                             else (ss_quantity*ss_sales_price)
end act_sales
>             from store_sales left outer join store_returns on (sr_item_sk = ss_item_sk
>                                                                and sr_ticket_number =
ss_ticket_number)
>                 ,reason
>             where sr_reason_sk = r_reason_sk
>               and r_reason_desc = 'reason 66') t
>       group by ss_customer_sk
>       order by sumsales, ss_customer_sk
> limit 100;
> {code}
> On 10TB-30TB scale there is a chance that from 3-4 mins of query runtime 1-2 mins are
spent with merging bloom filters (Reducer 2), as in:  [^lipwig-output3605036885489193068.svg]

> {code}
> ----------------------------------------------------------------------------------------------
>         VERTICES      MODE        STATUS  TOTAL  COMPLETED  RUNNING  PENDING  FAILED
 KILLED
> ----------------------------------------------------------------------------------------------
> Map 3 ..........      llap     SUCCEEDED      1          1        0        0       0
      0
> Map 1 ..........      llap     SUCCEEDED   1263       1263        0        0       0
      0
> Reducer 2             llap       RUNNING      1          0        1        0       0
      0
> Map 4                 llap       RUNNING   6154          0      207     5947       0
      0
> Reducer 5             llap        INITED     43          0        0       43       0
      0
> Reducer 6             llap        INITED      1          0        0        1       0
      0
> ----------------------------------------------------------------------------------------------
> VERTICES: 02/06  [====>>----------------------] 16%   ELAPSED TIME: 149.98 s
> ----------------------------------------------------------------------------------------------
> {code}
> For example, 70M entries in bloom filter leads to a 436 465 696 bits, so merging 1263
bloom filters means running ~ 1263 * 436 465 696 bitwise OR operation, which is very hot codepath,
but can be parallelized.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message