Hive LLAP概念透析

2022-05-11 08:58:28 浏览数 (1)

概览

由于社区近年来构建的各种功能和改进，包括 Tez 和基于成本的优化，Hive 的速度显着提高。 将 Hive 提升到一个新的水平需要以下内容：

  • 异步主轴感知 IO
  • 列块的预取和缓存
  • 多线程 JIT 友好的操作管道

LLAP 也称为 Live Long And Process，提供混合执行模型。 它由一个长期存在的守护进程组成，该守护进程取代了与 HDFS DataNode 的直接交互，以及一个紧密集成的基于 DAG 的框架。

缓存、预取、一些查询处理和访问控制等功能被移到守护进程中。 小/短查询主要由这个守护进程直接处理，而任何繁重的工作都将在标准 YARN 容器中执行。

与 DataNode 类似，LLAP 守护程序也可以被其他应用程序使用，特别是如果数据的关系视图优于以文件为中心的处理时。 守护进程还通过可选的 API（例如 InputFormat）开放，其他数据处理框架可以将其用作构建块。

最后但并非最不重要的一点是，细粒度的列级访问控制（Hive 主流采用的关键要求）非常适合此模型。

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

持续的守护进程

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

  • 这些节点是无状态的。 对 LLAP 节点的任何请求都包含数据位置和元数据。 它处理本地和远程位置； locality 是调用者的责任（YARN）。
  • 恢复/弹性。 由于任何数据节点仍可用于处理输入数据的任何片段，因此简化了故障和恢复。 因此，Tez AM 可以简单地在集群上重新运行失败的片段。
  • 节点之间的通信。 LLAP 节点能够共享数据（例如，获取分区、广播片段）。 这是通过 Tez 中使用的相同机制实现的。

执行引擎

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

守护程序是可选的。 Hive 可以在没有它们的情况下工作，并且即使它们已部署和运行也能够绕过它们。 保持与语言特征相关的特征对等。

  • 外部编排和执行引擎。 LLAP 不是执行引擎（如 MapReduce 或 Tez）。 整体执行由现有的 Hive 执行引擎（例如 Tez）在 LLAP 节点以及常规容器上透明地调度和监控。 显然，LLAP 的支持级别取决于每个单独的执行引擎（从 Tez 开始）。 未计划支持 MapReduce，但以后可能会添加其他引擎。 其他框架（如 Pig）也可以选择使用 LLAP 守护程序。
  • 部分执行。 LLAP 守护程序执行的工作的结果可以构成 Hive 查询结果的一部分，也可以传递给外部 Hive 任务，具体取决于查询。
  • 资源管理。 YARN 仍然负责资源的管理和分配。 YARN 容器委托模型用于允许将分配的资源转移到 LLAP。 为了避免 JVM 内存设置的限制，缓存数据保持在堆外，以及用于处理的大缓冲区（例如，group by、joins）。 这样，守护进程可以使用少量内存，并且将根据工作负载分配额外的资源（即 CPU 和内存）。

查询片段执行

对于如上所述的部分执行，LLAP 节点执行“查询片段”，例如过滤器、投影、数据转换、部分聚合、排序、分桶、散列连接/半连接等。LLAP 中只接受 Hive 代码和blessed UDF。 没有代码被本地化并即时执行。 这样做是出于稳定性和安全性的原因。

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

I/O

守护进程卸载 I/O 和从压缩格式到单独线程的转换。 数据在准备好后被传递给执行，因此可以在准备下一批的同时处理前一批。 数据以简单的 RLE 编码列格式传递给执行，该格式已准备好进行矢量化处理； 这也是缓存格式，旨在最大限度地减少 I/O、缓存和执行之间的复制。

  • 多种文件格式。 I/O 和缓存依赖于对底层文件格式的一些了解（特别是如果要高效完成）。 因此，与矢量化工作类似，将通过特定于每种格式的插件（从 ORC 开始）支持不同的文件格式。 此外，可以添加一个通用的、效率较低的插件来支持任何 Hive 输入格式。 插件必须维护元数据并将原始数据转换为列块。
  • 谓词和布隆过滤器。 如果支持 SARG 和布隆过滤器，它们将被下推到存储层。

自动创建布隆过滤器以提供动态运行时过滤。

工作负载管理

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

ACID支持

LLAP 了解事务。 在将数据放入缓存之前执行合并增量文件以产生表的特定状态。

多个版本是可能的，并且请求指定要使用哪个版本。 这样做的好处是异步进行合并，并且只对缓存数据进行一次合并，从而避免了对操作员管道的影响。

安全

LLAP 服务器是在比“每个文件”更细粒度的级别强制执行访问控制的自然场所。 由于守护进程知道处理了哪些列和记录，因此可以对这些对象实施策略。 这并不是要取代当前的机制，而是要增强它们并将它们也开放给其他应用程序。

监控

LLAP 监控的配置存储在 resources.json、appConfig.json、metainfo.xml 中，它们嵌入到 Slider 使用的 templates.py 中。

LLAP Monitor Daemon 运行在 YARN 容器上，类似于 LLAP Daemon，并在同一个端口上侦听。

LLAP 指标收集服务器定期从所有 LLAP 守护程序收集 JMX 指标。

LLAP 守护进程列表是从集群中启动的 Zookeeper 服务器中提取的。

Web服务

HIVE-9814 引入了以下 Web 服务：

JSON JMX 数据 – /jmx

所有线程的 JVM 堆栈跟踪 – /stacks

llap-daemon-site 的 XML 配置 – /conf

HIVE-13398 引入了以下 Web 服务：

LLAP 状态 – /status

LLAP 对等体 – /peers

0 0 投票数

文章评分

本文为从大数据到人工智能博主「xiaozhch5」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://cloud.tencent.com/developer/article/2000010

hive yarn node.js 缓存 容器

0 人点赞