hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suraj Menon <surajsme...@apache.org>
Subject Re: Issues about Partitioning and Record converter
Date Sun, 05 May 2013 22:11:28 GMT
I am still -1 if this means our graph module can work only on sequential
file format.
Please note that you can set record converter to null and make changes to
loadVertices for what you desire here.

If we came to this design, because TextInputFormat is inefficient, would
this work for Avro or Thrift input format?
Please let me know before this is changed, I would like to work on a
separate branch.
You may proceed as you wish.

Regards,
Suraj


On Sun, May 5, 2013 at 4:09 PM, Edward J. Yoon <edwardyoon@apache.org>wrote:

> I think 'record converter' should be removed. It's not good idea.
> Moreover, it's unnecessarily complex. To keep vertex input reader, we
> can move related classes into common module.
>
> Let's go with my original plan.
>
> On Sat, May 4, 2013 at 9:32 AM, Edward J. Yoon <edwardyoon@apache.org>
> wrote:
> > Hi all,
> >
> > I'm reading our old discussions about record converter, superstep
> > injection, and common module:
> >
> > - http://markmail.org/message/ol32pp2ixfazcxfc
> > - http://markmail.org/message/xwtmfdrag34g5xc4
> >
> > To clarify goals and objectives:
> >
> > 1. A parallel input partition is necessary for obtaining scalability
> > and elasticity of a Bulk Synchronous Parallel processing (It's not a
> > memory issue, or Disk/Spilling Queue, or HAMA-644. Please don't
> > shake).
> > 2. Input partitioning should be handled at BSP framework level, and it
> > is for every Hama jobs, not only for Graph jobs.
> > 3. Unnecessary I/O Overhead need to be avoided, and NoSQLs input also
> > should be considered.
> >
> > The current problem is that every input of graph jobs should be
> > rewritten on HDFS. If you have a good idea, Please let me know.
> >
> > --
> > Best Regards, Edward J. Yoon
> > @eddieyoon
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message