Hi Hitesh,
I think you took Prakash¹s question to be a statement.
What is being suggested here is not we drop support for all older hadoop
versions² - but is really ³switch to the same version² as every downstream
project.
Let me repeat - we are *NOT* dropping support for older hadoop versions,
Hi,
+1 here.
PIG Hive are JDK7 targetVersions.
https://github.com/apache/pig/blob/trunk/build.xml#L64
https://github.com/apache/hive/blob/master/pom.xml#L616
Flink Spark have JDK8 code in them via activation.
From earlier mails, I remember seeing only JDK7 bugs reported for Tez so
far.
+1 - I¹ve been testing this branch with Tez+Uber+External hybrid mode
execution.
Cheers,
Gopal
On 8/17/15, 3:19 PM, Siddharth Seth ss...@apache.org wrote:
Following up from the earlier note about merging the TEZ-2003 branch back
into master, this is a vote for the same.
Hi,
There is a way around this, because the data doesn¹t move by a Tez edge,
there¹s no reason to actually use an edge partitioner.
https://github.com/t3rmin4t0r/tpcds-partitioner/blob/master/src/main/java/o
rg/notmysock/tpcds/ParTable.java#L198
But that¹s the terminal Vertex case.
If you
Sreenath has a mock-ATS which accepts those .zip files.
https://github.com/sreenaths/mock-ats
Start that up and go to http://:8188/dagupload to upload the
zip files.
Caveat: unlike LevelDB it doesn't do de-dups, so uploading the same DAG
twice messes it up.
Cheers,
Gopal
On 10/14/15, 11:11
Verified signatures. Ran a couple of 200Gb and 1Tb scale workloads to
check.
+1.
Cheers,
Gopal
On 1/12/16, 6:49 PM, "Siddharth Seth" wrote:
>I have created a tez-0.8.2 release candidate (rc0).
>
>GIT source tag:
> Thanks Gopal. Does ORC conversion have to see the entire data before it can
> write output? My source table is fairly large (~70 TB) which I am trying to
> convert to ORC.
Only for partitioned/bucketed tables.
In case of partitioned tables, you do not want each task opening new files
> For instance I want to say that DataMovementEvent(s) from the tasks in the
> source vertex should be routed to the tasks in the destination vertex based
> on the fact whether the tasks are in the same rack or not (or for that matter
> use some other key to route events between the tasks in
> I have implemented/overriden routeCompositeDataMovementEventToDestination but
> it isn't getting called. I'm raising DataMovementEvents though (and not
> composite ones), so it might be expected?
I'm not sure if you're raising compose DMEs or not, so I'm speaking purely from
the point of
>I wanted to see if there has been additional work regarding:
>https://issues.apache.org/jira/browse/TEZ-1190
>That has not been published yet.
As far as I know, that patch + design has been abandoned.
There was a discussion about adding it without fundamentally changing the
DAGImpl
Hi,
Sounds good +1 - I see about 8 tickets with 0.10.0.
Cheers,
Gopal
On 7/18/18, 12:57 PM, "Eric Wohlstadter" wrote:
Hi all,
I'd like to propose a deadline of July 27th for work on tickets to be
included in the 0.10.0 release.
Please +1 or -1 this proposal by July
> The named vertex approach seems the right way to go here. We took the patch
> in the JIRA and applied it to our branch. After fixing bugs and some tweaks
> the prototype does work. The change however is pretty big and we want to
> contribute back this to the trunk.
>
> Are there any
+1
Cheers,
Gopal
On 4/12/18, 5:22 PM, "Eric Wohlstadter" wrote:
Just a friendly reminder that this vote is still open.
On Wed, Apr 11, 2018 at 6:33 AM, Jason Lowe wrote:
> There was a discussion thread that was started two
Gopal Vijayaraghavan created TEZ-4186:
-
Summary: Limits: Fix init order regression from TEZ-4155
Key: TEZ-4186
URL: https://issues.apache.org/jira/browse/TEZ-4186
Project: Apache Tez
14 matches
Mail list logo