在 Oozie 中优化多个 Hive QL
Optimize multiple Hive QL in Oozie
我对hive还不够熟悉，所以来了。我们正在使用 Oozie 将一堆 hive ql 作业链接在一起。我的任务是优化已经 运行 在我们的生产环境中的应用程序。业务合作伙伴不希望它花费超过 1.5 小时的时间。我注意到的第一件事是，在这个工作流程中有大约 90 个 oozie 操作。我们还与其他应用程序共享一个 yarn 队列。这些操作中有一半是 hive2 操作，每个 Hive QL 操作只执行一个 HQL 语句。似乎有时 HiveQL 操作之间存在延迟，因为 Oozie 启动器在队列中等待，然后 HiveQL 在队列中等待。那是正常的吗？有没有办法解决这个问题。
对于时间敏感的 Hive 查询：
1) Oozie 是我们应该用来将时间敏感的 HiveQL 脚本链接在一起的正确工具吗
2）有哪些替代方案（使用 Java 或 Python 来启动和处理 HQL 之间的流程是否具有性能优势）？
3）我们可以在 HQL 中做些什么吗？ （同样，我是配置单元的新手，主要体验 MapReduce/Spark 和简单的工作流程（少于 20 个操作）
4) 还有其他我没有提到的性能考虑因素吗？
谢谢，
Oozie 是完美的日程安排工具。以下是您需要研究的几件事：-
- 检查是否有少数操作可以合并或重复？
- 检查动作的依赖关系。如果很少有操作没有依赖性，则尝试移出并行工作流程。
- 尝试为这个时间敏感的作业设置一个专用队列。
- 也尝试优化 HQL 查询。
对于你的问题"It seems sometimes there are delays between HiveQL actions because the Oozie launcher waits in a queue, and then the HiveQL waits in a queue. Is that normal?"，如果队列容量被其他作业完全使用，那么新作业将等待直到有人释放容量。所以我要求在第 3 点有一个专用队列。
the Oozie launcher waits in a queue, and then the HiveQL waits in a queue.
Oozie 本身没有 运行 任何东西。它首先启动一个 Launcher——一个虚拟的 YARN 作业（1 个 AppMaster + 1 个映射器）——只是 运行 基本命令（[=94= 的 Hive CLI 胖客户端） ], Beeline thin client for "hive2", Pig CLI, Sqoop, Spark Driver, Bash shell, etc.) 然后，该命令可能会产生一系列 YARN 作业。
请注意，YARN 不了解启动器与其生成的作业之间的依赖关系。特别是在 "hive2" 操作的情况下，因为启动器连接到 HiveServer2 并且是 HiveServer2 产生作业！
建议 #1 - Launcher 作业需要很少的协调（只需 1 个 Mapper，记住） 因此应设置其 AppMaster 资源相当低，以避免消耗过多的 RAM 并因此阻塞队列。您可以使用（遗憾的是未记录）操作属性 oozie.launcher.yarn.app.mapreduce.am.resource.mb（总 RAM）和 oozie.launcher.yarn.app.mapreduce.am.command-opts（Java 堆大小的显式配额与“-Xmx”参数覆盖默认设置，通常为 80 RAM 的百分比 - 太低会出现 OutOfMemory 错误，太高则 YARN 可能会因为配额滥用而杀死你的容器）
建议 #2 - 对于 "hive2"，Launcher 作业也需要很少的资源 （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"，你可以在上面插入命令blah blah blah
HQL 脚本
警告 #1-2-4：您不能请求少于 yarn.scheduler.minimum-allocation-mb（它是为 ResourceManager 服务设置的，您不能覆盖那个在每个工作的基础上）。
Are there any other performance considerations
建议 #5 - 如果可以将某些步骤链接到同一个 HQL 脚本中，它将减少 Oozie 轮询 YARN 以检测第一个查询结束，然后开始的开销另一个启动器，然后启动器启动另一个 Hive 会话。当然，如果出现错误，执行控制将不会细粒度，并且可能需要在重启前进行一些手动清理。
建议 #6 - 如果某些步骤可以并行完成，并且您实际上有足够的 YARN 资源来并行 运行 它们，那么将它们放在不同的位置Oozie 的分支 Fork/Join （根据 Biswajit Nayak 的建议）.
建议 #7 - 如果您还没有使用 TEZ，请尝试一下。为您的集群找到一组好的参数可能很棘手，但当它工作时，它在许多情况下比 MapReduce 更有效（即它为 Map 和 Reduce 步骤重新使用相同的 YARN 容器，并且即使对于连续的查询——更少的 YARN 开销，更少的中间磁盘 I/O，等等）
~~~~~~~~
顺便问一下，您认为在某些地方使用较旧的 "hive" 操作有什么好的理由吗？也许有强制 "local mode" 的选项，即跳过启动器内的 YARN 和 运行 小查询，没有额外的开销？或者也许他们想要详细的日志？
我对hive还不够熟悉，所以来了。我们正在使用 Oozie 将一堆 hive ql 作业链接在一起。我的任务是优化已经 运行 在我们的生产环境中的应用程序。业务合作伙伴不希望它花费超过 1.5 小时的时间。我注意到的第一件事是，在这个工作流程中有大约 90 个 oozie 操作。我们还与其他应用程序共享一个 yarn 队列。这些操作中有一半是 hive2 操作，每个 Hive QL 操作只执行一个 HQL 语句。似乎有时 HiveQL 操作之间存在延迟，因为 Oozie 启动器在队列中等待，然后 HiveQL 在队列中等待。那是正常的吗？有没有办法解决这个问题。
对于时间敏感的 Hive 查询： 1) Oozie 是我们应该用来将时间敏感的 HiveQL 脚本链接在一起的正确工具吗 2）有哪些替代方案（使用 Java 或 Python 来启动和处理 HQL 之间的流程是否具有性能优势）？ 3）我们可以在 HQL 中做些什么吗？ （同样，我是配置单元的新手，主要体验 MapReduce/Spark 和简单的工作流程（少于 20 个操作） 4) 还有其他我没有提到的性能考虑因素吗？
谢谢，
Oozie 是完美的日程安排工具。以下是您需要研究的几件事：-
- 检查是否有少数操作可以合并或重复？
- 检查动作的依赖关系。如果很少有操作没有依赖性，则尝试移出并行工作流程。
- 尝试为这个时间敏感的作业设置一个专用队列。
- 也尝试优化 HQL 查询。
对于你的问题"It seems sometimes there are delays between HiveQL actions because the Oozie launcher waits in a queue, and then the HiveQL waits in a queue. Is that normal?"，如果队列容量被其他作业完全使用，那么新作业将等待直到有人释放容量。所以我要求在第 3 点有一个专用队列。
the Oozie launcher waits in a queue, and then the HiveQL waits in a queue.
Oozie 本身没有 运行 任何东西。它首先启动一个 Launcher——一个虚拟的 YARN 作业（1 个 AppMaster + 1 个映射器）——只是 运行 基本命令（[=94= 的 Hive CLI 胖客户端） ], Beeline thin client for "hive2", Pig CLI, Sqoop, Spark Driver, Bash shell, etc.) 然后，该命令可能会产生一系列 YARN 作业。
请注意，YARN 不了解启动器与其生成的作业之间的依赖关系。特别是在 "hive2" 操作的情况下，因为启动器连接到 HiveServer2 并且是 HiveServer2 产生作业！
建议 #1 - Launcher 作业需要很少的协调（只需 1 个 Mapper，记住） 因此应设置其 AppMaster 资源相当低，以避免消耗过多的 RAM 并因此阻塞队列。您可以使用（遗憾的是未记录）操作属性 oozie.launcher.yarn.app.mapreduce.am.resource.mb（总 RAM）和 oozie.launcher.yarn.app.mapreduce.am.command-opts（Java 堆大小的显式配额与“-Xmx”参数覆盖默认设置，通常为 80 RAM 的百分比 - 太低会出现 OutOfMemory 错误，太高则 YARN 可能会因为配额滥用而杀死你的容器）
建议 #2 - 对于 "hive2"，Launcher 作业也需要很少的资源 （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"，你可以在上面插入命令blah blah blah HQL 脚本
警告 #1-2-4：您不能请求少于 yarn.scheduler.minimum-allocation-mb（它是为 ResourceManager 服务设置的，您不能覆盖那个在每个工作的基础上）。
Are there any other performance considerations
建议 #5 - 如果可以将某些步骤链接到同一个 HQL 脚本中，它将减少 Oozie 轮询 YARN 以检测第一个查询结束，然后开始的开销另一个启动器，然后启动器启动另一个 Hive 会话。当然，如果出现错误，执行控制将不会细粒度，并且可能需要在重启前进行一些手动清理。
建议 #6 - 如果某些步骤可以并行完成，并且您实际上有足够的 YARN 资源来并行 运行 它们，那么将它们放在不同的位置Oozie 的分支 Fork/Join （根据 Biswajit Nayak 的建议）.
建议 #7 - 如果您还没有使用 TEZ，请尝试一下。为您的集群找到一组好的参数可能很棘手，但当它工作时，它在许多情况下比 MapReduce 更有效（即它为 Map 和 Reduce 步骤重新使用相同的 YARN 容器，并且即使对于连续的查询——更少的 YARN 开销，更少的中间磁盘 I/O，等等）
~~~~~~~~
顺便问一下，您认为在某些地方使用较旧的 "hive" 操作有什么好的理由吗？也许有强制 "local mode" 的选项，即跳过启动器内的 YARN 和 运行 小查询，没有额外的开销？或者也许他们想要详细的日志？