將零 ETL 整合與 Amazon Redshift 搭配使用的考量

您的目標 Amazon Redshift 資料倉儲必須符合下列先決條件：

如果您刪除來源，而該來源是 Amazon Redshift 資料倉儲的授權整合來源，則所有相關聯的整合都會進入 FAILED 狀態。任何先前複寫的資料都會保留在您的 Amazon Redshift 資料庫中，並且可供查詢。

目的地資料庫是唯讀的。您無法在目的地資料庫中建立資料表、視觀表或具體化視觀表。不過，您可以在目標資料倉儲中的其他資料表上使用具體化視觀表。

具體化視觀表在用於跨資料庫查詢時才會得到支援。如需使用透過零 ETL 整合複寫之資料來建立具體化視觀表的相關資訊，請參閱 透過具體化視觀表查詢複寫的資料。

根據預設，您只能查詢目標資料倉儲中處於 Synced 狀態的資料表。若要查詢其他狀態的資料表，請將資料庫參數 QUERY_ALL_STATES 設定為 TRUE。如需有關設定 QUERY_ALL_STATES 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 CREATE DATABASE 和 ALTER DATABASE。如需資料庫狀態的詳細資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 SVV_INTEGRATION_TABLE_STATE。

Amazon Redshift 只接受 UTF-8 字元，因此可能不遵守您的來源中定義的定序。排序和比較規則可能會有所不同，這最後可能會變更查詢結果。

每個 Amazon Redshift 資料倉儲目標的零 ETL 整合限制為 50 個。

整合來源中的資料表必須有主索引鍵。否則，無法將您的資料表複寫至 Amazon Redshift 中的目標資料倉儲。

如需如何將主索引鍵新增至 Amazon Aurora PostgreSQL 的相關資訊，請參閱 AWS 資料庫部落格中的建立與 Amazon Redshift 的 Amazon Aurora PostgreSQL 零 ETL 整合時，在沒有主索引鍵的情況下處理資料表。如需如何將主索引鍵新增至 Amazon Aurora MySQL 或 RDS for MySQL 的相關資訊，請參閱 AWS 資料庫部落格中的建立與 Amazon Redshift 的 Amazon Aurora MySQL 或 Amazon RDS for MySQL 零 ETL 整合時，在沒有主索引鍵的情況下處理資料表。

您可以使用資料篩選來進行 Aurora 零 ETL 整合，以定義從來源 Aurora 資料庫叢集複寫至目標 Amazon Redshift 資料倉儲的範圍。您可以定義一或多項篩選條件，以選擇性地包含或排除複寫某些資料表，而不要將所有資料複寫至目標。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》中的使用資料篩選以便與 Amazon Redshift 進行 Aurora 零 ETL 整合。

對於與 Amazon Redshift 的 Aurora PostgreSQL 零 ETL 整合，Amazon Redshift 最多支援來自 Aurora PostgreSQL 的 100 個資料庫。每個資料庫都會單獨從來源複寫至目標。

零 ETL 整合不支援將資料從交易資料存放區複寫到 Amazon Redshift 時進行轉換。資料會依原樣從來源資料庫複寫。不過，您可以在 Amazon Redshift 中對複寫的資料套用轉換。

零 ETL 整合在 Amazon Redshift 中執行時是使用平行連線。其使用從整合建立資料庫之使用者的憑證執行。當查詢執行時，不會在同步 (寫入) 期間對這些連線進行並行擴展。並行擴展讀取 (從 Amazon Redshift 用戶端) 適用於已同步的物件。

您可以針對零 ETL 整合設定 REFRESH_INTERVAL，以控制資料複寫至 Amazon Redshift 的頻率。如需詳細資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 CREATE DATABASE 和 ALTER DATABASE。

您從與 Amazon DynamoDB 的零 ETL 整合建立 Amazon Redshift 資料庫之後，資料庫狀態應該會從建立變更為作用中。此時會在來源 DynamoDB 資料表中開始將資料複寫至目標 Redshift 資料表，這些資料表是在目的地資料庫 (ddb_rs_customerprofiles_zetl_db) 的公有結構描述下建立。

當您捨棄來源上的某個資料表時，目標上不會捨棄該資料表，但其狀態會變更為 DroppedSource。您可以在 Amazon Redshift 資料庫上捨棄或重新命名資料表。

當您截斷來源上的資料表時，目標資料表上就會執行刪除作業。例如，如果來源上的所有記錄都遭到截斷，則目標欄 _record_is_active 上的對應記錄會變更為 false。

當您在目標資料表上執行 TRUNCATE 資料表 SQL 時，作用中歷史記錄列會標記為非作用中且包含對應的時間戳記。

資料表中的列設定為非作用中時，就可以在短暫 (約 10 分鐘) 延遲後將其刪除。若要刪除非作用中的列，請使用查詢編輯器 v2 或其他 SQL 用戶端連線至零 ETL 資料庫。

您只能在歷史記錄模式開啟的狀態下，從資料表中刪除非作用中的列。例如，類似下方所示的 SQL 命令只會刪除非作用中的列。

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'

這相當於 SQL 命令，如下所示。

delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False

