tez-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bikas Saha <bi...@hortonworks.com>
Subject RE: Distributed Cache in Tez
Date Fri, 26 Jul 2013 22:58:06 GMT
With local resources used in the Tez API, we have the choice about being
efficient and using specific resources for specific vertices. So if an
enormous look up table is used for a vertex1 then it can be added to only
that vertex. I think dist-cache ends up making all resources available to
all tasks even if they don't need them.

Hitesh, the archive jars is an interesting point. Without a
YARN/LocalResource-NM/Tez support to help edit the classpath (and even
notify users that they need to do something to make that archive available
via the classpath) its hard for users to do the right thing.


-----Original Message-----
From: Hitesh Shah [mailto:hitesh@apache.org]
Sent: Friday, July 26, 2013 3:03 PM
To: dev@tez.incubator.apache.org
Subject: Re: Distributed Cache in Tez

Hi Achal,

Yes you are right - I forgot to mention that bit. Distributed cache does
also modify the classpath to account for the jars being distributed.

One thing to note is that LocalResources supports 2 modes - file and
archive mode. In case of file mode, the jar will be localized as a single
file. In archive mode, the jar will be unzipped. By default, Tez adds
PWD/* to the classpath of a task so all local resources in file mode are
accounted for. For archive mode, the onus is on the user to modify the
classpath as needed to ensure that all the paths of the unzipped structure
are accounted for in the classpath for the task.

Thanks for raising these questions. If you see something lacking in the
javadocs, would you mind filing jiras so that we can address such issues.

-- Hitesh

On Jul 26, 2013, at 2:22 PM, Achal Soni wrote:

> Hi Hitesh,
> I think the DistributedCache name is very misleading because it really
> doesn't act much like a cache, for the reasons you stated above.The
> management of these additional fies and jars I think is a different
> discussion and definitely out of the scope of Tez. I agree that
> clients like Pig and Hive should be more mindful and perhaps develop
> systems for managing these files.
> I think that the LocalResources way is perfectly suitable. What I
> don't quite get is, is there any difference between DistributedCache
> and what it offers to the client as opposed to LocalResources. For
> example, Pig needs to distribute jars to the nodes. These need to be
added to the classpath.
> Does DC do that which the LR way won't?
> Thanks,
> Achal
> On Fri, Jul 26, 2013 at 2:11 PM, Hitesh Shah <hitesh@apache.org> wrote:
>> Hi Achal
>> We want to force folks to use local resources as it makes the users
>> more aware of how to use the cache.
>> Pushing local files to distributed cache for each job does not bring
>> any performance improvement. All it does is ensure that the local
>> files are now available on the remote node in the cluster where the
>> task is run. It also requires uploading the local files to hdfs each
>> and every time. This also means that given that there is a new hdfs
>> file each and every time, the "cache" on the remote node can be used.
>> With local resources, the user is making a conscious choice of first
>> uploading a local file to hdfs and then adding the hdfs file as a
>> local resource for the remote task. As long as the file on hdfs
>> remains unchanged, the remote node will re-use the local copy ( local
>> copy is downloaded once the first time around from hdfs ). With this
>> in mind, a user will be more mindful of when to upload a local file
>> and how to re-use hdfs-based resources across jobs. A user would now
>> realize that the penalty of uploading a non-changing jar for each and
>> every job ( as was done by hive earlier ).
>> In the case of helpers, are you looking at a helper method for
>> creating local resources out of files that change for each and every
>> Furthermore, there is a question of management of these uploaded files?
>> When should they be deleted - after the job completes? If yes, is the
>> AM supposed to delete them or the client? What if a client does not
>> hang around for the job to complete or is killed before it can clean
>> up the files?
>> thanks
>> -- Hitesh
>> On Jul 26, 2013, at 1:59 PM, Achal Soni wrote:
>>> Hey all,
>>> Have any thoughts be given to distributed cache in Tez? It seems
>>> that it
>> is
>>> almost as simple as adding local files to vertices via YARN.
>>> Is there any insight into how DistributedCache differs from adding
>>> LocalResources? Should I be looking into MRApps for helper methods?
>>> Thanks!
>>> Achal

View raw message