我对hive不够熟悉，所以我在这里。我们正在使用 Oozie 将一堆 Hive ql 作业链接在一起。我的任务是优化已经在生产环境中运行的应用程序。业务合作伙伴不希望花费超过 1.5 小时的时间。我注意到的第一件事是，在这个工作流程中大约有 90 个 oozie 操作。我们还与其他应用程序共享一个纱线队列。这些操作中有一半是 hive2 操作，每个 Hive QL 操作只执行一个 HQL 语句。有时 HiveQL 操作之间似乎有延迟，因为 Oozie 启动器在队列中等待，然后 HiveQL 在队列中等待。这正常吗？有没有办法解决这个问题。
对于时间敏感的 Hive 查询：1） Oozie 是我们应该用来将时间敏感的 HiveQL 脚本链接在一起的正确工具吗？2）有哪些替代方案（使用Java或Python启动和处理HQL之间的流是否有性能优势）？3）我们可以在HQL本身做些什么吗？（同样，我是Hive的新手，主要是MapReduce/Spark和简单工作流程（少于20个操作）的经验）4） 还有其他我没有提到的性能注意事项吗？
谢谢
Oozie 启动器在队列中等待，然后 HiveQL 在队列中等待。
Oozie不会自己运行任何东西。它首先启动一个启动器 - 一个虚拟的YARN作业（1个AppMaster + 1个映射器） - 只是为了运行基本命令（Hive CLI胖客户端用于"hive"，Beeline瘦客户端用于"hive2"，Pig CLI，Sqoop，Spark Driver，Bash shell等）。然后，该命令可能会生成一系列 YARN 作业。
请注意，YARN 不知道启动器与其生成的作业之间的依赖关系。特别是在"hive2"操作的情况下，因为启动器连接到
HiveServer2，并且是HiveServer2生成作业！建议#1 - 启动器作业需要很少的协调（记住，只有1个映射器），因此其AppMaster资源应设置得相当低，以避免消耗太多RAM并因此阻塞队列。您可以使用（不幸的是没有记录）操作属性oozie.launcher.yarn.app.mapreduce.am.resource.mb（总 RAM）和oozie.launcher.yarn.app.mapreduce.am.command-opts（带有"-Xmx"参数的 Java 堆大小的显式配额，通常为 RAM 的 80% - 太低，您会收到内存不足错误，太高，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行动 - 使用"hive"或"hive2"，可以在 HQL 脚本的顶部插入命令
set mapreduce.job.queuename = *** ;
建议 #4 - 如果默认 AM 资源对于 Hive 查询来说似乎过大，您也可以尝试调整它们的大小
仅使用"Hive"，您可以设置
yarn.app.mapreduce.am.resource.mb和yarn.app.mapreduce.am.command-opts在Oozie行动 - 或者可能 使用时的tez.am.resource.memory.mb和tez.am.launch.cmd-opts技术研发中心（TEZ）使用"Hive"或"Hive2"，您可以在顶部插入命令等等等等的 HQL 脚本
#1-2-4 的警告：您不能请求少于 yarn.scheduler.minimum-allocation-mb（并且它是为 ResourceManager 服务设置的，您不能基于每个作业覆盖该服务）。
是否有任何其他性能注意事项
建议 #5 - 如果某些步骤可以链接在同一个 HQL 脚本中，它将减少 Oozie 轮询 YARN 的开销，以检测第一个查询的结束，然后启动另一个启动器，然后启动器启动另一个 Hive 会话。当然，如果出现错误，执行控件将不会是细粒度的，在重新启动之前可能需要进行一些手动清理。
建议#6 - 如果某些步骤可以并行完成，并且您实际上有足够的YARN资源来并行运行它们，那么将它们放置在Oozie Fork/Join的不同分支中（如Biswajit Nayak建议的那样）。
建议#7 - 如果您还没有使用技术研发中心，请尝试一下。为集群找到一组好的参数可能很棘手，但是当它工作时，在许多情况下，它比MapReduce更有效（即，它在映射和Reduce步骤中重复使用相同的YARN容器，甚至用于连续查询 - 更少的YARN开销，更少的中间磁盘I/O等）。
~~~~~~~~
顺便问一下，你认为在某些地方使用旧的"hive"操作有什么很好的理由吗？也许有一些选项可以强制"本地模式"，即跳过 YARN 并在启动器内运行小查询，而无需额外的开销？或者也许他们想要冗长的日志？
Oozie 是调度的完美工具。以下是您必须研究的几件事：-
- 检查是否可以合并或复制很少的操作？
- 检查操作的依赖项。如果很少有操作没有依赖关系，则尝试移出并行工作流。
- 尝试为此时间敏感的作业设置专用队列。
- 尝试同时优化 HQL 查询。
对于您的问题"有时 HiveQL 操作之间似乎有延迟，因为 Oozie 启动器在队列中等待，然后 HiveQL 在队列中等待。这正常吗？"，如果队列容量被其他作业完全使用，则新作业将等到某人释放容量。所以我要求在第 3 点有一个专门的队列。