關閉資料表的歷史記錄模式時，所有歷史資料都會儲存到名為 <schema>.<table-name>_historical_<timestamp> 的資料表，同時名為 <schema>.<table-name> 的原始資料表會重新整理。

若使用資料表篩選條件從複寫作業中排除歷史記錄模式為開啟狀態的資料表，則所有列都會設定為非作用中並變更為 DroppedSource 狀態。如需資料表篩選條件的詳細資訊，請參閱《Amazon Aurora 使用者指南》中的使用資料篩選以便與 Amazon Redshift 進行 Aurora 零 ETL 整合。

只有處於 Synced 狀態的資料表，才能將其歷史記錄模式切換為 true 或 false。

歷史記錄模式為開啟狀態之資料表的具體化視觀表會以完整重新計算的形式建立。

您可以使用資料篩選來進行 Aurora 和 RDS for MySQL 零 ETL 整合，以定義從來源資料庫叢集複寫至目標 Amazon Redshift 資料倉儲的範圍。您可以定義一或多項篩選條件，以選擇性地包含或排除複寫某些資料表，而不要將所有資料複寫至目標。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》中的使用資料篩選以便與 Amazon Redshift 進行 Aurora 零 ETL 整合。

整合來源中的資料表必須有主索引鍵。否則，無法將您的資料表複寫至 Amazon Redshift 中的目標資料倉儲。

如需如何將主索引鍵新增至 Amazon Aurora PostgreSQL 的相關資訊，請參閱 AWS 資料庫部落格中的建立與 Amazon Redshift 的 Amazon Aurora PostgreSQL 零 ETL 整合時，在沒有主索引鍵的情況下處理資料表。如需如何將主索引鍵新增至 Amazon Aurora MySQL 或 RDS for MySQL 的相關資訊，請參閱 AWS 資料庫部落格中的建立與 Amazon Redshift 的 Amazon Aurora MySQL 或 Amazon RDS for MySQL 零 ETL 整合時，在沒有主索引鍵的情況下處理資料表。

Amazon Redshift VARCHAR 資料類型的長度上限為 65,535 個位元組。當來源的內容不符合此限制時，複寫就不會繼續，且資料表會進入失敗狀態。您可以將資料庫參數 TRUNCATECOLUMNS 設定為 TRUE 來截斷內容以符合欄寬。如需有關設定 TRUNCATECOLUMNS 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 CREATE DATABASE 和 ALTER DATABASE。

如需零 ETL 整合來源和 Amazon Redshift 資料庫之間資料類型差異的詳細資訊，請參閱《Amazon Aurora 使用者指南》中的 Aurora 和 Amazon Redshift 之間的資料類型差異。

不支援 DynamoDB 中長度超過 127 個字元的資料表名稱。

DynamoDB 零 ETL 整合中的資料會對應至 Amazon Redshift 中的 SUPER 資料類型欄。

不支援長度超過 127 個字元的分割區索引鍵或排序索引鍵的欄名稱。

來自 DynamoDB 的零 ETL 整合只能對應至一個 Amazon Redshift 資料庫。

對於分割區索引鍵和排序索引鍵，精確度和小數位數上限為 (38,18)。DynamoDB 上的數值資料類型支援最高 38 的精確度。Amazon Redshift 也支援最高精確度 38，但 Amazon Redshift 上預設的十進位精確度/小數位數為 (38,10)。這表示小數位數值可以遭到截斷。

若要成功進行零 ETL 整合，DynamoDB 項目中的個別屬性 (由 name+value 組成) 不得超過 64 KB。

啟用時，零 ETL 整合會匯出完整的 DynamoDB 資料表以填入 Amazon Redshift 資料庫。完成此初始程序所需的時間取決於 DynamoDB 資料表大小。然後，零 ETL 整合會使用 DynamoDB 增量匯出，將更新從 DynamoDB 增量複寫到 Amazon Redshift。這表示 Amazon Redshift 中複寫的 DynamoDB 資料會自動保持為最新。

目前，DynamoDB 零 ETL 整合的最低延遲為 15 分鐘。您可以透過為零 ETL 整合設定非零的 REFRESH_INTERVAL 來進一步增加此值。如需詳細資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 CREATE DATABASE 和 ALTER DATABASE。

不支援應用程式來源中長度超過 127 個字元的資料表名稱和欄名稱。

Amazon Redshift VARCHAR 資料類型的長度上限為 65,535 個位元組。當來源的內容不符合此限制時，複寫就不會繼續，且資料表會進入失敗狀態。您可以將資料庫參數 TRUNCATECOLUMNS 設定為 TRUE 來截斷內容以符合欄寬。如需有關設定 TRUNCATECOLUMNS 的資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 CREATE DATABASE 和 ALTER DATABASE。

如需零 ETL 整合應用程式來源與 Amazon Redshift 資料庫之間資料類型差異的詳細資訊，請參閱《AWS Glue 開發人員指南》中的零 ETL 整合。

與應用程式的零 ETL 整合的最低延遲為 1 小時。您可以透過為零 ETL 整合設定非零的 REFRESH_INTERVAL 來進一步增加此值。如需詳細資訊，請參閱《Amazon Redshift 資料庫開發人員指南》中的 CREATE DATABASE 和 ALTER DATABASE。