最佳化服務使用

服務層級考量包括您每個帳戶執行的工作負載數量、不僅針對 Athena 的服務配額，也包括跨服務的服務配額，以及思考如何減少「資源不足」錯誤。

在同一帳戶中操作多個工作負載

Athena 使用配額來限制帳戶層級的查詢並行和 API 請求率。超過這些配額可能會導致查詢在執行期間或提交時失敗。如需有關這些配額的詳細資訊，請參閱 Service Quotas。

如果您在同一個 AWS 帳戶中操作多個工作負載，您的工作負載會爭奪相同的帳戶層級配額。例如，如果一個工作負載遇到意外的查詢爆增，您可能會遇到查詢提交限流或增加的佇列時間。

我們建議您使用 CloudWatch 透過圖形和儀表板監控您的服務使用情況。您也可以設定 CloudWatch 警示，在用量接近並行查詢的服務配額時提醒您，讓您在達到配額限制之前採取動作。如需詳細資訊，請參閱使用 CloudWatch 監控 Athena 用量指標。

若要控制查詢並行並隔離帳戶中的工作負載，請使用容量保留。容量保留可在單一帳戶中提供專用查詢處理容量。容量是以資料處理單位 (DPUs測量，可分別新增或移除，以增加或減少查詢並行。容量保留可讓您透過將容量指派給一或多個工作群組，將帳戶中的工作負載彼此隔離。如需詳細資訊，請參閱管理查詢處理容量。

雖然將工作負載分成不同的 AWS 帳戶對於組織用途 （例如隔離開發與生產環境） 可能很有用，但這種方法無法提供可擴展的方式來增加查詢並行。反之，請使用容量保留來管理和擴展單一帳戶中的查詢處理需求。

考慮其他服務中的配額

當 Athena 執行查詢時，它可以呼叫其他強制執行配額的服務。在查詢執行期間，Athena 可以對 AWS Glue Data Catalog、Amazon S3 和其他 AWS 服務進行 API 呼叫，例如 IAM 和 AWS KMS。如果您使用聯合查詢，Athena 也會呼叫 AWS Lambda。所有這些服務都有自己的限制和配額，可以超過。當查詢執行遇到來自這些服務的錯誤時，其便會失敗並包含來源服務的錯誤。重試可復原的錯誤，但如果問題無法及時自行解決，查詢仍可能失敗。請務必徹底閱讀錯誤訊息，以判斷其是來自 Athena 還是來自其他服務。此效能調校區段涵蓋一些相關錯誤。

如需有關解決 Amazon S3 Service Quotas 造成的錯誤的資訊，請參閱本文件稍後的 避免檔案太多。如需有關 Amazon S3 效能最佳化的詳細資訊，請參閱《Amazon S3 使用者指南》中的最佳實務設計模式：最佳化 Amazon S3 效能。

減少「資源不足」錯誤

Athena 會在分散式查詢引擎中執行查詢。當您提交查詢時，Athena 引擎查詢規劃程式會預估執行查詢所需的運算容量，並相應地準備運算節點叢集。某些查詢 (例如 DDL 查詢) 只在一個節點上執行。大型資料集的複雜查詢可在更大的叢集上執行。節點是統一的，具有相同的記憶體、CPU 和磁碟組態。Athena 透過橫向擴展 (而非向上擴展) 來處理要求更高的查詢。

有時候，查詢的需求會超過執行查詢的叢集的可用資源。發生這種情況時，查詢會失敗，並顯示錯誤在此擴展因數下查詢耗盡的資源。

最常耗盡的資源是記憶體，但在極少數情況下，也可以是磁碟空間。當引擎執行聯結或視窗函數時，通常會發生記憶體錯誤，但也可能發生在不同的計數和彙總中。

即使查詢失敗並出現「資源不足」錯誤一次，當您再次執行時，其可能會成功。查詢執行不是確定性的。載入資料所花費時間以及如何在節點上分配中繼資料集等因素，可能會導致資源使用量不同。例如，假設一個查詢聯結兩個資料表，並且聯結條件的值分佈存在很大偏差。這樣的查詢在大多數時間都可以成功，但是當最常見的值最終由相同節點處理時，偶爾會失敗。

若要避免查詢超出可用資源，請使用本文件中提及的效能調校秘訣。具體而言，有關如何最佳化會耗盡可用資源之查詢的秘訣，請參閱 最佳化聯結、縮小或移除視窗函數的範圍 和 使用近似值最佳化查詢。