java - 在Oozie中优化多个Hive QL

Question

我对 hive 不够熟悉，所以我在这里。我们正在使用Oozie将一堆 hive ql作业链接在一起。我的任务是优化已经在我们的生产环境中运行的应用程序。业务合作伙伴不希望它花费超过1.5个小时的时间。我注意到的第一件事是，在一个工作流程中大约有90个oozie Action 。我们还与其他应用程序共享 yarn 队列。这些 Action 的一半是hive2 Action ，并且每个Hive QL Action 仅执行一个HQL语句。有时似乎HiveQL操作之间存在延迟，因为Oozie启动器在队列中等待，然后HiveQL在队列中等待。那是正常的吗？有没有解决的办法。

对于时间敏感的Hive查询:
1)Oozie是正确的工具，应该用于将对时间敏感的HiveQL脚本链接在一起
2)有哪些替代方案(可以使用Java或Python启动并处理HQL之间的流程具有性能优势)吗？
3)HQL本身可以做些什么？ (再次，我是 hive 新手，主要体验MapReduce / Spark和简单的工作流程(少于20个 Action )
4)还有我没有提到的其他性能考量吗？

谢谢，

Answer 1

the Oozie launcher waits in a queue, and then the HiveQL waits in a queue.

Oozie本身不会运行任何内容。它首先启动 启动器-一个虚拟YARN作业(1个AppMaster + 1个Mapper)-仅运行基本命令(“hive”使用Hive CLI胖客户端，“hive2”使用Beeline瘦客户端，Pig CLI，Sqoop) ，Spark Driver，Bash shell等)。然后，该命令可能会产生一系列YARN作业。

请注意，YARN并不了解启动器及其派生作业之间的依赖关系。特别是在“hive2”操作的情况下，因为启动器连接到HiveServer2，而HiveServer2产生了作业!

建议＃1 -Launcher作业需要很少的协调(记住，只有1个Mapper)，因此应将其AppMaster资源设置得较低，以避免占用过多的RAM并因此阻塞队列。您可以使用(遗憾的是未记录) Action 属性 oozie.launcher.yarn.app.mapreduce.am.resource.mb(总RAM)和 oozie.launcher.yarn.app.mapreduce.am.command-opts(带有“-Xmx”参数的Java堆大小的显式配额，通常为80％RAM)-太低，而出现OutOfMemory错误，从而覆盖默认设置，太高，YARN可能会因配额滥用而杀死您的容器)

建议＃2 -对于“hive2”，启动器作业也需要很少的资源(Beeline是一个瘦JDBC客户端)，所以等等 oozie.launcher.mapreduce.map.memory.mb和 oozie.launcher.mapreduce.map.java.opts等等。

建议＃3 -如果您可以访问优先级较高的YARN队列(由Biswajit Nayak建议)，则将其与 oozie.launcher.mapreduce.job.queuename一起用于启动器。对于实际的Hive查询，取决于:

仅带有“ hive ”，您也可以在Oozie中设置mapreduce.job.queuename Action

带有“hive”或“hive2”的

，您可以在HQL脚本

的顶部插入命令 set
mapreduce.job.queuename = *** ;
建议＃4 -如果您的Hive查询的默认AM资源似乎过大，您也可以尝试调整它们的大小

仅带有“ hive ”，您可以设置yarn.app.mapreduce.am.resource.mb和
Oozie Action 中的yarn.app.mapreduce.am.command-opts-或可能
使用时的tez.am.resource.memory.mb和tez.am.launch.cmd-optsTEZ

带有“hive”或“hive2”的

，您可以在顶部插入命令等等等等
HQL脚本

注意＃1-2-4:您不能要求的请求数不超过 yarn.scheduler.minimum-allocation-mb(并且它是为ResourceManager服务设置的，不能在每个工作的基础上覆盖该请求)。

Are there any other performance considerations

建议＃5 -如果可以在同一HQL脚本中链接某些步骤，则它将减少Oozie轮询YARN来检测第一个查询结束，然后启动另一个Launcher，然后启动Launcher发起另一个Hive session 的开销。当然，在发生错误的情况下，将无法细化执行控制，并且可能需要在重新启动之前进行一些手动清理。

建议＃6 -如果可以并行执行一些步骤，并且您实际上有足够的YARN资源可以并行运行它们，然后将它们放在Oozie Fork / Join的不同分支中(如Biswajit Nayak所建议)。

建议＃7 -如果您尚未使用TEZ，请尝试一下。为您的集群找到一套不错的参数可能很棘手，但是当它工作时，它在许多情况下比MapReduce效率更高(例如，它将相同的YARN容器重新用于Map和Reduce步骤，甚至用于后续查询-更少的YARN开销，更少的中间磁盘I / O等)

~~~~~~~~~

顺便说一句，您是否看到在某些地方使用较旧的“配置单元”操作的充分理由？也许有强制“本地模式”的选项，即跳过YARN并在启动器内运行小的查询而没有额外的开销？还是他们想要详细的日志？