[ 
https://issues.apache.org/jira/browse/TEZ-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842816#comment-16842816
 ] 

Oliver Draese commented on TEZ-4069:
------------------------------------

Hi [~jeagles],

the HostAffinitySplitLocationProvider is part of Hive:

[https://github.com/apache/hive/blob/9a10bc28bee5250c0f667c94a295706a44ed4d7e/ql/src/java/org/apache/hadoop/hive/ql/exec/tez/HostAffinitySplitLocationProvider.java#L82]

The calculation creates a copy of the split's path name together with start 
position, creates a MurMur3 hash over it, and then uses Hashing.consistentHash 
to create a consistent hash (to determine a particular Hive/LLAP node for it). 
So, there is some CPU involved in the Hive/LLAP scenario. About the memory 
costs: I am not sure that the patch is adding significant memory to the split 
grouper as the locations are already kept multiple times in memory (together 
with all split containers) anyway. 

Cheers.

Oliver

 

> Avoid repeated computation of preferred locations in split grouping.
> --------------------------------------------------------------------
>
>                 Key: TEZ-4069
>                 URL: https://issues.apache.org/jira/browse/TEZ-4069
>             Project: Apache Tez
>          Issue Type: Improvement
>    Affects Versions: 0.9.2
>            Reporter: Oliver Draese
>            Priority: Major
>         Attachments: TEZ-4069.1.patch, TEZ-4069.patch
>
>
> The TezSplitGrouper iterates through the list of splits multiple times, when 
> trying to group the splits (see getGroupedSplits). Each time, it asks the 
> locationProvider to return the array of preferred locations for the splits. 
> This has two side effects:
>  * generating the list of preferred locations can cause some CPU overhead 
> (i.e. calculating the consistent hash in HostAffinitySplitLocationProvider), 
> which can be avoided
>  * if the list of preferred location is changing between the different loops 
> of getGroupedSplits, we might encounter a NullPointerException. This happens 
> if a new location appears, that was not part of the initial set of locations 
> when populating the distinctLocations map.
> The getGroupedSplits should query the preferred locations only once (for each 
> split) via the location provider and then memorize these instead of asking 
> the location provider repeatedly.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to