优化服务使用
服务级别考虑因素包括每个账户运行的工作负载数量、不仅是 Athena 的服务配额，还包括跨服务的服务配额，以及考虑如何减少“资源不足”错误。
在同一账户内运行多个工作负载
Athena 使用配额来限制账户级别的查询并发和 API 请求速率。超过这些配额可能会导致查询在执行期间或提交时失败。有关限额的更多信息，请参阅 服务配额。
如果您在同一个 Amazon 账户内运行多个工作负载，则您的工作负载会争用同一账户级配额。例如，如果一个工作负载出现意外的查询激增，则可能会遇到查询提交节流或排队时间延长的情况。
我们建议您使用 CloudWatch 通过图表和控制面板监控服务使用情况。您还可以配置 CloudWatch 警报，在使用量接近并发查询的服务配额时提醒您，这样您就可以在达到配额限制之前采取措施。有关更多信息，请参阅 使用 CloudWatch 监控 Athena 使用情况指标。
要控制查询并发并隔离账户内的工作负载，请使用容量预留。容量预留可在单个账户中提供专用的查询处理能力。容量以数据处理单元（DPU）为计量单位，可以进行增减以分别增加或减少查询并发。容量预留可以通过将容量分配给一个或多个工作组，将账户内的工作负载彼此隔离。有关更多信息，请参阅 管理查询处理容量。
虽然将工作负载分成不同的 Amazon 账户可能有助于组织目的（例如将开发与生产环境隔离），但这种方法不能提供可扩展查询并发提升方式。相反，使用容量预留可在单个账户中管理和扩展您的查询处理需求。
考虑其他服务的限额
当 Athena 运行查询时，它可以调用其他强制实施限额的服务。在查询执行期间，Athena 可以对 Amazon Glue Data Catalog、Amazon S3 以及其他 Amazon 服务（如 IAM 和 Amazon KMS）进行 API 调用。如果您使用联合查询，Athena 也会调用 Amazon Lambda。所有这些服务都有自己的限制和限额，可以超出。当查询执行遇到来自这些服务的错误时，查询会失败并包括来自源服务的错误。系统会重试可恢复的错误；但如果问题不能及时解决，查询仍可能失败。请务必仔细阅读错误消息，以确定它们是来自 Athena 还是来自其他服务。此性能优化部分介绍了一些相关错误。
有关如何解决由 Amazon S3 服务限额导致的错误的更多信息，请参阅本文档后面的 避免文件过多。有关 Amazon S3 性能优化的更多信息，请参阅《Amazon S3 用户指南》中的最佳实践设计模式：优化 Amazon S3 性能。
减少“资源不足”错误
Athena 在分布式查询引擎中运行查询。当您提交查询时，Athena 引擎查询计划程序会估计运行查询所需的计算容量，并相应地准备计算节点集群。有些查询（例如 DDL 查询）只能在一个节点上运行。对大型数据集的复杂查询在更大的集群上运行。节点是统一的，具有相同的内存、CPU 和磁盘配置。Athena 横向扩展，而非纵向扩展，以处理要求更高的查询。
有时，查询的需求会超过运行查询的集群可用的资源。发生这种情况时，查询会失败，并显示错误查询在此缩放系数耗尽了资源。
最常耗尽的资源是内存，但在极少数情况下，也可能是磁盘空间。内存错误通常发生在引擎执行联接或窗口函数时，但也可能发生在不同的计数和聚合中。
即使查询因出现“资源不足”错误而失败一次，当您再次运行它时，它也可能会成功。查询执行的确定性不定。加载数据需要多长时间以及中间数据集在节点上的分布方式等因素可能会导致不同的资源使用情况。例如，假设一个查询连接两个表，并且在连接条件的值分布中存在严重偏差。这样的查询在大多数情况下都可以成功，但是当最常见的值最终由同一个节点处理时，偶尔会失败。
为防止您的查询超出可用资源，请使用本文档中提到的性能调整提示。特别是，有关如何优化耗尽可用资源的查询的提示，请参阅 优化联接、缩小窗口函数的范围，或者将其移除 和 使用近似值优化查询。