hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <>
Subject [jira] [Commented] (HIVE-4660) Let there be Tez
Date Wed, 24 Jul 2013 15:23:51 GMT


Edward Capriolo commented on HIVE-4660:

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:

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:
>             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:
> 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:

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:

View raw message