升级到 CDP 后Hive on Tez 性能调整和故障排除指南
优化Hive on Tez查询永远不能以一种万能的方法来完成。查询的性能取决于数据的大小、文件类型、查询设计和查询模式。在性能测试期间，要评估和验证配置参数和任何 SQL 修改。建议在工作负载的性能测试期间一次进行一项更改，并且最好在生产环境中使用它们之前评估调整更改在您的开发和 QA 环境中的影响。Cloudera WXM可以帮助评估性能测试期间查询更改的好处。
1. 调优指南
在从 CDH 发行版到 CDP 私有云的多次迁移中观察到，与 MR 或 Spark 等较旧的执行引擎相比，Hive on Tez查询往往执行得更慢。这通常是由不同执行引擎之间的开箱即用的调整行为的差异引起的。此外，用户可能已经完成了对旧版分发的调整，这不会自动反映在 Hive on Tez转换中。对于从 HDP 发行版升级的用户，此讨论还有助于查看和验证是否正确配置了属性以实现 CDP 中的性能。
1.1. 确定问题步骤
以下步骤可帮助您确定可能会降低性能的重点领域。
第 1 步：核实和验证 YARN 容量调度器的配置。由于错误配置的队列配置（用户可用资源的任意上限）可能会影响查询性能。验证用户限制因子、最小用户限制百分比和最大容量。（请参阅YARN – 容量调度器博客以了解这些配置设置。）
第 2 步：查看 Hive on Tez和 Hive 的任何安全阀（Hive 和 HiveServer2 配置的非默认值）的相关性。删除任何遗留和过时的属性。
第 3 步：识别缓慢的区域，例如 map 任务、reduce 任务和Join。
1) 查看通用的 Tez 引擎和平台的可调整的属性。
2) 查看Map任务并调整-根据需要增加/减少任务计数。
3) 查看Reduce任务并调整-根据需要增加/减少任务计数。
4) 查看任何与并发相关的问题——这里有两种并发问题，如下所示：
- 队列内用户之间的并发。这可以使用 YARN 队列的用户限制因子进行调整（请参阅容量调度器博客中的详细信息）。
Hive on Tez 会话的预热容器之间的并发性，如下文详细讨论。
2. 了解 Tez 中的并行化
在更改任何配置之前，您必须了解 Tez 内部工作的机制。例如，这包括了解 Tez 如何确定正确的Map和Reduce数量。查看 Tez 架构设计以及有关初始任务并行性和自动减少并行性如何工作的详细信息将帮助您优化查询性能。
3. 了解Map的数量
Tez 使用作业的初始输入数据来确定Map任务的数量。在 Tez 中，任务的数量由分组拆分决定，这相当于 map reduce 作业中由输入拆分确定的Map数量。
- tez.grouping.min-size和tez.grouping.max-size确定Map的数量。min-size的默认值为16 MB， max-size为 1 GB。
- Tez 确定任务的数量，以使每个任务的数据符合分组最大/最小大小。
- 减小tez.grouping.max-size会增加Map/Reduce的数量。
- 增加tez.grouping.max-size会减少任务的数量。
考虑以下示例：
- 输入数据（输入分片/分割）– 1000 个文件（大约 1.5 MB 大小）
- 总数据大小为 – 1000*1.5 MB = ~ 1.5 GB
- Tez 可以尝试使用至少两个任务处理此数据，因为最大数据/任务可能是 1 G。最终，Tez 可以强制将 1000 个文件（拆分）合并为两个任务，从而导致执行时间变慢。
如果tez.grouping.max-size从 1 GB 减少到 100 MB，则Map的数量可以增加到 15 个，从而提供更好的并行性。然后性能会提高，因为改进的并行性将工作从两个并发任务扩展到 15 个。
以上是一个示例场景，但是在使用 ORC 或 parquet 等二进制文件格式的生产环境中，根据存储类型、拆分策略文件或 HDFS 块边界确定Map的数量可能会变得复杂。
注意：更高程度的并行性（例如大量Map/Reduce）并不总是转化为更好的性能，因为它可能导致每个任务的资源更少，并且由于任务开销而导致更高的资源浪费。4. 了解Reduce的数量
Tez 使用多种机制和设置来确定完成查询所需的 reducer 数量。