I have changes jobs 3 times since tez was introduced. It is a true waste of compute resources and time that it was never patched in. So I either have to waste my time patching it in, waste my time running a side deployment, or not installing it and waste money having queries run longer on mr/spark engine.
Imagine how much compute hours have been lost world wide. On Tuesday, April 16, 2019, Manoj Murumkar <manoj.murum...@gmail.com> wrote: > If we install our own build of Hive, we'll be out of support from CDH. > > Tez is not supported anyway and we're not touching any CDH bits, so it's > not a big issue to have our own build of Tez engine. > > > On Apr 15, 2019, at 9:20 PM, Gopal Vijayaraghavan <gop...@apache.org> > wrote: > > > > > > Hi, > > > >>> However, we have built Tez on CDH and it runs just fine. > > > > Down that path you'll also need to deploy a slightly newer version of > Hive as well, because Hive 1.1 is a bit ancient & has known bugs with the > tez planner code. > > > > You effectively end up building the hortonworks/hive-release builds, by > undoing the non-htrace tracing impl & applying the htrace one back etc. > > > >> Lol. I was hoping that the merger would unblock the "saltyness". > > > > Historically, I've unofficially supported folks using Tez on CDH in prod > (assuming they buy me enough coffee), though I might have discontinue that. > > > > https://github.com/t3rmin4t0r/tez-autobuild/blob/llap/ > vendor-repos.xml#L11 > > > > Cheers, > > Gopal > > > > > -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
