Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce, mail # user - Simplifying MapReduce API


Copy link to this message
-
Re: Simplifying MapReduce API
Shahab Yunus 2013-08-27, 15:48
For starters (experts might have more complex reasons), what if your
respective map and reduce logic becomes complex enough to demand separate
classes? Why tie the clients to implement both by moving these in one Job
interface. In the current design you can always implement both (map and
reduce) interfaces if your logic is simple enough and go the other route,
of separate classes if that is required. I think it is more flexible this
way (you can always build up from and on top of granular design, rather
than other way around.)

I hope I understood your concern correctly...

Regards,
Shahab
On Tue, Aug 27, 2013 at 11:35 AM, Andrew Pennebaker
<[EMAIL PROTECTED]>wrote:

> There seems to be an abundance of boilerplate patterns in MapReduce:
>
> * Write a class extending Map (1), implementing Mapper (2), with a map
> method (3)
> * Write a class extending Reduce (4), implementing Reducer (5), with a
> reduce method (6)
>
> Could we achieve the same behavior with a single Job interface requiring
> map() and reduce() methods?
>