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

# 防止 Amazon S3 限流
<a name="performance-tuning-s3-throttling"></a>

限流是限制您使用服務、應用程式或系統的速率的程序。在 中 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)

# 減少服務層級的限流
<a name="performance-tuning-s3-throttling-reduce-throttling-at-the-service-level"></a>

若要避免 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 （開發人員指南*)

# 最佳化您的資料表
<a name="performance-tuning-s3-throttling-optimizing-your-tables"></a>

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

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

## 使用分割區
<a name="performance-tuning-s3-throttling-use-partitioning"></a>

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

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

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

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

如需有關在 Athena 中分割的詳細資訊，請參閱 [什麼是分割？](ctas-partitioning-and-bucketing-what-is-partitioning.md)

## 歸納您的資料
<a name="performance-tuning-s3-throttling-bucket-your-data"></a>

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

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

如需有關在 Athena 中歸納的詳細資訊，請參閱 [什麼是歸納？](ctas-partitioning-and-bucketing-what-is-bucketing.md)。

## 使用 AWS Glue 分割區索引
<a name="performance-tuning-s3-throttling-use-aws-glue-partition-indexes"></a>

您可以使用 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)。

## 使用資料壓縮和檔案分割
<a name="performance-tuning-s3-throttling-use-data-compression-and-file-splitting"></a>

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

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

## 使用優化單欄式資料存放區
<a name="performance-tuning-s3-throttling-use-optimized-columnar-data-stores"></a>

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

Apache Parquet 和 Apache ORC 是常用的開放原始碼單欄式資料存放區。如需有關將現有 Amazon S3 資料來源轉換為其中一種格式的資訊，請參閱 [轉換為單欄式格式](columnar-storage.md#convert-to-columnar)。

### 使用較大的 Parquet 區塊大小或 ORC 條紋大小
<a name="performance-tuning-s3-throttling-use-a-larger-parquet-block-size-or-orc-stripe-size"></a>

Parquet 和 ORC 具有資料儲存參數，您可以調整以進行優化。在 Parquet 中，您可以優化區塊大小。在 ORC 中，您可以優化條紋大小。區塊或條紋越大，您可以在其中儲存的資料列就越多。依預設，Parquet 區塊大小為 128 MB，而 ORC 條紋大小為 64 MB。

如果 ORC 條紋小於 8 MB (預設值為 `hive.orc.max_buffer_size`)，則 Athena 會讀取整個 ORC 條紋。對於較小的條紋，這是 Athena 在資料欄選取性和每秒輸入/輸出操作之間進行的權衡。

如果您的資料表包含大量資料欄，則較小的區塊或條紋大小可能會導致掃描的資料超過必要的數量。在這些情況下，較大的區塊大小可能會更有效率。

### 對複雜類型使用 ORC
<a name="performance-tuning-s3-throttling-use-orc-for-complex-types"></a>

目前，當您查詢存放在 Parquet 中且具有複雜資料類型 (例如，`array`、`map` 或 `struct`) 的資料欄時，Athena 會讀取整個資料列，而不是只選擇性地讀取指定的資料欄。這是 Athena 的已知問題。解決方法是考慮使用 ORC。

### 選擇壓縮演算法
<a name="performance-tuning-s3-throttling-choose-a-compression-algorithm"></a>

您可以設定的另一個參數是資料區塊上的壓縮演算法。如需有關 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 資料表
<a name="performance-tuning-s3-throttling-use-iceberg-tables"></a>

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)。

# 最佳化您的查詢
<a name="performance-tuning-s3-throttling-optimizing-queries"></a>

使用本節中的建議優化 Athena 中的 SQL 查詢。

## 使用 LIMIT 與 ORDER BY 子句
<a name="performance-tuning-s3-throttling-use-limit-with-the-order-by-clause"></a>

`ORDER BY` 子句會以排序順序傳回資料。這需要 Athena 將所有資料列傳送至單一工作節點，然後排序資料列。這種查詢類型可以執行很長一段時間，甚至失敗。

為了提高查詢的效率，請查看頂部或底部的 *N* 個值，然後使用 `LIMIT` 子句。這樣可以將排序和限制推送至個別工作節點，而不是單一工作節點，進而大幅降低排序的成本。

## 優化 JOIN 子句
<a name="performance-tuning-s3-throttling-optimize-join-clauses"></a>

當您聯結兩個資料表時，Athena 會將右側的資料表分散至工作節點，然後串流左側的資料表以執行聯結。

因此，請在聯結左側指定較大的資料表，並在聯結的右側指定較小的資料表。如此一來，Athena 會使用較少的記憶體，並以較低的延遲執行查詢。

另外，請注意以下重點：
+ 當您使用多個 `JOIN` 命令時，請按從最大到最小的順序指定資料表。
+ 除非查詢需要交叉聯結，否則請予以避免。

## 優化 GROUP BY 子句
<a name="performance-tuning-s3-throttling-optimize-group-by-clauses"></a>

`GROUP BY` 運算子會根據 `GROUP BY` 資料欄將資料列分散至工作節點。我們會在記憶體中引用這些資料欄，並在擷取資料列時比較這些值。當 `GROUP BY` 資料欄相符時，這些值彙總在一起。考慮到此程序的運作方式，建議按從最高基數到最低基數的順序排序資料欄。

## 使用數字而不是字串
<a name="performance-tuning-s3-throttling-use-numbers-instead-of-strings"></a>

由於相較於字串，數字需要的記憶體較少，而且處理速度更快，因此請盡可能使用數字而不是字串。

## 限制資料欄的數目
<a name="performance-tuning-s3-throttling-limit-the-number-of-columns"></a>

若要減少儲存資料所需的記憶體總量，請限制 `SELECT` 陳述式中指定的資料欄數。

## 使用規則表達式而不是 LIKE
<a name="performance-tuning-s3-throttling-use-regular-expressions-instead-of-like"></a>

包含子句 (例如大型字串上的 `LIKE '%string%'`) 的查詢可能需要非常大量的運算。當您篩選字串資料欄上的多個值時，請改用 [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) 函數和規則表達式。當您比較一長串值時，這特別有用。

## 使用 LIMIT 子句
<a name="performance-tuning-s3-throttling-use-the-limit-clause"></a>

當您執行查詢時，請不要選取所有資料欄，而是使用 `LIMIT` 子句，以只傳回您需要的資料欄。這樣做可減少透過查詢執行管道處理的資料集大小。當您查詢具有大量字串型資料欄的資料表時，`LIMIT` 子句會更有幫助。當您對任何查詢執行多個聯結或彙總時，`LIMIT` 子句也很有用。