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

Edward Capriolo commented on HIVE-4660:
---------------------------------------

{quote}
We’ve initially investigated to add Tez as a simple shim option to the code 
base. This didn’t work out mostly because Tez’ API is very different from the 
MR api. It does not make much sense to move the entire “execute” infrastructure 
to the shim layer. That would require large code changes with little benefit. 
Instead there will be separate “Task” implementations for MR and TEZ and hive 
will decide at runtime which implementation to use.

We’re planning to have two packages:
org.apache.hadoop.hive.ql.exec.mr
org.apache.hadoop.hive.ql.exec.tez
{quote}

Can you please go into some detail here? My larger concern is hive having 2x of 
everything, and then doing it in such a way that another integration will 
involve 3x of everything. What approximate percentage of the exec package will 
need to be duplicated? Worried about hive codebase having to many "silos's".

                
> Let there be Tez
> ----------------
>
>                 Key: HIVE-4660
>                 URL: https://issues.apache.org/jira/browse/HIVE-4660
>             Project: Hive
>          Issue Type: New Feature
>            Reporter: Gunther Hagleitner
>            Assignee: Gunther Hagleitner
>
> Tez is a new application framework built on Hadoop Yarn that can execute 
> complex directed acyclic graphs of general data processing tasks. Here's the 
> project's page: http://incubator.apache.org/projects/tez.html
> The interesting thing about Tez from Hive's perspective is that it will over 
> time allow us to overcome inefficiencies in query processing due to having to 
> express every algorithm in the map-reduce paradigm.
> The barrier to entry is pretty low as well: Tez can actually run unmodified 
> MR jobs; But as a first step we can without much trouble start using more of 
> Tez' features by taking advantage of the MRR pattern. 
> MRR simply means that there can be any number of reduce stages following a 
> single map stage - without having to write intermediate results to HDFS and 
> re-read them in a new job. This is common when queries require multiple 
> shuffles on keys without correlation (e.g.: join - grp by - window function - 
> order by)
> For more details see the design doc here: 
> https://cwiki.apache.org/confluence/display/Hive/Hive+on+Tez

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to