Yes, the idea is almost the same -- LLAP daemons can accept tasks from different Tez AMs, whereas MR3 containers can accept tasks from different DAGs. A minor difference is that in the case of MR3, a single shared AM can manage multiple concurrent DAGs. As a result, there is no need to start a new AM for each Beeline connection.
Hive-LLAP on MR3 is currently under development, and will be released as part of Hive-MR3 0.2. In the meanwhile, let me test Hive-LLAP on Tez and Hive-MR3 1.0 for performance and report the result in the MR3 blog. --- Sungwoo On Thu, Apr 5, 2018 at 12:38 AM, Thai Bui <blquyt...@gmail.com> wrote: > It would be interesting to see how this compares to Hive LLAP on Tez. > Since the llap daemons contain a queue of tasks that is shared amongst many > Tez AMs, it could have similar characteristics to the way MR3 is sharing > the containers between the AMs. > > On Wed, Apr 4, 2018 at 10:06 AM Sungwoo Park <glap...@gmail.com> wrote: > >> Hello Hive users, >> >> I am pleased to announce MR3 and Hive-MR3. Please visit the following >> webpage for everything on MR3 and Hive-MR3: >> >> https://mr3.postech.ac.kr/ >> http://datamonad.com >> >> Here is a description of MR3 and Hive-MR3 from the webpage: >> >> MR3 is a new execution engine for Hadoop. Similar in spirit to Tez, it >> can be thought of as an enhancement of Tez with simpler design, better >> performance, and more features. MR3 is ready for production use as it >> supports all major features from Tez such as Kerberos-based security, >> authentication and authorization, fault-tolerance, and recovery. MR3 is >> implemented in Scala. >> >> Hive-MR3 is an extension of Hive that runs on top of MR3. In order to >> exploit new features in MR3, Hive-MR3 is built on a modified backend of >> Hive. In comparison with Hive-on-Tez, Hive-MR3 generally runs faster for >> sequential queries by virtue of the simple architectual design of >> ApplicationMaster in MR3. In particular, it makes a better utilization of >> computing resources and thus yields a higher throughput for concurrent >> queries. >> >> --- Sungwoo Park >> >> -- > Thai >
