hive2.0的LLAP特性

1.LLAP特性

得益于 Tez 和 Cost-based-optimization模型的推动，hive的特性有以下进步：

• Asynchronous spindle-aware IO
• Pre-fetching and caching of column chunks
• Multi-threaded JIT-friendly operator pipelines

LLAP：Low Latency Analytical Processing（低延迟分析处理），也可称作Live Long and Process。
LLAP是由==一个替代直接与HDFS DataNode交互的长久守护进程==和==一个紧密集成的DAG框架==组成。
与DataNode类似，LLAP守护进程也可以被其他应用程序使用，尤其是数据的关系视图比以文件为中心的处理更为重要。守护进程也可以通过其他数据处理框架作为构建块的可选API（例如InputFormat）打开。
最后，至少，细粒度的列级访问控制与这个模型是非常匹配的，而这种细粒度的访问控制是hive现在的主流诉求之一。

下图显示了使用LLAP的示例执行。 Tez AM协调整体执行。查询的初始阶段被推入LLAP。 在reduce阶段，大的shuffle在单独的容器中进行。 多个查询和应用程序可以同时访问LLAP。

2. 持久化进程

为了便于缓存和JIT优化，并且为了消除大部分的启动成本，守护进程将在群集上的工作节点上运行。 处理I / O，缓存和查询片段执行。

• 这些节点是无状态的。 对LLAP节点的任何请求都包含数据位置和元数据。 包括本地和远程的。
• 恢复/弹性。因为任何数据节点仍可用于处理输入数据的任何片段，故障恢复变得更简单。 因此，Tez AM可以轻易地重新运行集群上的故障碎片。
• 节点之间的通信。 LLAP节点能够共享数据（例如，获取分区，广播片段）。 Tez中也使用相同机制。

3.执行引擎

LLAP在现有的基于过程的Hive执行中工作，以保持Hive的可扩展性和多功能性。 它不会替代现有的执行模型，而是增强它。

• 守护进程是可选的。 Hive没有他们也可以工作，即使它们被部署和运行也能绕过它们。 语言特征相关的特征平衡被保留了。
• 外部协调和执行引擎。 LLAP不是执行引擎（如MapReduce或Tez）。 总体执行由所有的LLAP节点以及常规容器透明地由现有的Hive执行引擎（如Tez）进行调度和监视。 显然，LLAP的支持水平取决于每个执行引擎（从Tez开始）。 MapReduce暂不支持，但是以后可能会添加其他引擎。 如类似Pig框架也可以选择使用LLAP守护进程。
• 部分执行。 由LLAP守护程序执行的工作的结果可以构成Hive查询结果的一部分，也可以根据查询传递到外部Hive任务。
• 资源管理。 YARN仍然负责资源的管理和分配。 YARN容器委托模型用于允许将分配的资源传输到LLAP。 为了避免JVM内存设置的限制，缓存的数据保持在堆栈外，以及用于处理的大型缓冲区（例如，分组，连接）。 这样，守护进程可以使用少量内存，并且将根据工作负载分配额外的资源（即CPU和内存）。

4.查询片段执行

对于如上所述的部分执行，LLAP节点执行“查询片段”，例如过滤器，投影，数据转换，部分聚合，排序，分桶，hash joins/semi-joins等。仅在LLAP中接受Hive代码和UDF。 没有代码本地化，并且即时执行。 这是为了稳定和安全的原因。

• 并行执行。一个 LLAP节点允许并行执行来自不同查询和会话的多个查询片段。
• 接口。 用户可以通过客户端API直接访问LLAP节点。 他们能够通过面向记录的流来指定关系转换和读取数据。

5.I/O

该守护程序卸载I / O并将其从压缩格式转换为单独的线程。 数据在准备就绪时被传递到执行，因此可以处理以前的批次，同时准备下一批次。 数据以简单的RLE编码柱状格式传递到执行，该格式准备好进行向量化处理; 这也是缓存格式，旨在最大限度地减少I / O，缓存和执行之间的复制。
- 多种文件格式 。I / O和缓存取决于底层文件格式的一些知识（特别是如果要有效地完成）。 因此，与Vectorization工作类似，通过特定于每种格式的插件（ORC开始）将支持不同的文件格式。 此外，可以添加一个通用的，低效率的插件，可以支持任何Hive输入格式。 插件必须保留元数据并将原始数据转换为列块。
- 谓词和布隆过滤器。 如果支持的话，SARG和bloom过滤器被压缩到存储层。

6. 缓存

守护进程缓存输入文件的元数据以及数据。 即使对于当前未缓存的数据，也可以缓存元数据和索引信息。 元数据存储在Java对象的进程中; 缓存数据以I / O部分中描述的格式存储，并保持堆栈外（参见资源管理）。
- 驱逐政策。 驱逐策略适用于频繁（部分）表扫描的分析工作负载。 最初，使用像LRFU这样的简单策略。 该策略是可插拔的。
- 缓存粒度。 列块是缓存中数据的基本单元。 这实现了低开销处理和存储效率之间的折中。 块的粒度取决于特定的文件格式和执行引擎（向量化行批量大小，ORC条带等）。
自动创建一个布隆过滤器以提供动态运行时过滤。

7.工作负载管理

YARN用于为不同的工作负载获取资源。 一旦从特定工作负载的YARN获得资源（CPU，内存等），执行引擎可以选择将这些资源委派给LLAP，或者在单独进程中启动Hive执行程序。 通过YARN进行的资源执行具有确保节点不会被LLAP或其他容器过载的优点。 守护进程本身受到YARN的控制。

8.ACID 支持

LLAP可以感知事务处理。在将数据放入高速缓存之前执行delta文件的合并以产生表的某一状态。
多个版本是可能的，请求指定要使用哪个版本。 这样做有利于对于缓存数据进行异步合并，并且只有一次，从而避免了对操作员管道的打击。

9.安全

LLAP服务器是一个自然的地方，以比“每个文件”更细粒度的级别执行访问控制。 由于守护程序知道处理哪些列和记录，因此可以强制执行这些对象的策略。 这并不是为了取代目前的机制，而是要加强和打开它们到其他应用程序。

10.监控

LLAP监视的配置存储在resources.json，appConfig.json，metainfo.xml中，它们嵌入到Slider使用的templates.py中。
LLAP Monitor Daemon在YARN容器上运行，类似于LLAP守护进程，并在同一个端口上侦听。
LLAP Metrics Collection Server定期从所有LLAP守护程序收集JMX指标。
从集群中启动的Zookeeper服务器提取LLAP守护进程列表。