LLAP 起源

说workload management 就要先说LLAP。

LLAP 存在的必要性，为了解决什么问题才被设计出来的呢？

这东西的由来其实是因为 每次一个查询被提交到hive server，然后都会去启动一个 Yarn Application。当一个查询很大的时候，启动yarn 应用的代价就被均摊到长时间的任务时间中了，但是当是一个小查询 比如BI 的交互式查询时，这个代价就很重了，一个查询总共才几秒，但是提交到yarn 就需要好几秒，几乎不可接受！

下图是一个 hive query的流程。

在LLAP之前也有feature 试图解决这个问题，比如 “Container re-use”或“container prewarm” 一个query 跑完后不释放这个查询分配的container，然后后续的查询可以重用这个container。但是这会带来新的问题，当用户不执行查询时，或者是跑别的查询时，这个container就得不到释放，并且也不能被其他的查询使用，造成资源的浪费（container的状态在不同用户直接也不能共享）。

这之后LLAP出世，一个在Yarn 之上的共享的可重用的查询层(符合java的架构设计原理😂遇事不绝就加一个抽象层)。

LLAP 一般叫 Live Long And Process 长期存活的进程，因为是一个长驻Yarn的应用，也叫做 low-latency analytical processing 。第二个名字更能反应其设计意图和场景，就是低延迟分析型查询。

LLAP 启动时会启动一个长时间运行的 Yarn 程序，可配置其所占用的最小和最大CPU，RAM。

根据在一定时间内运行的查询数量和查询的数据量，可以动态的扩容缩容其占用的 CPU 和 RAM。这样小的查询不需要提前申请资源就可以运行，降低了资源调度的耗时代价。对于大查询会扩容则不会浪费太多的资源。

LLAP 的整体架构图如下

组件介绍：

Hive Interactive Server：提供连接到Hive LLAP的JDBC 借口的 Thrift server 。

Slider AM : 一个 Apache Slider 应用主要钥匙负责启动，监控，维护LLAP 进程的。

TEZ AM query coordinator ：TEZ AM 接受query 请求 并在LLAP 的Executors中执行。

LLAP daemons : 提供对外缓存，JIT 优化，消除大多数情况的启动开销，提供部分sql 算子执行的容器（如果是非常大的的QL 还会走Yarn 的那一套）。属于worker 节点上常驻yarn 的进程。

从图上可以看出，LLAP 提供Tez executor的执行容器，同时提供堆外缓存，针对那分析型的大量交互式查询，缓存热数据，避免每次都去磁盘拉取数据，可以显著提升加速效果，类似大数据的分布式内存缓存框架Alluxio。 对变化周期长，数据量不大的热数据的查询分析这种场景可以达到准实时的效果！

稍微说下Tez 和 LLAP的关系

Tez 是一个设计思想类似spark的DAG 执行引擎，把Map Reduce 细分成了更多的算子。

Tez 可以执行在普通的container或者LLAP上。

Tez vs Tez + LLAP 对比:

workload management

workload 是什么？ 是为了解决什么问题？

回到正题 workload management，其实就是一个LLAP中的负载和资源管理模块

当我们有很多部门或者租户时，一般会根据任务的重要性优先级，根据业务的特性，或者一些临时紧急需求在 Yarn 上分出不同的资源队列来。当租户多，部门多，各自对资源的数量和时效需求不同时，yarn 的资源队列的配置就显得很复杂，并且不够灵活了。

而hive的 workload management 就是为了解决这个问题。

这之后就可以使用yarn 为hive 配置大略的几个队列，然后具体更细分和复杂的资源负载管理策略交给 LLAP的 workload management去做，效率和易用性，灵活性会提升很多。

workload management 的资源管理使用的是 resource plan ，相当于一个资源策略。并且启用或者关闭一个 resource plan 并不会影响正在执行的 query。

我们可以根据集群和业务的复杂情况随时切换不同的 resource plan，比如夜间ETL的时候一般数据量占用带宽都很多，提供Aplan, 白天短平快的交互式分析很多，可以切换另一个配置的 resource plan。

resource plan 可以包含一个或多个查询池，查询路由和触发器：

查询池与LLAP群集进程和池中的查询共享资源，并设置最大并发查询数。

查询路由根据指定的因素（例如用户名，组或应用程序）将传入的查询路由到池。

触发器基于Apache Hadoop，Tez和Hive计数器所代表的查询指标来启动操作，例如终止池中的查询或群集中运行的所有查询。

下图描述了一个简单的resource plan。第一个图显示了为高流量时段设计的资源计划，第二个图为低流量时段设计了资源计划。

高流量

低流量

参考链接：

https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.5/hive-workload/content/hive_workload_management.html

https://medium.com/sqooba/hive-llap-brings-interactive-sql-queries-on-hadoop-8f876ef116d8

https://community.cloudera.com/t5/Community-Articles/Hive-LLAP-deep-dive/ta-p/248893