Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 壓縮編碼
*壓縮編碼*會指定在資料列新增至資料表時，套用至一欄資料值的壓縮類型。
ENCODE AUTO 是資料表的預設值。當資料表設定為 ENCODE AUTO 時，Amazon Redshift 會自動管理資料表中所有資料欄的壓縮編碼。如需詳細資訊，請參閱[CREATE TABLE](r_CREATE_TABLE_NEW.md)及[ALTER TABLE](r_ALTER_TABLE.md)。
不過，如果您為資料表中的任何資料欄指定壓縮編碼，資料表就不會再設定為 ENCODE AUTO。Amazon Redshift 不再自動管理資料表中所有資料欄的壓縮編碼。
當您使用 CREATE TABLE 時，當您為資料表中的任何資料欄指定壓縮編碼時，會停用 ENCODE AUTO。如果停用 ENCODE AUTO，Amazon Redshift 會自動將壓縮編碼指派給您未指定 ENCODE 類型的資料欄，如下所示：
+ 定義為排序索引鍵的資料欄會有指派的 RAW 壓縮。
+ 定義為 BOOLEAN、REAL 或 DOUBLE PRECISION 資料類型的資料欄會有指派的 RAW 壓縮。
+ 定義為 SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIMESTAMP 或 TIMESTAMPTZ 資料類型的資料欄會有指派的 AZ64 壓縮。
+ 定義為 CHAR 或 VARCHAR 資料類型的資料欄會有指派的 LZO 壓縮。
您可以使用 ALTER TABLE 在建立資料表之後變更資料表的編碼。如果您使用 ALTER 資料表停用 ENCODE AUTO 功能，Amazon Redshift 將不再自動管理資料欄的壓縮編碼。所有資料欄都會保留您停用 ENCODE 時的壓縮編碼類型，直到您將其變更或再次啟用 ENCODE AUTO 為止。
Amazon Redshift 支援下列壓縮編碼：
------
#### [ Raw ]
Raw 編碼是下列資料欄的預設編碼：指定為排序索引鍵的資料欄，以及定義為 BOOLEAN、REAL 或 DOUBLE PRECISION 資料類型的資料欄。系統使用 Raw 編碼，以原始、未壓縮格式來儲存資料。
------
#### [ AZ64 ]
AZ64 是 Amazon 設計的專屬壓縮編碼，旨在實現高壓縮比並改善查詢處理能力。AZ64 演算法的核心是壓縮更小的一組資料值，並使用單指令、多資料 (SIMD) 指令進行並行處理。使用 AZ64 為數字、日期及時間資料類型節省大量儲存空間並實現高效能。
當搭配下列資料類型使用 CREATE TABLE 及 ALTER TABLE 陳述式，來定義資料欄時，您可以使用 AZ64 做為壓縮編碼：
+ SMALLINT
+ INTEGER
+ BIGINT
+ DECIMAL
+ DATE
+ TIMESTAMP
+ TIMESTAMPTZ
------
#### [ Byte-dictionary ]
在 byte dictionary 編碼中，唯一值的個別字典是針對磁碟上資料欄值的每個區塊而建立的。(Amazon Redshift 磁碟會佔用 1 MB。) 字典最多可包含 256 個一元位元組值，其會以索引形式儲存至原始資料值。如果在單一區塊中儲存超過 256 個值，則額外的值會以原始、未壓縮格式寫入至區塊。對於每個磁碟區塊都會重複此程序。
這種編碼對低基數字串資料欄非常有效。當資料欄的資料網域少於 256 個唯一值時，這是最佳的編碼。
對於字串資料類型 (CHAR 和 VARCHAR) 使用 BYTEDICT 編碼的資料欄，Amazon Redshift 會執行向量化掃描和述詞評估，直接對壓縮資料進行操作。這些掃描會使用硬體專屬的單一指示和多重資料 (SIMD) 指示進行平行處理。這會顯著加快字串資料欄的掃描速度。如果 CHAR/VARCHAR 資料欄保存長字元字串，則 Byte-dictionary 編碼特別節省空間。
假設資料表具有資料類型為 CHAR(30) 的 COUNTRY 資料欄。載入資料時，Amazon Redshift 會建立字典。並在 COUNTRY 資料欄填入索引值。字典包含已建立索引的唯一值，而且資料表本身只包含對應值的一位元組下標。
**注意**
會儲存固定長度字元欄的多餘空格。因此，在 CHAR(30) 資料欄中，當您使用 byte-dictionary 編碼時，每個對應值都會節省 29 個位元組的儲存空間。
下表代表 COUNTRY 資料欄的字典。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)
下表代表 COUNTRY 資料欄中的值。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)
此範例中的合計壓縮大小計算如下：6 個不同項目儲存在字典 (6 \* 30 = 180)，而且資料表包含 10 個 1 位元組壓縮值，合計 190 個位元組。
------
#### [ Delta ]
Delta 編碼對日期時間欄很有用。
Delta 藉由記錄資料欄中彼此跟隨的值之間的差異來壓縮資料。此差異會記錄在磁碟上資料欄值之每個區塊的個別字典中。(Amazon Redshift 磁碟會佔用 1 MB。) 例如，假設資料欄包含 10 個整數，順序從 1 到 10。第一個會儲存為 4 位元組整數 (加上 1 位元組旗標)。接下來的九個會分別儲存為值為 1 的位元組，表示比前一個值多 1。
Delta 編碼附有兩個變異：
+ DELTA 會將差異記錄為 1 位元組值 (8 位元組整數)
+ DELTA32K 會將差異記錄為 2 位元組值 (16 位元組整數)
如果資料欄中的大多數值可以透過使用單一位元組進行壓縮，則 1 位元組的變化非常有效。但是，如果差異較大，則此編碼 (在最壞的情況下) 會比儲存未壓縮資料的效果差。類似邏輯適用於 16 位元版本。
如果兩個值之間的差異超過 1 位元組範圍 (DELTA) 或 2 位元組範圍 (DELTA32K)，則會儲存完整原始值，前面為 1 位元組旗標。1 位元組範圍從 -127 到 127，而 2 位元組範圍從 -32K 到 32K。
下表顯示數值欄的 Delta 編碼如何運作。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)
------
#### [ LZO ]
LZO 壓縮編碼提供非常高的壓縮率和良好的效能。LZO 編碼特別適用於儲存很長的字元字串的 CHAR 和 VARCHAR 資料欄。它們特別適用於自由格式文字，例如產品說明、使用者註解或 JSON 字串。
------
#### [ Mostly ]
當資料欄的資料類型大於大部份儲存值所需的資料類型時，Mostly 編碼很有用。您可以對此類型的資料欄指定 mostly 編碼，將資料欄中的大部分值壓縮為更小的標準儲存空間大小。剩下無法壓縮的值會以其原始格式儲存。例如，您可以將 16 位元資料欄 (例如 INT2 資料欄) 壓縮為 8 位元儲存空間。
通常，mostly 編碼會使用下列資料類型：
+ SMALLINT/INT2 (16 位元)
+ INTEGER/INT (32 位元)
+ BIGINT/INT8 (64 位元)
+ DECIMAL/NUMERIC (64 位元)
選擇 mostly 編碼的適當變異來符合資料欄之資料類型的大小。例如，將 MOSTLY8 套用至定義為 16 位元整數資料欄的資料欄。不允許將 MOSTLY16 套用至具有 16 位元資料類型的資料欄，也不允許將 MOSTLY32 套用至具有 32 位元資料類型的資料欄。
當資料欄中有相當多的值無法壓縮時，Mostly 編碼可能比無壓縮更沒效率。在將其中一種編碼套用到資料欄之前，請執行檢查。您現在將載入的*大部分*值 (也可能在未來載入) 應納入下表中顯示的範圍。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)
**注意**
對於小數，忽略小數點以判斷值是否納入範圍。例如，1,234.56 會視為 123,456，且可在 MOSTLY32 資料欄中壓縮。
例如，VENUE 資料表中的 VENUEID 資料欄會定義為原始整數資料欄，這表示其值佔用 4 位元組的儲存空間。不過，此欄的值目前範圍是 **0** 到 **309**。因此，針對 VENUEID 使用 MOSTLY16 編碼來重建和重新載入此資料表，會將該資料欄中每個值的儲存空間減少至 2 個位元組。
如果另一個資料表中參考的 VENUEID 值大部分在範圍 0 到 127，則將該外部索引鍵資料欄編碼為 MOSTLY8 可能就有意義。在做出選擇之前，請針對參考資料表資料執行數個查詢，以了解值是否大部分都落入 8 位元、16 位元或 32 位元範圍。
下表顯示在使用 MOSTLY8、MOSTLY16 和 MOSTLY32 編碼時特定數值的壓縮大小：
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)
------
#### [ Run length ]
執行長度編碼會將連續重複的值取代為由值和連續出現次數 (執行長度) 組成的符記。唯一值的個別字典是針對磁碟上資料欄值的每個區塊而建立的。(Amazon Redshift 磁碟會佔用 1 MB。) 此編碼最適合於資料值通常連續重複的資料表，例如，依那些值排序資料表時。
例如，假設大型維度資料表中的資料欄具有可預測的較小領域，例如 COLOR 資料欄的可能值少於 10 個。這些值可能會落在整個資料表中的長序列中，即使資料未排序也是如此。
不建議在指定為排序索引鍵的任何資料欄上套用執行長度編碼。當區塊包含類似的列數時，限制範圍的掃描執行效果會更好。如果排序索引鍵欄位的壓縮比相同查詢中的其他欄位高出許多，限制範圍的掃描執行效果可能較差。
下表使用 COLOR 資料欄範例來顯示執行長度編碼如何運作。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)
------
#### [ Text255 and Text32k ]
Text255 和 text32k 編碼有助於相同單字經常重複出現的壓縮 VARCHAR 資料欄。唯一單字的個別字典是針對磁碟上資料欄值的每個區塊而建立的。(Amazon Redshift 磁碟會佔用 1 MB。) 字典包含資料欄中前 245 個唯一單字。那些單字會在磁碟上被代表 245 個值之一的一位元組索引值所取代，而且未在字典中表示的任何單字會以未壓縮形式儲存。對於每個 1 MB 磁碟區塊都會重複此程序。如果建立索引的單字經常出現在資料欄中，則資料欄將產生高壓縮率。
對於 text32k 編碼，原則相同，但每個區塊的字典不會擷取特定數目的單字。反之，字典會為其找到的每個唯一單字建立索引，直到結合的項目達到 32K 長度，減去一些額外負荷。索引值是以兩個位元組儲存。
例如，考慮 VENUE 資料表中的 VENUENAME 資料欄。**Arena**、**Center** 和 **Theatre** 等單字反覆出現在這個欄中，而且若套用 text255 壓縮，則很可能出現在每個區塊中的前 245 個單字之中。如果是這樣，則此資料欄將受益於壓縮。因為每次那些單字出現，它們將只佔用 1 個位元組的儲存空間 (而不是分別佔用 5、6 或 7 個位元組)。
------
#### [ ZSTD ]
對於各種資料集，Zstandard (ZSTD) 編碼提供高壓縮率和極佳效能。ZSTD 編碼特別適用於儲存廣泛長短字串的 CHAR 和 VARCHAR 資料欄，特別是自由格式的文字，例如產品描述、使用者意見、日誌和 JSON 字串。其中某些演算法 (例如 Delta 編碼或 Mostly 編碼) 可以潛在比無壓縮使用更多的儲存空間，而 ZSTD 不可能增加磁碟用量。
ZSTD 支援 SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP 和 TIMESTAMPTZ 等資料類型。
------
下表識別支援的壓縮編碼和支援編碼的資料類型。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/c_Compression_encodings.html)