[
https://issues.apache.org/jira/browse/PIG-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779238#action_12779238
]
Olga Natkovich commented on PIG-872:
------------------------------------
Patch looks good. A couple of comments:
(1) Looks like the newly added test just have a plain replicated join. I think
this is already covered in TestFRJoin.java.
(2) JobControlCompiler.java" 943 lines: the comment says that the fragmented
input is usually null and that it is the first one. Would it be more clear if
we just started with the second file and did not have to check for null every
time since null in any other position should be treated as error.
> use distributed cache for the replicated data set in FR join
> ------------------------------------------------------------
>
> Key: PIG-872
> URL: https://issues.apache.org/jira/browse/PIG-872
> Project: Pig
> Issue Type: Improvement
> Reporter: Olga Natkovich
> Assignee: Sriranjan Manjunath
> Attachments: PIG_872.patch
>
>
> Currently, the replicated file is read directly from DFS by all maps. If the
> number of the concurrent maps is huge, we can overwhelm the NameNode with
> open calls.
> Using distributed cache will address the issue and might also give a
> performance boost since the file will be copied locally once and the reused
> by all tasks running on the same machine.
> The basic approach would be to use cacheArchive to place the file into the
> cache on the frontend and on the backend, the tasks would need to refer to
> the data using path from the cache.
> Note that cacheArchive does not work in Hadoop local mode. (Not a problem for
> us right now as we don't use it.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
