本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

最佳化您的資料表

如果遇到限流問題，建構資料很重要。雖然 Amazon S3 可以處理大量資料，但有時會因為資料的建構方式而發生限流。

下列各節就如何在 Amazon S3 中建構資料以避免限流問題提供了一些建議。

使用分割區

您可以限制在任何指定時間內存取的資料量，使用分割來減少限流。藉由分割特定資料欄上的資料，您可以將請求平均分散至多個物件，並減少單一物件的請求數目。減少必須掃描的資料量會改善查詢效能並降低成本。

您可以在建立資料表時，定義可做為虛擬資料欄的分割區。若要在 CREATE TABLE 陳述式中建立含有分割區的資料表，您可以使用 PARTITIONED BY (column_name data_type) 子句來定義分割資料的索引鍵。

若要限制查詢掃描的分割區，您可以在查詢的 WHERE 子句中將其指定為述詞。因此，經常用作篩選器的資料欄是分割的理想候選者。常見做法是根據時間間隔來分割資料，這通常會產生多層級的分割機制。

請注意，分割也有成本。當您增加資料表中的分割區數目時，擷取和處理分割區中繼資料所需的時間也會增加。因此，過度分割會消除您透過更明智分區而獲得的益處。如果您的資料明顯集中於一個分割區值，並且大多數查詢使用該值，則可能會產生額外開銷。

如需有關在 Athena 中分割的詳細資訊，請參閱 什麼是分割？

歸納您的資料

分割資料的另一個方法是將資料歸納在單一分割區內。使用歸納功能時，您可以指定一或多個資料欄，其中包含要組合在一起的資料列。然後，將這些資料列放入多個儲存貯體中。如此一來，您只會查詢必須讀取的儲存貯體，從而減少必須掃描的資料列數目。

當您選取要用於歸納的資料欄時，請選取具有高基數 (亦即，具有許多不同值)、均勻分散且經常用來篩選資料的資料欄。主索引鍵 (例如 ID 資料欄) 是用來歸納的良好資料欄範例。

如需有關在 Athena 中歸納的詳細資訊，請參閱 什麼是歸納？。

使用 AWS Glue 分割區索引

您可以使用 AWS Glue 分割區索引，根據一或多個分割區的值整理資料表中的資料。 AWS Glue 分割區索引可減少資料傳輸的數量、資料處理量，以及查詢的處理時間。

AWS Glue 分割區索引是中繼資料檔案，其中包含資料表中分割區的相關資訊，包括分割區索引鍵及其值。分割區索引存放在 Amazon S3 儲存貯體中，當新的分割區新增至資料表 AWS Glue 時， 會自動更新分割區索引。

當 AWS Glue 分割區索引存在時，查詢會嘗試擷取分割區的子集，而不是載入資料表中的所有分割區。查詢只會在與查詢相關的資料子集上執行。

在 中建立資料表時 AWS Glue，您可以在資料表上定義的任意分割區索引鍵組合上建立分割區索引。在資料表上建立一或多個分割區索引之後，您必須將屬性新增至啟用分割區篩選的資料表。然後，您可以從 Athena 查詢資料表。

如需有關在 中建立分割區索引的資訊 AWS Glue，請參閱《 AWS Glue 開發人員指南》中的在 中使用分割區索引 AWS Glue。如需有關新增資料表屬性以啟用分割區篩選的資訊，請參閱 使用 AWS Glue 分割區索引和篩選來最佳化查詢。

使用資料壓縮和檔案分割

如果檔案處於最佳大小，或可以將檔案分割成邏輯群組，則資料壓縮可以大幅加快查詢速度。一般而言，較高的壓縮比需要更多的 CPU 週期來壓縮和解壓縮資料。對於 Athena，建議您使用 Apache Parquet 或 Apache ORC，因為其預設會壓縮資料。如需有關 Athena 中資料壓縮的資訊，請參閱在 Athena 中使用壓縮。

分割檔案可讓 Athena 將讀取單一檔案的任務分散至多個讀取器，藉此提高平行處理能力。如果單一檔案不可分割，則只有一個讀取器可以讀取檔案，而其他讀取器則處於閒置狀態。Apache Parquet 和 Apache ORC 還支援可分割的檔案。

使用優化單欄式資料存放區

如果您將資料轉換為單欄式格式，則 Athena 查詢效能會大幅提升。當您產生單欄式檔案時，需要考量的一種優化技術是根據資料分割區索引鍵排序資料。

Apache Parquet 和 Apache ORC 是常用的開放原始碼單欄式資料存放區。如需有關將現有 Amazon S3 資料來源轉換為其中一種格式的資訊，請參閱 轉換為單欄式格式。

使用較大的 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 壓縮支援。

如需 Athena 中單欄式儲存格式最佳化的詳細資訊，請參閱 AWS 大數據部落格文章 Amazon Athena 的前 10 個效能調校秘訣中的「最佳化單欄式資料存放區產生」一節。

使用 Iceberg 資料表

Apache Iceberg 是開放式的資料表格式，專用於非常大型的分析資料集，旨在優化 Amazon S3 上的用量。您可以使用 Iceberg 資料表來協助減少 Amazon S3 中的限流。

Iceberg 資料表可為您提供下列優點：

如需有關 Apache Iceberg 的詳細資訊，請參閱 Apache Iceberg。如需有關在 Athena 中使用 Apache Iceberg 資料表的詳細資訊，請參閱使用 Iceberg 資料表。