本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 工作負載管理 您可以使用 Athena 的工作群組、容量管理、效能調校、壓縮支援、標籤和服務配額功能來管理工作負載。 **Topics** + [使用工作群組來控制查詢存取和成本](workgroups-manage-queries-control-costs.md) + [管理查詢處理容量](capacity-management.md) + [最佳化 Athena 效能](performance-tuning.md) + [在 Athena 中使用壓縮](compression-formats.md) + [標記 Athena 資源](tags.md) + [Service Quotas](service-limits.md) # 使用工作群組來控制查詢存取和成本 您可以使用 Athena 工作群組來分隔工作負載、控制團隊存取權、強制執行組態，以及追蹤查詢指標和控制成本。 **分隔工作負載** 您可以使用工作群組來分隔工作負載。例如，您可以建立兩個獨立工作群組，一個用於自動排定的應用程式，例如產生報告，另一個供分析師臨時使用。 **控制團隊存取權** 因為工作群組扮演 IAM 資源的角色，所以您可以使用資源層級的身分型政策，控制可存取工作群組並在其中執行查詢的人員。若要隔離組織中兩個不同團隊的查詢，您可以為每個團隊建立單獨的工作群組。每個工作群組都有其自己的查詢歷史記錄以及該工作群組中的查詢的易儲存查詢的清單，而不是針對帳戶中的所有查詢。如需詳細資訊，請參閱[使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。 **強制執行組態** 您可以選擇性地對該工作群組中執行的所有查詢強制執行相同的工作群組整體設定。這些設定包含 Amazon S3 中查詢結果的位置、預期的儲存貯體擁有者、加密和對寫入查詢結果儲存貯體之物件的控制。如需詳細資訊，請參閱[Override client-side settings (覆寫用戶端設定)](workgroups-settings-override.md)。 **追蹤查詢指標、查詢事件和控制成本** 若要追蹤每個 Athena 工作群組的查詢指標、查詢事件和控制成本，您可以使用下列功能： + **發布查詢指標** – 將工作群組的查詢指標發布至 CloudWatch。在 Athena 主控台中，您可以檢視每個工作群組的查詢指標。在 CloudWatch 中，您可以建立自訂儀表板，並針對這些指標設定閾值和警示。如需詳細資訊，請參閱[在 Athena 中啟用 CloudWatch 查詢指標](athena-cloudwatch-metrics-enable.md)及[使用 CloudWatch 監控 Athena 查詢指標](query-metrics-viewing.md)。 + **監控 Athena 用量指標** – 透過在 CloudWatch 圖表和儀表板上顯示您目前的服務用量，了解您的帳戶如何使用資源。如需詳細資訊，請參閱[使用 CloudWatch 監控 Athena 用量指標](monitoring-athena-usage-metrics.md) + **監控查詢事件** – 使用 Amazon EventBridge 來接收查詢狀態的即時通知。如需詳細資訊，請參閱[使用 EventBridge 監控 Athena 查詢事件](athena-events.md)。 + **建立資料用量控制** – 在 Athena 中，您可以設定每一查詢和每一工作群組資料用量控制。Athena 會在超過指定閾值時取消查詢，或在超過工作群組閾值時啟用 Amazon SNS 警示。如需詳細資訊，請參閱[設定每一查詢和每一工作群組資料用量控制](workgroups-setting-control-limits-cloudwatch.md)。 + **使用成本分配標籤** – 使用帳單和成本管理主控台為工作群組加上成本分配標籤。與工作群組中執行查詢相關聯的成本會在成本和用量報告中顯示，並具有相應的成本分配標籤。如需詳細資訊，請參閱《AWS Billing 使用者指南**》中的[使用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)。 + **使用容量保留** – 您可以使用指定的資料處理單位數目來建立容量保留，並將一或多個工作群組新增至保留。如需詳細資訊，請參閱[管理查詢處理容量](capacity-management.md)。 如需有關使用 Athena 工作群組分隔工作負載、控制使用者存取和管理查詢用量和成本的其他資訊，請參閱 AWS 大數據部落格文章[使用 Amazon Athena 工作群組分隔查詢和管理成本](https://aws.amazon.com/blogs/big-data/separating-queries-and-managing-costs-using-amazon-athena-workgroups/)。 **注意** Amazon Athena 資源現可在 Amazon SageMaker Unified Studio (預覽版) 內進行存取，如此可協助您存取組織的資料，並使用最佳工具對其採取行動。您可以將儲存的查詢從 Athena 工作群組移轉至 SageMaker Unified Studio 專案、使用現有的 Athena 工作群組設定專案，以及透過 IAM 角色更新維護必要許可。如需詳細資訊，請參閱[將 Amazon Athena 資源移轉至 Amazon SageMaker Unified Studio (預覽版)](https://github.com/aws/Unified-Studio-for-Amazon-Sagemaker/tree/main/migration/athena)。 ## 考量和限制 當您在 Athena 中使用工作群組時，請謹記以下幾點： + 每個帳戶都有一個主要工作群組。在預設情況下，如果您尚未建立任何工作群組，則您帳戶中的所有查詢會在主要工作群組中執行。無法刪除主要工作群組。預設許可允許所有已驗證身分的使用者存取該工作群組。 + 當您能夠存取工作群組時，您可以檢視工作群組的設定、指標和資料用量控制限制。利用額外的許可，您可以編輯設定和資料用量控制限制。 + 當您執行查詢時，它們會在目前工作群組中執行。您可以在主控台中，透過 API 操作、命令列介面或使用 JDBC 或 ODBC 驅動器的用戶端應用程式，在工作群組的內容中執行查詢。 + 在 Athena 主控台查詢編輯器中，每個工作群組最多可開啟十個查詢索引標籤。在工作群組之間切換時，您的查詢索引標籤最多可以在三個工作群組中保持開啟。 + AWS 區域 您帳戶中的每個 最多可建立 1000 個工作群組。 + 工作群組可以停用。停用工作群組會阻止查詢在該工作群組中執行，直到您重新啟用該工作群組。 + 如果您嘗試刪除包含已儲存查詢的工作群組，Athena 會向您發出警告。在您刪除其他使用者可存取的工作群組之前，請確保其可以存取能夠讓他們用於執行查詢的其他工作群組。 **Topics** + [考量和限制](#workgroups-considerations-limitations) + [建立工作群組](creating-workgroups.md) + [受管工作群組](workgroups-create-update-delete.md) + [使用 CloudWatch 和 EventBridge 來監控查詢](workgroups-control-limits.md) + [使用 Athena 工作群組 API](workgroups-api-list.md) + [對工作群組進行疑難排解](workgroups-troubleshooting.md) # 建立工作群組 建立工作群組需要有執行 `CreateWorkgroup` API 動作的許可。請參閱 [設定存取工作群組和標籤](workgroups-access.md) 和 [使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。如果您新增標籤，您也需要將許可新增到 `TagResource`。請參閱 [工作群組的標籤政策範例](tags-access-control.md#tag-policy-examples-workgroups)。 下列程序說明如何使用 Athena 主控台來建立工作群組。若要使用 Athena API 建立工作群組，請參閱 [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html)。 **在 Athena 主控台中建立工作群組** 1. 決定建立哪些工作群組。要考量的幾個關鍵因素包括： + 誰可以在每個工作群組中執行查詢，以及誰擁有工作群組的組態。使用 IAM 政策來強制執行工作群組許可。如需詳細資訊，請參閱[使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。 + Amazon S3 中用於存放工作群組查詢結果的位置。工作群組的所有使用者必須能夠存取這個位置。 + 工作群組查詢結果是否必須加密。由於加密是按工作群組 (而不是按查詢) 進行的，因此您應該為加密和非加密的查詢結果建立單獨的工作群組。如需詳細資訊，請參閱[加密 Amazon S3 中存放的 Athena 查詢結果](encrypting-query-results-stored-in-s3.md)。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 ![\[選擇展開選單。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/nav-pane-expansion.png) 1. 在 Athena 主控台導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 在 **Workgroups** (工作群組) 頁面中，請選擇 **Create workgroup** (建立工作群組)。 1. 在 **Create workgroup** (建立工作群組) 頁面上，如下所示填寫欄位： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/creating-workgroups.html) 1. 選擇**建立工作群組**。工作群組會出現在 **Workgroups** (工作群組) 頁面上的清單。 在查詢編輯器中，Athena 會在位於主控台右上角的**工作群組**選項中顯示目前工作群組。您可以使用此選項來切換工作群組。當您執行查詢時，它們會在目前工作群組中執行。 1. 建立 IAM 政策以允許使用者、群組或角色存取工作群組。政策建立工作群組成員資格和在 `workgroup` 資源上的動作存取權。如需詳細資訊，請參閱[使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。如需 JSON 政策的範例，請參閱[設定存取工作群組和標籤](workgroups-access.md)。 1. (選用) 當覆寫用戶端設定選項不會強制執行工作群組整體加密時，在 Amazon S3 中對該工作群組的所有查詢結果設定最低層級的加密。您可以使用此功能，確保查詢結果絕不會儲存在處於未加密狀態的 Amazon S3 儲存貯體中。如需詳細資訊，請參閱[為工作群組設定最低加密](workgroups-minimum-encryption.md)。 1. (選用) 使用 Amazon CloudWatch 和 Amazon EventBridge 來監控工作群組的查詢和控制成本。如需詳細資訊，請參閱[使用 CloudWatch 和 EventBridge 來監控查詢和控制成本](workgroups-control-limits.md)。 1. (選用) 使用帳單和成本管理主控台為工作群組加上成本分配標籤。如需詳細資訊，請參閱《AWS Billing 使用者指南**》中的[使用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)。 1. (選用) 若要取得工作群組中查詢的專用處理容量，請將該工作群組新增至容量保留。您可以將一或多個工作群組指派給預留。如需詳細資訊，請參閱[管理查詢處理容量](capacity-management.md)。 # Override client-side settings (覆寫用戶端設定) 當您建立或編輯工作群組時，您可以選擇**覆寫用戶端設定**選項。預設不會選取此選項。視您是否選取它而定，Athena 的行為如下： + 如果未選取**覆寫用戶端設定**，則不會在用戶端層級強制工作群組設定。當未為工作群組選取覆寫用戶端設定選項時，Athena 將對工作群組中執行的所有查詢使用用戶端的設定，包括查詢結果位置、預期的儲存貯體擁有者、加密和對寫入查詢結果儲存貯體之物件的控制等的設定。每個使用者可以在主控台的**設定**選單中指定其自己的設定。如果不設定用戶端設定，則會套用工作群組整體設定。如果您使用 AWS CLI、 API 動作或 JDBC 和 ODBC 驅動程式，在不覆寫用戶端設定的工作群組中執行查詢，您的查詢會使用您在查詢中指定的設定。 + 如果選取**覆寫用戶端設定**，則會在工作群組層級強制工作群組中所有用戶端執行工作群組設定。當為工作群組選取覆寫用戶端設定選項時，Athena 將對工作群組中執行的所有查詢使用工作群組的設定，包括查詢結果位置、預期的儲存貯體擁有者、加密和對寫入查詢結果儲存貯體之物件的控制等的設定。當您使用主控台、API 動作或 JDBC 或 ODBC 驅動程式時，工作群組設定會覆寫您為查詢指定的任何用戶端設定。將工作群組設定設定為覆寫用戶端設定之後，可以省略驅動器或 API 中的用戶端設定。 如果您覆寫使用者端設定，則您或任何工作群組使用者下次開啟 Athena 主控台時，Athena 會向您告知此工作群組中的查詢使用工作群組的設定，並提示您確認此變更。 **注意** 由於覆寫用戶端設定可能會中斷根據任意 Amazon S3 儲存貯體中結果可用性的自訂自動化，我們建議您在覆寫之前先通知使用者。 **重要** 如果您使用 API 動作 AWS CLI、 或 JDBC 和 ODBC 驅動程式在覆寫用戶端設定的工作群組中執行查詢，請確定您省略查詢中的用戶端設定，或更新它們以符合工作群組的設定。 如果您在查詢中指定用戶端設定，但在覆寫設定的工作群組中執行這些設定，則將會使用工作群組設定執行查詢。如需有關檢視工作群組設定的資訊，請參閱 [檢視工作群組的詳細資訊](viewing-details-workgroups.md)。 # 受管工作群組 在 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 的 Athena 主控台中，您可以執行下列任務： | 陳述式 | Description | | --- | --- | | [建立工作群組](creating-workgroups.md) | 建立新的工作群組。 | | [檢視工作群組的詳細資訊](viewing-details-workgroups.md) | 檢視工作群組的詳細資訊，例如其名稱、描述、資料用量限制、查詢結果的位置、預期查詢結果儲存貯體擁有者、加密和對寫入查詢結果儲存貯體之物件的控制。如果已勾選 Override client-side settings (覆寫用戶端設定)，您也可以驗證此工作群組是否強制其設定。 | | [指定查詢的工作群組](specify-wkgroup-to-athena-in-which-to-run-queries.md) | 您必須向 Athena 指定要使用的工作群組，才能執行查詢。您必須具有此工作群組的許可。 | | [切換工作群組](switching-workgroups.md) | 在您可以存取的工作群組之間切換。 | | [編輯工作群組](editing-workgroups.md) | 編輯工作群組和變更其設定。您無法變更工作群組的名稱，但可以使用相同的設定和不同的名稱來建立新的工作群組。 | | [啟用或停用工作群組](workgroups-enabled-disabled.md) | 啟用或停用工作群組。當工作群組停用時，其使用者無法執行查詢，或建立新的具名查詢。如果您可以存取此工作群組，則您仍可以檢視指標、資料用量限制控制、工作群組的設定、查詢歷史記錄和儲存的查詢。 | | [在工作群組之間複製儲存的查詢](copy-a-query-between-workgroups.md) | 在工作群組之間複製儲存的查詢。例如，如果您在預覽工作群組中建立了查詢，並且想要在非預覽工作群組中使用該查詢，則您可能需要執行此操作。 | | [刪除工作群組](deleting-workgroups.md) | 刪除工作群組。如果您刪除工作群組，將會刪除查詢歷史記錄、儲存的查詢、工作群組的設定和每一查詢資料限制控制。CloudWatch 中會保留工作群組整體的資料限制控制，您可以個別刪除它們。 無法刪除主要工作群組。 | | [使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md) | 使用 IAM 政策來控制工作群組存取權。如需工作群組政策的範例，請參閱 [工作群組政策範例](example-policies-workgroup.md)。 | | [建立使用 IAM Identity Center 身分驗證的 Athena 工作群組](workgroups-identity-center.md) | 若要將 IAM Identity Center 身分與 Athena 搭配使用，您必須建立啟用 IAM Identity Center 的工作群組。建立工作群組後，您可以使用 IAM Identity Center 主控台或 API，將 IAM Identity Center 使用者或群組指派給工作群組。 | | [為工作群組設定最低加密](workgroups-minimum-encryption.md) | 在 Amazon S3 對工作群組的所有查詢結果強制執行最低層級的加密。使用此功能，確保查詢結果絕不會儲存在處於未加密狀態的 Amazon S3 儲存貯體中。 | # 檢視工作群組的詳細資訊 對於每個工作群組，您可以查看其詳細資訊。詳細資訊包括工作群組的名稱、描述、已啟用或停用，以及工作群組中執行的查詢所使用的設定，其中包括查詢結果的位置、預期的儲存貯體擁有者、加密和對寫入查詢結果儲存貯體之物件的控制。如果工作群組有資料用量限額，則也會顯示。 **若要檢視工作群組的詳細資訊** 1. 在 Athena 主控台導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 在 **Workgroups** (工作群組) 頁面上，請選擇您要檢視的工作群組連結。工作群組的 **Overview Details** (概觀詳細資料) 頁面隨即會顯示。 # 指定查詢的工作群組 若要指定使用的工作群組，您必須具有此工作群組的許可。 **指定工作群組使用** 1. 請確認您的許可允許您在您想要使用在工作群組中執行查詢。如需詳細資訊，請參閱[使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。 1. 若要指定工作群組，請使用以下其中一個選項： + 如果您正在使用 Athena 主控台，請[切換工作群組](switching-workgroups.md)來設定工作群組。 + 如果您是使用 Athena API 操作，請在 API 動作中指定工作群組名稱。例如，您可以在 [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) 中設定工作群組名稱，如下所示： ``` StartQueryExecutionRequest startQueryExecutionRequest = new StartQueryExecutionRequest() .withQueryString(ExampleConstants.ATHENA_SAMPLE_QUERY) .withQueryExecutionContext(queryExecutionContext) .withWorkGroup(WorkgroupName) ``` + 如果您是使用 JDBC 或 ODBC 驅動程式，請在連線字串中使用 `Workgroup` 組態參數來設定工作群組名稱。驅動程式會將工作群組名稱傳遞給 Athena。在連線字串中指定工作群組參數，如下列範例所示： ``` jdbc:awsathena://AwsRegion=;UID=; PWD=;S3OutputLocation=s3://amzn-s3-demo-bucket/-/; Workgroup=; ``` # 切換工作群組 如果您對兩個工作群組都有許可，您可以從其中一個切換到另一個。 在每個工作群組內，您最多可以開啟十個查詢索引標籤。在工作群組之間切換時，您的查詢索引標籤最多可以在三個工作群組中保持開啟。 **切換工作群組** 1. 在 Athena 主控台中，使用右上角的 **Workgroup** (工作群組) 選項選擇工作群組。 1. 如果**工作群組 *workgroup-name* 設定**對話方塊出現時，請選擇 **Acknowledge** (確認)。 **Workgroup** (工作群組) 選項會顯示您已切換到其中的工作群組名稱。您現在可以在此工作群組中執行查詢。 # 編輯工作群組 編輯工作群組需要有執行 `UpdateWorkgroup` API 操作的許可。請參閱 [設定存取工作群組和標籤](workgroups-access.md) 和 [使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。如果您新增或編輯標籤，您也需要有 `TagResource` 的許可。請參閱 [工作群組的標籤政策範例](tags-access-control.md#tag-policy-examples-workgroups)。 **在主控台編輯工作群組** 1. 在 Athena 主控台導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 在 **Workgroups** (工作群組) 頁面上，選取您要編輯的工作群組的按鈕。 1. 選擇 **Actions** (動作)、**Edit** (編輯)。 1. 請依需求變更欄位。關於欄位清單，請參閱[建立工作群組](creating-workgroups.md)。工作群組的名稱除外，您可以變更所有欄位。如果您需要變更名稱，請使用新的名稱和相同的設定建立另一個工作群組。 1. 選擇**儲存變更**。更新的工作群組會出現在 **Workgroups** (工作群組) 頁面上的清單。 # 啟用或停用工作群組 如果您有許可這樣做，您可以在主控台、使用 API 操作或透過 JDBC 和 ODBC 驅動程式來啟用或停用工作群組。 **若要啟用或停用工作群組** 1. 在 Athena 主控台導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 在 **Workgroups** (工作群組) 頁面上，請選擇工作群組的連結。 1. 在右上角，選擇 **Enable workgroup** (啟用工作群組) 或 **Disable workgroup** (停用工作群組)。 1. 在確認提示時，選擇 **Enable** (啟用) 或 **Disable** (停用)。如果您停用工作群組，則其使用者無法在其中執行查詢，或建立新的具名查詢。如果您啟用工作群組，使用者可以使用它來執行查詢。 # 在工作群組之間複製儲存的查詢 Athena 主控台目前沒有將儲存的查詢從某個工作群組直接複製到另一個工作群組的選項，但您可以使用下列程序手動執行相同的任務。 **若要在工作群組之間複製儲存的查詢** 1. 在 Athena 主控台中，從您想要從中複製查詢的工作群組中，選擇 **Saved queries** (儲存的查詢) 索引標籤。 1. 選擇您想要複製的已儲存查詢連結。Athena 會在查詢編輯器中開啟查詢。 1. 在查詢編輯器中，選取查詢文字，然後按下 **Ctrl\$1C** 以進行複製。 1. [切換](switching-workgroups.md)至目的地工作群組，或[建立工作群組](creating-workgroups.md)，然後切換至該工作群組。 1. 在查詢編輯器中開啟新索引標籤，然後按下 **Ctrl\$1V** 將文字貼到新索引標籤中。 1. 在查詢編輯器中，選擇 **Save as** (另存為)，將查詢儲存在目的地工作群組中。 1. 在 **Choose a name** (選擇名稱) 對話方塊中，輸入查詢的名稱和選擇性描述。 1. 選擇**儲存**。 # 刪除工作群組 如果您有許可刪除工作群組，您可以這樣做。無法刪除主要工作群組。 如有許可，您可以隨時刪除空的工作群組。您也可以刪除包含儲存的查詢的工作群組。在這種情況下，在繼續刪除工作群組之前，Athena 會警告將刪除儲存的查詢。 如果您刪除自己所在的工作群組，主控台將焦點切換到主要工作群組。如果您有它的存取權，則可以執行查詢和檢視其設定。 如果您刪除工作群組，則其設定和每一查詢資料限制控制也會刪除。CloudWatch 中會保留工作群組整體的資料限制控制，您可以視需要刪除它們。 **重要** 在刪除工作群組之前，請確定其使用者也屬於能夠讓他們繼續執行查詢的其他工作群組。如果使用者的 IAM 政策*僅*允許他們在此工作群組中執行查詢，而且您刪除此工作群組，則他們再也沒有許可來執行查詢。如需詳細資訊，請參閱[Example policy for running queries in the primary workgroup](example-policies-workgroup.md#example4-run-in-primary-access)。 **在主控台刪除工作群組** 1. 在 Athena 主控台導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 在 **Workgroups** (工作群組) 頁面上，選取您要刪除的工作群組的按鈕。 1. 選擇 **動作**、**刪除**。 1. 在 **Delete workgroup** (刪除工作群組) 確認提示中，輸入工作群組的名稱，然後選擇 **Delete** (刪除)。 若要使用 API 操作來刪除工作群組，請使用 `DeleteWorkGroup` 動作。 # 使用 CloudWatch 和 EventBridge 來監控查詢和控制成本 工作群組可讓您設定每一查詢或每一工作群組的資料用量控制限制，設定超過這些限制時的警示，以及將查詢指標發布至 CloudWatch。 在每個工作群組中，您可以： + 設定每一查詢和每一工作群組的 **Data usage controls (資料用量控制)**，並建立當查詢超出閾值時將採取的動作。 + 檢視和分析查詢指標，並將其發布至 CloudWatch。如果您在主控台中建立工作群組，則系統會為您選取將指標發布至 CloudWatch 的設定。如果您使用 API 操作，您必須[啟用發布指標](athena-cloudwatch-metrics-enable.md)。發布指標時，其會顯示在 **Workgroups** (工作群組) 面板中的 **Metrics** (指標) 索引標籤。對於主要工作群組，預設會停用指標。 ## 影片 下列影片說明如何在 CloudWatch 中建立自訂儀表板，以及設定指標的警示和觸發。您可以直接從 Athena 主控台使用預先填入的儀表板，以使用這些查詢指標。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/x1V_lhkdKCg/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/x1V_lhkdKCg) **Topics** + [影片](#athena-cloudwatch-metrics-video) + [啟用查詢指標](athena-cloudwatch-metrics-enable.md) + [使用 CloudWatch 監控查詢指標](query-metrics-viewing.md) + [使用 CloudWatch 監控用量指標](monitoring-athena-usage-metrics.md) + [使用 EventBridge 監控查詢事件](athena-events.md) + [設定資料用量控制](workgroups-setting-control-limits-cloudwatch.md) # 在 Athena 中啟用 CloudWatch 查詢指標 當您在主控台中建立工作群組時，系統預設會選取將查詢指標發布至 CloudWatch 的設定。 **若要在 Athena 主控台中啟用或停用工作群組的查詢指標** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 ![\[選擇展開選單。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/nav-pane-expansion.png) 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 選擇您想要修改的工作群組連結。 1. 在工作群組的詳細資訊頁面上，選擇 **Edit** (編輯)。 1. 在**設定**區段中，選取或清除將**查詢指標發佈至 AWS CloudWatch**。 如果您使用 API 操作、命令列界面或具有 JDBC 驅動程式的用戶端應用程式來建立工作群組，啟用查詢指標的發布，請在 [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html) 中將 `PublishCloudWatchMetricsEnabled` 設定為 `true`。以下範例只顯示指標組態，而省略其他組態： ``` "WorkGroupConfiguration": { "PublishCloudWatchMetricsEnabled": "true" .... } ``` # 使用 CloudWatch 監控 Athena 查詢指標 當已選取 [publish query metrics to CloudWatch](athena-cloudwatch-metrics-enable.md) (將查詢指標發布至 CloudWatch) 選項時，Athena 會將查詢相關指標發布至 Amazon CloudWatch。您可以建立自訂儀表板，在 CloudWatch 中設定指標的警示和觸發，或直接從 Athena 主控台使用預先填入的儀表板。 當您為工作群組中的查詢啟用查詢指標時，Athena 主控台中每個工作群組的指標會顯示在 **Workgroups** (工作群組) 面板中的 **Metrics** (指標) 索引標籤中。 Athena 會將以下指標發布至 CloudWatch 主控台： + `DPUAllocated` – 在容量保留中佈建的用於執行查詢的 DPU (資料處理單位) 總數。 + `DPUConsumed` – 在指定的時間，容量保留中處於 `RUNNING` 狀態的查詢主動使用的 DPU 數目。僅當工作群組與容量保留相關聯，並包含與保留關聯的所有工作群組時，才會發出指標。 + `DPUCount` – 查詢使用的 DPU 數目上限，僅當查詢完成時發布一次。 + `EngineExecutionTime` – 執行查詢所花費的毫秒數。 + `ProcessedBytes` – Athena 在每次 DML 查詢所掃描的位元組。 + `QueryPlanningTime` – Athena 規劃查詢處理流程所花費的毫秒數。 + `QueryQueueTime` – 查詢在查詢佇列中等待資源的毫秒數。 + `ServicePreProcessingTime` – 提交查詢至查詢引擎之前，Athena 預先處理查詢所花費的毫秒數。 + `ServiceProcessingTime` – 查詢引擎完成查詢的執行後，Athena 處理查詢結果所花費的毫秒數。 + `TotalExecutionTime` – Athena 執行 DDL 或 DML 查詢所花費的毫秒數。 如需更完整的描述，請參閱本文件稍後的 [Athena 的 CloudWatch 指標和維度清單](#athena-cloudwatch-metrics-table)。 這些指標具有下列維度： + `CapacityReservation`– 用於執行查詢的容量保留名稱 (如果適用)。 + `QueryState` – `SUCCEEDED`、`FAILED` 或 `CANCELED` + `QueryType` – `DML`、`DDL` 或 `UTILITY` + `WorkGroup` – 工作群組的名稱 Athena 會將以下指標發布至 `AmazonAthenaForApacheSpark` 命名空間下的 CloudWatch 主控台： + `DPUCount` – 工作階段期間用來執行計算所消耗的 DPU 數目。 該指標具有下列兩個維度： + `SessionId` – 要提交計算的工作階段 ID。 + `WorkGroup` – 工作群組的名稱。 如需詳細資訊，請參閱本主題稍後的[Athena 的 CloudWatch 指標和維度清單](#athena-cloudwatch-metrics-table)。如需有關 Athena 用量指標的資訊，請參閱[使用 CloudWatch 監控 Athena 用量指標](monitoring-athena-usage-metrics.md)。 您可以在 Athena 主控台或 CloudWatch 主控台中檢視查詢指標。 ## 在 Athena 主控台中檢視查詢指標 **在 Athena 主控台中檢視工作群組的查詢指標** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 ![\[選擇展開選單。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/nav-pane-expansion.png) 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 從清單中選擇所需的工作群組，然後選擇 **Metrics** (指標) 索引標籤。 指標儀表板隨即顯示。 **注意** 如果您最近剛啟用工作群組的指標，且/或最近沒有任何查詢活動，儀表板上的圖形可能會是空白的狀態。系統會根據您在下一個步驟中指定的間隔，從 CloudWatch 擷取查詢活動。 1. 在 **Metrics** (指標) 區段中，選擇 Athena 應用來從 CloudWatch 擷取查詢指標的指標間隔，或指定自訂間隔。 ![\[指定 Athena 主控台中工作群組的指標擷取間隔。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/wg-custom-interval.png) 1. 若要重新整理顯示的指標，請選擇重新整理圖示。 ![\[選擇重新整理圖示。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/wg-refresh-metrics.png) 1. 按一下重新整理圖示旁的箭頭，以選擇您希望指標顯示的更新頻率。 ![\[選擇 Athena 主控台中工作群組指標顯示的重新整理間隔。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/wg-choose-refresh-interval.png) ## 在 CloudWatch 主控台中檢視查詢指標 **若要在 Amazon CloudWatch 主控台中檢視指標** 1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。 1. 在導覽窗格中，選擇 **Metrics** (指標)、**All metrics** (所有指標)。 1. 選取 **AWS/Athena** 命名空間。 ## 使用 檢視查詢指標 AWS CLI **使用 檢視指標 AWS CLI** + 執行以下任意一項： + 若要列出 Athena 的指標，請開啟命令提示，然後使用下列命令： ``` aws cloudwatch list-metrics --namespace "AWS/Athena" ``` + 若要列出所有可用的指標，請使用以下命令： ``` aws cloudwatch list-metrics" ``` ## Athena 的 CloudWatch 指標和維度清單 如果您已在 Athena 中啟用 CloudWatch 指標，其會按照工作群組將以下指標傳送到 CloudWatch。下列指標使用 `AWS/Athena` 命名空間。 | 指標名稱 | Description | | --- | --- | | DPUAllocated | 在容量保留中佈建的用於執行查詢的 DPU (資料處理單位) 總數。 | | DPUConsumed | 在給定的時間，保留區中處於 RUNNING 狀態的查詢主動使用的 DPU 數目。僅當工作群組與容量保留相關聯並包含與保留關聯的所有工作群組時，才會發出這個指標。如果您將工作群組從一個保留區移至另一個保留區，則該指標會包含該工作群組屬於第一個保留區時的資料。如需有關容量保留的詳細資訊，請參閱 [管理查詢處理容量](capacity-management.md)。 | | DPUCount | 查詢使用的 DPU 數目上限，僅當查詢完成時發布一次。只有附加至容量保留的工作群組才會發出此指標。 | | EngineExecutionTime | 查詢執行所花費的毫秒數。 | | ProcessedBytes | Athena 在每次 DML 查詢所掃描的位元組。對於取消的查詢 (無論是由使用者取消，或達到上限時自動取消)，這包括取消前掃描的資料量。DDL 查詢不會報告此指標。 | | QueryPlanningTime | Athena 規劃查詢處理流程所花費的毫秒數。這包括從資料來源擷取資料表分割區所花費的時間。請注意，因為查詢引擎會執行查詢規劃，所以查詢規劃時間是 EngineExecutionTime 的子集。 | | QueryQueueTime | 查詢在查詢佇列中等待資源的毫秒數。請注意，如果發生暫時性錯誤，查詢可能自動加回到佇列。 | | ServicePreProcessingTime | 提交查詢至查詢引擎之前，Athena 預先處理查詢所花費的毫秒數。 | | ServiceProcessingTime | 查詢引擎完成查詢的執行後，Athena 處理查詢結果所花費的毫秒數。 | | TotalExecutionTime | Athena 執行 DDL 或 DML 查詢所花費的毫秒數。TotalExecutionTime 包括 QueryQueueTime、QueryPlanningTime、EngineExecutionTime 和 ServiceProcessingTime。 | Athena 的這些指標具有下列維度。 | 維度 | Description | | --- | --- | | CapacityReservation | 用於執行查詢的容量保留名稱 (如果適用)。當未使用容量保留時，此維度不會傳回任何資料。 | | QueryState | 查詢狀態。 有效的統計資訊：已成功、已失敗、已取消。 | | QueryType | 查詢類型。 有效的統計資訊：`DDL`、`DML` 或 `UTILITY`。執行的查詢陳述式類型。`DDL` 表示 DDL (資料定義語言) 查詢陳述式。`DML` 表示 DML (資料處理語言) 查詢陳述式，例如 `CREATE TABLE AS SELECT`。`UTILITY` 表示除 DDL 和 DML 以外的查詢陳述式，例如 `SHOW CREATE TABLE` 或 `DESCRIBE TABLE`。 | | WorkGroup | 工作群組的名稱。 | # 使用 CloudWatch 監控 Athena 用量指標 您可使用 CloudWatch 用量指標，透過在 CloudWatch 圖表和儀表板中顯示目前的服務使用量狀況，瞭解您的帳戶如何使用資源。 對於 Athena，用量可用性指標對應至 Athena AWS 服務 的配額。您可以設定警示，在您的用量接近服務配額時發出警示。如需有關 Athena 服務配額的詳細資訊，請參閱[Service Quotas](service-limits.md)。如需 AWS 用量指標的詳細資訊，請參閱《*Amazon CloudWatch 使用者指南*》中的[AWS 用量指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Service-Quota-Integration.html)。 Athena 在 `AWS/Usage` 命名空間中發布下列指標。 | 指標名稱 | Description | | --- | --- | | `ResourceCount` | AWS 區域 每個帳戶所有佇列和執行查詢的總和，依查詢類型 (DML 或 DDL) 分隔。此指標唯一實用的統計資料是「上限」。 此指標每分鐘定期發布一次。如果您沒有執行任何查詢，則指標不會報告任何內容 (甚至不會報告 0)。僅當採用指標時正在執行啟用查詢時，指標才會發布。 | 下列維度用於強化 Athena 所發布的用量指標。 | 維度 | Description | | --- | --- | | `Service` | AWS 服務 包含資源的 名稱。對 Athena 而言，此維度的數值為 `Athena`。 | | `Resource` | 正在執行的資源類型。Athena 查詢用量的資源值為 `ActiveQueryCount`。 | | `Type` | 正在報告的實體類型。目前，Athena 用量指標的唯一有效值為 `Resource`。 | | `Class` | 正在追蹤的資源類別。對 Athena 而言，`Class` 可以是 `DML` 或 `DDL`。 | ## 在 CloudWatch 主控台中檢視 Athena 資源用量指標 您可以使用 CloudWatch 主控台查看 Athena 用量指標圖表，並設定警示在用量接近服務配額時提醒您。 **檢視 Athena 資源用量指標** 1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。 1. 在導覽窗格中，選擇 **Metrics** (指標)、**All metrics** (所有指標)。 1. 選擇**用量**，然後選擇**依據 AWS 資源**。 服務配額用量指標清單隨即出現。 1. 選取 **Athena** 和 **ActiveQueryCount** 旁的核取方塊。 1. 選擇 **Graphed metrics (圖表化指標)** 標籤。 上圖顯示資源的目前用量 AWS 。 如需了解如何將服務配額新增至圖表，以及設定警示，讓系統在用量接近服務配額時通知您，請參閱*《Amazon CloudWatch 使用者指南》*中[視覺化您的服務配額和設定警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html)。如需設定每個工作群組用量限制的詳細資訊，請參閱 [設定每一查詢和每一工作群組資料用量控制](workgroups-setting-control-limits-cloudwatch.md)。 # 使用 EventBridge 監控 Athena 查詢事件 您可以搭配使用 Amazon EventBridge 與 Amazon Athena，以接收有關查詢狀態的即時通知。當您提交的查詢轉換狀態時，Athena 會將事件發布至 EventBridge，當中包含該查詢狀態轉換的相關資訊。您可以針對感興趣的事件撰寫簡單的規則，並在事件符合規則時採取自動化動作。例如，您可以建立規則，在查詢達到終端狀態時叫用 AWS Lambda 函數。盡可能發出事件。 在您為 Athena 建立事件規則之前，請執行下列動作： + 熟悉 Eventbridge 中的事件、規則和目標。如需詳細資訊，請參閱[什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 如需有關如何設定規則的詳細資訊，請參閱 [Amazon EventBridge 入門](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)。 + 建立要在事件規則中使用的一或多個目標。 **注意** Athena 目前提供一種事件類型 (Athena 查詢狀態變更)，但可能會新增其他事件類型和詳細資訊。如果您是透過程式設計方式將事件 JSON 資料還原序列化，請確定您的應用程式在新增這些額外屬性時已準備好處理不明屬性。 ## Athena 事件格式 以下是 Amazon Athena 事件的基本模式。 ``` { "source":[ "aws.athena" ], "detail-type":[ "Athena Query State Change" ], "detail":{ "currentState":[ "SUCCEEDED" ] } } ``` ## Athena 查詢狀態變更事件 下列範例會顯示 `currentState` 值為 `SUCCEEDED` 的 Athena 狀態變更事件。 ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "versionId":"0", "currentState":"SUCCEEDED", "previousState":"RUNNING", "statementType":"DDL", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` 下列範例會顯示 `currentState` 值為 `FAILED` 的 Athena 狀態變更事件。只有在 `currentState` 為 `FAILED` 時，才會顯示 `athenaError` 區塊。如需有關 `errorCategory` 和 `errorType` 值的詳細資訊，請參閱 [Athena 錯誤目錄](error-reference.md)。 ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "athenaError": { "errorCategory": 2.0, //Value depends on nature of exception "errorType": 1306.0, //Type depends on nature of exception "errorMessage": "Amazon S3 bucket not found", //Message depends on nature of exception "retryable":false //Retryable value depends on nature of exception }, "versionId":"0", "currentState": "FAILED", "previousState": "RUNNING", "statementType":"DML", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` ### 輸出屬性 JSON 輸出包含以下屬性。 **** | 屬性 | Description | | --- | --- | | athenaError | 只有在 currentState 為 FAILED 時才會顯示。包含發生之錯誤的相關資訊，包括錯誤類別、錯誤類型、錯誤訊息，以及是否可以重試導致錯誤的動作。每個欄位的值視錯誤性質而定。如需有關 errorCategory 和 errorType 值的詳細資訊，請參閱 [Athena 錯誤目錄](error-reference.md)。 | | versionId | 詳細資訊物件之結構描述的版本號碼。 | | currentState | 在事件發生時查詢所轉換成的狀態。 | | previousState | 在事件發生時查詢從其轉換的狀態。 | | statementType | 執行的查詢陳述式類型。 | | queryExecutionId | 查詢執行的唯一識別碼。 | | workgroupName | 執行查詢的工作群組名稱。 | | sequenceNumber | 單調遞增的數字，允許刪除重複和排序涉及所執行單一查詢的傳入事件。當針對相同的狀態轉換發布重複事件時，sequenceNumber 值是相同的。當查詢經歷一次以上的狀態轉換時 (例如遇到鮮少列入佇列的查詢)，您可以使用 sequenceNumber 來排序 currentState 和 previousState 值相同的事件。 | ## 範例 下列範例會將事件發布至您已訂閱的 Amazon SNS 主題。查詢 Athena 時，您會收到一封電子郵件。該範例假設 Amazon SNS 主題存在且您已訂閱該主題。 **若要將 Athena 事件發布至 Amazon SNS 主題** 1. 建立 Amazon SNS 主題的目標。授予 EventBridge 事件服務主體發布至 Amazon SNS 主題的 `events.amazonaws.com` 許可，如下列範例所示。 ``` { "Effect":"Allow", "Principal":{ "Service":"events.amazonaws.com" }, "Action":"sns:Publish", "Resource":"arn:aws:sns:us-east-1:111111111111:your-sns-topic" } ``` 1. 使用 AWS CLI `events put-rule`命令來建立 Athena 事件的規則，如下列範例所示。 ``` aws events put-rule --name {ruleName} --event-pattern '{"source": ["aws.athena"]}' ``` 1. 使用 AWS CLI `events put-targets`命令將 Amazon SNS 主題目標連接至規則，如下列範例所示。 ``` aws events put-targets --rule {ruleName} --targets Id=1,Arn=arn:aws:sns:us-east-1:111111111111:your-sns-topic ``` 1. 查詢 Athena 並觀察被叫用的目標。您應該會收到來自該 Amazon SNS 主題的相應電子郵件。 ## AWS 使用者通知 搭配 Amazon Athena 使用 您可使用 [AWS 使用者通知](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html) 來設定交付管道，以取得有關 Amazon Athena 事件的通知。當事件符合您指定的規則時，便會收到通知。您可以透過多個管道接收事件通知，包括電子郵件、[聊天應用程式中的 Amazon Q Developer](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) 聊天通知或 [AWS Console Mobile Application](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/what-is-consolemobileapp.html) 推送通知。您也可以在[主控台通知中心](https://console.aws.amazon.com/notifications/)查看通知。 使用者通知 支援彙總，這可以減少您在特定事件期間收到的通知數量。 如需詳細資訊，請參閱[「*AWS 使用者通知 使用者指南」*](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html)。 # 設定每一查詢和每一工作群組資料用量控制 Athena 可讓您設定兩種類型的成本控制：每一查詢限制和每一工作群組限制。對於每個工作群組，您只能設定一個每一查詢限制和多個每一工作群組限制。 + **每一查詢控制限制**指定每次查詢所掃描的資料總量。如果工作群組中執行的任何查詢超過此限制，則會取消。您在工作群組中只能建立一個每一查詢控制限制，它會套用到其中執行的每個查詢。如果您需要變更限制，請編輯限制。如需詳細步驟，請參閱[建立每一查詢資料用量控制](#configure-control-limit-per-query)。 + **工作群組整體資料用量控制限制**指定在指定期間內針對此工作群組中執行的所有查詢所掃描的資料總量。您可以為每一工作群組建立多個限制。工作群組整體查詢限制可讓您針對工作群組中執行的查詢所掃描的資料，在每小時或每日彙總上設定多個閾值。 如果掃描的資料總量超過閾值，您可以將通知推送至 Amazon SNS 主題。若要這麼做，請在 Athena 主控台中設定 Amazon SNS 警示和動作，以便在超過限制時通知管理員。如需詳細步驟，請參閱[建立每一工作群組資料用量控制](#configure-control-limit-per-workgroup)。對於 Athena 從 CloudWatch 主控台發布的任何指標，您也可以建立警示和動作。例如，您可以對失敗的查詢次數設定提醒。如果次數超過特定閾值，這個提醒可以觸發將電子郵件寄給管理員。如果超過限制，將會有動作將 Amazon SNS 警示通知傳送給指定的使用者。 您可以採取的其他動作： + 調用 Lambda 函數。如需詳細資訊，請參閱《Amazon Simple Notification Service 開發人員指南》**中的[使用 Amazon SNS 通知叫用 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda-as-subscriber.html)。 + 停用工作群組，以停止執行任何進一步的查詢。如需這些步驟，請參閱 [啟用或停用工作群組](workgroups-enabled-disabled.md)。 每一查詢限制和每一工作群組限制彼此獨立。每當超過任一限制時就會採取指定的動作。如果兩個或更多使用者在同一個工作群組中同時執行查詢，則可能每個查詢都不超過任何指定的限制，但掃描的資料總數超過每一工作群組的資料用量限制。在這種情況下，Amazon SNS 警示會傳送給使用者。 ## 建立每一查詢資料用量控制 **建立每一查詢資料用量控制** 每一查詢控制限制指定每次查詢所掃描的資料總量。如果工作群組中執行的任何查詢超過此限制，則會取消。已取消的查詢會按照 [Amazon Athena 定價](https://aws.amazon.com/athena/pricing/)計費。 **注意** 如果是已取消或失敗的查詢，Athena 可能已將局部結果寫入 Amazon S3。在這種情況下，Athena 不會從存放結果的 Amazon S3 字首中刪除這些局部結果。您必須移除含有局部結果的 Amazon S3 字首。Athena 使用 Amazon S3 分段上傳，將資料寫入 Amazon S3。我們建議您設定儲存貯體生命週期政策，指定當查詢失敗時結束分段上傳。如需詳細資訊，請參閱《Amazon Simple Storage Service 使用者指南》**中的[使用儲存貯體生命週期政策中止未完成的分段上傳](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config)。 在某些情況下，Athena 可能會自動重試查詢執行。在大多數情況下，這些查詢能夠成功完成，且查詢 ID 會標記為 `Completed`。這些查詢可能在初始嘗試期間已寫入部分結果，並可能產生未完成的分段上傳。 您在工作群組中只能建立一個每一查詢控制限制，它會套用到其中執行的每個查詢。如果您需要變更限制，請編輯限制。 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 從清單中選擇工作群組名稱。 1. 在**執行控制項**索引標籤上，選擇**編輯控制項**。 1. 編輯**資料掃描限制**的值。 + 指定介於 10 MB （最小值） 和 7 EB （最大值） 之間的值。 + 從下拉式清單中選取單位值 （例如 **Kilobytes KB** 或 **Exabytes EB**)。 **注意** 預設動作是在查詢超過限制時取消查詢。此設定無法變更。 1. 選擇**儲存**以立即套用您的變更。 ## 建立或編輯每一工作群組資料用量提醒 **建立或編輯每一工作群組資料用量提醒** 當工作群組中執行的查詢在特定時段內掃描指定數量的資料時，您可以設定多個提醒閾值。提醒會透過 Amazon CloudWatch 警示實作，並套用於工作群組中的所有查詢。達到閾值後，您可以讓 Amazon SNS 向您指定的使用者傳送電子郵件。達到閾值時，查詢作業不會自動取消。 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 從清單中選擇工作群組名稱。 1. 選擇 **Edit** (編輯) 以編輯工作群組的設定。 1. 向下捲動到並展開 **Workgroup data usage alerts - optional** (工作群組資料用量提醒 - 選用)。 1. 選擇 **Add alert** (新增提醒)。 1. 針對 **Data usage threshold configuration** (資料用量閾值組態)，指定值，如下所示： + 針對 **Data threshold** (資料閾值)，指定數字，然後從下拉式清單中選取單位值。 + 對於 **Time period** (期間)，請從下拉式清單中選擇期間。 + 針對 **SNS topic selection** (SNS 主題選擇)，請從下拉式清單中選擇 Amazon SNS 主題。或者，選擇 **Create SNS topic** (建立 SNS 主題)，直接前往 [Amazon SNS 主控台](https://console.aws.amazon.com/sns/v2/home)，建立 Amazon SNS 主題，並為 Athena 帳戶中的其中一個使用者設定主題訂閱。如需詳細資訊，請參閱《Amazon Simple Notification Service 開發人員指南》**中的 [Amazon SNS 入門](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)。 1. 如果您正在建立新提醒，請選擇 **Add alert** (新增提醒)，或選擇 **Save** (儲存) 來儲存現有提醒。 # 使用 Athena 工作群組 API 以下是一些用於 Athena 工作群組的 REST API 操作。在以下所有操作中 (`ListWorkGroups` 除外)，您必須指定工作群組。在其他操作中，例如 `StartQueryExecution`，工作群組參數是選擇性，此處未列出這些操作。如需操作的完整清單，請參閱 [Amazon Athena API 參考](https://docs.aws.amazon.com/athena/latest/APIReference/)。 + [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html) + [DeleteWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteWorkGroup.html) + [GetWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetWorkGroup.html) + [ListWorkGroups](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListWorkGroups.html) + [UpdateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateWorkGroup.html) # 對工作群組錯誤進行疑難排解 使用以下秘訣進行工作群組疑難排解。 + 檢查您的帳戶中個別使用者的許可。他們必須有權存取查詢結果的位置，以及您們想要在其中執行查詢的工作群組。如果他們想要切換工作群組，則還需要有這兩個工作群組的許可。如需相關資訊，請參閱[使用 IAM 政策來控制工作群組存取](workgroups-iam-policy.md)。 + 請注意 Athena 主控台中的內容，了解您將在哪個工作群組中執行查詢。如果您使用驅動程式，請務必設定為您需要的工作群組。如需相關資訊，請參閱[指定查詢的工作群組](specify-wkgroup-to-athena-in-which-to-run-queries.md)。 + 如果您使用 API 或驅動程式來執行查詢，您必須使用其中一種方式指定查詢結果位置：對於個別的查詢，使用 [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation) (用戶端)。在工作群組中，使用 [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html)。如果未以任何方式指定位置，Athena 會在查詢執行期時發出錯誤。 + 如果您以工作群組設定覆寫用戶端設定，您可能會遇到查詢結果位置方面的錯誤。例如，工作群組的使用者可能沒有許可，無法在 Amazon S3 中的工作群組位置存放查詢結果。在這種情況下，請新增必要的許可。 + 工作群組會對 API 操作的行為造成改變。您帳戶中的使用者在 IAM 中，對工作群組需要有以資源為基礎的許可，才能在這些工作群組中呼叫以下現有的 API 操作。如果沒有工作群組和工作群組動作的許可，下列 API 動作會擲出 `AccessDeniedException`：**CreateNamedQuery**、**DeleteNamedQuery**、**GetNamedQuery**、**ListNamedQueries**、**StartQueryExecution**、**StopQueryExecution**、**ListQueryExecutions**、**GetQueryExecution**、**GetQueryResults** 和 **GetQueryResultsStream** (此 API 動作只適用於驅動器，不公開為公有使用)。如需詳細資訊，請參閱《服務授權參考》**中的 [Amazon Athena 的動作、資源和條件索引鍵](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html)。 只有針對在使用者可存取的工作群組中執行的查詢，呼叫 **BatchGetQueryExecution** 和 **BatchGetNamedQuery** API 操作才會傳回查詢的相關資訊。如果使用者無法存取此工作群組，這些 API 操作會在未處理的 ID 清單中傳回未經授權的查詢 ID。如需詳細資訊，請參閱[使用 Athena 工作群組 API](workgroups-api-list.md)。 + 如果執行查詢的工作群組已設定有[強制的查詢結果位置](workgroups-settings-override.md)，請勿為 CTAS 查詢指定 `external_location`。在這種情況下，Athena 會發出錯誤，且指定 `external_location` 的查詢會失敗。例如，如果您覆寫用戶端的查詢結果位置設定，而強制工作群組使用其自己的位置，此查詢會失敗：`CREATE TABLE . WITH (format='Parquet', external_location='s3://amzn-s3-demo-bucket/test/') AS SELECT * FROM . LIMIT 10;` 您可能會看到下列錯誤。下表列出工作群組的一些相關錯誤和建議的解決方案。 **工作群組錯誤** | 錯誤 | 發生時情況... | | --- | --- | | 查詢狀態為 CANCELED (已取消)。超出掃描的位元組限制。 | 查詢達到每一查詢資料限制，並且被取消。請考慮重寫查詢，以讀取較少的資料，或聯絡您的帳戶管理員。 | | 使用者 arn:aws:iam::123456789012:user/abc 無權對資源 arn:aws:athena:us-east-1:123456789012:workgroup/workgroupname 執行 athena:StartQueryExecution | 使用者在工作群組中執行查詢，但沒有它的存取權。更新您的政策以提供此工作群組的存取權。 | | INVALID\$1INPUT。工作群組 已停用。 | 使用者在工作群組中執行查詢，但此工作群組已停用。管理員可能停用您的工作群組。也可能是您沒有它的存取權。在這兩種情況下，請聯絡有權修改工作群組的管理員。 | | INVALID\$1INPUT。找不到工作群組 。 | 使用者在工作群組中執行查詢，但此工作群組不存在。如果已刪除工作群組，則可能發生此情況。切換到另一個工作群組來執行您的查詢。 | | InvalidRequestException：呼叫 StartQueryExecution 操作時：未提供輸出位置。需要透過工作群組結果組態設定或作為 API 輸入來提供輸出位置。 | 使用者以 API 執行查詢，但未指定查詢結果的位置。您必須使用兩種方式之一來設定查詢結果的輸出位置：對於個別的查詢，使用 [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation) (用戶端)，或在工作群組中，使用 [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html)。 | | Create Table As Select 查詢失敗，因為該查詢已使用 'external\$1location' 屬性提交至 Athena 工作群組，而該工作群組會針對所有查詢強制執行集中輸出位置。請移除 'external\$1location' 屬性，然後重新提交查詢。 | 如果執行查詢的工作群組已設定[強制的查詢結果位置](workgroups-settings-override.md)，而且您為 CTAS 查詢指定 external\$1location。在這種情況下，請移除 external\$1location 並重新執行查詢。 | | 無法建立預備陳述式 prepared\$1statement\$1name。此工作群組中的預備陳述式數目超過 1000 的上限。 | 工作群組包含的預備陳述式超過 1000 的上限。若要解決此問題，請使用 [DEALLOCATE PREPARE](sql-deallocate-prepare.md) 以從工作群組中移除一或多個預備陳述式。或者，建立新的工作群組。 | # 管理查詢處理容量 您可以使用容量保留，為您在 Athena 中執行的查詢取得專用無伺服器處理容量。透過容量保留，您可以利用工作負載管理功能，協助您排定優先順序、控制和擴展最重要的工作負載。例如，您可以新增容量來控制可同時執行的查詢數量、選擇可使用容量的工作負載，以及在工作負載之間共用容量。容量是無伺服器且由 Athena 完全管理，只要您需要，就會為您保留。設定非常簡單，不需要變更 SQL 查詢。 若要取得查詢的處理能力，您可建立容量保留、指定所需的資料處理單位 (DPU) 數目，然後將一或多個工作群組指派給保留。 當您使用容量保留時，工作群組扮演著重要角色。工作群組可讓您將查詢組織成邏輯分組或使用案例。透過容量保留，您可以選擇性地將容量指派給工作群組，以便控制每個工作群組的查詢行為方式以及計費方式。如需有關工作群組的詳細資訊，請參閱 [使用工作群組來控制查詢存取和成本](workgroups-manage-queries-control-costs.md)。 將工作群組指派給容量保留可讓您優先處理這些查詢，因為它們會在預留容量上執行，且不計入您的 DDL 和 DML 查詢配額。例如，您可以將容量分配給用於時間敏感財務報告查詢的工作群組，以將這些查詢與其他工作群組中較不重要的查詢隔離。這可讓您預測關鍵工作負載的查詢執行，同時允許其他工作負載獨立執行。 您可以結合使用容量保留和工作群組，以滿足不同的需求。以下為一些範例案例： + **隔離重要的查詢** – 為了確保重要的工作負載具有所需的容量，請建立容量保留，並將其工作群組指派給保留。只有來自指派工作群組的查詢會使用保留的處理容量。例如，為了確保可靠執行支援生產應用程式的查詢，請將這些查詢的生產工作群組指派給容量保留。開發查詢時，請使用與保留無關的個別工作群組，並在就緒時將查詢移至生產工作群組。 + **在類似的工作負載之間共用容量** – 多個工作負載可以從一個保留中共用容量。這可讓您實現這些工作負載的可預測成本，並控制其並行。例如，如果您的排程工作負載可容忍延遲的查詢執行開始時間，您可以將其工作群組指派給單一保留。這樣可以釋放 DDL 和 DML 查詢配額，以便在相同帳戶中執行的互動式查詢，確保這些查詢以最少的延遲開始。 ## 了解 DPU 容量是以資料處理單位 (DPU) 為單位測量而得。DPUs代表 Athena 用來代表您存取和處理資料的無伺服器運算和記憶體資源。一個 DPU 通常提供 4 個 vCPUs和 16 GB 的記憶體。您持有DPUs 數量會影響您可以同時執行的查詢數量。例如，具有 256 個 DPU 的保留所支援的並行查詢數量大約是具有 128 個 DPU 的保留的兩倍。 如需有關估算容量需求的資訊，請參閱 [判斷容量需求](capacity-management-requirements.md)。如需定價資訊，請參閱 [Amazon Athena 定價](https://aws.amazon.com/athena/pricing/)。 ## 考量和限制 + 您可以根據掃描的資料，在同一帳戶中同時使用容量保留和每個查詢計費。 + 在容量保留上執行的查詢不會計入您的 DDL 和 DML 查詢配額。 + 如果您的容量忙於處理其他查詢，新提交的查詢會排入佇列，直到容量可用為止。佇列中允許的時間上限為 10 小時。 + 一個工作群組一次可以指派給一個容量保留。您總共可以將 20 個工作群組指派給單一保留。當您將多個工作群組指派給保留時，容量會跨工作群組共用，並根據其提交順序配置給查詢。由於 Athena 如何動態分配容量給查詢，執行順序可能會有所不同。 + Athena 會根據 DML 查詢的複雜性，自動將 4 到 124 DPUs 配置給 DML 查詢。DDL 查詢各使用 4 DPUs。如需詳細資訊，請參閱下列主題： + [判斷容量需求](capacity-management-requirements.md) + [控制容量用量](capacity-management-control-capacity-usage.md) + 每個容量保留所需的 DPUs 數目下限為 4。如需定價資訊，請參閱 [Amazon Athena 定價](https://aws.amazon.com/athena/pricing/)。 + 您可建立多達 100 個容量保留，每個帳戶和區域可建立多達 1,000 個 DPU 總數目上限。如果您的使用案例需要 1,000 個以上的 DPU，請聯絡 [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com?subject=Athena Provisioned Capacity DPU Limit Request)。 + 無法保證容量請求，且可能需要 30 分鐘才能完成。容量無法轉移至另一個容量保留 AWS 帳戶，或 AWS 區域。 + `DPUConsumed` CloudWatch 指標是以工作群組為單位，而非保留區為單位。因此，如果您將工作群組從一個保留區移至另一個保留區，則 `DPUConsumed` 指標會包含該工作群組屬於第一個保留區時的資料。如需有關使用 Athena 中的 CloudWatch 指標的詳細資訊，請參閱 [使用 CloudWatch 監控 Athena 查詢指標](query-metrics-viewing.md)。 + 若要刪除已指派給保留的工作群組，請先從保留中移除該工作群組。 + 不支援設定為使用 Apache Spark 的工作群組。 + 容量保留不適用於下列商業 AWS 區域： + 以色列 (特拉維夫) + 中東 (阿拉伯聯合大公國) + Middle East (Bahrain) + 亞太區域 (紐西蘭) **Topics** + [了解 DPU](#capacity-management-understanding-dpus) + [考量和限制](#capacity-management-considerations-limitations) + [判斷容量需求](capacity-management-requirements.md) + [建立容量保留](capacity-management-creating-capacity-reservations.md) + [控制容量用量](capacity-management-control-capacity-usage.md) + [自動調整容量](capacity-management-automatically-adjust-capacity.md) + [管理保留](capacity-management-managing-reservations.md) + [容量保留的 IAM 政策](capacity-reservations-iam-policy.md) + [Athena 容量保留 API](capacity-management-api-list.md) # 判斷容量需求 建立容量保留之前，您可以預估所需的容量，以便為其指派正確的 DPU 數目。而且，在使用保留後，您可能需要檢查保留的容量是不足還是過多。本主題說明可用來進行這些預估的技術，也說明評估用量和成本的一些 AWS 工具。 **Topics** + [預估所需的容量](#capacity-management-requirements-estimating) + [需要更多容量的跡象](#capacity-management-requirements-insufficient-capacity) + [檢查閒置容量](#capacity-management-requirements-idle-capacity) + [監控 DPU 使用量](#capacity-management-requirements-monitoring-dpu-consumption) ## 預估所需的容量 預估容量需求時，考慮兩個觀點非常有用：特定查詢可能需要多少容量，以及一般需要多少容量。 ### 預估每個查詢的容量需求 若要判斷查詢可能需要的 DPU 數目，您可以使用下列指導方針： + DDL 查詢會消耗 4 個 GPU。 + DML 查詢會消耗 4 到 124 個 GPU。 Athena 可判斷提交查詢時 DML 查詢所需的 DPU 數目。數目會根據資料大小、儲存格式、查詢建構和其他因素而異。一般而言，Athena 會嘗試選取最低、最有效率的 DPU 數目。如果 Athena 判斷需要更多的運算能力才能順利完成查詢，則會增加指派給查詢的 DPU 數目。 ### 預估工作負載特定容量需求 若要判斷同時執行多個查詢時可能需要多少容量，請考慮下列資料表中的一般指導方針： **** | 並行查詢 | 所需的 DPU | | --- | --- | | 10 | 40 或以上 | | 20 | 96 或以上 | | 30 或以上 | 240 或以上 | 請注意，您實際需要的 DPU 數目取決於您的目標和分析模式。例如，如果您想要立即開始查詢而不排入佇列，請判斷尖峰並行查詢需求，然後相應地佈建 DPU 數目。 您可以佈建比尖峰需求更少的 DPU，但在發生尖峰需求時可能會導致佇列。進行佇列時，Athena 會將您的查詢保存在佇列中，並在容量可用時執行查詢。 如果您的目標是在固定預算內執行查詢，您可以使用 [AWS Pricing Calculator](https://calculator.aws/#/addService/Athena) 來判斷適合您預算的 DPU 數目。 最後請記住，資料大小、儲存格式和查詢的寫入方式會影響查詢所需的 DPU。若要提高查詢效能，您可以壓縮或分割資料，或將其轉換為單欄式格式。如需詳細資訊，請參閱[最佳化 Athena 效能](performance-tuning.md)。 ## 需要更多容量的跡象 容量不足錯誤訊息和查詢佇列是指派容量不足的兩個指示。 如果您的查詢失敗並顯示容量不足錯誤訊息，則容量保留的 DPU 數目太低，無法滿足您的查詢要求。例如，如果您的保留具有 24 個 DPU，且執行的查詢需要 24 個以上的 DPU，則查詢將失敗。若要監控此查詢錯誤，您可以使用 Athena 的 [EventBridge 事件](athena-events.md)。嘗試新增更多 DPU，然後重新執行查詢。 如果有許多查詢排入佇列，則表示您的容量已被其他查詢充分利用。若要減少佇列，請執行下列任意一項： + 將 DPU 新增至您的保留，以提高查詢並行性。 + 從保留中移除工作群組，以釋放容量供其他查詢使用。 若要檢查是否有過多的查詢佇列，請針對容量保留中的工作群組使用 Athena 查詢佇列時間 [CloudWatch 指標](query-metrics-viewing.md)。如果該值超過您偏好的閾值，您可以將 DPU 新增至容量保留。 ## 檢查閒置容量 若要檢查閒置容量，您可以減少保留中的 DPU 數目或增加其工作負載，然後觀察結果。 **若要檢查閒置容量** 1. 執行以下任意一項： + 減少保留中的 DPU 數目 (減少可用資源) + 將工作群組新增至您的保留 (增加工作負載) 1. 使用 [CloudWatch](query-metrics-viewing.md) 來測量查詢佇列時間。 1. 如果佇列時間增加超過理想水平，請執行下列任意一項 + 移除工作群組 + 將 DPU 新增至您的容量保留 1. 每次變更之後，請檢查效能和查詢佇列時間。 1. 繼續調整工作負載及/或 DPU 計數，以達到所需的平衡。 如果您不想將容量維持在偏好期間以外，您可以[取消](capacity-management-cancelling-a-capacity-reservation.md)保留並稍後建立另一個保留。但是，即使您最近取消了其他保留的容量，也無法保證請求新容量，而且建立新的保留需要一些時間。 ## 監控 DPU 使用量 查詢執行後，您可以檢視查詢使用的 DPU，以協助精簡容量預估。Athena 透過主控台、API 操作和 CloudWatch 提供 DPU 耗用指標。此資訊可協助您識別耗用比預期更多或更少資源的查詢，並根據實際資料最佳化容量配置。如需檢視和追蹤 DPU 使用量的詳細資訊，請參閱 [監控 DPU 用量](capacity-management-control-capacity-usage.md#capacity-management-monitor-dpu-usage)。 ## 評估容量需求和成本的工具 您可以在 中使用下列服務和功能 AWS 來測量您的 Athena 用量和成本。 ### CloudWatch 指標 您可以將 Athena 設定為在工作群組層級將查詢相關指標發佈到 Amazon CloudWatch。為工作群組啟用指標後，工作群組查詢的指標會顯示在工作群組詳細資訊頁面的 Athena 主控台中。 如需有關發佈至 CloudWatch 的 Athena 指標及其維度的資訊，請參閱 [使用 CloudWatch 監控 Athena 查詢指標](query-metrics-viewing.md)。 ### CloudWatch 用量指標 您可使用 CloudWatch 用量指標，透過在 CloudWatch 圖表和儀表板中顯示目前的服務使用量狀況，瞭解您的帳戶如何使用資源。對於 Athena，用量可用性指標對應至 Athena AWS [的服務配額](service-limits.md)。您可以設定警示，在您的用量接近服務配額時發出警示。 如需詳細資訊，請參閱[使用 CloudWatch 監控 Athena 用量指標](monitoring-athena-usage-metrics.md)。 ### Amazon EventBridge 事件 您可以搭配使用 Amazon EventBridge 與 Amazon Athena，以接收有關查詢狀態的即時通知。當您提交的查詢變更狀態時，Athena 會將事件發布至 EventBridge，當中包含該查詢狀態轉換的相關資訊。您可以針對感興趣的事件撰寫簡單的規則，並在事件符合規則時採取自動化動作。 如需詳細資訊，請參閱下列資源。 + [使用 EventBridge 監控 Athena 查詢事件](athena-events.md) + [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [Amazon EventBridge 事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html) ### Tags (標籤) 在 Athena 中，容量保留支援標籤。一個標籤均包含一个索引鍵和一個值。若要在 Athena 中追蹤您的成本，您可以使用 AWS產生的成本分配標籤。 AWS 會使用成本分配標籤來整理成本[和用量報告中](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)的資源成本。這可讓您更輕鬆地分類和追蹤 AWS 成本。若要啟用 Athena 的成本分配標籤，請使用 [AWS 帳單與成本管理 主控台](https://console.aws.amazon.com/billing/)。 如需詳細資訊，請參閱下列資源。 + [標記 Athena 資源](tags.md) + [啟用 AWS產生的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activate-built-in-tags.html) + [使用  AWS 成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) # 建立容量保留 若要開始使用，您可建立具有所需 DPU 數目的容量保留，然後指派一或多個工作群組，以使用該容量進行查詢。您可以稍後視需要調整容量，以提供更一致的效能或更好地管理成本。如需有關估算容量需求的資訊，請參閱 [判斷容量需求](capacity-management-requirements.md)。 **重要** 無法保證容量請求，且可能需要 30 分鐘才能完成。 **若要建立容量保留** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 1. 選擇**管理**、**容量保留**。 1. 選擇**建立容量保留**。 1. 在**建立容量保留**頁面上，對於**容量保留名稱**，輸入名稱。名稱必須是唯一的，長度介於 1 至 128 個字元之間，且只能使用字元 a-z、A-Z、0-9、\$1(底線)、.(句點) 和 -(連字號)。建立保留後，便無法變更名稱。 1. 對於 **DPU**，選擇或輸入所需的資料處理單位 (DPU) 數目，增量為 4。如需詳細資訊，請參閱[了解 DPU](capacity-management.md#capacity-management-understanding-dpus)。 1. (選用) 展開**標籤**選項，然後選擇**新增標籤**，以新增一或多個鍵值組，進而與容量保留資源建立關聯。如需詳細資訊，請參閱[標記 Athena 資源](tags.md)。 1. 選擇**檢閱**。 1. 在**確認建立容量保留**提示中，確認 DPUs數量 AWS 區域和其他資訊。如果您接受，請選擇**提交**。 在詳細資訊頁面上，容量保留的**狀態**會顯示為**待定**。當您的預留容量可用於執行查詢時，其狀態會顯示為**作用中**。 此時，您可在保留中新增一或多個工作群組。如需這些步驟，請參閱 [將工作群組新增至保留](capacity-management-adding-workgroups-to-a-reservation.md)。 # 控制容量用量 您可以設定最大或最小 DPU 控制項，以控制 Athena 配置給查詢的 DPU 數量。您可以在工作群組層級設定這些項目，以為所有查詢建立基準控制，或在個別查詢層級建立精細控制。這可讓您直接控制查詢效能、工作負載並行和成本。 + 當您設定最大數量的 DPU 時，會防止查詢消耗超過您指定的容量。這可讓您輕鬆地控制成本和工作負載並行。例如，如果您的容量保留有 200 個 DPU，將每個查詢的 DPU 上限設定為 8 可讓您同時執行 25 個查詢。如果您將保留增加到 400 個 DPU，您可以同時執行 50 個查詢。 + 當您設定最低數量的 DPU 時，您可以確保使用所需的最低數量的 DPU 執行查詢。當您事先了解查詢的一般容量用量描述檔時，這會很有幫助。 **注意** DPU 用量控制僅適用於使用容量保留執行的查詢。 **注意** 若要對所有查詢使用相同數量的 DPU，請針對最小和最大 DPU 使用相同的值。 ## 在工作群組層級設定 DPU 控制項 在工作群組層級設定 DPU 控制，以管理成本和控制您選擇的工作群組的工作負載效能。啟用**覆寫用戶端設定**時，工作群組層級設定的 DPU 控制項會套用至所有查詢。 **使用主控台設定 DPU 控制項** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 選取使用容量保留的工作群組。 1. 在**執行控制項**索引標籤上，選擇**編輯控制項**。 1. 設定下列項目： + 對於**每個查詢的最小 DPU**，以 4 為增量，輸入介於 4 到 124 之間的值。 + 對於**每個查詢的最大 DPU**，以 4 為增量，輸入介於 4 到 124 之間的值。 1. 選擇**儲存**。 1. （選用） 選取**覆寫用戶端設定**以強制執行這些設定，並忽略查詢層級 DPU 組態。 **使用 設定 DPU 控制項 AWS CLI** + 使用 `update-work-group`命令來設定工作群組的 DPU 控制項： ``` aws athena update-work-group \ --work-group my_workgroup \ --configuration-updates '{ "EngineConfiguration": { "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "24", "min-dpu-count" : "12" } } ] }}' ``` 如果您將 `EnforceWorkGroupConfiguration` 設定為 `true`，工作群組設定會覆寫透過 [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) 提交時在查詢層級指定的任何 DPU 控制項。這可確保工作群組中所有查詢的資源配置一致。 ## 使用個別查詢設定 DPU 控制項 當您需要使用具有不同資源需求的查詢進行精細控制時，請設定查詢層級 DPU 控制。查詢層級 DPU 控制優先於工作群組層級設定，除非工作群組已啟用**覆寫用戶端設定**。 **使用主控台設定查詢的 DPU 控制項** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽窗格中，選擇 **Query Editor (查詢編輯器)**。 1. 選取使用容量保留的工作群組。 1. 選擇**查詢設定**索引標籤。 1. 在**執行控制項**區段中，選擇**編輯控制項**。 1. 設定下列項目： + 對於**每個查詢的最小 DPU**，以 4 為增量，輸入介於 4 到 124 之間的值。 + 對於**每個查詢的最大 DPU**，以 4 為增量，輸入介於 4 到 124 之間的值。 1. 選擇**儲存**。 **使用 設定查詢的 DPU 控制項 AWS CLI** + 使用 `start-query-execution`命令搭配 `engine-configuration` 參數： ``` aws athena start-query-execution \ --query-string "SELECT * FROM my_table LIMIT 10" \ --work-group "my_workgroup" \ --engine-configuration '{ "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "32", "min-dpu-count" : "8" } } ]}' ``` 查詢層級和工作群組層級 DPU 設定之間的關係取決於您的工作群組組態： + 啟用**覆寫用戶端設定**時，工作群組層級 DPU 控制優先於任何查詢層級設定。這可確保指定工作群組中所有查詢的一致資源用量。 + 未啟用**覆寫用戶端設定**時，查詢層級 DPU 控制優先於工作群組層級設定。這可讓個別查詢最佳化的彈性。 如果您未在任一層級指定 DPU 控制項，Athena 會根據查詢複雜性自動配置容量。 **注意** 對於 DDL 查詢，最小 DPUs的最大值為 4。為 DDL 查詢設定較高的最小值會導致錯誤。 ## 監控 DPU 用量 查詢完成後，您可以檢視其 DPU 用量。Athena 透過主控台、API 操作和 CloudWatch 提供 DPU 用量指標。 **在主控台中檢視 DPU 使用量** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽窗格中，選擇 **Query Editor (查詢編輯器)**。 1. 查詢完成後，請在查詢結果容器中檢視其**已使用的 DPU **值。 1. 若要檢視過去查詢的 DPU 使用量： 1. 在導覽窗格中選擇**最近的查詢**。 1. 如果尚未顯示，請選取設定圖示，將**已使用的 DPU** 資料欄新增至資料表。 1. 檢閱每個已完成查詢的 DPU 使用量。 1. 或者，從**查詢編輯器**中，選擇**查詢統計資料**索引標籤，並檢閱**已使用的 DPU**。 **使用 API 擷取 DPU 耗用** 1. 使用下列 API 操作以程式設計方式擷取 DPU 耗用量： + `GetQueryExecution` - 傳回特定查詢的執行詳細資訊 + `BatchGetQueryExecution` - 傳回多個查詢的執行詳細資訊 1. 使用 AWS CLI的範例： ``` aws athena get-query-execution \ --query-execution-id "123e4567-e89b-12d3-a456-426614174000" ``` 回應包含 `Statistics` 物件中的 `DpuCount` 欄位： ``` { "QueryExecution": { "Statistics": { "DpuCount": 8 } } } ``` **使用 CloudWatch 監控 DPU 用量** + Athena 會將查詢相關指標發佈至 CloudWatch，協助您監控容量使用率和其他效能資料。如需詳細資訊，請參閱 [使用 CloudWatch 監控 Athena 查詢指標](query-metrics-viewing.md)。 # 自動調整容量 您可以使用 Athena 的自動擴展解決方案自動調整保留的容量，以回應工作負載使用率。當使用率超過您設定的閾值時，它會自動新增容量，並在低使用率期間移除容量以降低成本。您可以透過設定不同的使用率閾值、最小和最大 DPU 數量、擴展增量和使用率評估頻率來自訂其行為。這可消除手動容量調整，同時協助您平衡效能需求與成本最佳化。 您可以使用 CloudFormation 範本部署此無伺服器解決方案。它建立 Step Functions 狀態機器，可監控使用率指標並做出擴展決策。您可以進一步自訂範本或狀態機器，以符合您的特定需求。 若要開始使用，請使用 Athena 主控台，然後選擇在容量保留詳細資訊頁面上**設定自動調整規模**，該頁面會使用預先載入的 CloudFormation 範本將您重新導向至 。或者，請遵循下列程序。 ## 先決條件 + 需要主動容量保留 + 部署 CloudFormation 堆疊和建立 Step Functions 資源所需的 IAM 許可 ## 啟動 CloudFormation 堆疊 此自動化 CloudFormation 範本會部署 Athena 容量保留自動擴展解決方案。您必須先完成 中的適用步驟，[先決條件](#capacity-management-auto-scaling-prerequisites)才能啟動堆疊。 [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml) **啟動自動擴展解決方案** 1. 登入 [AWS 管理主控台](https://console.aws.amazon.com/)，然後選取按鈕以啟動`AWSAccelerator-InstallerStack` CloudFormation 範本。 1. 根據預設，範本會在美國東部 （維吉尼亞北部） 啟動。若要在不同的 中啟動解決方案 AWS 區域，請使用主控台導覽列中的區域選擇器。 1. 在**建立堆疊**頁面上，確認範本 URL 位於 **Amazon S3 URL** 文字方塊中，然後選擇**下一步**。 1. 在**指定堆疊詳細資訊**頁面上，為您的解決方案堆疊指派名稱。 1. 在**參數**下，檢閱此解決方案範本的參數，並視需要修改這些參數。此解決方案使用下列預設值。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/capacity-management-automatically-adjust-capacity.html) **注意** 所有 DPU 值都必須是 4 的倍數，以符合 Athena 的容量保留要求。 1. 選擇**下一步**。 1. 在 **Configure stack options** (設定堆疊選項) 頁面，選擇 **Next** (下一步)。 1. 在**檢閱和建立**頁面上，檢閱並確認設定。選取確認範本可能會建立 IAM 資源的方塊。 1. 選擇**提交**以部署堆疊。 您可以在狀態欄的 CloudFormation 主控台中檢視堆疊**的狀態**。您應該會在幾分鐘內收到 `CREATE_COMPLETE` 狀態。 # 管理保留 您可以在**容量保留**頁面上檢視和管理您的容量保留。您可以執行管理任務，例如新增或減少 DPU、修改工作群組指派，以及標記或取消保留。 **若要檢視和管理容量保留** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 1. 選擇**管理**、**容量保留**。 1. 在容量保留頁面上，您可以執行下列任務： + 若要建立容量保留，請選擇**建立容量保留**。 + 使用搜尋方塊，依名稱或 DPU 數目篩選保留。 + 選擇狀態下拉式選單，依容量保留狀態進行篩選 (例如，**作用中**或**已取消**)。如需有關保留狀態的詳細資訊，請參閱 [了解保留狀態](#capacity-management-understanding-reservation-status)。 + 若要檢視容量保留的詳細資訊，請選擇保留的連結。保留的詳細資訊頁面包括以下選項：[編輯容量](capacity-management-editing-capacity-reservations.md)、[新增工作群組](capacity-management-adding-workgroups-to-a-reservation.md)、[移除工作群組](capacity-management-removing-a-workgroup-from-a-reservation.md)以及[取消](capacity-management-cancelling-a-capacity-reservation.md)保留。 + 若要編輯保留 (例如，透過新增或移除 DPU)，請選取保留的按鈕，然後選擇**編輯**。 + 若要取消預留，請選取保留按鈕，然後選擇**取消**。 ## 了解保留狀態 下表說明容量保留的可能狀態值。 **** | 狀態 | Description | | --- | --- | | 待定 | Athena 正在處理您的容量請求。容量尚未準備好執行查詢。 | | Active (作用中) | 容量可用於執行查詢。 | | 失敗 | 您的容量請求未成功完成。請注意，無法保證滿足容量請求。失敗的保留會計入您的帳戶 DPU 限制。若要釋出使用量，您必須取消保留。 | | 更新待定 | Athena 正在處理保留的變更。例如，在您編輯保留以新增或移除 DPU 之後，就會發生此狀態。 | | 取消 | Athena 正在處理取消保留的請求。仍在使用保留的工作群組中執行的查詢可以完成，但工作群組中的其他查詢將使用隨選 (未佈建的) 容量。 | | 已取消 | 容量保留取消完成。已取消的保留會在主控台中保留 45 天。45 天後，Athena 將刪除保留。在這 45 天期間，您無法重新規劃或重複使用保留，但您可以參考其標籤並檢視其詳細資訊以供歷史參考。 無法保證可在未來日期重新保留取消的容量。容量無法轉移到另一個保留， AWS 帳戶 或 AWS 區域。 | ## 了解作用中 DPU 和目標 DPU 在 Athena 主控台的容量保留清單中，您的保留會顯示兩個 DPU 值：**作用中 DPU** 和**目標 DPU**。 + **作用中 DPU** – 保留中可用來執行查詢的 DPU 數目。例如，如果您請求 100 個 DPU，且您的請求已滿足，則**作用中 DPU** 會顯示 **100**。 + **目標 DPU** – 您的保留正在移至的 DPU 數目。在建立保留或待定增加或減少 DPU 數目時，**目標 DPU** 顯示的值會與**作用中 DPU** 不同。 例如，在您提交請求以建立具有 24 個 DPU 的保留之後，保留**狀態**將為**待定**，**作用中 DPU** 將為 **0**，而**目標 DPU** 將為 **24**。 如果您的保留有 100 個 DPU，並編輯您的保留以請求增加 20 個 DPU，則**狀態**將為**更新待定**，**作用中 DPU** 將為 **100**，而**目標 DPU** 將為 **120**。 如果您的保留有 100 個 DPU，並編輯您的保留以請求減少 20 個 DPU，則**狀態**將為**更新待定**，**作用中 DPU** 將為 **100**，而**目標 DPU** 將為 **80**。 在這些轉換期間，Athena 會根據您的請求積極獲取或減少 DPU 數目。當**作用中 DPU** 等於**目標 DPU** 時，則達到目標數目，且沒有任何待定變更。 若要以程式設計方式擷取這些值，您可以呼叫 [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html) API 動作。該 API 將**作用中 DPU** 和**目標 DPU** 稱為 `AllocatedDpus` 和 `TargetDpus`。 **Topics** + [了解保留狀態](#capacity-management-understanding-reservation-status) + [了解作用中 DPU 和目標 DPU](#capacity-management-understanding-dpu-status) + [編輯容量保留](capacity-management-editing-capacity-reservations.md) + [將工作群組新增至保留](capacity-management-adding-workgroups-to-a-reservation.md) + [從保留中移除工作群組](capacity-management-removing-a-workgroup-from-a-reservation.md) + [取消容量保留](capacity-management-cancelling-a-capacity-reservation.md) + [刪除容量保留](capacity-management-deleting-a-capacity-reservation.md) # 編輯容量保留 建立容量保留後，您可以調整其 DPU 數目，以及新增或移除其自訂標籤。 **若要編輯容量保留** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 1. 選擇**管理**、**容量保留**。 1. 在容量保留清單中，執行下列任意一項： + 選取保留旁邊的按鈕，然後選擇**編輯**。 + 選擇保留連結，然後選擇**編輯**。 1. 針對 **DPU**，選擇或輸入您想要的資料處理單位數量。如需詳細資訊，請參閱[了解 DPU](capacity-management.md#capacity-management-understanding-dpus)。 **注意** 您可以隨時請求將 DPUs 新增至作用中容量保留。 當保留變為作用中或上次新增 DPUs後已超過 1 分鐘時，您可以請求從作用中容量保留減少 DPUs。 當您請求減少 DPUs 時，Athena 會優先移除閒置DPUs而非作用中DPUs。如果查詢正在使用標記為移除DPUs，Athena 會等待查詢完成，然後再移除 DPUs。 1. (選用) 針對**標籤**，選擇**移除**以移除標籤，或選擇**新增標籤**以新增標籤。 1. 選擇**提交**。保留詳細資訊頁面會顯示更新的組態。 # 將工作群組新增至保留 建立容量保留後，您最多可以將 20 個工作群組新增至保留。將工作群組新增至保留會告訴 Athena 應該在預留容量上執行哪些查詢。來自未與保留關聯的工作群組查詢，會繼續使用預設的每 TB 掃描定價模式執行。 當保留有兩個或多個工作群組時，來自這些工作群組的查詢可以使用保留的容量。您可以隨時新增和移除工作群組。新增或移除工作群組時，不會中斷正在執行的查詢。 當您的保留處於待定狀態時，來自您新增的工作群組的查詢會繼續使用預設的每 TB 掃描定價模式執行，直到保留變為作用中。 **若要將一或多個工作群組新增至您的容量保留** 1. 在容量保留的詳細資訊頁面上，選擇**新增工作群組**。 1. 在**新增工作群組**頁面上，選取要新增的工作群組，然後選擇**新增工作群組**。您不能將一個工作群組指派至多個預留。 容量保留的詳細資訊頁面會列出您新增的工作群組。在這些工作群組中執行的查詢，將使用您在保留處於作用中狀態時保留的容量。 # 從保留中移除工作群組 如果您不再需要工作群組專用容量，或想要將工作群組移至其自己的保留中，您可以隨時將其移除。從保留移除工作群組輕鬆簡單。從保留中移除工作群組後，從移除的工作群組查詢會使用隨需容量返回 ，並根據掃描的 TB (TB) 計費。 **若要從保留移除一或多個工作群組** 1. 在容量保留之詳細資料頁面上，選取您要移除的工作群組。 1. 選擇**移除工作群組**。**是否移除工作群組？**提示會通知您，在將工作群組從保留中移除之前，將會完成所有目前作用中的查詢。 1. 選擇**移除**。容量保留的詳細資訊頁面會顯示移除的工作群組不再存在。 # 取消容量保留 如果您不想再使用容量保留，則可將其取消。仍在使用保留的工作群組中執行的查詢將可完成，但工作群組中的其他查詢將不再使用保留。 **注意** 無法保證可在未來日期重新保留取消的容量。容量無法轉移至其他保留， AWS 帳戶 或 AWS 區域。 **若要取消容量保留** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 1. 選擇**管理**、**容量保留**。 1. 在容量保留清單中，執行下列任意一項： + 選取保留旁邊的按鈕，然後選擇**取消**。 + 選擇容量連結，然後選擇**取消容量保留**。 1. 畫面出現**是否取消容量保留？**提示時，輸入**取消**，然後選擇**取消容量保留**。 保留的狀態會變更為**取消中**，且進度橫幅會通知您正在取消。 取消完成後，容量保留仍會保留，但其狀態會顯示為**已取消**。保留將在取消後 45 天刪除。在這 45 天期間，您無法重新規劃或重複使用已取消的保留，但您可以參考其標籤並檢視其詳細資訊以供歷史參考。 # 刪除容量保留 如果您要移除已取消的容量保留的所有參考，您可以刪除保留。必須先取消保留，然後才可將其刪除。刪除的保留會立即從您的帳戶中移除，且無法再參考，包括其 ARN。 **若要刪除容量保留** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 1. 選擇**管理**、**容量保留**。 1. 在容量保留清單中，執行下列任意一項： + 選取已取消的保留旁邊的按鈕，然後選擇**動作**、**刪除**。 + 選擇保留連結，然後選擇**刪除**。 1. 畫面出現**是否刪除容量保留？**提示時，選擇**刪除**。 畫面會出現橫幅，通知您已成功刪除容量保留。刪除的保留不再出現在容量保留清單中。 # 容量保留的 IAM 政策 若要控制對容量保留的存取，請使用資源層級 IAM 許可或以身分為基礎的 IAM 政策。每當您使用 IAM 政策時，請務必遵循 IAM 最佳實務。如需詳細資訊，請參閱*《IAM 使用者指南》*中的 [IAM 中的安全性最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 下列程序專用於 Athena。 如需 IAM 特定的資訊，請參閱本節最後列出的連結。如需有關範例 JSON 容量保留政策的資訊，請參閱 [容量保留政策範例](example-policies-capacity-reservations.md)。 **若要在 IAM 主控台中使用視覺化編輯器來建立容量保留政策** 1. 登入 AWS 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。 1. 在左邊的導覽窗格中，選擇 **Policies** (政策)，然後選擇 **Create policy** (建立政策)。 1. 在 **Visual editor** (視覺化編輯器) 標籤上，選擇 **Choose a service** (選擇一項服務)。接著選擇 Athena 以新增到政策。 1. 選擇 **Select actions** (選取動作)，然後選擇要新增到政策的動作。視覺化編輯器會顯示 Athena 中可用的動作。如需詳細資訊，請參閱《服務授權參考》**中的 [Amazon Athena 的動作、資源和條件索引鍵](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html)。 1. 選擇**新增動作**來輸入特定動作，或使用萬用字元 (\$1) 來指定多個動作。 預設情況下，您建立的政策允許執行選擇的操作。對於 Athena 中的 `capacity-reservation` 資源，如果您選擇的一個或多個動作支援資源層級許可，則編輯器會列出 `capacity-reservation` 資源。 1. 選擇**資源**來為您的政策指定特定容量保留。如需有關範例 JSON 容量保留政策的資訊，請參閱 [容量保留政策範例](example-policies-capacity-reservations.md)。 1. 如下所示指定 `capacity-reservation` 資源： ``` arn:aws:athena:::capacity-reservation/ ``` 1. 選擇 **Review policy** (檢閱政策)，然後為您正在建立的政策輸入 **Name** (名稱) 與 **Description** (描述) (選用)。檢閱政策摘要來確認您已授予想要的許可。 1. 選擇 **Create policy** (建立政策) 儲存您的新政策。 1. 將此基於身分的政策連接到使用者、群組或角色。 如需詳細資訊，請參閱《服務授權參考》**與《IAM 使用者指南》**中的下列主題： + [Amazon Athena 的操作、資料和條件索引鍵](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) + [使用視覺化編輯器來建立政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor) + [新增和移除 IAM 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) + [控制資源的存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-resources) 如需有關範例 JSON 容量保留政策的資訊，請參閱 [容量保留政策範例](example-policies-capacity-reservations.md)。 如需 Amazon Athena 動作的完整清單，請參閱《[Amazon Athena API 參考](https://docs.aws.amazon.com/athena/latest/APIReference/)》中的 API 動作名稱。 # 容量保留政策範例 本節包含可讓您在容量保留上用來啟用各種動作的範例政策。每當您使用 IAM 政策時，請務必遵循 IAM 最佳實務。如需詳細資訊，請參閱《IAM 使用者指南》**中的 [IAM 中的安全性最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 容量保留是由 Athena 管理的 IAM 資源。因此，如果您的容量保留政策使用 `capacity-reservation` 做為輸入的動作，您必須指定容量保留的 ARN，如下所示： ``` "Resource": [arn:aws:athena:::capacity-reservation/] ``` 其中 `` 為容量保留的名稱。例如，對於名為 `test_capacity_reservation` 的容量保留，將其指定為資源，如下所示： ``` "Resource": ["arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation"] ``` 如需 Amazon Athena 動作的完整清單，請參閱《[Amazon Athena API 參考](https://docs.aws.amazon.com/athena/latest/APIReference/)》中的 API 動作名稱。如需有關 IAM 政策的詳細資訊，請參閱《IAM 使用者指南》**中的[使用視覺化編輯器來建立政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor)。 **Example 適用於列出容量保留的政策範例** 以下政策允許所有使用者列出所有容量保留。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListCapacityReservations" ], "Resource": "*" } ] } ``` **Example 適用於管理操作的政策範例** 下列政策可讓使用者建立、取消、取得詳細資訊，以及更新容量保留 `test_capacity_reservation`。該政策還允許使用者指派 `workgroupA` 和 `workgroupB` 給 `test_capacity_reservation`。 **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Action": [ "athena:CreateCapacityReservation", "athena:GetCapacityReservation", "athena:CancelCapacityReservation", "athena:UpdateCapacityReservation", "athena:GetCapacityAssignmentConfiguration", "athena:PutCapacityAssignmentConfiguration" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupB" ] } ] } ``` # Athena 容量保留 API 下列清單包含 Athena 容量保留 API 動作的參考連結。如需資料結構和其他 Athena API 動作，請參閱 [https://docs.aws.amazon.com/athena/latest/APIReference/](https://docs.aws.amazon.com/athena/latest/APIReference/)。 + [CancelCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CancelCapacityReservation.html) + [CreateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateCapacityReservation.html) + [DeleteCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteCapacityReservation.html) + [GetCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityAssignmentConfiguration.html) + [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html) + [ListCapacityReservations](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListCapacityReservations.html) + [PutCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_PutCapacityAssignmentConfiguration.html) + [UpdateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateCapacityReservation.html) # 最佳化 Athena 效能 本主題就改善 Athena 查詢效能以及如何解決與限制和資源使用量相關的錯誤，提供了一般資訊和具體建議。 一般而言，最佳化可以分組成服務、查詢和資料結構類別。在服務層級就撰寫查詢的方式以及建構資料和資料表的方式所做的決策，都可能會影響效能。 **Topics** + [最佳化服務使用](performance-tuning-service-level-considerations.md) + [最佳化查詢](performance-tuning-query-optimization-techniques.md) + [最佳化資料](performance-tuning-data-optimization-techniques.md) + [使用單欄式儲存格式](columnar-storage.md) + [使用分割和歸納](ctas-partitioning-and-bucketing.md) + [分割您的資料](partitions.md) + [透過 Amazon Athena 使用分割區投影](partition-projection.md) + [防止 Amazon S3 限流](performance-tuning-s3-throttling.md) + [其他資源](performance-tuning-additional-resources.md) # 最佳化服務使用 服務層級考量事項包括您每一帳戶執行的工作負載數量、不僅限於 Athena (而是所有服務) 的服務配額，以及思考如何減少「資源不足」錯誤。 **Topics** + [在同一帳戶中操作多個工作負載](#performance-tuning-service-quotas) + [減少「資源不足」錯誤](#performance-tuning-resource-limits) ## 在同一帳戶中操作多個工作負載 Athena 使用配額來限制帳戶層級的查詢並行和 API 請求率。超出這些配額可能會導致查詢在執行期間或提交時失敗。如需有關這些配額的詳細資訊，請參閱 [Service Quotas](service-limits.md)。 如果您在同一個 AWS 帳戶中操作多個工作負載，您的工作負載會爭奪相同的帳戶層級配額。例如，如果一個工作負載遇到未預期的查詢爆量，同一帳戶中執行的另一個工作負載可能會出現佇列時間增加，或在最壞的情況下，因限流而導致查詢提交失敗。 我們建議您使用 CloudWatch 透過圖表和儀表板監控您的服務用量。您也可以設定 CloudWatch 警示，在用量接近並行查詢的服務配額時提醒您，讓您能在達到配額限制之前採取動作。如需詳細資訊，請參閱[使用 CloudWatch 監控 Athena 用量指標](monitoring-athena-usage-metrics.md)。 若要控制查詢並行並隔離帳戶內的工作負載，請使用容量保留。容量保留可在單一帳戶內提供專用查詢處理容量。容量是以資料處理單位 (DPU) 為單位測量而得，並可透過新增來增加查詢並行或透過移除來減少查詢並行。容量保留讓您能夠將容量指派給一或多個工作群組，進而隔離帳戶內的工作負載。如需詳細資訊，請參閱[管理查詢處理容量](capacity-management.md)。 雖然您應該隔離不同 AWS 帳戶中不相關的工作負載 （例如隔離開發與生產環境），但此方法無法提供可擴展的方式來增加查詢並行。反之，請使用容量保留來管理和擴展單一帳戶內的查詢處理需求。 ### 考慮其他服務中的配額 當 Athena 執行查詢時，它可以呼叫其他強制執行配額的服務。在查詢執行期間，Athena 可以對 AWS Glue Data Catalog、Amazon S3 和其他 AWS 服務進行 API 呼叫，例如 IAM 和 AWS KMS。如果您使用[聯合查詢](federated-queries.md)，Athena 也會呼叫 AWS Lambda。所有這些服務都有自己的限制和配額，可以超過。當查詢執行遇到來自這些服務的錯誤時，其便會失敗並包含來源服務的錯誤。重試可復原的錯誤，但如果問題無法及時自行解決，查詢仍可能失敗。請務必徹底閱讀錯誤訊息，以判斷其是來自 Athena 還是來自其他服務。此效能調校區段涵蓋一些相關錯誤。 如需有關解決 Amazon S3 Service Quotas 造成的錯誤的資訊，請參閱本文件稍後的 [避免檔案太多](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files)。如需有關 Amazon S3 效能最佳化的詳細資訊，請參閱《Amazon S3 使用者指南》**中的[最佳實務設計模式：最佳化 Amazon S3 效能](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)。 ## 減少「資源不足」錯誤 Athena 會在分散式查詢引擎中執行查詢。當您提交查詢時，Athena 引擎查詢規劃程式會預估執行查詢所需的運算容量，並相應地準備運算節點叢集。某些查詢 (例如 DDL 查詢) 只在一個節點上執行。大型資料集的複雜查詢可在更大的叢集上執行。節點是統一的，具有相同的記憶體、CPU 和磁碟組態。Athena 透過橫向擴展 (而非向上擴展) 來處理要求更高的查詢。 有時候，查詢的需求會超過執行查詢的叢集的可用資源。發生這種情況時，查詢會失敗，並顯示錯誤在此擴展因數下查詢耗盡的資源。 最常耗盡的資源是記憶體，但在極少數情況下，也可以是磁碟空間。當引擎執行聯結或視窗函數時，通常會發生記憶體錯誤，但也可能發生在不同的計數和彙總中。 即使查詢失敗並出現「資源不足」錯誤一次，當您再次執行時，其可能會成功。查詢執行不是確定性的。載入資料所花費時間以及如何在節點上分配中繼資料集等因素，可能會導致資源使用量不同。例如，假設一個查詢聯結兩個資料表，並且聯結條件的值分佈存在很大偏差。這樣的查詢在大多數時間都可以成功，但是當最常見的值最終由相同節點處理時，偶爾會失敗。 若要避免查詢超出可用資源，請使用本文件中提及的效能調校秘訣。具體而言，有關如何最佳化會耗盡可用資源之查詢的秘訣，請參閱 [最佳化聯結](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins)、[減少視窗函式的範圍，或將其移除](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions) 和 [使用近似值最佳化查詢](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations)。 # 最佳化查詢 使用本節中描述的查詢最佳化技術，可加快查詢執行速度，或做為 Athena 中超出資源限制的查詢解決方法。 ## 最佳化聯結 在分散式查詢引擎中執行聯結的策略有很多。最常見的兩個是分散式雜湊聯結和具有複雜聯結條件的查詢。 ### 在分散式雜湊聯結中，將大型資料表放在左側，小型資料表放在右側 最常見的聯結類型使用對等比較做為聯結條件。Athena 以分散式雜湊聯結的形式執行此類聯結。 在分散式雜湊聯結中，引擎會從聯結的一側建置一個查詢表 (雜湊資料表)。這一側稱為*建置端*。建置端的記錄分散在多個節點上。每個節點為其子集建置一個查詢表。接著，聯結的另一端稱為*探查端*，會透過節點進行串流。探查端的記錄以與建置端相同的方式分散在節點上。這樣會啟用每個節點，以透過在其自己的查詢表中查詢相符記錄來執行聯結。 當從聯結的建置端建立的查詢表不適合放入記憶體中時，查詢可能會失敗。即使建置端的總大小小於可用記憶體，如果記錄的分佈存在很大偏差，查詢也可能會失敗。在極端情況下，所有記錄可能具有相同的聯結條件值，並且必須放入單一節點上的記憶體中。如果將一組值傳送至相同節點，且值加起來超過可用記憶體，即使是查詢偏差較小，也可能會失敗。節點確實可以將記錄溢寫至磁碟，但溢出會降低查詢執行速度，並且可能不足以防止查詢失敗。 Athena 會嘗試重新排序聯結，以使用較大的關係做為探查端，而較小的關係做為建置端。不過，由於 Athena 不會管理資料表中的資料，所以資訊有限，而且通常必須假設第一個資料表較大，第二個資料表較小。 使用以等值為基礎的聯結條件撰寫聯結時，假設 `JOIN` 關鍵字左側的資料表是探查端，右側的資料表是建置端。確保正確的資料表 (建置端) 是較小的資料表。如果無法使聯結的建置端足夠小以放入記憶體中，請考慮執行多個聯結建置資料表子集的查詢。 ### 使用 EXPLAIN 來分析具有複雜聯結的查詢 具有複雜聯結條件的查詢 (例如，使用 `LIKE`、`>` 或其他運算子的查詢) 通常運算要求較高。在最壞的情況下，聯結一端的每條記錄必須與聯結另一端的每條記錄進行比較。由於執行時間會隨著記錄數量的平方而增加，因此此類查詢會有超過最大執行時間的風險。 若要了解 Athena 將如何事先執行查詢，您可以使用 `EXPLAIN` 陳述式。如需詳細資訊，請參閱[在 Athena 使用 EXPLAIN 和 EXPLAIN ANALYZE](athena-explain-statement.md)及[了解 Athena EXPLAIN 陳述式結果](athena-explain-statement-understanding.md)。 ## 減少視窗函式的範圍，或將其移除 由於視窗函數是資源密集型操作，所以它們可能會使查詢執行緩慢甚至失敗，並顯示在此擴展因數下查詢耗盡的資源。視窗函數將其操作的所有記錄保留在記憶體中，以便計算其結果。當視窗非常大時，視窗函數可能會耗盡記憶體。 為了確保您的查詢在可用的記憶體限制內執行，請減少視窗函數操作的視窗大小。為此，您可以新增 `PARTITIONED BY` 子句或縮小現有分割區子句的範圍。 ### 使用非視窗函式 有時，具有視窗函數的查詢可以在沒有視窗函數的情況下重寫。例如，您可以使用 `ORDER BY` 和 `LIMIT`，而不是使用 `row_number` 來尋找前 `N` 個記錄。您可以使用彙總函數 (例如 [max\$1by](https://trino.io/docs/current/functions/aggregate.html#max_by)、[min\$1by](https://trino.io/docs/current/functions/aggregate.html#min_by) 和 [arbitrary](https://trino.io/docs/current/functions/aggregate.html#arbitrary))，而不是使用 `row_number` 或 `rank` 來重複記錄。 例如，假設您的資料集包含來自感應器的更新。感應器會定期報告其電池狀態，並包含一些中繼資料，例如位置。如果您想知道每個感應器及其位置的最新電池狀態，可以使用以下查詢： ``` SELECT sensor_id, arbitrary(location) AS location, max_by(battery_status, updated_at) AS battery_status FROM sensor_readings GROUP BY sensor_id ``` 因為每筆記錄的中繼資料 (例如位置) 都相同，因此您可以使用 `arbitrary` 函數從群組中選擇任何值。 要獲取最新的電池狀態，您可以使用 `max_by` 函數。`max_by` 函數從找到另一個資料欄的最大值的記錄中選擇資料欄的值。在此範例中，它會傳回群組內上次更新時間的記錄的電池狀態。與具有視窗函數的對等查詢相比，此查詢執行速度更快，而且使用的記憶體更少。 ## 最佳化彙總 當 Athena 執行彙總時，它會使用 `GROUP BY` 子句中的資料欄，跨不同的工作節點分佈記錄。為了使相符記錄與群組的任務盡可能有效率，節點會嘗試將記錄放入記憶體中，但必要時會將記錄溢寫至磁碟。 避免在 `GROUP BY` 子句中包含備援資料欄也是個不錯的主意。由於較少的資料欄需要較少的記憶體，因此使用較少資料欄描述群組的查詢會更有效率。數值資料欄使用的記憶體也少於字串。例如，當您彙總同時具有數值類別 ID 和類別名稱的資料集時，請僅使用 `GROUP BY` 子句中的類別 ID 資料欄。 有時候，查詢會在 `GROUP BY` 子句中包含資料欄，以解決資料欄必須是 `GROUP BY` 子句的一部分或彙總表達式的事實。如果未遵循此規則，您可能會收到以下錯誤訊息： EXPRESSION\$1NOT\$1AGGREGATE：行 1:8：「類別」必須是一個彙總表達式或出現在 GROUP BY 子句 若要避免在 `GROUP BY` 子句中新增備援資料欄，您可以使用[任意](https://trino.io/docs/current/functions/aggregate.html#arbitrary)函數，如下列範例所示。 ``` SELECT country_id, arbitrary(country_name) AS country_name, COUNT(*) AS city_count FROM world_cities GROUP BY country_id ``` `ARBITRARY` 函數會從群組中傳回任意值。當您知道群組中的所有記錄都具有相同的資料欄值，但該值無法識別群組時，此函數非常有用。 ## 最佳化前 N 個查詢 `ORDER BY` 子句會以排序順序傳回查詢的結果。Athena 使用分散式排序，在多個節點上平行執行排序操作。 如果您並不需要對結果進行排序，請避免新增 `ORDER BY` 子句。另外，如果並非絕對必要，請避免新增 `ORDER BY` 到內部查詢。在許多情況下，查詢規劃程式可以移除備援排序，但不保證一定如此。此規則的例外是，如果內部查詢正在執行前 `N` 個操作，例如尋找最新的 `N` 個值或最常用的 `N` 個值。 當 Athena 發現 `ORDER BY` 與 `LIMIT` 時，就會明白您正在執行前 `N` 個查詢，並相應地使用專用操作。 **注意** 雖然 Athena 也經常可以偵測視窗函數 (例如使用前 `N` 個的 `row_number`)，但我們建議使用 `ORDER BY` 和 `LIMIT` 的較簡單版本。如需詳細資訊，請參閱[減少視窗函式的範圍，或將其移除](#performance-tuning-optimizing-window-functions)。 ## 僅包含必填資料欄 如果您並不需要資料欄，請不要將其包含在查詢中。查詢必須處理的資料越少，執行速度就越快。這可以減少所需的記憶體數量，以及必須在節點之間傳送的資料量。如果您使用的是單欄式檔案格式，減少資料欄數量也會減少從 Amazon S3 讀取的資料量。 Athena 對結果中的資料欄數量沒有特定限制，但是執行查詢的方式會限制可能的資料欄合併大小。資料欄的合併大小包括它們的名稱和類型。 例如，下列錯誤是由超出關係描述項大小限制的關係造成的： GENERIC\$1INTERNAL\$1ERROR: io.airlift.bytecode.CompilationException 若要解決此問題，請減少查詢中的資料欄數量或建立子查詢，並使用擷取較少量資料的 `JOIN`。如果您有在最外層查詢中執行 `SELECT *` 的查詢，則應將 `*` 變更為僅包含所需資料欄的清單。 ## 使用近似值最佳化查詢 Athena 支援[近似彙總函數](https://trino.io/docs/current/functions/aggregate.html#appro)，用於計算獨特值、最常出現的值、百分位數 (包括近似中位數)，以及建立直方圖。每當不需要確切值時，請使用這些函數。 與 `COUNT(DISTINCT col)` 操作不同，[approx\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) 使用的記憶體更少且執行速度更快。同樣，使用 [numeric\$1histogram](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram) (而不是[直方圖](https://trino.io/docs/current/functions/aggregate.html#histogram)) 使用了近似方法，因此所需的記憶體更少。 ## 最佳化 LIKE 您可以使用 `LIKE` 來查找相符字串，但對於長字串而言，此為計算密集型。[regexp\$1like](https://trino.io/docs/current/functions/regexp.html#regexp_like) 函數在大多數情況下是一個更快的替代方案，並且還提供了更多的靈活性。 通常，您可以透過錨定要尋找的子字串來最佳化搜尋。*例如，如果您正在尋找字首，最好使用 '*substr*%' 而不是 '%substr*%'。或者，如果您使用的是 `regexp_like`，則為 '^*substr*'。 ## 使用 UNION ALL 而非 UNION `UNION ALL` 和 `UNION` 是兩種將兩個查詢結果合併為一個結果的方法。`UNION ALL` 將第一個查詢中的記錄與第二個查詢中的記錄串連起來，且 `UNION` 會執行相同的操作，但也會移除重複項目。`UNION` 需要處理所有記錄並找到重複項目，此為記憶體和計算密集型，不過 `UNION ALL` 是一個相對快速的操作。除非您需要重複記錄，否則請使用 `UNION ALL` 以獲得最佳效能。 ## 對大型結果集使用 UNLOAD 當查詢結果預期很大 (例如，數萬個資料列或更多) 時，請使用 UNLOAD 匯出結果。在大多數情況下，這比執行規則查詢更快，並且使用 `UNLOAD` 也可以讓您更好地控制輸出。 查詢完成執行後，Athena 會將結果以單一未壓縮的 CSV 檔案形式存放在 Amazon S3 上。這比 `UNLOAD` 需要更長的時間，不僅因為結果未壓縮，而且還因為操作無法平行化。相反地，`UNLOAD` 會直接從工作節點寫入結果，並充分利用運算叢集的平行處理。此外，您可以設定 `UNLOAD`，以壓縮格式和其他檔案格式 (例如 JSON 和 Parquet) 寫入結果。 如需詳細資訊，請參閱[UNLOAD](unload.md)。 ## 使用 CTAS 或 Glue ETL 將常用的彙總具體化 「具體化」查詢是一種透過儲存預先計算的複雜查詢結果 (例如，彙總和聯結) 以便在後續查詢中重複使用，來加速查詢效能的方法。 如果您的許多查詢包含相同的聯結和彙總，您可以將通用子查詢具體化為新資料表，然後針對該資料表執行查詢。您可以使用 [從查詢結果建立資料表 (CTAS)](ctas.md) 或專用 ETL 工具 (例如 [Glue ETL](https://aws.amazon.com/glue)) 來建立新的資料表。 例如，假設您的儀表板中包含顯示訂單資料集的不同層面的小工具。每個小工具都有自己的查詢，但所有查詢會共用相同的聯結和篩選條件。訂單資料表會與明細項目資料表結合在一起，而且有一個篩選條件，可僅顯示過去三個月。如果您識別這些查詢的常用功能，您可以建立小工具可使用的新資料表。這樣可以減少重複並提高效能。缺點是您必須將資料表保持在最新狀態。 ## 重複使用查詢結果 同一查詢在短時間內執行多次非常常見。例如，當多個人開啟相同的資料儀表板時，就會發生這種情況。執行查詢時，您可以告訴 Athena 重複使用先前計算的結果。您可以指定要重複使用的結果的最長期限。如果先前在該時間範圍內執行同一查詢，Athena 會傳回這些結果，而不是再次執行查詢。如需詳細資訊，請參閱此處《*Amazon Athena 使用者指南*》中的 [在 Athena 中重複使用查詢結果](reusing-query-results.md)，以及 *AWS 大數據部落格*中的[使用 Amazon Athena 查詢結果重複使用降低成本和提升查詢效能](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/)。 # 最佳化資料 效能不僅取決於查詢，而且還取決於資料集的組織方式，以及資料集使用的檔案格式和壓縮。 ## 分割您的資料 分割會將您的資料表分為多個部分，並根據日期、國家或地區等屬性將相關資料保留在一起。分割區索引鍵可可做為虛擬資料欄。您可以在建立資料表時定義分割區索引鍵，並使用它們來篩選查詢。當您篩選分割區索引鍵資料欄時，只會讀取相符分割區中的資料。例如，如果您的資料集依日期進行分割，而您的查詢具有僅符合上週的篩選條件，則只會讀取上週的資料。如需有關分割區的詳細資訊，請參閱 [分割您的資料](partitions.md)。 ## 選擇將支援您查詢的分割區索引鍵 由於分割會對查詢效能產生重大影響，因此在設計資料集和資料表時，請務必仔細考慮分割的方式。分割區索引鍵太多可能會導致資料集分段為過多的檔案且各個檔案過小。相反地，分割區索引鍵太少或完全沒有分割，會導致查詢掃描的資料超過必要的資料。 ### 避免最佳化罕見查詢 一個好的策略是針對最常見的查詢進行最佳化，並避免針對罕見查詢進行最佳化。例如，如果您的查詢瀏覽時間跨度 (天數)，即使某些查詢會篩選至該級別，也不要按小時進行分割。如果您的資料具有精確的時間戳記資料欄，則依小時篩選的罕見查詢可以使用時間戳記資料欄。即使極少數情況掃描的資料超過必要的資料，為了極少數情況而降低整體效能通常不是一種很好的權衡。 若要減少查詢必須掃描的資料量，進而改善效能，請使用單欄式檔案格式，並保持記錄排序。請依時間戳記排序記錄，而不是依小時分割。對於在較短時間視窗上進行查詢，按時間戳記排序的效率幾乎與依小時分割一樣有效。此外，依時間戳記排序通常不會損害時間視窗上的查詢效能 (以天數計算)。如需詳細資訊，請參閱[使用單欄式檔案格式](#performance-tuning-use-columnar-file-formats)。 請注意，如果所有分割區索引鍵都有述詞，則對具有數萬個分割區的資料表進行查詢的效果會更好。這是為最常見的查詢設計分割結構的另一個原因。如需詳細資訊，請參閱[依等式查詢分割區](#performance-tuning-query-partitions-by-equality)。 ## 使用分割區投影 分割區投影是一種 Athena 功能，可儲存不在 中的分割區資訊 AWS Glue Data Catalog，但做為 資料表屬性中的規則 AWS Glue。當 Athena 在設定了分割區投影的資料表上計劃查詢時，其會讀取資料表的分割區投影規則。Athena 會根據查詢和規則，計算要在記憶體中讀取的分割區，而不是在 AWS Glue Data Catalog中查找分割區。 除了簡化分割區管理之外，分割區投影還可以改善具有大量分割區的資料集的效能。當查詢包含範圍而不是分割區索引鍵的特定值時，在目錄中查找相符分割區所花費的時間越長，所需的分割區就越多。使用分割區投影，可以在記憶體中計算篩選條件而無需進入目錄，並且速度可以更快。 在某些情況下，分割區投影可能會導致效能變差。一個範例就是當資料表為「稀疏」時。稀疏資料表沒有分割區投影組態所描述的分割區索引鍵值的每個排列資料。使用稀疏資料表時，從查詢和分割區投影組態計算的一組分區都會列在 Amazon S3 上，即使它們沒有資料也一樣。 當您使用分割區投影時，請務必在所有分割區索引鍵上包含述詞。縮小可能值的範圍，以避免不必要的 Amazon S3 清單。假設一個分割區索引鍵的範圍包含一百萬個值，以及查詢在該分割區索引鍵上沒有任何篩選條件。若要執行查詢，Athena 必須執行至少一百萬個 Amazon S3 清單操作。查詢特定值時，無論您是使用分割區投影還是將分割區資訊儲存在目錄中，查詢速度都是最快的。如需詳細資訊，請參閱[依等式查詢分割區](#performance-tuning-query-partitions-by-equality)。 當您設定分割區投影的資料表時，請確定您指定的範圍是合理的。如果查詢不包含分割區索引鍵的述詞，則會使用該索引鍵範圍內的所有值。如果您的資料集是在特定日期建立的，請使用該日期做為任何日期範圍的起點。使用 `NOW` 作為日期範圍的結束。避免使用具有大量值的數值範圍，並考慮改用[注入](partition-projection-dynamic-id-partitioning.md#partition-projection-injection)類型。 如需有關分割區投影的詳細資訊，請參閱[透過 Amazon Athena 使用分割區投影](partition-projection.md)。 ## 使用分割區索引 分割區索引是 中的一項功能 AWS Glue Data Catalog ，可改善具有大量分割區之資料表的分割區查詢效能。 目錄中的分割區清單就像是關聯式資料庫中的資料表。此資料表包含分割區索引鍵的資料欄，以及分割區位置的其他資料欄。當您查詢分割區資料表時，會掃描此資料表來查詢分割區位置。 就像關聯式資料庫一樣，您可以透過新增索引來提高查詢的效能。您可以新增多個索引，以支援不同的查詢模式。 AWS Glue Data Catalog 分割區索引支援等式運算子和比較運算子`>`，例如 `>=`、 和 與運算`AND`子`<`結合。如需詳細資訊，請參閱《 *AWS Glue 開發人員指南*》中的[在 中使用分割區索引 AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)，以及《 *AWS 大數據部落格*》中的[使用 AWS Glue Data Catalog 分割區索引改善 Amazon Athena 查詢效能](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/)。 ## 始終使用 STRING 做為分割區索引鍵類型 當您查詢分割區索引鍵時，請記住 Athena 要求分割區索引鍵為類型 `STRING`，才能將分割區篩選下推至 AWS Glue。如果分割區數目不小，使用其他類型可能會導致效能變差。如果您的分割區索引鍵值為 date-like 或 number-like，請將它們轉換為查詢中的適當類型。 ## 移除舊的和空的分割區 如果您從 Amazon S3 上的分割區移除資料 (例如，使用 Amazon S3 [生命週期](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html))，您也應該從 AWS Glue Data Catalog中移除分割區項目。在查詢規劃期間，與查詢相符的任何分割區都會列在 Amazon S3 上。如果您有許多空的分割區，列出這些分割區的負荷可能會產生不利影響。 此外，如果您有數千個分割區，請考慮移除不再相關的舊資料的分割區中繼資料。例如，如果查詢從未查看超過一年的資料，您可以定期移除舊分割區的分割區中繼資料。如果分割區數目增加到數萬個，移除未使用的分割區可以加速查詢，其中這些查詢不包含所有分割區索引鍵的述詞。如需有關在查詢中包含所有分割區索引鍵的述詞的資訊，請參閱 [依等式查詢分割區](#performance-tuning-query-partitions-by-equality)。 ## 依等式查詢分割區 在所有分割區索引鍵上包含等式述詞的查詢執行速度更快，因為可以直接載入分割區中繼資料。避免查詢中一個或多個分割區索引鍵沒有述詞，或述詞選擇了範圍值。對於此類查詢，必須篩選所有分割區的清理，以找到相符的值。對於大多數資料表而言，負荷會降至最低，但對於具有數萬個或更多分割區的資料表而言，負荷可能會變得很大。 如果無法重寫查詢以透過等式篩選分割區，則可以嘗試分割區投影。如需詳細資訊，請參閱[使用分割區投影](#performance-tuning-use-partition-projection)。 ## 避免使用 MSCK REPAIR TABLE 進行分割區維護 由於 `MSCK REPAIR TABLE` 可能需要很長的時間才能執行，並且僅會新增分割區，而不會移除舊的分割區，因此不是管理分割區的有效方法 (請參閱 [考量和限制](msck-repair-table.md#msck-repair-table-considerations))。 使用 [AWS Glue Data Catalog API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html)、[ALTER TABLE ADD PARTITION](alter-table-add-partition.md) 或 [AWS Glue 爬蟲程式](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html)可以更好地手動管理分割區。或者，您也可以使用分割區投影，這樣就不需要完全管理分割區。如需詳細資訊，請參閱[透過 Amazon Athena 使用分割區投影](partition-projection.md)。 ## 驗證您的查詢是否與分割結構相容 您可以使用 [`EXPLAIN`](athena-explain-statement.md) 陳述式預先檢查查詢將掃描的分割區。使用 `EXPLAIN` 關鍵字作為查詢字首，然後在 `EXPLAIN` 輸出底部附近查找每個資料表的來源片段 (例如，`Fragment 2 [SOURCE]`)。查找右側被定義為分割區索引鍵的指派。下方的列包含一份清單，列出執行查詢時將要掃描的該分割區索引鍵的所有值。 例如，假設您對具有 `dt` 分割區索引鍵的資料表進行查詢，並使用 `EXPLAIN` 作為查詢字首。如果查詢中的值是日期，並且篩選條件選取了三天的範圍，則 `EXPLAIN` 輸出可能如下所示： ``` dt := dt:string:PARTITION_KEY :: [[2023-06-11], [2023-06-12], [2023-06-13]] ``` `EXPLAIN` 輸出顯示，規劃程式找到了此分割區索引鍵的三個值，且其與查詢相符。它還顯示了這些值是什麼。如需有關使用 `EXPLAIN` 的詳細資訊，請參閱 [在 Athena 使用 EXPLAIN 和 EXPLAIN ANALYZE](athena-explain-statement.md) 和 [了解 Athena EXPLAIN 陳述式結果](athena-explain-statement-understanding.md)。 ## 使用單欄式檔案格式 專為分散式分析工作負載而設計的單欄式檔案格式，例如 Parquet 和 ORC。它們依資料欄而非資料列整理資料。以單欄式格式整理資料具有下列優點： + 僅會載入查詢所需的資料欄 + 減少需要載入的整體資料量 + 資料欄值會一起存放，因此可以有效地壓縮資料 + 檔案可以包含允許引擎略過載入不需要的資料的中繼資料 做為如何使用檔案中繼資料的範例，檔案中繼資料可以包含有關資料頁面中最小值和最大值的資訊。如果查詢的值不在中繼資料中註明的範圍內，則可以略過該頁面。 使用此中繼資料提高效能的一種方法是，確定對檔案中的資料進行排序。例如，假設您有查詢會尋找 `created_at` 項目在短時間範圍內的記錄。如果您的資料依 `created_at` 資料欄排序，Athena 可以使用檔案中繼資料中的最小值和最大值來略過資料檔案中不需要的部分。 使用單欄式檔案格式時，請確定檔案不會太小。如 [避免檔案太多](#performance-tuning-avoid-having-too-many-files) 中所述，含有許多小型檔案的資料集會造成效能問題。對於單欄式檔案格式而言，尤其如此。對於小型檔案，單欄式檔案格式的負荷超過優勢。 請注意，Parquet 和 ORC 在內部依資料列群組 (Parquet) 和條紋 (ORC) 進行整理。資料列群組的預設大小為 128 MB，而條紋的預設大小則為 64 MB。如果您有許多資料欄，您可以增加資料列群組和條紋大小，以提升效能。不建議將資料列群組或條紋大小減少至小於其預設值。 若要將其他資料格式轉換為 Parquet 或 ORC，您可以使用 AWS Glue ETL 或 Athena。如需詳細資訊，請參閱[轉換為單欄式格式](columnar-storage.md#convert-to-columnar)。 ## 壓縮資料 Athena 支援各種壓縮格式。查詢壓縮資料的速度更快，也更便宜，因為您需要為解壓縮前掃描的位元組數量進行支付。 [gzip](https://www.gnu.org/software/gzip/) 格式提供了良好的壓縮比，並且在其他工具和服務中具有廣泛的支援。[zstd](https://facebook.github.io/zstd/) (Zstandard) 格式是一種較新的壓縮格式，可使效能和壓縮比之間達到良好的平衡。 壓縮文字檔案 (例如 JSON 和 CSV 資料) 時，請嘗試在檔案數量和檔案大小之間取得平衡。大多數壓縮格式都要求讀者從頭開始讀取檔案。這表示一般而言，壓縮的文字檔案無法平行處理。大型未壓縮的檔案通常會在工作者之間分割，以在查詢處理期間達到更高的平行處理能力，但大多數壓縮格式無法執行這項操作。 如 [避免檔案太多](#performance-tuning-avoid-having-too-many-files) 中所述，檔案最好不要太多也不宜過少。由於檔案數目是可處理查詢的工作者數量限制，因此對於壓縮檔案而言，此規則尤其如此。 如需有關在 Athena 中使用壓縮的詳細資訊，請參閱 [在 Athena 中使用壓縮](compression-formats.md)。 ## 使用歸納來查詢具有高基數的索引鍵 歸納是一種技術，可根據其中一個資料欄的值，將記錄分佈至個別檔案中。這能確保具有相同值的所有記錄都位於同一個檔案中。當您擁有高基數的索引鍵，而且許多查詢都會查詢索引鍵的特定值時，歸納功能非常有用。 例如，假設您查詢特定使用者的一組記錄。如果資料是依使用者 ID 歸納，Athena 會事先知道哪些檔案包含特定 ID 的記錄，哪些檔案不包含。這可讓 Athena 僅讀取包含 ID 的檔案，進而大幅減少讀取的資料量。這同意也可減少在資料中搜尋特定 ID 所需的運算時間。 ### 當查詢頻繁搜尋資料欄中的多個值時，請避免使用歸納 當查詢經常在資料歸納的資料欄中搜尋多個值時，歸納的價值就不太重要。查詢的值越多，必須讀取所有或大部分檔案的可能性就越高。例如，如果您有三個儲存貯體，而查詢會尋找三個不同的值，則可能必須讀取所有檔案。當查詢在查找單一值時，歸納效果最佳。 如需詳細資訊，請參閱[使用分割和歸納](ctas-partitioning-and-bucketing.md)。 ## 避免檔案太多 由許多小型檔案組成的資料集會導致整體查詢效能不佳。Athena 計劃查詢時，會列出所有分割區位置，而這需要花費一些時間。處理和請求每個檔案也會產生運算負載。因此，從 Amazon S3 載入單一較大的檔案比從許多較小的檔案載入相同記錄更快。 在極端情況下，您可能會遇到 Amazon S3 服務限制。針對單一索引分割區，Amazon S3 每秒最多可支援 5,500 個請求。最初，儲存貯體會被視為單一索引分割區，但隨著請求載入的增加，它可以分割成多個索引分割區。 Amazon S3 會根據索引鍵字首查詢請求模式和分割。如果您的資料集包含數千個檔案，則來自 Athena 的請求可能會超出請求的配額。即使檔案較少，如果對同一個資料集進行多個並行查詢，則可能會超過配額。存取相同檔案的其他應用程式可能會增加請求總數。 當超出請求率 `limit` 時，Amazon S3 會傳回下列錯誤。此錯誤已包含在 Athena 查詢的狀態資訊中。 SlowDown：請降低請求率 若要進行疑難排解，請先判斷錯誤是由單一查詢還是由可讀取相同檔案的多個查詢造成的。如果是後者，請協調查詢的執行，以便它們不會同時執行。為此，請在應用程式中新增佇列機制，甚至是重試。 如果執行單一查詢觸發錯誤，請嘗試合併資料檔案或修改查詢，以讀取較少的檔案。合併小型檔案的最佳時間是在將其寫入之前。為此，請考慮下列技巧： + 變更寫入檔案的程序，以寫入較大的檔案。例如，您可以在寫入記錄之前緩衝一段較長的時間。 + 將檔案放在 Amazon S3 上的某個位置，然後使用 Glue ETL 等工具將其合併為較大的檔案。然後，將較大的檔案移至資料表所指向的位置。如需詳細資訊，請參閱《 *AWS Glue 開發人員指南*》中的[讀取較大群組中的輸入檔案](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html)，以及[如何在 re：Post 知識中心中設定 AWS Glue ETL 任務以輸出較大的檔案？](https://repost.aws/knowledge-center/glue-job-output-large-files)。 *AWS * + 減少分割區索引鍵的數量。當您的分割區索引鍵太多時，每個分割區可能只有少數記錄，因此會產生過多的小型檔案。如需有關決定要建立哪些分割區的資訊，請參閱 [選擇將支援您查詢的分割區索引鍵](#performance-tuning-pick-partition-keys-that-will-support-your-queries)。 ## 避免分割區以外的其他儲存體階層 若要避免查詢規劃負荷，請將檔案儲存在每個分割區位置的單層式結構中。請勿使用任何其他目錄階層。 Athena 計劃查詢時，會列出與查詢相符的所有分割區中的所有檔案。雖然 Amazon S3 本身沒有目錄，但慣例是將 `/` 斜線解譯為目錄分隔符號。當 Athena 列出分割區位置時，其會遞歸列出找到的任何目錄。當分割區內的檔案整理成階層時，會出現多輪清單。 當所有檔案都直接位於分割區位置時，大多數情況下只需執行一個清單操作。但是，如果一個分割區中有 1000 個以上的檔案，則需要多個連續清單操作，因為 Amazon S3 每個清單操作只會傳回 1000 個物件。分區中有 1000 多個檔案也可能會導致其他更嚴重的效能問題。如需詳細資訊，請參閱[避免檔案太多](#performance-tuning-avoid-having-too-many-files)。 ## 僅在必要時使用 SymlinkTextInputFormat 使用 [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat) 技術可以是一種解決相關情況的方法，當資料表的檔案沒有整齊地整理到分割區中時。例如，當所有檔案都使用相同的字首，或是具有不同結構描述的檔案位於相同位置時，符號連結可能很有用。 但是，使用符號連結會為查詢執行增加間接層級。這些間接層級會影響整體效能。必須讀取符號連結檔案，並且必須列出它們定義的位置。如此會新增至 Amazon S3 的多次往返，而這並非常見 Hive 資料表所需的。總之，只有當沒有更好的選項 (例如整理檔案) 可用時，您才應使用 `SymlinkTextInputFormat`。 # 使用單欄式儲存格式 [Apache Parquet](https://parquet.apache.org) 和 [ORC](https://orc.apache.org/) 是經過最佳化的單欄式儲存格式，可快速擷取資料並用於 AWS 分析應用程式。 單欄式儲存格式具有以下特點，使其適用於 Athena： + *針對資料欄資料類型選擇壓縮演算法來壓縮欄*，可以節省 Amazon S3 中的儲存空間，並在查詢處理期間降低磁碟空間和輸入/輸出。 + Parquet 和 ORC 中的*述詞下推*，可讓 Athena 查詢僅擷取需要的區塊，進而提高查詢效能。當 Athena 查詢從您的資料中取得特定資料欄值時，它會使用資料區塊述詞 (例如上限/下限值) 的統計資料，判斷要讀取或略過該區塊。 + Parquet 和 ORC 中的*資料分割*，可讓 Athena 將資料的讀取分割給多個讀取器，在其查詢處理期間增加平行處理。 若要將您現有的原始資料從其他儲存格式轉換為 Parquet 或 ORC，您可以在 Athena 中執行 [CREATE TABLE AS SELECT (CTAS)](ctas.md) 查詢，並將資料儲存格式指定為 Parquet 或 ORC，或使用 AWS Glue 爬蟲程式。 ## 在 Parquet 與 ORC 之間進行選擇 ORC (優化列單欄式) 和 Parquet 之間的選擇取決於您的特定使用需求。 Apache Parquet 提供高效的資料壓縮和編碼機制，非常適合用於執行複雜查詢和處理大量資料。為與 [Apache Arrow](https://arrow.apache.org/) 搭配使用，Parquet 進行了優化，因此如果您使用與 Arrow 相關的工具，Parquet 可能比較有利。 ORC 可以很有效率地存放 Hive 資料。ORC 檔案通常比 Parquet 檔案要小，因此 ORC 索引可以加快查詢速度。此外，ORC 支援複雜類型，例如結構、映射和清單。 在 Parquet 或 ORC 間選擇時，請考慮以下因素： **查詢效能** – 由於 Parquet 能夠支援更廣泛的查詢類型，因此，如果您打算執行複雜的查詢，則 Parquet 可能是更好的選擇。 **複雜的資料類型** – 如果您使用的是複雜的資料類型，那麼 ORC 可能是更好的選擇，因為它能支援更廣泛的複雜資料類型。 **檔案大小** – 如果需要考慮磁碟空間，ORC 通常可產生較小的檔案，進而降低儲存成本。 **壓縮** – Parquet 和 ORC 均可提供良好的壓縮，但最適合您的最佳格式主要取決於您的特定使用案例。 **演進** – Parquet 和 ORC 均可支援支持結構描述變化，這意味著您可以隨時間新增、刪除或修改資料欄。 對於大數據應用程式來說，Parquet 和 ORC 都是不錯的選擇，但在選擇之前，請考慮您的案例需求。您可能希望對資料和查詢執行基準測試，以查看哪種格式更適合您的使用案例。 ## 轉換為單欄式格式 將 JSON 或 CSV 等來源資料輕鬆轉換為單欄式格式的選項，包括使用 [CREATE TABLE AS](ctas.md) 查詢或執行 AWS Glue中的任務。 + 使用 `CREATE TABLE AS` (CTAS) 查詢，只需一個步驟即可將資料轉換為 Parquet 或 ORC。如需範例，請參閱 [CTAS 查詢的範例](ctas-examples.md) 頁面上的[範例：將查詢結果寫為不同格式](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format)。 + 如需有關使用 Athena for ETL 將資料從 CSV 轉換為 Parquet 的詳細資訊，請參閱 [使用 CTAS 和 INSERT INTO 以進行 ETL 和資料分析](ctas-insert-into-etl.md)。 + 如需有關執行 AWS Glue 任務以將 CSV 資料轉換為 Parquet 的資訊，請參閱 AWS 大數據部落格文章中的「將資料從 CSV 轉換為 Parquet 格式」一節[使用 AWS Glue 和 Amazon S3 建置資料湖基礎](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/)。 AWS Glue 支援使用相同的技術將 CSV 資料轉換為 ORC，或 JSON 資料轉換為 Parquet 或 ORC。 # 使用分割和歸納 分割和歸納是減少執行查詢時 Athena 必須掃描的資料量的兩種方法。分割和歸納互為補充，且可搭配使用。減少掃描的資料量可改善查詢效能並降低成本。如需有關 Athena 查詢效能的一般指導方針，請參閱 [Amazon Athena 的十大效能調校秘訣](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)。 **Topics** + [什麼是分割？](ctas-partitioning-and-bucketing-what-is-partitioning.md) + [什麼是歸納？](ctas-partitioning-and-bucketing-what-is-bucketing.md) + [其他資源](ctas-partitioning-and-bucketing-additional-resources.md) # 什麼是分割？ 分割表示根據資料的特定屬性，將資料整理到 Amazon S3 上的目錄 (或「字首」)。這類屬性稱為分割區索引鍵。常見的分割區索引鍵是日期或一些其他時間單位，例如年份或月份。不過，資料集可以依多個索引鍵進行分割。例如，有關產品銷售的資料可能依日期、產品類別和市場進行分割。 ## 決定如何分割 分割區索引鍵的理想候選者是始終或經常在查詢中使用且具有低基數的屬性。分割區過多和分割區過少之間需要取得權衡。由於分割區過多，檔案數增加會產生負荷。篩選分割區本身也有一些負荷。如果分割區太少，查詢通常需要掃描更多資料。 ## 建立分割的資料表 分割資料集後，您可以在 Athena 建立分割的資料表。分割的資料表是具有分割區索引鍵的資料表。使用 `CREATE TABLE` 時，您可以將分割區新增至資料表中。使用 `CREATE TABLE AS` 時，在 Amazon S3 上建立的分割區會自動新增至資料表。 在 `CREATE TABLE` 陳述式中，您可以在 `PARTITIONED BY (column_name data_type)` 子句中指定分割區索引鍵。在 `CREATE TABLE AS` 陳述式中，您可以在 `WITH (partitioned_by = ARRAY['partition_key'])` 子句或 Iceberg 資料表的 `WITH (partitioning = ARRAY['partition_key'])` 中指定分割區索引鍵。出於效能考量，分割區索引鍵應始終是類型 `STRING`。如需詳細資訊，請參閱[使用字串做為分割區索引鍵的資料類型](data-types-timestamps.md#data-types-timestamps-partition-key-types)。 如需其他 `CREATE TABLE` 和 `CREATE TABLE AS` 語法詳細資訊，請參閱 [CREATE TABLE](create-table.md) 和 [CTAS 資料表屬性](create-table-as.md#ctas-table-properties)。 ## 查詢分割的資料表 當您查詢分割區資料表時，Athena 會使用查詢中的述詞來篩選分割區的清單。然後，其會使用相符分割區的位置來處理找到的檔案。Athena 只要不讀取與查詢述詞不相符的分割區中的資料，就能有效減少掃描的資料量。 ### 範例 假設您有一個依 `sales_date` 和 `product_category` 分割的資料表，並且想知道特定類別中一周的總收入。您可以在 `sales_date` 和 `product_category` 資料欄上加入述詞，以確保 Athena 只掃描最少量的資料，如下列範例所示。 ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND product_category = 'Toys' ``` 假設您有依日期分割的資料集，但也有精細的時間戳記。 使用 Iceberg 資料表，您可以宣告分割區索引鍵與資料欄之間的關係，但是使用 Hive 資料表時，查詢引擎對資料欄和分割區索引鍵之間的關係一無所知。因此，您必須在查詢中包含資料欄和分割區索引鍵的述詞，以確保查詢掃描的資料不會超過必要數目。 例如，假設上一個範例中的 `sales` 資料表也有 `TIMESTAMP` 資料類型的 `sold_at` 資料欄。如果您只想在特定時間範圍內獲得收入，則可以像這樣寫入查詢： ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date = '2023-02-28' AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' AND product_category = 'Toys' ``` 如需有關查詢 Hive 和 Iceberg 資料之間的差異的詳細資訊，請參閱 [如何寫入同樣按時間分割的時間戳記欄位的查詢](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned)。 # 什麼是歸納？ 歸納是一種將資料集的記錄整理至稱為儲存貯體的類別的方法。 儲存貯體和歸納的含義與 Amazon S3 儲存貯體不同，且不應與 Amazon S3 儲存貯體混淆。在資料歸納中，具有相同屬性值的記錄會進入同一個儲存貯體。記錄會盡可能在儲存貯體之間平均分配，因此每個儲存貯體的資料量大致相同。 實際上，儲存貯體是檔案，而雜湊函數可確定記錄進入的儲存貯體。歸納的資料集在每個分割區的每個儲存貯體中會有一或多個檔案。檔案所屬的儲存貯體會以檔案名稱編碼。 ## 歸納益處 當資料集依特定屬性進行歸納，而且您想要擷取該屬性具有特定值的記錄時，歸納功能非常有用。由於資料是歸納性質的，Athena 可以使用此值來判斷要查看的檔案。例如，假設資料集依 `customer_id` 進行歸納，而您想要尋找特定客戶的所有記錄。Athena 會判斷包含這些記錄的儲存貯體，而且只會讀取該儲存貯體中的檔案。 當您的資料欄具有高基數 (也就是，有許多不同的值)、平均分散，以及您經常查詢特定值的資料欄時，就會發生歸納的適當候選項。 **注意** Athena 不支援使用 `INSERT INTO` 將新記錄新增至歸納的資料表。 ## 支援依據已歸納資料欄進行篩選的資料類型 您可以在具有某些資料類型的歸納資料欄上新增篩選條件。Athena 支援對具有下列資料類型的已歸納資料欄進行篩選： + BOOLEAN + BYTE + DATE + DOUBLE + FLOAT + INT + LONG + SHORT + STRING + VARCHAR ## Hive 和 Spark 支援 Athena 引擎版本 2 支援使用 Hive 儲存貯體演算法歸納的資料集，而 Athena 引擎版本 3 也支援 Apache Spark 歸納演算法。預設為 Hive 歸納。如果您的資料集是使用 Spark 演算法歸納，請使用 `TBLPROPERTIES` 子句將 `bucketing_format` 屬性值設定為 `spark`。 **注意** Athena 在每個 `CREATE TABLE AS SELECT` ([CTAS](ctas.md)) 查詢的分割區限制為 100 個。同樣地，您僅可以使用 [INSERT INTO](insert-into.md) 陳述式將最多 100 個分割區新增至目的地資料表。 如果您超出此限制，您可能會收到錯誤訊息 HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Exceeded limit of 100 open writers for partitions/buckets (HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS：超過分割區／儲存貯體 100 個開啟寫入器的限制)。若要避開此限制，您可以使用 CTAS 陳述式和一系列的 `INSERT INTO` 陳述式，每個陳述式可建立或插入最多 100 個分割區。如需詳細資訊，請參閱[使用 CTAS 和 INSERT INTO 來解決 100 個分割區限制](ctas-insert-into.md)。 ## 歸納 CREATE TABLE 範例 若要為現有歸納的資料集建立資料表，請使用 `CLUSTERED BY (column)` 子句，後面接著 `INTO N BUCKETS` 子句。`INTO N BUCKETS` 子句指定了資料要歸納到的儲存貯體數量。 在下列 `CREATE TABLE` 範例中，使用 Spark 演算法，依 `customer_id` 將 `sales` 資料集歸納成 8 個儲存貯體。`CREATE TABLE` 陳述式會使用 `CLUSTERED BY` 和 `TBLPROPERTIES` 子句來設定相應的屬性。 ``` CREATE EXTERNAL TABLE sales (...) ... CLUSTERED BY (`customer_id`) INTO 8 BUCKETS ... TBLPROPERTIES ( 'bucketing_format' = 'spark' ) ``` ## 歸納 CREATE TABLE AS (CTAS) 範例 若要使用 `CREATE TABLE AS` 指定歸納，請使用 `bucketed_by` 和 `bucket_count` 參數，如下列範例所示。 ``` CREATE TABLE sales WITH ( ... bucketed_by = ARRAY['customer_id'], bucket_count = 8 ) AS SELECT ... ``` ## 歸納查詢範例 下列範例查詢會尋找特定客戶在一週內購買的產品名稱。 ``` SELECT DISTINCT product_name FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND customer_id = 'c123' ``` 如果此資料表依 `sales_date` 進行分割並依 `customer_id` 歸納，則 Athena 可以計算客戶記錄所在的儲存貯體。Athena 每個分割區最多只能讀取一個檔案。 # 其他資源 + 有關建立歸納和分割資料表的 `CREATE TABLE AS` 範例，請參閱[範例：建立歸納和分割的資料表](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed)。 + 如需在 AWS 資料湖實作儲存貯體的資訊，包括使用 Athena CTAS 陳述式、 AWS Glue 適用於 Apache Spark 的儲存貯體，以及適用於 Apache Iceberg 資料表的儲存貯體，請參閱 AWS 大數據部落格文章[使用 Amazon Athena 儲存貯體最佳化資料配置 AWS Glue ，並加速下游查詢](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/)。 # 分割您的資料 您可以分割資料，以限制每個查詢所掃描的資料量，從而提高效能和降低成本。您可透過任何索引鍵來分割您的資料。常見做法是根據時間來分割資料，這通常會產生多層級的分割機制。例如，每小時都有資料傳入的客戶可能決定依年、月、日、小時來分割。另一個客戶的資料來自許多不同來源，且每天只載入一次，則可能依資料來源識別符和日期來分割。 Athena 可以使用 Apache Hive 樣式的分割區，其資料路徑包含由等號連接的鍵值對 (例如 `country=us/...` 或 `year=2021/month=01/day=26/...`)。因此，路徑會包含分割區索引鍵的名稱，以及每個路徑所代表的值。若要將新的 Hive 分割區載入已分割的資料表，您可以使用 [MSCK REPAIR TABLE](msck-repair-table.md) 命令，其只適用於 Hive 樣式的分割區。 Athena 也可以使用非 Hive 樣式的分割區結構描述。例如，CloudTrail 日誌和 Firehose 交付串流對日期部分使用不同的路徑元件，例如 `data/2021/01/26/us/6fc7845e.json`。對於這類非 Hive 樣式的分割區，您可以使用 [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) 手動新增分割區。 ## 考量和限制 使用分割區時，請謹記以下幾點： + 若您查詢已分割的資料表並在 `WHERE` 子句中指定分割區，Athena 便只會掃描該分割區中的資料。 + 如果您對 Amazon S3 儲存貯體發出具有大量物件的查詢，並且未將資料分割，這類查詢可能會影響 Amazon S3 中的 `GET` 請求率限制，並導致 Amazon S3 例外狀況。若要避免錯誤，請分割您的資料。此外，請考慮調校您的 Amazon S3 請求率。如需詳細資訊，請參閱[最佳實務設計模式：最佳化 Amazon S3 效能](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html)。 + 要搭配 Athena 使用的分割區位置必須使用 `s3` 通訊協定 (例如，`s3://amzn-s3-demo-bucket/folder/`)。在 Athena 中，當在包含的資料表上執行 `MSCK REPAIR TABLE` 查詢時，使用其他通訊協定的位置 (例如 `s3a://amzn-s3-demo-bucket/folder/`) 會導致查詢失敗。 + 請確定 Amazon S3 路徑是小寫而不是小駝峰式命名法 (camel case) (例如，`userid` 而非 `userId`)。如果 S3 路徑是小駝峰式命名法 (camel case)，則 `MSCK REPAIR TABLE` 不會將分割區新增到 AWS Glue Data Catalog。如需詳細資訊，請參閱 [MSCK REPAIR TABLE](msck-repair-table.md)。 + 由於 `MSCK REPAIR TABLE` 會同時掃描資料夾及其子資料夾，以尋找相符的分割區配置，請務必將個別資料表的資料留在不同的資料夾階層中。例如，假設您在 `s3://amzn-s3-demo-bucket1` 中有資料表 1 的資料，在 `s3://amzn-s3-demo-bucket1/table-2-data` 中有資料表 2 的資料。如果兩個資料表都以字串分割，`MSCK REPAIR TABLE` 會將資料表 2 的分割區新增至資料表 1 中。為避免此情況，請改用單獨的資料夾結構，如 `s3://amzn-s3-demo-bucket1` 和 `s3://amzn-s3-demo-bucket2`。請注意，此行為與 Amazon EMR 和 Apache Hive 一致。 + 如果您將 AWS Glue Data Catalog 與 Athena 搭配使用，請參閱每個帳戶[AWS Glue 和每個資料表分割區上服務配額的端點](https://docs.aws.amazon.com/general/latest/gr/glue.html)和配額。 + 雖然 Athena 支援查詢具有 1，000 萬個分割區的 AWS Glue 資料表，但 Athena 無法在單一掃描中讀取超過 100 萬個分割區。在這種情況下，分割區索引可能有利。如需詳細資訊，請參閱 AWS 大數據部落格文章[使用 AWS Glue Data Catalog 分割區索引改善 Amazon Athena 查詢效能](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/)。 + 若要在使用 時請求增加分割區配額 AWS Glue Data Catalog，請造訪 [Service Quotas 主控台 AWS Glue](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas)。 ## 建立和載入含有分割資料的資料表 若要建立使用分割區的資料表，請在 [CREATE TABLE](create-table.md) 陳述式中使用 `PARTITIONED BY` 子句。`PARTITIONED BY` 子句定義對資料進行分割區的索引鍵，如下列範例所示。`LOCATION` 子句指定已分割的資料的根位置。 ``` CREATE EXTERNAL TABLE users ( first string, last string, username string ) PARTITIONED BY (id string) STORED AS parquet LOCATION 's3://amzn-s3-demo-bucket' ``` 建立資料表之後，您可以在分割區中載入要查詢的資料。對於 Hive 樣式的分割區，您可以執行 [MSCK REPAIR TABLE](msck-repair-table.md)。對於非 Hive 樣式的分割區，您可以使用 [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) 手動新增分割區。 ## 準備 Hive 樣式和非 Hive 樣式資料進行查詢 下列區段說明如何準備 Hive 樣式和非 Hive 樣式資料，以便在 Athena 中進行查詢。 ### 案例 1：以 Hive 格式存放在 Amazon S3 上的資料 在此案例中，分割區存放在 Amazon S3 中的單獨資料夾。例如，以下是 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html) 命令輸出的廣告曝光範例的部分清單，其中列出了指定字首下的 S3 物件： ``` aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/ PRE dt=2009-04-12-13-00/ PRE dt=2009-04-12-13-05/ PRE dt=2009-04-12-13-10/ PRE dt=2009-04-12-13-15/ PRE dt=2009-04-12-13-20/ PRE dt=2009-04-12-14-00/ PRE dt=2009-04-12-14-05/ PRE dt=2009-04-12-14-10/ PRE dt=2009-04-12-14-15/ PRE dt=2009-04-12-14-20/ PRE dt=2009-04-12-15-00/ PRE dt=2009-04-12-15-05/ ``` 在此，存放的日誌將欄名稱 (dt) 設為等於日期、小時和分鐘增量。當您在 DDL 中提供父資料夾的位置、結構描述和分割欄的名稱時，Athena 就能在這些子資料夾中查詢資料。 #### 建立資料表 若要使用此資料建立資料表，請沿著 'dt' 建立分割區，如下列 Athena DDL 陳述式所示： ``` CREATE EXTERNAL TABLE impressions ( requestBeginTime string, adId string, impressionId string, referrer string, userAgent string, userCookie string, ip string, number string, processId string, browserCookie string, requestEndTime string, timers struct, threadId string, hostname string, sessionId string) PARTITIONED BY (dt string) ROW FORMAT serde 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ; ``` 此資料表使用 Hive 的原生 JSON 序列化程式-還原序列化程式，讀取存放在 Amazon S3 中的 JSON 資料。如需支援格式的詳細資訊，請參閱[為您的資料選擇 SerDe](supported-serdes.md)。 #### 執行 MSCK REPAIR TABLE 在您執行 `CREATE TABLE` 查詢後，在 Athena 查詢編輯器中執行 `MSCK REPAIR TABLE` 命令以載入分割區，如下列範例所示。 ``` MSCK REPAIR TABLE impressions ``` 執行此命令後，即可對資料進行查詢。 #### 查詢資料 使用分割區欄位查詢 impressions 資料表的資料。範例如下： ``` SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100 ``` 此查詢應該會顯示類似下列的資料： ``` 2009-04-12-13-20 ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc 2009-04-12-13-20 17uchtodoS9kdeQP1x0XThKl5IuRsV 2009-04-12-13-20 JOUf1SCtRwviGw8sVcghqE5h0nkgtp 2009-04-12-13-20 NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH 2009-04-12-13-20 fFAItiBMsgqro9kRdIwbeX60SROaxr 2009-04-12-13-20 V4og4R9W6G3QjHHwF7gI1cSqig5D1G 2009-04-12-13-20 hPEPtBwk45msmwWTxPVVo1kVu4v11b 2009-04-12-13-20 v0SkfxegheD90gp31UCr6FplnKpx6i 2009-04-12-13-20 1iD9odVgOIi4QWkwHMcOhmwTkWDKfj 2009-04-12-13-20 b31tJiIA25CK8eDHQrHnbcknfSndUk ``` ### 案例 2：資料未分割 (Hive 格式) 在下列範例中，`aws s3 ls` 命令顯示存放在 Amazon S3 中的 [ELB](elasticloadbalancer-classic-logs.md) 日誌。請注意，資料配置如何不使用 `key=value` 對，因此不屬於 Hive 格式。(`aws s3 ls` 命令的 `--recursive` 選項指定列出指定目錄或字首下的所有檔案或物件。) ``` aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive 2016-11-23 17:54:46 11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 0 elb/plaintext/2015/01/01_$folder$ 2016-11-23 17:54:47 9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 0 elb/plaintext/2015/01/02_$folder$ 2016-11-23 17:54:48 11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 0 elb/plaintext/2015/01/03_$folder$ 2016-11-23 17:54:50 8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/04_$folder$ 2016-11-23 17:54:51 7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/05_$folder$ 2016-11-23 17:54:51 11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 0 elb/plaintext/2015/01/06_$folder$ 2016-11-23 17:54:52 8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 0 elb/plaintext/2015/01/07_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015/01_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015_$folder$ ``` #### 執行 ALTER TABLE ADD PARTITION 因為資料不是 Hive 格式，您無法在建立資料表後，使用 `MSCK REPAIR TABLE` 命令將分割區新增至該資料表。相反，您可以使用 [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) 命令以手動新增每個分割區。例如，如需載入 s3://athena-examples-*myregion*/elb/plaintext/2015/01/01/ 中的資料，您可以執行下列查詢：請注意，每個 Amazon S3 資料夾不需要單獨的分割區資料欄，且分割區鍵值可與 Amazon S3 索引鍵不同。 ``` ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/' ``` 如果已具有分割區，您會收到 Partition already exists (分割區已存在) 錯誤。若要避免發生此錯誤，您可以使用 `IF NOT EXISTS` 子句。如需詳細資訊，請參閱[ALTER TABLE ADD PARTITION](alter-table-add-partition.md)。如需移除分割區，請使用 [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md)。 ## 考慮分割區投影 若要避免必須自行管理分割區，您可以使用分割區投影。分割區投影是高度已分割的資料表，其結構是提前已知的選項。在分割區投影中，分割區的值和位置是以您所設定的資料表屬性計算，而不是從中繼資料儲存庫所讀取到的來計算。因為記憶體中的計算是比遠端查詢更快，分割區投影的使用可以大幅減少查詢執行時間。 如需詳細資訊，請參閱[透過 Amazon Athena 使用分割區投影](partition-projection.md)。 ## 其他資源 + 如需有關 Firehose 資料分割選項的資訊，請參閱 [Amazon Data Firehose 範例](partition-projection-kinesis-firehose-example.md)。 + 您可以使用 [JDBC 驅動程式](connect-with-jdbc.md)來自動新增分割區。 + 您可以使用 CTAS 和 INSERT INTO 來分割資料集。如需詳細資訊，請參閱[使用 CTAS 和 INSERT INTO 以進行 ETL 和資料分析](ctas-insert-into-etl.md)。 # 透過 Amazon Athena 使用分割區投影 您可以使用 Athena 中的分割區投影來加速高度分割資料表的查詢處理，以及自動化分割區管理。 在分割區投影中，Athena 會使用您直接在 AWS Glue中的資料表設定的資料表屬性來計算分割區的值和位置。資料表屬性可讓 Athena「投影」或判斷必要的分割區資訊，而不必在 AWS Glue Data Catalog中執行耗時的中繼資料查詢。因為記憶體內操作通常比遠端操作更快，所以分割區投影可以減少對高度分割資料表的查詢執行期。取決於查詢和基礎資料的特定特性，分割區投影可能大幅減少受限於分割區中繼資料擷取的查詢執行期。 ## 了解分割區剔除與分割區投影 分割區清除會收集中繼資料，並將它「修剪」至只限適用於查詢的分割區。這通常可加快查詢速度。Athena 會對所有具有分割區資料欄的資料表使用分割區剔除，包括為分割區投影設定的資料表。 一般而言，在處理查詢時，Athena 會`GetPartitions`先呼叫 ， AWS Glue Data Catalog 再執行分割區剔除。如果資料表有大量分割區，使用 `GetPartitions` 可能會對效能造成負面影響。若要避免這種情況，您可以使用分割區投影。分割區投影讓 Athena 可以避免呼叫 `GetPartitions`，因為分割區投影組態可提供 Athena 建置分割區本身的全部所需資訊。 ## 如何使用分割區投影 若要使用分割區投影，請在 AWS Glue Data Catalog 或[外部 Hive 中繼存放](connect-to-data-source-hive.md)區中的資料表屬性中指定每個分割區欄的分割區值和投影類型範圍。資料表上的這些自訂屬性可讓 Athena 知道在資料表上執行查詢時預期的分割區模式。在查詢執行期間，Athena 會使用此資訊投影分割區值，而不是從 AWS Glue Data Catalog 或外部 Hive 中繼存放區擷取它們。這不僅可以減少查詢執行期，還可以自動化分割區管理，因為它不需要在 Athena、 AWS Glue或外部 Hive 中繼存放區中手動建立分割區。 **重要** 在資料表上啟用分割區投影會導致 Athena 忽略註冊到 AWS Glue Data Catalog 或 Hive 中繼存放區中資料表的任何分割區中繼資料。 ## 一些使用案例 適合使用分割區投影的案例包括下列： + 針對高度分割資料表的查詢無法如您所願的那麼快完成。 + 隨著在資料中建立新的日期或時間分割區，您定期將分割區新增至資料表。使用分割區投影，您可以設定相對日期範圍，以便在新資料到達時使用。 + 您在 Amazon S3 中有高度分割的資料。資料在 AWS Glue Data Catalog 或 Hive 中繼存放區中建立模型並不切實際，您的查詢只會讀取其中的一小部分。 ### 可投影的分割區結構 當您的分割區遵循可預測的模式 (例如，但不限於下列項目) 時，分割區投影最容易設定： + **整數** – 任何連續的整數序列，例如 `[1, 2, 3, 4, ..., 1000]` 或 `[0500, 0550, 0600, ..., 2500]`。 + **日期** – 任何連續的日期或日期時間序列，例如 `[20200101, 20200102, ..., 20201231]` 或 `[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]`。 + **列舉值** – 一組有限的列舉值，例如機場代碼或 AWS 區域。 + **AWS 服務 日誌** – AWS 服務 日誌通常具有已知的結構，您可以在其中指定分割區配置 AWS Glue ，因此 Athena 可以用於分割區投影。 ### 如何自訂分割區路徑範本 依預設，Athena 會使用格式 `s3://amzn-s3-demo-bucket//partition-col-1=/partition-col-2=/` 建置分割區位置，但如果您的資料以不同的方式組織，Athena 也提供自訂此路徑範本的機制。如需這些步驟，請參閱 [如何指定自訂 S3 儲存位置](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations)。 ## 考量和限制 適用下列注意事項： + 分割區投影無須在 AWS Glue 或外部 Hive 中繼存放區手動指定分割區。 + 當您在資料表上啟用分割區投影時，Athena 會忽略該資料表的 AWS Glue Data Catalog 或外部 Hive 中繼存放區中的任何分割區中繼資料。 + 如果投影的分割區不存在於 Amazon S3 中，Athena 仍會投影該分割區。Athena 不會擲回錯誤，但也不會傳回任何資料。不過，如果太多分割區是空的，效能可能會比傳統 AWS Glue 分割區慢。如果超過一半的投影分割區是空的，建議您使用傳統分割區。 + 如果數值超過分割區投影定義的範圍邊界，查詢不會傳回錯誤。查詢反而會執行，但不會傳回任何資料行。例如，如果您擁有自 2020 年起並定義為 `'projection.timestamp.range'='2020/01/01,NOW'` 的時間相關資料，如 `SELECT * FROM table-name WHERE timestamp = '2019/02/02'` 等的查詢將成功完成，但不會傳回任何資料行。 + 分割區投影只適用於透過 Athena 查詢資料表時。如果透過其他服務 (例如 Amazon Redshift Spectrum、Athena for Spark 或 Amazon EMR) 讀取相同的資料表，則會使用標準的分割區中繼資料。 + 由於分割區投影是僅限 DML 的功能， `SHOW PARTITIONS` 不會列出 Athena 投影但未在 AWS Glue 目錄或外部 Hive 中繼存放區中註冊的分割區。 + Athena 未將檢視的資料表屬性作為分割區投影的組態。若要解決此限制，請在檢視參照之資料表的資料表屬性中設定並啟用分割區投影。 ## 影片 以下影片展示如何使用分割區投影，改善在 Athena 中的查詢效能。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk) **Topics** + [了解分割區剔除與分割區投影](#partition-projection-pruning-vs-projection) + [如何使用分割區投影](#partition-projection-using) + [一些使用案例](#partition-projection-use-cases) + [考量和限制](#partition-projection-considerations-and-limitations) + [影片](#partition-projection-video) + [設定分割區投影](partition-projection-setting-up.md) + [支援的分割區投影類型](partition-projection-supported-types.md) + [使用動態 ID 分割](partition-projection-dynamic-id-partitioning.md) + [Amazon Data Firehose 範例](partition-projection-kinesis-firehose-example.md) # 設定分割區投影 在資料表屬性中設定分割區投影共有兩個步驟： 1. 為每個分割區資料欄指定資料範圍和相關模式，或使用自訂範本。 1. 啟用資料表的分割區投影。 **注意** 在您將分割區投影屬性新增至現有的資料表之前，您要設定分割區投影屬性的分割區資料欄必須已經存在於資料表結構描述中。如果分割區資料欄尚不存在，您必須手動將分割區資料欄新增至現有資料表。 AWS Glue 不會自動為您執行此步驟。 本節說明如何設定 的資料表屬性 AWS Glue。若要設定它們，您可以使用 AWS Glue 主控台、Athena [CREATE TABLE](create-table.md)查詢或 [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html)操作。下列程序說明如何在 AWS Glue 主控台中設定屬性。 **使用 AWS Glue 主控台設定和啟用分割區投影** 1. 登入 AWS 管理主控台 ，並在 https：//[https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) 開啟 AWS Glue 主控台。 1. 選擇 **Tables** (資料表) 索引標籤。 在 **Tables** (資料表) 索引標籤上，您可以編輯現有資料表，或選擇 **Add tables** (新增資料表) 以建立新的資料表。如需有關手動或使用爬蟲程式新增資料表的資訊，請參閱《AWS Glue 開發人員指南》**中的 [在 AWS Glue 主控台上使用資料表。](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html) 1. 在資料表清單中，選擇您要編輯之資料表的連結。 ![\[在 AWS Glue 主控台中，選擇要編輯的資料表。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/partition-projection-1.png) 1. 選擇 **Actions** (動作)、**Edit table** (編輯資料表)。 1. 在 **Edit table** (編輯資料表) 頁面的 **Table properties** (資料表屬性) 區段中，針對每個分割的資料欄新增下列索引鍵/值組： 1. 對於 **Key** (索引鍵)，新增 `projection.columnName.type`。 1. 對於 **Value** (值)，新增其中一個支援的類型：`enum`、`integer`、`date` 或 `injected`。如需詳細資訊，請參閱[支援的分割區投影類型](partition-projection-supported-types.md)。 1. 遵循[支援的分割區投影類型](partition-projection-supported-types.md)中的指導，根據您的組態需求新增額外的索引鍵/值組。 下列範例資料表組態會設定分割區投影的 `year` 資料欄，限制可傳回值的範圍為 2010 年到 2016 年。 ![\[在 AWS Glue 主控台資料表屬性中為分割區資料欄設定分割區投影。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/partition-projection-3.png) 1. 新增索引鍵/值組以啟用分割區投影。對於 **Key** (索引鍵)，輸入 `projection.enabled`，對於其 **Value** (值)，輸入 `true`。 **注意** 您可以透過將 `projection.enabled` 設定為 `false`，隨時停用此資料表上的分割區投影。 1. 完成時，請選擇 **Save (儲存)**。 1. 在 Athena 查詢編輯器中，測試查詢您為資料表設定的資料欄。 下列範例查詢使用 `SELECT DISTINCT` 從 `year` 資料欄傳回唯一值。資料庫包含 1987 年到 2016 年的資料，但 `projection.year.range` 屬性將傳回的值限制為 2010 年到 2016 年。 ![\[查詢使用分割區投影的資料欄。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/partition-projection-5.png) **注意** 如果您將 `projection.enabled` 設定為 `true` 但無法設定一或多個分割區資料欄，您會收到如下所示的錯誤訊息： `HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`. ## 如何指定自訂 S3 儲存位置 在 中編輯資料表屬性時 AWS Glue，您也可以為投影的分割區指定自訂 Amazon S3 路徑範本。自訂範本可讓 Athena 將分割區值正確地對應到不遵循典型 `.../column=value/...` 模式的自訂 Amazon S3 檔案位置。 使用自訂範本是選擇性的。不過，如果您使用自訂範本，則範本必須包含每個分割區資料欄的預留位置。範本位置必須以正斜線結尾，以便分割的資料檔案存在於每個分割區的「資料夾」中。 **指定自訂分割區位置範本** 1. 依照[使用 AWS Glue 主控台設定和啟用分割區投影](#partition-projection-setting-up-procedure)的步驟，新增額外的鍵/值對，指定自訂範本，如下所示： 1. 在 **Key** (索引鍵) 欄位，輸入 `storage.location.template`。 1. 對於 **Value** (值)，指定包含每個分割區資料欄之預留位置的位置。請確定每個預留位置 (及 S3 路徑本身) 是以單一正斜線結尾。 下列範例範本值假設資料表具有分割區資料欄 `a`、`b` 和 `c`。 ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/ ``` ``` s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/ ``` 對於相同的資料表，下列範例範本值無效，因為它不包含資料欄 `c` 的預留位置。 ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/ ``` 1. 選擇 **Apply** (套用)。 # 支援的分割區投影類型 資料表可以具有 `enum`、`integer`、`date,` 或 `injected` 分割區資料欄類型的任意組合。 ## 列舉類型 將 `enum`類型用於值為列舉集合成員的分割區資料欄 （例如，機場代碼 或 AWS 區域)。 在資料表中定義分割區屬性，如下所示： **** | 屬性名稱 | 範例值 | Description | | --- | --- | --- | | projection.columnName.type | `enum` | 必要。用於資料欄 columnName 的投影類型。該值必須是 enum (不區分大小寫) 以表示使用列舉類型。允許開頭和結尾空格。 | | projection.columnName.values | `A,B,C,D,E,F,G,Unknown` | 必要. 用於資料欄 columnName 之以逗號分隔的列舉分割區值清單。任何空格都會被視為列舉值的一部分。 | **注意** 建議的最佳實務是將 `enum` 型分割區投影的使用限制成幾十個或以下。雖然`enum`投影沒有特定限制，但 gzip 壓縮時，資料表中繼資料的總大小不得超過約 1 MB AWS Glue 的限制。請注意，您資料表的主要部分會共用此限制，例如資料欄名稱、位置、儲存格式等。如果您發現自己在 `enum` 投影中使用幾十個以上的唯一 ID，請考慮使用替代方法，例如歸納為代理欄位中較少數的唯一數值。您可以透過取捨基數的方式，控制 `enum` 欄位中唯一數值的數量。 ## 整數類型 對於其可能值會被解譯為定義範圍內整數的分割區資料欄，請使用整數類型。投影整數資料欄目前限制為帶正負號的 Java 長整數範圍 (-263 至 263-1，含)。 **** | 屬性名稱 | 範例值 | Description | | --- | --- | --- | | projection.columnName.type | `integer` | 必要。用於資料欄 columnName 的投影類型。該值必須是 integer (不區分大小寫) 以表示使用整數類型。允許開頭和結尾空格。 | | projection.columnName.range | `0,10` `-1,8675309` `0001,9999` | 必要. 以逗號分隔的雙元素清單，提供資料欄 columnName 上的查詢要傳回的最小和最大範圍值。請注意，值必須以逗號分隔，而非連字號。這些值包含在內，可以是負的，也可以以零開頭。允許開頭和結尾空格。 | | projection.columnName.interval | `1` `5` | 選用。正整數，指定用於資料欄 columnName 之連續分割區值之間的間隔。例如，range 值 "1,3" 具有 "1" 的 interval 值，會產生 1、2 和 3 的值。range 值相同但 interval 值為 "2" 會產生 1 和 3 的值，略過 2。允許開頭和結尾空格。預設為 1。 | | projection.columnName.digits | `1` `5` | 選用。正整數，指定用於資料欄 columnName 之分割區值最終表示法中要包含的位數。例如，range 值 "1,3" 具有 "1" 的 digits 值，會產生 1、2 和 3 的值。range 值相同但 digits 值為 "2" 會產生 01、02 和 03 的值。允許開頭和結尾空格。預設值是非靜態位數，且不以零開頭。 | ## 日期類型 對於其值會被解譯為定義範圍內之日期 (以及選用的時間) 的分割區資料欄，請使用整數類型。 **重要** 投影的日期資料欄會在查詢執行期以國際標準時間 (UTC) 產生。 **** | 屬性名稱 | 範例值 | Description | | --- | --- | --- | | projection.columnName.type | `date` | 必要。用於資料欄 columnName 的投影類型。該值必須是 date (不區分大小寫) 以表示使用日期類型。允許開頭和結尾空格。 | | projection.columnName.range | `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH` | 必要. 以逗號分隔的雙元素清單，提供資料欄 *columnName* 的最小和最大 `range` 值。這些數值包含在內，可以使用與 Java `java.time.*` 日期類型相容的任何格式。最小值和最大值都必須使用相同的格式。`.format` 屬性中指定的格式必須是用於這些值的格式。 此資料欄也可以包含相對日期字串，格式化為此規則運算式模式： `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` 允許使用空格，但在日期常值中會被視為日期字串本身的一部分。 | | projection.columnName.format | `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss` | 必要. 根據 Java 日期格式 [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) 的日期格式字串。可以是任何支援的 Java.time.\$1 類型。 | | projection.columnName.interval | `1` `5` | 正整數，指定用於資料欄 *columnName* 之連續分割區值之間的間隔。例如，`range` 值為 `2017-01,2018-12` 搭配 `interval` 值為 `1` 以及 `interval.unit` 值為 `MONTHS`，會產生值 2017-01、2017-02、2017-03 等。相同的 `range` 值搭配 `interval` 值為 `2` 且 `interval.unit` 值為 `MONTHS`，會產生值 2017-01、2017-03、2017-05 等。允許開頭和結尾空格。 如果提供的日期採用單日或單月精確度，則 `interval` 是選用的，並且分別預設為 1 天或 1 個月。否則，`interval` 是必要的。 | | projection.columnName.interval.unit | `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS` | 時間單位，代表 [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html) 的序列化格式。可能值為 `YEARS`、`MONTHS`、`WEEKS`、`DAYS`、`HOURS`、`MINUTES`、`SECONDS` 或 `MILLIS`。這些值不區分大小寫。 如果提供的日期採用單日或單月精確度，則 `interval.unit` 是選用的，並且分別預設為 1 天或 1 個月。否則，`interval.unit` 是必要的。 | **Example – 按月份分割** 下列範例資料表組態會按月份分割 2015 年至今的資料。 ``` 'projection.month.type'='date', 'projection.month.format'='yyyy-MM', 'projection.month.interval'='1', 'projection.month.interval.unit'='MONTHS', 'projection.month.range'='2015-01,NOW', ... ``` ## 注入類型 注入類型適用於其可能值不能在某個邏輯範圍內依程序產生，但可在查詢的 `WHERE` 子句中作為單一值提供的分割區資料欄。 請務必牢記以下幾點： + 如果未為每個注入的資料欄提供篩選條件表達式，則注入資料欄上的查詢會失敗。 + 只有當值為分離值時，才能成功在注入資料欄上針對篩選條件表達式查詢多個值。 + 僅支援 `string` 類型的資料欄。 + 當您使用具有注入的分割區資料欄的 `WHERE IN` 子句時，您可在 `IN` 清單中指定的值的限制為 1,000 個。若要查詢的資料集包含的注入資料欄具有超過 1,000 個分割區，則請將查詢分割為多個較小的查詢，每個查詢的 `WHERE IN` 子句中最多可以包含 1,000 個值，然後彙總結果。 **** | 屬性名稱 | Value | Description | | --- | --- | --- | | projection.columnName.type | `injected` | 必要. 用於資料欄 columnName 的投影類型。僅支援 string 類型。指定的值必須是 injected (不區分大小寫)。允許開頭和結尾空格。 | 如需詳細資訊，請參閱[何時使用 `injected` 投影類型](partition-projection-dynamic-id-partitioning.md#partition-projection-injection)。 # 使用動態 ID 分割 當您的資料以高基數屬性分割，或者無法事先知道這些值時，您可使用 `injected` 投影類型。此類屬性的範例包括使用者名稱，以及裝置或產品的 ID。當您使用 `injected` 投影類型來設定分割區索引鍵時，Athena 會使用查詢本身的值來計算將要讀取的分割區集。 對於具有使用 `injected` 投影類型設定的分割區索引鍵的資料表，若要讓 Athena 能夠在此類資料表上執行查詢，必須符合下列條件： + 您的查詢必須包含至少一個分割區索引鍵值。 + 值必須是文字或運算式，可在不讀取任何資料的情況下進行評估。 如果不滿足上述任何條件，您的查詢會失敗，並出現下列錯誤： CONSTRAINT\$1VIOLATION：對於注入的投影分割區資料欄 *column\$1name*，WHERE 子句必須僅包含靜態等式條件，且必須至少存在一個此類條件。 ## 何時使用 `injected` 投影類型 假設您有一個資料集，其中包含 IoT 裝置的事件，並根據裝置的 ID 進行分割。此資料集具有下列特性： + 裝置 ID 隨機產生。 + 新裝置會經常進行佈建。 + 目前有數十萬部裝置，未來將會有數百萬部裝置。 使用傳統的中繼儲存難以管理此資料集。在資料儲存與中繼儲存之間難以保持分割區同步，並且在查詢規劃期間篩選分割區可能較慢。但是，如果您將資料表設定為使用分割區投影，並使用 `injected` 投影類型，則有兩項優勢：您不必管理中繼儲存中的分割區，並且您的查詢也不必查詢分割區中繼資料。 下列 `CREATE TABLE` 範例會針對剛才描述的裝置事件資料集來建立資料表。該資料表使用注入的投影類型。 ``` CREATE EXTERNAL TABLE device_events ( event_time TIMESTAMP, data STRING, battery_level INT ) PARTITIONED BY ( device_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.device_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}" ) ``` 下列範例查詢會查詢 12 小時內，從三個特定裝置接收的事件數目。 ``` SELECT device_id, COUNT(*) AS events FROM device_events WHERE device_id IN ( '4a770164-0392-4a41-8565-40ed8cec737e', 'f71d12cf-f01f-4877-875d-128c23cbde17', '763421d8-b005-47c3-ba32-cc747ab32f9a' ) AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00' GROUP BY device_id ``` 當您執行此查詢時，Athena 會看到 `device_id` 分割區索引鍵的三個值，並使用這些值來計算分割區位置。Athena 會使用 `storage.location.template` 屬性的值來產生下列位置： + `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e` + `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17` + `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a` 如果您從分割區投影組態中省略 `storage.location.template` 屬性，Athena 會根據 `LOCATION` 中的值 (例如 `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e`)，使用 HIVE 樣式的分割區來投影分割區位置。 # Amazon Data Firehose 範例 當您使用 Firehose 將資料交付到 Amazon S3 時，預設組態會使用下列範例所示的索引鍵來寫入物件： ``` s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension ``` 若要建立 Athena 資料表，在查詢時間自動尋找分割區，而不必在新資料送達 AWS Glue Data Catalog 時將其新增至 ，您可以使用分割區投影。 下列 `CREATE TABLE` 範例使用的是預設的 Firehose 組態。 ``` CREATE EXTERNAL TABLE my_ingested_data ( ... ) ... PARTITIONED BY ( datehour STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.datehour.type" = "date", "projection.datehour.format" = "yyyy/MM/dd/HH", "projection.datehour.range" = "2021/01/01/00,NOW", "projection.datehour.interval" = "1", "projection.datehour.interval.unit" = "HOURS", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/" ) ``` `CREATE TABLE` 陳述式中的 `TBLPROPERTIES` 子句告訴 Athena 以下內容： + 查詢資料表時使用分割區投影 + 分割區索引鍵 `datehour` 的類型為 `date` (其中包括可選時間) + 將日期格式化的方式 + 日期時間的範圍。請注意，值必須以逗號分隔，而非連字號。 + 可尋找 Amazon S3 上資料的位置。 當您查詢資料表時，Athena 會計算 `datehour` 的值，並使用儲存位置範本來產生分割區位置的清單。 **Topics** + [如何使用 `date` 類型](partition-projection-kinesis-firehose-example-using-the-date-type.md) + [如何選擇分割區索引鍵](partition-projection-kinesis-firehose-example-choosing-partition-keys.md) + [如何使用自訂字首和動態分割](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md) # 如何使用 `date` 類型 當您將 `date` 類型用於投影分割區索引鍵時，您必須指定範圍。因為您在建立 Firehose 交付串流之前沒有日期資料，您可以使用建立日期作為開始日期。並且因為您沒有未來日期的資料，您可以使用特殊字符 `NOW` 作為結束。 在 `CREATE TABLE` 範例中，開始日期指定為世界協調時間 (UTC) 2021 年 1 月 1 日午夜。 **注意** 設定與您的資料盡可能相符的範圍，以便 Athena 僅查詢現有分割區。 在範例資料表上執行查詢時，Athena 將 `datehour` 分割區索引鍵上的條件與範圍結合使用來產生值。請考處下列查詢： ``` SELECT * FROM my_ingested_data WHERE datehour >= '2020/12/15/00' AND datehour < '2021/02/03/15' ``` `SELECT` 查詢中的第一個條件會使用日期，該日期會在 `CREATE TABLE` 陳述句指定的日期範圍開始之前。由於分割區投影組態沒有為 2021 年 1 月 1 日之前的日期指定分割區，因此 Athena 僅在以下位置查詢資料，並忽略查詢中較早的日期。 ``` s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/ ... s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/ ``` 同樣地，如果在 2021 年 2 月 3 日 15:00 之前的日期和時間執行查詢，則最後一個分割區會反映目前的日期和時間，而不是在查詢條件中的日期和時間。 如果要查詢最新資料，您可以利用 Athena 不產生未來日期並僅指定開頭 `datehour` 的事實，如下列範例所示。 ``` SELECT * FROM my_ingested_data WHERE datehour >= '2021/11/09/00' ``` # 如何選擇分割區索引鍵 您可以指定分割區投影將分割區位置映射至分割區索引鍵的方式。在前一部份的 `CREATE TABLE` 範例中，日期和小時被合併成一個名為 datehour 的分割區索引鍵，但也可以使用其他結構描述。例如，您也可以針對年份、月份、日期及小時，設定個別分割區索引鍵的資料表。 但是，將日期分割為年、月和日，表示無法使用 `date` 分割區投影類型。另一種方法是將日期與小時分開，即可仍然利用 `date` 分割區投影類型，但讓指定小時範圍的查詢更易於閱讀。 請記住，以下 `CREATE TABLE` 範例將日期與小時分開。由於 `date` 是 SQL 中的保留字詞，因此此範例會用 `day` 表示日期之分割區索引鍵的名稱。 ``` CREATE EXTERNAL TABLE my_ingested_data2 ( ... ) ... PARTITIONED BY ( day STRING, hour INT ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy/MM/dd", "projection.day.range" = "2021/01/01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.hour.type" = "integer", "projection.hour.range" = "0,23", "projection.hour.digits" = "2", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/" ) ``` 在範例 `CREATE TABLE` 陳述式中，小時是個別的分割區索引鍵並設定為整數。小時分割區索引鍵的組態會指定範圍 0 到 23，而當 Athena 產生分割區位置時，小時應該格式化為兩位數。 對 `my_ingested_data2` 資料表的查詢可能如下所示： ``` SELECT * FROM my_ingested_data2 WHERE day = '2021/11/09' AND hour > 3 ``` ## 了解分割區索引鍵和分割區投影資料類型 請注意，第一個 `CREATE TABLE` 範例中的 `datehour` 索引鍵在分割區投影組態中設定為 `date`，但是分割區索引鍵的類型為 `string`。第二個範例中的 `day` 也是如此。分割區投影組態中的類型只會告訴 Athena 在產生分割區位置時如何將值格式化。您指定的類型不會變更分割區索引鍵的類型；在查詢中，`datehour` 和 `day` 為 `string` 類型。 當查詢包含類似 `day = '2021/11/09'` 的條件時，Athena 會使用分割區投影組態中指定的日期格式剖析表達式右側的字串。在 Athena 確認日期是否位於所設定範圍後，它會再次使用日期格式將日期作為字串插入儲存位置範本。 同樣，對於像 `day > '2021/11/09'` 的查詢條件，Athena 會剖析右側並產生設定範圍內所有相符日期的清單。然後，它會使用日期格式將每個日期插入儲存位置範本，以建立分割區位置的清單。 寫入與 `day > '2021-11-09'` 或 `day > DATE '2021-11-09'` 相同的條件不起作用。在第一種情況下，日期格式不相符 (請注意連字號而不是正斜線)，而在第二種情況下，資料類型不相符。 # 如何使用自訂字首和動態分割 可以使用[自訂字首](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)和[動態分割](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html)設定 Firehose。使用這些功能，您可以設定 Amazon S3 索引鍵，並設定能對您使用案例提供更佳支援的分割區結構描述。您還可以將分割區投影與這些分割結構描述搭配使用並相應地設定它們。 例如，您可以使用自訂字首功能來取得具有 ISO 格式化日期的 Amazon S3 索引鍵，而不是預設 `yyyy/MM/dd/HH` 結構描述。 您還可以將自訂字首與動態分割結合，從 Firehose 訊息中擷取類似於 `customer_id` 的內容，如下列範例所示。 ``` prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/ ``` 使用 Amazon S3 字首，Firehose 交付串流會將物件寫入索引鍵，例如 `s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension`。對於像 `customer_id` 的屬性，其中值並未事先知道，您可以使用分割區投影類型 `injected` 並使用 `CREATE TABLE` 陳述式，如下所示： ``` CREATE EXTERNAL TABLE my_ingested_data3 ( ... ) ... PARTITIONED BY ( day STRING, customer_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy-MM-dd", "projection.day.range" = "2021-01-01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.customer_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/" ) ``` 當您查詢具有類型 `injected` 的分割區索引鍵的資料表時，您的查詢必須包含該分割區索引鍵的值。對 `my_ingested_data3` 資料表的查詢可能如下所示： ``` SELECT * FROM my_ingested_data3 WHERE day BETWEEN '2021-11-01' AND '2021-11-30' AND customer_id = 'customer-1234' ``` ## 使用 DATE 類型作為日期分割區索引鍵 因為 `day` 分割區索引鍵的值是 ISO 格式化，所以您也可以使用 `DATE` 類型而不是 `STRING` 來做為日期分割區索引鍵，如下列範例所示： ``` PARTITIONED BY (day DATE, customer_id STRING) ``` 當您查詢時，此策略可讓您在分割區索引鍵上使用日期函數，而不需要剖析或轉換，如下列範例所示： ``` SELECT * FROM my_ingested_data3 WHERE day > CURRENT_DATE - INTERVAL '7' DAY AND customer_id = 'customer-1234' ``` **注意** 指定 `DATE` 類型的分割區索引鍵，假設您已使用[自訂字首](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)功能建立具有 ISO 格式化日期的 Amazon S3 索引鍵。如果您使用預設的 Firehose 格式 `yyyy/MM/dd/HH`，即使對應的資料表屬性為類型 `date`，您仍必須將分割區索引鍵指定為類型 `string`，如下列範例所示： ``` PARTITIONED BY ( `mydate` string) TBLPROPERTIES ( 'projection.enabled'='true', ... 'projection.mydate.type'='date', 'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}') ``` # 防止 Amazon S3 限流 限流是限制您使用服務、應用程式或系統的速率的程序。在 中 AWS，您可以使用限流來防止過度使用 Amazon S3 服務，並提高所有使用者的 Amazon S3 可用性和回應能力。但是，由於限流限制了資料傳輸到 Amazon S3 或從 Amazon S3 傳輸的速率，因此請務必考慮防止您的互動受到限流。 正如[效能調校](performance-tuning.md)章節所述，最佳化取決於您的服務層級決策、您建構資料表和資料的方式，以及您寫入查詢的方式。 **Topics** + [減少服務層級的限流](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md) + [最佳化您的資料表](performance-tuning-s3-throttling-optimizing-your-tables.md) + [最佳化您的查詢](performance-tuning-s3-throttling-optimizing-queries.md) # 減少服務層級的限流 若要避免 Amazon S3 在服務層級的限流，您可以監控您的用量並調整[服務配額](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3)，或者使用分割等特定技術。以下某些條件可能導致限流： + **超出帳戶的 API 請求限制** – Amazon S3 具有基於帳戶類型和用量的預設 API 請求限制。如果您超過單一字首每秒的請求數目上限，則您的請求可能會受到限流，以防止 Amazon S3 服務多載。 + **資料分割不足** – 如果您沒有正確地分割資料並傳輸大量資料，Amazon S3 可能會對您的請求限流。如需有關分割的詳細資訊，請參閱本文件中的 [使用分割區](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) 部分。 + **大量小型物件** – 如果可能，請避免擁有大量小型檔案。Amazon S3 每個分割的字首具有每秒 [5500 個 GET 請求](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)的限制，而您的 Athena 查詢也共用此相同限制。如果您在單一查詢中掃描數百萬個小型物件，您的查詢將很容易受到 Amazon S3 限流。 若要避免過度掃描，您可以使用 AWS Glue ETL 定期壓縮檔案，或分割資料表並新增分割區索引鍵篩選條件。如需詳細資訊，請參閱下列資源。 + [如何設定 AWS Glue ETL 任務以輸出較大的檔案？](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*AWS 知識中心*) + [讀取較大群組中的輸入檔案](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) *AWS Glue （開發人員指南*) # 最佳化您的資料表 如果遇到限流問題，建構資料很重要。雖然 Amazon S3 可以處理大量資料，但有時會因為資料的建構方式而發生限流。 下列各節就如何在 Amazon S3 中建構資料以避免限流問題提供了一些建議。 ## 使用分割區 您可以限制在任何指定時間內存取的資料量，使用分割來減少限流。藉由分割特定資料欄上的資料，您可以將請求平均分散至多個物件，並減少單一物件的請求數目。減少必須掃描的資料量會改善查詢效能並降低成本。 您可以在建立資料表時，定義可做為虛擬資料欄的分割區。若要在 `CREATE TABLE` 陳述式中建立含有分割區的資料表，您可以使用 `PARTITIONED BY (column_name data_type)` 子句來定義分割資料的索引鍵。 若要限制查詢掃描的分割區，您可以在查詢的 `WHERE` 子句中將其指定為述詞。因此，經常用作篩選器的資料欄是分割的理想候選者。常見做法是根據時間間隔來分割資料，這通常會產生多層級的分割機制。 請注意，分割也有成本。當您增加資料表中的分割區數目時，擷取和處理分割區中繼資料所需的時間也會增加。因此，過度分割會消除您透過更明智分區而獲得的益處。如果您的資料明顯集中於一個分割區值，並且大多數查詢使用該值，則可能會產生額外開銷。 如需有關在 Athena 中分割的詳細資訊，請參閱 [什麼是分割？](ctas-partitioning-and-bucketing-what-is-partitioning.md) ## 歸納您的資料 分割資料的另一個方法是將資料歸納在單一分割區內。使用歸納功能時，您可以指定一或多個資料欄，其中包含要組合在一起的資料列。然後，將這些資料列放入多個儲存貯體中。如此一來，您只會查詢必須讀取的儲存貯體，從而減少必須掃描的資料列數目。 當您選取要用於歸納的資料欄時，請選取具有高基數 (亦即，具有許多不同值)、均勻分散且經常用來篩選資料的資料欄。主索引鍵 (例如 ID 資料欄) 是用來歸納的良好資料欄範例。 如需有關在 Athena 中歸納的詳細資訊，請參閱 [什麼是歸納？](ctas-partitioning-and-bucketing-what-is-bucketing.md)。 ## 使用 AWS Glue 分割區索引 您可以使用 AWS Glue 分割區索引，根據一或多個分割區的值整理資料表中的資料。 AWS Glue 分割區索引可減少資料傳輸的數量、資料處理量，以及查詢的處理時間。 AWS Glue 分割區索引是中繼資料檔案，其中包含資料表中分割區的相關資訊，包括分割區索引鍵及其值。分割區索引存放在 Amazon S3 儲存貯體中，當新的分割區新增至資料表 AWS Glue 時， 會自動更新分割區索引。 當 AWS Glue 分割區索引存在時，查詢會嘗試擷取分割區的子集，而不是載入資料表中的所有分割區。查詢只會在與查詢相關的資料子集上執行。 在 中建立資料表時 AWS Glue，您可以在資料表上定義的任意分割區索引鍵組合上建立分割區索引。在資料表上建立一或多個分割區索引之後，您必須將屬性新增至啟用分割區篩選的資料表。然後，您可以從 Athena 查詢資料表。 如需有關在 中建立分割區索引的資訊 AWS Glue，請參閱《 *AWS Glue 開發人員指南*》中的[在 中使用分割區索引 AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)。如需有關新增資料表屬性以啟用分割區篩選的資訊，請參閱 [使用 AWS Glue 分割區索引和篩選來最佳化查詢](glue-best-practices-partition-index.md)。 ## 使用資料壓縮和檔案分割 如果檔案處於最佳大小，或可以將檔案分割成邏輯群組，則資料壓縮可以大幅加快查詢速度。一般而言，較高的壓縮比需要更多的 CPU 週期來壓縮和解壓縮資料。對於 Athena，建議您使用 Apache Parquet 或 Apache ORC，因為其預設會壓縮資料。如需有關 Athena 中資料壓縮的資訊，請參閱[在 Athena 中使用壓縮](compression-formats.md)。 分割檔案可讓 Athena 將讀取單一檔案的任務分散至多個讀取器，藉此提高平行處理能力。如果單一檔案不可分割，則只有一個讀取器可以讀取檔案，而其他讀取器則處於閒置狀態。Apache Parquet 和 Apache ORC 還支援可分割的檔案。 ## 使用優化單欄式資料存放區 如果您將資料轉換為單欄式格式，則 Athena 查詢效能會大幅提升。當您產生單欄式檔案時，需要考量的一種優化技術是根據資料分割區索引鍵排序資料。 Apache Parquet 和 Apache ORC 是常用的開放原始碼單欄式資料存放區。如需有關將現有 Amazon S3 資料來源轉換為其中一種格式的資訊，請參閱 [轉換為單欄式格式](columnar-storage.md#convert-to-columnar)。 ### 使用較大的 Parquet 區塊大小或 ORC 條紋大小 Parquet 和 ORC 具有資料儲存參數，您可以調整以進行優化。在 Parquet 中，您可以優化區塊大小。在 ORC 中，您可以優化條紋大小。區塊或條紋越大，您可以在其中儲存的資料列就越多。依預設，Parquet 區塊大小為 128 MB，而 ORC 條紋大小為 64 MB。 如果 ORC 條紋小於 8 MB (預設值為 `hive.orc.max_buffer_size`)，則 Athena 會讀取整個 ORC 條紋。對於較小的條紋，這是 Athena 在資料欄選取性和每秒輸入/輸出操作之間進行的權衡。 如果您的資料表包含大量資料欄，則較小的區塊或條紋大小可能會導致掃描的資料超過必要的數量。在這些情況下，較大的區塊大小可能會更有效率。 ### 對複雜類型使用 ORC 目前，當您查詢存放在 Parquet 中且具有複雜資料類型 (例如，`array`、`map` 或 `struct`) 的資料欄時，Athena 會讀取整個資料列，而不是只選擇性地讀取指定的資料欄。這是 Athena 的已知問題。解決方法是考慮使用 ORC。 ### 選擇壓縮演算法 您可以設定的另一個參數是資料區塊上的壓縮演算法。如需有關 Athena 中 Parquet 和 ORC 支援的壓縮演算法的資訊，請參閱 [Athena 壓縮支援](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)。 如需 Athena 中單欄式儲存格式最佳化的詳細資訊，請參閱 AWS 大數據部落格文章 [Amazon Athena 的前 10 個效能調校秘訣](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)中的「最佳化單欄式資料存放區產生」一節。 ## 使用 Iceberg 資料表 Apache Iceberg 是開放式的資料表格式，專用於非常大型的分析資料集，旨在優化 Amazon S3 上的用量。您可以使用 Iceberg 資料表來協助減少 Amazon S3 中的限流。 Iceberg 資料表可為您提供下列優點： + 您可以在一或多個資料欄上對 Iceberg 資料表進行分割。這樣可優化資料存取，並減少查詢必須掃描的資料量。 + 由於 Iceberg 物件儲存模式可將 Iceberg 資料表優化以與 Amazon S3 搭配使用，因此其可以處理大量資料和繁重的查詢工作負載。 + 物件儲存模式中的 Iceberg 資料表具備可擴展性、容錯能力和耐用性，有助於減少限流。 + ACID 交易支援意味著，多個使用者可以以原子方式新增和刪除 Amazon S3 物件。 如需有關 Apache Iceberg 的詳細資訊，請參閱 [Apache Iceberg](https://iceberg.apache.org/)。如需有關在 Athena 中使用 Apache Iceberg 資料表的詳細資訊，請參閱[使用 Iceberg 資料表](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html)。 # 最佳化您的查詢 使用本節中的建議優化 Athena 中的 SQL 查詢。 ## 使用 LIMIT 與 ORDER BY 子句 `ORDER BY` 子句會以排序順序傳回資料。這需要 Athena 將所有資料列傳送至單一工作節點，然後排序資料列。這種查詢類型可以執行很長一段時間，甚至失敗。 為了提高查詢的效率，請查看頂部或底部的 *N* 個值，然後使用 `LIMIT` 子句。這樣可以將排序和限制推送至個別工作節點，而不是單一工作節點，進而大幅降低排序的成本。 ## 優化 JOIN 子句 當您聯結兩個資料表時，Athena 會將右側的資料表分散至工作節點，然後串流左側的資料表以執行聯結。 因此，請在聯結左側指定較大的資料表，並在聯結的右側指定較小的資料表。如此一來，Athena 會使用較少的記憶體，並以較低的延遲執行查詢。 另外，請注意以下重點： + 當您使用多個 `JOIN` 命令時，請按從最大到最小的順序指定資料表。 + 除非查詢需要交叉聯結，否則請予以避免。 ## 優化 GROUP BY 子句 `GROUP BY` 運算子會根據 `GROUP BY` 資料欄將資料列分散至工作節點。我們會在記憶體中引用這些資料欄，並在擷取資料列時比較這些值。當 `GROUP BY` 資料欄相符時，這些值彙總在一起。考慮到此程序的運作方式，建議按從最高基數到最低基數的順序排序資料欄。 ## 使用數字而不是字串 由於相較於字串，數字需要的記憶體較少，而且處理速度更快，因此請盡可能使用數字而不是字串。 ## 限制資料欄的數目 若要減少儲存資料所需的記憶體總量，請限制 `SELECT` 陳述式中指定的資料欄數。 ## 使用規則表達式而不是 LIKE 包含子句 (例如大型字串上的 `LIKE '%string%'`) 的查詢可能需要非常大量的運算。當您篩選字串資料欄上的多個值時，請改用 [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) 函數和規則表達式。當您比較一長串值時，這特別有用。 ## 使用 LIMIT 子句 當您執行查詢時，請不要選取所有資料欄，而是使用 `LIMIT` 子句，以只傳回您需要的資料欄。這樣做可減少透過查詢執行管道處理的資料集大小。當您查詢具有大量字串型資料欄的資料表時，`LIMIT` 子句會更有幫助。當您對任何查詢執行多個聯結或彙總時，`LIMIT` 子句也很有用。 # 其他資源 如需 Athena 效能調校的其他相關資訊，請參閱下列資源： + AWS 大數據部落格文章：[Amazon Athena 的前 10 大效能調校秘訣](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)。 + AWS 大數據部落格文章：*AWS 大數據部落格*中[的最新 Amazon Athena 引擎，以 3 倍的速度執行查詢，節省高達 70% 的成本](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/)。 + AWS 大數據部落格文章：[在 Amazon Athena 中使用述詞下推來改善聯合查詢](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/)。 + 《Amazon Simple Storage Service 使用者指南》：[最佳實務設計模式：最佳化 Amazon S3 效能](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)。 + AWS 巨量資料部落格中的其他 [Athena 文章](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/)。 + 使用 **Amazon Athena** 標籤在 [AWS re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) 上詢問問題。 + 請參閱[AWS 知識中心的 Athena 主題](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena)。 + Contact AWS 支援 （在 中 AWS 管理主控台，按一下 **Support**、**Support Center**) # 在 Athena 中使用壓縮 Athena 支援各種壓縮格式來讀取和寫入資料，包括從使用多種壓縮格式的資料表讀取。例如，當某些 Parquet 檔案使用 Snappy 壓縮而其他 Parquet 檔案使用 GZIP 壓縮時，Athena 可以成功讀取使用 Parquet 檔案格式的資料表中的資料。相同的原則適用於 ORC、文字檔案和 JSON 儲存格式。 ## 支援的壓縮格式 Athena 支援以下壓縮格式： + **BZIP2** – 使用 Burrows-Wheeler 演算法的格式。 + **DEFLATE** – 基於 [LZSS](https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski) 和 [Huffman 編碼](https://en.wikipedia.org/wiki/Huffman_coding)的壓縮演算法。[Deflate](https://en.wikipedia.org/wiki/Deflate) 僅適用於 Avro 檔案格式。 + **GZIP** – 以 Deflate 為基礎的壓縮演算法。對於 Athena 引擎版本 2 和 3 中的 Hive 資料表，以及 Athena 引擎版本 2 中的 Iceberg 資料表，GZIP 是採用 Parquet 格式和文字檔案存儲格式之檔案的預設寫入壓縮格式。不支援 `tar.gz` 格式的檔案。 + **LZ4** – Lempel-Ziv 77 (LZ7) 系列的這個成員也著重於壓縮和解壓縮速度，而不是資料的最大壓縮。LZ4 具有以下框架格式： + **LZ4 原始/無框架** – LZ4 區塊壓縮格式的無框架標準實作。如需詳細資訊，請參閱 GitHub 上的 [LZ4 區塊格式說明](https://github.com/lz4/lz4/blob/dev/doc/lz4_Block_format.md)。 + **LZ4 框架** – LZ4 的一般框架實作。如需詳細資訊，請參閱 GitHub 上的 [LZ4 框架格式說明](https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md)。 + **LZ4 Hadoop 相容** – LZ4 的 Apache Haddop 實作。這個實作使用 [BlockCompressorStream.java](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java) 類別包裝 LZ4 壓縮。 + **LZO** – 使用 Lempel–Ziv–Oberhumer 演算法的格式，該演算法著重於高壓縮和解壓縮速度，而不是資料的最大壓縮。LZO 有兩種實作： + **標準 LZO** – 如需詳細資訊，請參閱 Oberhumer 網站上的 LZO [摘要](http://www.oberhumer.com/opensource/lzo/#abstract)。 + **LZO Hadoop 相容** – 這個實作使用 [BlockCompressorStream.java](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java) 類別包裝 LZO 演算法。 + **SNAPPY** – 屬於 Lempel-Ziv 77 (LZ7) 系列的壓縮演算法。Snappy 著重於高壓縮和解壓縮速度，而不是資料的最大壓縮。 + **ZLIB** – 根據 Deflate，ZLIB 是 ORC 資料儲存格式中檔案的預設寫入壓縮格式。如需詳細資訊，請參閱 GitHub 上的 [zlib](https://github.com/madler/zlib) 頁面。 + **ZSTD** – [Zstandard 即時資料壓縮演算法](http://facebook.github.io/zstd/)是一種提供高壓縮比的快速壓縮演算法。Zstandard (ZSTD) 程式庫是使用 BSD 授權作為開放原始碼所提供。ZSTD 是 Iceberg 資料表的預設壓縮。寫入 ZSTD 壓縮資料時，Athena 預設使用 ZSTD 壓縮級別 3。如需有關在 Athena 中使用 ZSTD 壓縮級別的詳細資訊，請參閱 [使用 ZSTD 壓縮級別](compression-support-zstd-levels.md)。 **注意** Athena 不支援寫入以 LZ4 或 LZO 格式壓縮的 Parquet 檔案。支援讀取這些壓縮格式。 ## 指定壓縮格式 當您寫入 CREATE TABLE 或 CTAS 陳述式時，您可以指定壓縮屬性，以指定 Athena 寫入這些資料表時要使用的壓縮類型。 + 如需 CTAS 的資訊，請參閱 [CTAS 資料表屬性](create-table-as.md#ctas-table-properties)。如需範例，請參閱 [CTAS 查詢的範例](ctas-examples.md)。 + 如需 CREATE TABLE 的資訊，請參閱 [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md) 以取得壓縮資料表屬性的清單。 ## 指定未壓縮 CREATE TABLE 陳述式支援寫入未壓縮的檔案。若要編寫未壓縮檔案，請使用下列語法： + CREATE TABLE (文字檔案或 JSON) – 在 `TBLPROPERTIES` 中，指定 `write.compression = NONE`。 + CREATE TABLE (Parquet) – 在 `TBLPROPERTIES` 中，指定 `parquet.compression = UNCOMPRESSED`。 + CREATE TABLE (ORC) – 在 `TBLPROPERTIES` 中，指定 `orc.compress = NONE`。 ## 備註和資源 + 目前 Athena 無法識別大寫的副檔名，諸如 `.GZ` 或 `.BZIP2`。避免使用大寫副檔名的資料集，或將資料副檔名重新以小寫字母命名。 + 若為 CSV、TSV 和 JSON 的資料，Athena 會根據副檔名決定壓縮類型。如果不存在任何副檔名，Athena 會將資料視為未壓縮的純文字。如果您的資料已壓縮，請確定檔案名稱包含副檔名，例如 `gz`。 + 不支援 ZIP 檔案格式。 + 如需從 Athena 查詢 Amazon Data Firehose 日誌，支援的格式包括 GZIP 壓縮或具有 SNAPPY 壓縮的 ORC 檔案。 + 如需使用壓縮的詳細資訊，請參閱 Amazon Athena AWS 大數據部落格文章前 10 大效能調校秘訣的第 3 節 (「壓縮和分割檔案」)。 [ Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) **Topics** + [指定壓縮格式](#compression-support-specifying-compression-formats) + [指定未壓縮](#compression-support-specifying-no-compression) + [備註和資源](#compression-support-notes-and-resources) + [Hive 資料表壓縮](compression-support-hive.md) + [Iceberg 資料表壓縮](compression-support-iceberg.md) + [ZSTD 壓縮級別](compression-support-zstd-levels.md) # 使用 Hive 資料表壓縮 Athena 中 Hive 資料表的壓縮選項會隨引擎版本和檔案格式而異。 ## Athena 引擎版本 3 中的 Hive 壓縮支援 下列資料表摘要說明 Athena 引擎版本 3 對 Apache Hive 中的儲存檔案格式的壓縮格式支援。文字檔案格式包括 TSV、CSV、JSON 和文字的自訂 SerDes。儲存格中的「是」或「否」同樣適用於讀取和寫入操作，除非另有註明。基於本資料表的用途，CREATE TABLE、CTAS 和 INSERT INTO 會被視為寫入操作。如需有關在 Athena 中使用 ZSTD 壓縮級別的詳細資訊，請參閱 [使用 ZSTD 壓縮級別](compression-support-zstd-levels.md)。 **** | | Avro | Ion | ORC | Parquet | 文字檔案 | | --- | --- | --- | --- | --- | --- | | BZIP2 | 是 | 是 | 否 | 否 | 是 | | DEFLATE | 是 | 否 | 否 | 否 | 否 | | GZIP | 否 | 是 | 否 | 是 | 是 | | LZ4 | 否 | 是 | 是 | 寫入 - 否 讀取 - 是 | 是 | | LZO | 否 | 寫入 - 否 讀取 - 是 | 否 | 寫入 - 否 讀取 - 是 | 寫入 - 否 讀取 - 是 | | SNAPPY | 是 | 是 | 是 | 是 | 是 | | ZLIB | 否 | 否 | 是 | 否 | 否 | | ZSTD | 是 | 是 | 是 | 是 | 是 | | NONE | 是 | 是 | 是 | 是 | 是 | # 使用 Iceberg 資料表壓縮 Athena 中 Iceberg 資料表的壓縮選項會隨引擎版本和檔案格式而異。 ## Athena 引擎版本 3 中的 Iceberg 壓縮支援 下列資料表摘要說明 Athena 引擎版本 3 對 Apache Iceberg 中的儲存檔案格式的壓縮格式支援。儲存格中的「是」或「否」同樣適用於讀取和寫入操作，除非另有註明。基於本資料表的用途，CREATE TABLE、CTAS 和 INSERT INTO 會被視為寫入操作。Athena 引擎版本 3 中的 Iceberg 的預設儲存格式是 Parquet。Athena 引擎版本 3 中的 Iceberg 的預設壓縮格式是 ZSTD。如需有關在 Athena 中使用 ZSTD 壓縮級別的詳細資訊，請參閱 [使用 ZSTD 壓縮級別](compression-support-zstd-levels.md)。 **** | | Avro | ORC | Parquet (預設) | | --- | --- | --- | --- | | BZIP2 | 否 | 否 | 否 | | GZIP | 是 | 否 | 是 | | LZ4 | 否 | 是 | 否 | | SNAPPY | 是 | 是 | 是 | | ZLIB | 否 | 是 | 否 | | ZSTD | 是 | 是 | 是 (預設) | | NONE | 是 (指定 None 或 Deflate) | 是 | 是 (指定 None 或 Uncompressed) | # 使用 ZSTD 壓縮級別 [Zstandard 即時資料壓縮演算法](http://facebook.github.io/zstd/)是一種提供高壓縮比的快速壓縮演算法。Zstandard (ZSTD) 程式庫是開放原始碼軟體，使用 BSD 授權。Athena 支援讀取和寫入 ZStandard 壓縮的 ORC、Parquet 和文字檔案資料。 您可以使用 ZSTD 壓縮級別根據自己的要求調整壓縮比和速度。ZSTD 庫支援從 1 到 22 的壓縮級別。Athena 預設使用 ZSTD 壓縮級別 3。 壓縮級別在壓縮速度和達到的壓縮量之間提供了細微的權衡。壓縮級別越低，速度越快，但檔案大小更大。例如，如果速度最重要，則可以使用級別 1，如果大小最重要，則可以使用級別 22。級別 3 適用於許多使用案例，且為預設值。請謹慎使用大於 19 的級別，因為這些級別需要更多的記憶體。ZSTD 庫還提供負壓縮級別，其可擴展壓縮速度和比率的範圍。如需詳細資訊，請參閱 [Zstandard 壓縮 RFC](https://datatracker.ietf.org/doc/html/rfc8478)。 豐富的壓縮級別為微調提供了大量機會。但是，請確保在決定壓縮級別時測量資料並考慮權衡。建議使用預設級別 3，或 6 到 9 之間的級別，以便在壓縮速度與壓縮資料大小之間取得合理的權衡。對於大小最重要且壓縮速度不是問題的情況，預留級別 20 或更高。 ## 考量和限制 在 Athena 中使用 ZSTD 壓縮級別時，請考慮下列幾點。 + 只有 Athena 引擎版本 3 中才支援 ZSTD `compression_level` 屬性。 + `ALTER TABLE`、`CREATE TABLE`、`CREATE TABLE AS` (CTAS) 以及 `UNLOAD` 陳述式支援 ZSTD `compression_level` 屬性。 + `compression_level` 屬性是選用屬性。 + 只有 ZSTD 壓縮才支援 `compression_level` 屬性。 + 可能的壓縮級別為 1 到 22。 + 預設壓縮級別為 3。 如需有關 Athena 中 Apache Hive ZSTD 壓縮支援的資訊，請參閱 [使用 Hive 資料表壓縮](compression-support-hive.md)。如需有關 Athena 中 Apache Iceberg ZSTD 壓縮支援的資訊，請參閱 [使用 Iceberg 資料表壓縮](compression-support-iceberg.md)。 ## 指定 ZSTD 壓縮級別 若要指定 `ALTER TABLE`、`CREATE TABLE`、`CREATE TABLE AS` 和 `UNLOAD` 陳述式的 ZSTD 壓縮級別，請使用 `compression_level` 屬性。若要指定 ZSTD 壓縮本身，您必須使用陳述式語法所使用的單獨壓縮屬性。 ### ALTER TABLE SET TBLPROPERTIES 在 [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md) 陳述式 `SET TBLPROPERTIES` 子句中，使用 `'write.compression' = ' ZSTD'` 或 `'parquet.compression' = 'ZSTD'` 指定 ZSTD 壓縮。然後使用 `compression_level` 屬性來指定 1 到 22 之間的值 (例如，'`compression_level' = '5'`)。如果您沒有指定壓縮級別屬性，則壓縮級別會預設為 3。 #### 範例 下列範例會修改資料表 `existing_table`，以使用具有 ZSTD 壓縮和 ZSTD 壓縮級別 4 的 Parquet 檔案格式。請注意，在 `TBLPROPERTIES` 子句中，壓縮級別值必須輸入為字串而不是整數，因此必須用單引號或雙引號括住。 ``` ALTER TABLE existing_table SET TBLPROPERTIES ('parquet.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE 在 [CREATE TABLE](create-table.md) 陳述式 `TBLPROPERTIES` 子句中，指定 '`write.compression' = 'ZSTD'` 或 `'parquet.compression' = 'ZSTD'`，然後使用 `compression_level = compression_level` 並指定介於 1 到 22 之間的字串值。如果未指定 `compression_level` 屬性，則預設壓縮級別為 3。 #### 範例 下列範例使用 ZSTD 壓縮和 ZSTD 壓縮級別 4 建立 Parquet 檔案格式的資料表。 ``` CREATE EXTERNAL TABLE new_table ( `col0` string COMMENT '', `col1` string COMMENT '' ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/' TBLPROPERTIES ('write.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE AS (CTAS) 在 [CREATE TABLE AS](create-table-as.md) 陳述式 `WITH` 子句中，指定 `write_compression = 'ZSTD'` 或 `parquet_compression = 'ZSTD'`，然後使用 `compression_level = compression_level` 並指定介於 1 到 22 之間的整數值。如果未指定 `compression_level` 屬性，則預設壓縮級別為 3。 #### 範例 下列 CTAS 範例使用 ZSTD 壓縮和 ZSTD 壓縮級別 4，將 Parquet 指定為檔案格式。請注意，在 `WITH` 子句中，壓縮級別值必須指定為整數而不是字串。 ``` CREATE TABLE new_table WITH ( format = 'PARQUET', write_compression = 'ZSTD', compression_level = 4) AS SELECT * FROM old_table ``` ### UNLOAD 在 [UNLOAD](unload.md) 陳述式 `WITH` 子句中，指定 `compression = 'ZSTD'`，然後使用 `compression_level = compression_level` 並指定介於 1 到 22 之間的整數值。如果未指定 `compression_level` 屬性，則預設壓縮級別為 3。 #### 範例 下列範例會使用 Parquet 檔案格式、ZSTD 壓縮和 ZSTD 壓縮級別 4，將查詢結果卸載到指定的位置。 ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` # 標記 Athena 資源 每個標記皆包含由您定義的金鑰和值。標記 Athena 資源時，您可以將自訂中繼資料指派給該資源。您可以使用標籤以不同方式分類 AWS 資源，例如依用途、擁有者或環境。在 Athena 中，工作群組、資料目錄和容量保留等資源都是可標記的資源。例如，您可以為帳戶中的工作群組建立一組標籤，以協助您追蹤工作群組擁有者，或依用途來識別工作群組。如果您也在 Billing and Cost Management 主控台中啟用標籤作為成本分配標籤，則與執行查詢相關聯的成本會顯示在「成本和用量報告」中，並含有該成本分配標籤。我們建議您使用 AWS [ 標記最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)來建立一組一致的標籤，以滿足您組織的需求。 您可以使用 Athena 主控台或 API 操作來處理標籤。 **Topics** + [標籤基本概念](#tag-basics) + [標籤限制](#tag-restrictions) + [使用工作群組的標籤](tags-console.md) + [使用 API 和 AWS CLI 標籤操作](tags-operations.md) + [使用標籤型 IAM 存取控制政策](tags-access-control.md) ## 標籤基本概念 標籤是您指派給 Athena 資源的標籤。每個標籤皆包含由您定義的一個金鑰與一個選用值。 標籤可讓您以不同的方式分類 AWS 資源。例如，您可以為您帳戶的工作群組定義一組標籤，以協助您追蹤每個工作群組擁有者或用途。 您可以在建立新的 Athena 工作群組或資料目錄時新增標籤，或從中新增、編輯或移除標籤。您可以在主控台編輯標籤。如果您使用 API 操作來編輯標籤，請移除舊標籤，再加入新標籤。如果您刪除資源，也會刪除任何該資源所使用的標籤。 Athena 不會自動為您的資源指派標籤。您可以編輯標籤索引鍵和值，也可以隨時從資源中移除標籤。您可以將標籤的值設為空白字串，但您無法將標籤的值設為 Null。請勿將重複的標籤鍵新增至相同的資源。如果這樣做，Athena 會發出錯誤訊息。如果您使用 **TagResource** 動作來標記使用現有標籤鍵的資源，則新標籤值會覆寫舊值。 在 IAM 中，您可以控制 Amazon Web Services 帳戶中的哪些使用者具有建立、編輯、移除或列出標籤的許可。如需詳細資訊，請參閱[使用標籤型 IAM 存取控制政策](tags-access-control.md)。 如需 Amazon Athena 標籤動作的完整清單，請參閱 [Amazon Athena API 參考](https://docs.aws.amazon.com/athena/latest/APIReference/)中的 API 動作名稱。 您可以使用標籤來計費。如需詳細資訊，請參閱《AWS 帳單與成本管理 使用者指南》**中的[使用標籤計費](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)。 如需詳細資訊，請參閱[標籤限制](#tag-restrictions)。 ## 標籤限制 標籤有以下限制： + 在 Athena 中，您可以標記工作群組、資料目錄和容量保留。您無法標記查詢。 + 每一資源標籤數最多為 50。若要保持在限制內，請檢閱和刪除未使用的標籤。 + 針對每一個資源，每個標籤鍵必須是唯一的，且每個標籤鍵只能有一個值。請勿將重複的標籤鍵同時新增到相同的工作群組。如果這樣做，Athena 會發出錯誤訊息。如果您在個別的 `TagResource` 動作中使用現有的標籤鍵來標記資源，新標籤值會覆寫舊值。 + 標籤索引鍵長度為 1-128 個 UTF-8 Unicode 字元。 + 標籤值長度為 0-256 個 UTF-8 Unicode 字元。 您需要指定工作群組資源的 ARN，才能執行標記操作，例如新增、編輯、移除或列出標籤。 + Athena 可讓您使用字母、數字、以 UTF-8 表示的空格，以及下列字元：\$1 – = . \$1 : / @。 + 標籤鍵與值皆區分大小寫。 + 標籤索引鍵中的`"aws:"`字首保留供 AWS 使用。您無法編輯或刪除含有此字首的標籤索引鍵。含有此字首的標籤不算在每一資源的標籤限制內。 + 您指派的標籤僅供 Amazon Web Services 帳戶使用。 # 使用工作群組的標籤 您可以使用 Athena 主控台，查看您帳戶中每個工作群組正在使用的標籤。您只能依工作群組來檢視標籤。Athena 主控台也可讓您一次在一個工作群組中套用、編輯或移除標籤。 您可以使用您建立的標籤來搜尋工作群組。 **Topics** + [顯示個別工作群組的標籤](#tags-display) + [在個別工作群組上新增和刪除標籤](#tags-add-delete) ## 顯示個別工作群組的標籤 **在 Athena 主控台中顯示個別工作群組的標籤** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 如果未顯示主控台的導覽窗格，請選擇左側的展開選單。 ![\[選擇展開選單。\]](http://docs.aws.amazon.com/zh_tw/athena/latest/ug/images/nav-pane-expansion.png) 1. 在導覽選單上，選擇 **Workgroups** (工作群組)，然後選擇您要的工作群組。 1. 執行以下任意一項： + 選擇 **Tags** (標籤) 索引標籤。如果標籤清單很長，請使用搜尋方塊。 + 選擇 **Edit** (編輯)，然後向下捲動到 **Tags** (標籤) 區段。 ## 在個別工作群組上新增和刪除標籤 您可以直接從 **Workgroups** (工作群組) 索引標籤來管理個別工作群組的標籤。 **注意** 如果您希望使用者在主控台中建立工作群組時新增標籤，或在使用 **CreateWorkGroup** 動作時傳入標籤，請確定您授予使用者進行 **TagResource** 和 **CreateWorkGroup** 動作的 IAM 許可。 **在建立新的工作群組時新增標籤** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽選單中，選擇 **Workgroups** (工作群組)。 1. 選擇 **Create workgroup** (建立工作群組)，並視需要填寫值。如需詳細步驟，請參閱[建立工作群組](creating-workgroups.md)。 1. 在 **Tags** (標籤) 區段中，指定索引鍵和值來新增一或多個標籤。請勿將重複的標籤索引鍵同時新增到相同的工作群組。如果這樣做，Athena 會發出錯誤訊息。如需詳細資訊，請參閱[標籤限制](tags.md#tag-restrictions)。 1. 完成時，選擇 **Create Workgroup** (建立工作群組)。 **在現有的工作群組中新增或編輯標籤** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 選擇您想要修改的工作群組。 1. 執行以下任意一項： + 選擇 **Tags** (標籤) 索引標籤，然後選擇 **Manage tags** (管理標籤)。 + 選擇 **Edit** (編輯)，然後向下捲動到 **Tags** (標籤) 區段。 1. 指定每個標籤的索引鍵和數值。如需詳細資訊，請參閱[標籤限制](tags.md#tag-restrictions)。 1. 選擇 **Save** (儲存)。 **從個別工作群組中刪除標籤** 1. 前往 [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) 開啟 Athena 主控台。 1. 在導覽窗格中，選擇 **Workgroups** (工作群組)。 1. 選擇您想要修改的工作群組。 1. 執行以下任意一項： + 選擇 **Tags** (標籤) 索引標籤，然後選擇 **Manage tags** (管理標籤)。 + 選擇 **Edit** (編輯)，然後向下捲動到 **Tags** (標籤) 區段。 1. 在標籤清單中，選取您要刪除標籤的 **Remove** (移除)，然後選擇 **Save** (儲存)。 # 使用 API 和 AWS CLI 標籤操作 使用下列標籤操作來新增、移除或列出資源上的標籤。 **** | API | CLI | 動作描述 | | --- | --- | --- | | TagResource | tag-resource | 在具有指定 ARN 的資源上新增或覆寫一或多個標籤。 | | UntagResource | untag-resource | 從具有指定 ARN 的資源中刪除一個或多個標籤。 | | ListTagsForResource | list‑tags‑for‑resource | 列出具有指定 ARN 之資源的一個或多個標籤。 | **在建立資源時新增標籤** 若要在建立工作群組或資料目錄時新增標籤，請使用 `tags` 參數搭配 `CreateWorkGroup`或 `CreateDataCatalog` API 操作，或搭配 AWS CLI `create-work-group`或 `create-data-catalog`命令。 ## 使用 API 動作管理標籤 下列範例說明如何使用標籤 API 操作來管理工作群組和資料目錄上的標籤。這些範例使用 Java 程式語言。 ### 範例 – TagResource 下列範例將兩個標籤新增至工作群組 `workgroupA`： ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTags(tags); client.tagResource(request); ``` 下列範例將兩個標籤新增至資料目錄 `datacatalogA`： ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTags(tags); client.tagResource(request); ``` **注意** 請勿將重複的標籤鍵新增至相同的資源。如果這樣做，Athena 會發出錯誤訊息。如果您在個別的 `TagResource` 動作中使用現有的標籤鍵來標記資源，新標籤值會覆寫舊值。 ### 範例 – UntagResource 下列範例將 `tagKey2` 從工作群組 `workgroupA` 中移除： ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTagKeys(tagKeys); client.untagResource(request); ``` 下列範例將 `tagKey2` 從資料目錄 `datacatalogA` 中移除： ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTagKeys(tagKeys); client.untagResource(request); ``` ### 範例 – ListTagsForResource 下列範例列出工作群組 `workgroupA` 的標籤： ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` 下列範例列出資料目錄 `datacatalogA` 的標籤： ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` ## 使用 管理標籤 AWS CLI 下列範例示範如何使用 AWS CLI 來建立和管理資料目錄上的標籤。 ### 新增標籤至資源：tag-resource `tag-resource` 命令將一或多個標籤新增到指定的資源。 **語法** `aws athena tag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tags Key=string,Value=string Key=string,Value=string` `--resource-arn` 參數會指定要新增標籤的資源。`--tags` 參數會指定以空格分隔的鍵值組清單，以做為標籤新增至資源。 **Example** 下列範例會將標籤新增至 `mydatacatalog` 資料目錄。 ``` aws athena tag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tags Key=Color,Value=Orange Key=Time,Value=Now ``` 若要顯示結果，請使用 `list-tags-for-resource` 命令。 如需使用 `create-data-catalog` 命令時新增標籤的相關資訊，請參閱[註冊目錄：Create-data-catalog](datastores-hive-cli.md#datastores-hive-cli-registering-a-catalog)。 ### 列出資源的標籤：list-tags-for-resource `list-tags-for-resource` 命令會列出指定資源的標籤。 **語法** `aws athena list-tags-for-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name` `--resource-arn` 參數會指定列出標籤的資源。 下列範例列出 `mydatacatalog` 資料目錄的標籤。 ``` aws athena list-tags-for-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog ``` 以下樣本結果為 JSON 格式。 ``` { "Tags": [ { "Key": "Time", "Value": "Now" }, { "Key": "Color", "Value": "Orange" } ] } ``` ### 從資源移除標籤：untag-resource `untag-resource` 命令會從指定的資源中刪除指定的標籤鍵及其關聯的數值。 **語法** `aws athena untag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tag-keys key_name [key_name ...]` `--resource-arn` 參數會指定要從中移除標籤的資源。`--tag-keys` 參數會取得以空格分隔的索引鍵名稱清單。對於指定的每個索引鍵名稱，`untag-resource` 命令會同時移除索引鍵及其數值。 下列範例會從 `mydatacatalog` 目錄資源中移除 `Color` 和 `Time` 索引鍵及其數值。 ``` aws athena untag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tag-keys Color Time ``` # 使用標籤型 IAM 存取控制政策 使用標籤可讓您撰寫包含 `Condition` 區塊的 IAM 政策，以根據資源的標籤來控制對資源的存取。本節包含工作群組和資料目錄資源的標籤政策範例。 ## 工作群組的標籤政策範例 ### 範例 – 基本標籤政策 以下 IAM 政策可讓您執行查詢，並與名為 `workgroupA` 的工作群組的標籤互動： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA" } ] } ``` ------ ### 範例 – 根據標籤索引鍵和標籤值配對在工作群組上拒絕動作的政策區塊 與資源 (如工作群組) 相關聯的標籤稱為資源標籤。資源標籤可讓您編寫政策區塊，如以下項目在以鍵值組所標記的任何工作群組上拒絕列出的動作，例如 `stack`、`production`。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:GetWorkGroup", "athena:UpdateWorkGroup", "athena:DeleteWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### 範例 – 限制對指定的標籤提出標籤變更動作請求的政策區塊 做為參數傳入至變更標籤之操作的標籤 (例如帶有標籤的 `TagResource`、`UntagResource` 或 `CreateWorkGroup`) 稱為請求標籤。下列範例政策區塊只有在傳遞的其中一個標籤具有索引鍵 `costcenter` 和數值 `1`、`2` 或 `3` 時，才允許 `CreateWorkGroup` 操作。 **注意** 如果您想要允許 IAM 角色在 `CreateWorkGroup` 操作中傳入標籤，請確定您授予角色進行 `TagResource` 和 `CreateWorkGroup` 動作的許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateWorkGroup", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ ## 資料目錄的標籤政策範例 ### 範例 – 基本標籤政策 以下 IAM 政策可讓您與名為 `datacatalogA` 的資料目錄的標籤互動： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:workgroup/*" ] }, { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA" } ] } ``` ------ ### 範例 – 根據標籤索引鍵和標籤值組在資料目錄上拒絕動作的政策區塊 您可以使用資源標籤撰寫政策區塊，以拒絕針對以特定標籤鍵值組標記的資料目錄上的特定動作。下列範例政策會拒絕具有標籤鍵值組 `stack`、`production` 的資料目錄上的動作。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:GetDatabase", "athena:ListDatabases", "athena:GetTableMetadata", "athena:ListTableMetadata", "athena:StartQueryExecution", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### 範例 – 限制對指定的標籤提出標籤變更動作請求的政策區塊 做為參數傳入至變更標籤之操作的標籤 (例如帶有標籤的 `TagResource`、`UntagResource` 或 `CreateDataCatalog`) 稱為請求標籤。下列範例政策區塊只有在傳遞的其中一個標籤具有索引鍵 `costcenter` 和數值 `1`、`2` 或 `3` 時，才允許 `CreateDataCatalog` 操作。 **注意** 如果您想要允許 IAM 角色在 `CreateDataCatalog` 操作中傳入標籤，請確定您授予角色進行 `TagResource` 和 `CreateDataCatalog` 動作的許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ # Service Quotas **注意** Service Quotas 主控台提供有關 Amazon Athena 配額的資訊。您也可以使用 Service Quotas 主控台，針對可調整的配額[請求提高配額](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas)。如需 AWS Glue 相關的結構描述限制，請參閱 [AWS Glue 端點和配額](https://docs.aws.amazon.com/general/latest/gr/glue.html)頁面。如需 AWS 服務配額的一般資訊，請參閱 中的[AWS 服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)*AWS 一般參考*。 ## 查詢 您的帳戶於 Amazon Athena 有下列查詢相關的配額：如需詳細資訊，請參閱 AWS 一般參考的 [Amazon Athena 端點和配額](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits)頁面。 + **Active DDL queries** (作用中 DDL 查詢) - 作用中 DDL 查詢的數量。DDL 查詢包括 `CREATE TABLE` 和 `ALTER TABLE ADD PARTITION` 查詢。 + **DDL query timeout** (DDL 查詢逾時) - DDL 查詢在取消之前可以執行的時間上限，以分鐘為單位。 + **Active DML queries** (作用中 DML 查詢) - 作用中 DML 查詢的數量。DML 查詢包括 `SELECT`、`CREATE TABLE AS` (CTAS)和 `INSERT INTO` 查詢。具體配額因 AWS 區域而異。 + **DML query timeout** (DML 查詢逾時) - DML 查詢在取消之前可以執行的時間上限，以分鐘為單位。您可以請求將此逾時增加最多 240 分鐘。 若要請求增加配額，可使用 [Athena Service Quotas](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas) 主控台。 Athena 會根據整體服務負載和傳入請求數量，以指派資源來處理查詢。系統可能會在執行您的查詢之前，先將其暫時排入佇列。非同步處理會從佇列中接收查詢，並在資源可用且帳戶設定允許的情況下，立即在實體資源上執行查詢。 Active DML 查詢和 Active DDL 查詢配額包括正在執行中和已排入佇列的查詢。例如，如果您的 Active DML 查詢配額為 25，而正在執行中和佇列的查詢總數為 26，則查詢 26 會出現 TooManyRequestsException 的錯誤。 **注意** 若您要直接控制在 Athena 中執行的查詢的並行，則可以使用容量保留。如需詳細資訊，請參閱[管理查詢處理容量](capacity-management.md)。 ### 查詢字串長度 允許的查詢字串長度上限是 262144 位元組，其中字串以 UTF-8 編碼。這不是可調整的配額。不過，您可以將長查詢分割成多個較小的查詢，以解決這項限制。如需詳細資訊，請參閱 AWS 知識中心中的[如何在 Athena 中增加最大查詢字串長度？](https://aws.amazon.com/premiumsupport/knowledge-center/athena-query-string-length/)。 ## 工作群組 使用 Athena 工作群組時，請記住以下幾點： + Athena Service Quotas 會在帳戶中的所有工作群組之間共用。 + 可以在帳戶中為每個區域建立的工作群組數量上限為 1000 個。 + 工作群組中預備陳述式的數量上限為 1000。 + 每一工作階段的標籤數上限為 50。如需詳細資訊，請參閱[標籤限制](tags.md#tag-restrictions)。 ## 資料庫、資料表和分割區 Athena 使用 AWS Glue Data Catalog。如需了解資料表、資料庫和分割區的服務配額 (例如，每個帳戶的資料庫或資料表數量上限)，請參閱 [AWS Glue 端點和配額](https://docs.aws.amazon.com/general/latest/gr/glue.html)。請注意，雖然 Athena 支援查詢具有 1，000 萬個分割區的 AWS Glue 資料表，但 Athena 無法在單一掃描中讀取超過 100 萬個分割區。 ## Amazon S3 儲存貯體 在您使用 Amazon S3 儲存貯體時，請記住以下幾點： + Amazon S3 預設的服務配額為每個帳戶 10，000 個儲存貯體。 + Athena 需有一個單獨的儲存貯體來記錄結果。 + 您可以要求每個 AWS 帳戶增加最多 100 萬個 Amazon S3 儲存貯體的配額。 ## 每個帳戶 API 呼叫配額 Athena API 關於每個帳戶 (而非每個查詢) 的 API 呼叫數量的預設配額。如需預設配額的完整清單，請參閱 AWS 一般參考 指南中的[服務配額](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits)表。 如果您使用任何這些 API，且超過預設的每秒呼叫數配額，或帳戶中的高載容量，Athena API 會發出類似以下的錯誤："ClientError: An error occurred (ThrottlingException) when calling the ** operation: Rate exceeded." (ClientError：呼叫 操作時發生錯誤 (ThrottlingException)：超過速率。) 請減少每秒呼叫次數，或此帳戶的 API 爆發容量。 您可以在 [Athena Service Quotas 主控台](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas)中變更每個帳戶 API 呼叫的 Athena 配額。