Hi, > Looking at the resource usage Megabyte Millis(total container uptime * > allocatedMemory), it seems like Tez is at-par with Hadoop (0.59% worse). This > seems strange given that Tez is running for 2-3x lesser time. I'm trying to > understand why this is the case and I could use any ideas / suggestions that > folks might have.
The throughput of a workload is often not a framework thing - sometimes it is entirely IO driven. Once the workload is IO limited (or even CPU limited), any runtime benefit you get is actually from better scheduling or faster scheduling (i.e pipelining between stages). The framework code only matters when it is the bottleneck - with other bottlenecks, the expectation is that Tez will run at the same throughput but at better latency. > Is the Tez AM holding on to containers for a duration of time before starting > up tasks on them? This contributes around 5% of the MB_MILLIS in case of the > Tez run. Yes, it is waiting for confirmation to exit - I think that is 1 heartbeat. > Does anyone have suggestions what we could look into / explore? This is from my last visit to Twitter, I think twitter was building some sort of ordered serializers for .aggregateBy instead of using the Cascading defaults. The use of RawComparator which does an allocation was 3-5x slower for the sort operation - TEZ-1288 is the API which Hive takes advantage of. Scala somewhat locks you into allocating immutable objects in the inner loop, but for entirely byte-ordered keys, this works great. Cheers, Gopal
