由于社区近年来构建的各种功能和改进,包括 Tez 和基于成本的优化,Hive 的速度显着提高。 将 Hive 提升到一个新的水平需要以下内容:
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 在现有的、基于流程的 Hive 执行中工作,以保持 Hive 的可扩展性和多功能性。 它不会取代现有的执行模型,而是增强它。
守护程序是可选的。 Hive 可以在没有它们的情况下工作,并且即使它们已部署和运行也能够绕过它们。 保持与语言特征相关的特征对等。
对于如上所述的部分执行,LLAP 节点执行“查询片段”,例如过滤器、投影、数据转换、部分聚合、排序、分桶、散列连接/半连接等。LLAP 中只接受 Hive 代码和blessed UDF。 没有代码被本地化并即时执行。 这样做是出于稳定性和安全性的原因。
守护进程卸载 I/O 和从压缩格式到单独线程的转换。 数据在准备好后被传递给执行,因此可以在准备下一批的同时处理前一批。 数据以简单的 RLE 编码列格式传递给执行,该格式已准备好进行矢量化处理; 这也是缓存格式,旨在最大限度地减少 I/O、缓存和执行之间的复制。
自动创建布隆过滤器以提供动态运行时过滤。
YARN 用于获取不同工作负载的资源。 一旦从 YARN 为特定工作负载获得资源(CPU、内存等),执行引擎可以选择将这些资源委托给 LLAP,或者在单独的进程中启动 Hive 执行器。 通过 YARN 实施资源的优势在于确保节点不会因 LLAP 或其他容器而过载。 守护进程本身在 YARN 的控制之下。
LLAP 了解事务。 在将数据放入缓存之前执行合并增量文件以产生表的特定状态。
多个版本是可能的,并且请求指定要使用哪个版本。 这样做的好处是异步进行合并,并且只对缓存数据进行一次合并,从而避免了对操作员管道的影响。
LLAP 服务器是在比“每个文件”更细粒度的级别强制执行访问控制的自然场所。 由于守护进程知道处理了哪些列和记录,因此可以对这些对象实施策略。 这并不是要取代当前的机制,而是要增强它们并将它们也开放给其他应用程序。
LLAP 监控的配置存储在 resources.json、appConfig.json、metainfo.xml 中,它们嵌入到 Slider 使用的 templates.py 中。
LLAP Monitor Daemon 运行在 YARN 容器上,类似于 LLAP Daemon,并在同一个端口上侦听。
LLAP 指标收集服务器定期从所有 LLAP 守护程序收集 JMX 指标。
LLAP 守护进程列表是从集群中启动的 Zookeeper 服务器中提取的。
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版权协议,转载请附上原文出处链接及本声明。