將零 ETL 整合與 Amazon Redshift 搭配使用的考量 - Amazon Redshift
在目標上使用歷史記錄模式時的考量事項零 ETL 整合來源為 Aurora 或 Amazon RDS 時的考量零 ETL 整合來源為 DynamoDB 時的考量零 ETL 整合來源為應用程式時的考量，例如 Salesforce、SAP、ServiceNow 和 Zendesk

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

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

以下考量適用於 Amazon Redshift 的零 ETL 整合。

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

    • 執行 Amazon Redshift Serverless 或 RA3 節點類型。

    • 已加密 (如果使用已佈建的叢集)。

    • 已啟用區分大小寫。

  • 如果您刪除來源，而該來源是 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 Aurora MySQL 或 Amazon RDS for MySQL 零 ETL 整合時處理不含主金鑰的資料表。

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

  • 對於與 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。

在目標上使用歷史記錄模式時的考量事項

在目標資料庫上使用歷程記錄模式時，適用下列考量。如需詳細資訊，請參閱歷史記錄模式。

  • 當您在來源上捨棄資料表時，不會捨棄目標上的資料表，但會變更為 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 使用者指南》中的 Aurora 零 ETL 整合與 Amazon Redshift 的資料篩選。

  • 歷史記錄模式只能切換到處於 Synced 狀態false的資料表true或 。

零 ETL 整合來源為 Aurora 或 Amazon RDS 時的考量

下列考量適用於 Aurora 和 Amazon RDS 與 Amazon Redshift 的零 ETL 整合。

對於 Aurora 來源，另請參閱《Amazon Aurora 使用者指南》中的限制。

對於 Amazon RDS 來源，另請參閱《Amazon RDS 使用者指南》中的限制。

零 ETL 整合來源為 DynamoDB 時的考量

下列考量適用於與 Amazon Redshift 的 DynamoDB 零 ETL 整合。

  • 不支援來自 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 資料會自動保持在up-to-date。

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

對於 Amazon DynamoDB 來源，另請參閱《Amazon DynamoDB 開發人員指南》中的先決條件和限制。

零 ETL 整合來源為應用程式時的考量，例如 Salesforce、SAP、ServiceNow 和 Zendesk

下列考量適用於來源應用程式，例如 Salesforce、SAP、ServiceNow 和 Zendesk 搭配 Amazon Redshift。

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

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

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

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

如需與應用程式進行零 ETL 整合的來源，另請參閱《 AWS Glue 開發人員指南》中的零 ETL 整合。