Amazon Redshift は、2026 年 6 月 30 日以降、Python UDF の使用をサポートしなくなります。これは段階的に実施されます。Python のサポート終了と移行オプションの詳細については、2025 年 6 月 30 日に公開された[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# でゼロ ETL 統合を使用する場合の考慮事項
Amazon Redshift との ゼロ ETL 統合には、以下の制限が適用されます。
+ ターゲット Amazon Redshift データウェアハウスは、次の前提条件を満たす必要があります。
+ Amazon Redshift Serverless または RG や RA3 ノードタイプのプロビジョン済みクラスターを実行している。
+ 暗号化されている (プロビジョニングされたクラスターを使用している場合)
+ 大文字と小文字の区別が有効になっている。
+ Amazon Redshift データウェアハウスの承認済み統合ソースであるソースを削除すると、関連するすべての統合が `FAILED` 状態になります。以前にレプリケートされたデータは Amazon Redshift データベースに残っており、クエリを実行できます。
+ デスティネーションデータベースは読み取り専用です。デスティネーションデータベースにテーブル、ビュー、またはマテリアライズドビューを作成することはできません。ただし、ターゲットデータウェアハウスのその他のテーブルでもマテリアライズドビューを使用できます。
+ マテリアライズドビューは、クロスデータベースクエリで使用される場合にサポートされます。ゼロ ETL 統合を介してレプリケートされたデータを使用してマテリアライズドビューを作成する方法の詳細については、「[レプリケートしたデータのマテリアライズドビューでのクエリ](zero-etl-using.querying-and-creating-materialized-views.md#zero-etl-using.transforming)」を参照してください。
+ デフォルトでは、クエリできるのは、`Synced` 状態のターゲットデータウェアハウスのテーブルのみです。別の状態のテーブルをクエリするには、データベースパラメータ `QUERY_ALL_STATES` を `TRUE` に設定します。`QUERY_ALL_STATES` の設定の詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」と「[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html)」を参照してください。データベースの状態の詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[SVV\_INTEGRATION\_TABLE\_STATE](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_INTEGRATION_TABLE_STATE.html)」を参照してください。
+ Amazon Redshift では UTF-8 文字のみを使用できるため、ソースで定義された照合順序に従わない場合があります。ソートルールと比較ルールは異なる場合があり、それによって最終的にクエリ結果が変わる可能性があります。
+ ゼロ ETL 統合は、Amazon Redshift データウェアハウスのターゲットごとに 50 に制限されています。
+ 統合ソースのテーブルにはプライマリキーが必要です。それ以外の場合は、Amazon Redshift でターゲットのデータウェアハウスにテーブルが複製されません。
Amazon Aurora PostgreSQL にプライマリキーを追加する方法については、*AWS データベースブログ*の「[Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift](https://aws.amazon.com/blogs/database/handle-tables-without-primary-keys-while-creating-amazon-aurora-postgresql-zero-etl-integrations-with-amazon-redshift/)」を参照してください。Amazon Aurora MySQL または RDS for MySQL にプライマリキーを追加する方法については、*AWS データベースブログ*の「[Amazon Aurora MySQL または Amazon RDS for MySQL と Amazon Redshift とのゼロ ETL 統合を作成する際にプライマリキーがないテーブルを処理する](https://aws.amazon.com/blogs/database/handle-tables-without-primary-keys-while-creating-amazon-aurora-mysql-or-amazon-rds-for-mysql-zero-etl-integrations-with-amazon-redshift/)」を参照してください。
+ Aurora ゼロ ETL 統合でのデータフィルタリングを使用して、ソースの Aurora DB クラスターからターゲットの Amazon Redshift データウェアハウスへのレプリケーションの範囲を定義できます。すべてのデータをターゲットにレプリケートするのではなく、単一または複数のフィルターを定義して、特定のテーブルを選択的にレプリケーションの対象に含めたり除外したりできます。詳細については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Redshift との Aurora のゼロ ETL 統合向けのデータフィルタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.filtering.html)」を参照してください。
+ Aurora PostgreSQL と Amazon Redshift のゼロ ETL 統合では、Amazon Redshift は Aurora PostgreSQL から最大 100 個のデータベースをサポートします。各データベースは、ソースからターゲットに個別にレプリケートされます。
+ ゼロ ETL 統合は、トランザクションデータストアから Amazon Redshift にデータをレプリケートする際の変換をサポートしていません。データはソースデータベースからそのままレプリケートされます。ただし、Amazon Redshift でレプリケートしたデータに変換を適用することはできます。
+ ゼロ ETL 統合は、並列接続を使用して Amazon Redshift で実行します。この実行には、統合からデータベースを作成したユーザーの認証情報を使用します。
+ Amazon Redshift へのデータレプリケーションの頻度を制御するため、ゼロ ETL 統合の `REFRESH_INTERVAL` を設定できます。詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」および「[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html)」を参照してください。
+ Amazon DynamoDB とのゼロ ETL 統合から Amazon Redshift データベースを作成すると、データベースの状態が **[作成中]** から **[アクティブ]** に変わります。これにより、ソース DynamoDB テーブル内のデータのターゲット Redshift テーブルへのレプリケーションが開始されます。ターゲット Redshift テーブルは、送信先データベース (`ddb_rs_customerprofiles_zetl_db`) のパブリックスキーマの下に作成されます。
## ターゲットで履歴モードを使用する場合の考慮事項
ターゲットデータベースで履歴モードを使用する場合、次の考慮事項が適用されます。詳細については、「[履歴モード](zero-etl-history-mode.md)」を参照してください。
+ ソースのテーブルを削除すると、ターゲットのテーブルは削除されず、`DroppedSource` 状態に変更されます。Amazon Redshift データベースからテーブルを削除したり、名前を変更したりすることができます。
+ ソースのテーブルを切り捨てると、ターゲットテーブルで削除が実行されます。例えば、ソースですべてのレコードが切り捨てられると、ターゲット列 `_record_is_active` の対応するレコードが `false` に変更されます。
+ ターゲットテーブルで TRUNCATE table の 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
```
+ テーブルの履歴モードをオフにすると、すべての履歴データは `._historical_` という名前のテーブルに保存され、元の `.` という名前のテーブルは更新されます。
+ 履歴モードがオンになっているテーブルがテーブルフィルターを使用してレプリケーションから除外されると、すべての行が非アクティブに設定され、`DroppedSource` 状態に変更されます。テーブルフィルターの詳細については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Redshift との Aurora ゼロ ETL 統合でのデータフィルタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.filtering.html)」を参照してください。
+ 履歴モードを `true` または `false` に切り替えられるのは、`Synced` 状態のテーブルに対してのみです。
+ 履歴モードがオンになっているテーブルのマテリアライズドビューは、完全な再計算として作成されます。
## ゼロ ETL 統合ソースが Aurora または Amazon RDS である場合の考慮事項
Amazon Redshift との Aurora と Amazon RDS ゼロ ETL 統合には、以下の制限が適用されます。
+ Aurora と RDS for MySQL ゼロ ETL 統合でのデータフィルタリングを使用して、ソースの DB クラスターからターゲットの Amazon Redshift データウェアハウスへのレプリケーションの範囲を定義できます。すべてのデータをターゲットにレプリケートするのではなく、単一または複数のフィルターを定義して、特定のテーブルを選択的にレプリケーションの対象に含めたり除外したりできます。詳細については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Redshift との Aurora のゼロ ETL 統合向けのデータフィルタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.filtering.html)」を参照してください。
+ 統合ソースのテーブルにはプライマリキーが必要です。それ以外の場合は、Amazon Redshift でターゲットのデータウェアハウスにテーブルが複製されません。
Amazon Aurora PostgreSQL にプライマリキーを追加する方法については、*AWS データベースブログ*の「[Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift](https://aws.amazon.com/blogs/database/handle-tables-without-primary-keys-while-creating-amazon-aurora-postgresql-zero-etl-integrations-with-amazon-redshift/)」を参照してください。Amazon Aurora MySQL または RDS for MySQL にプライマリキーを追加する方法については、*AWS データベースブログ*の「[Amazon Aurora MySQL または Amazon RDS for MySQL と Amazon Redshift とのゼロ ETL 統合を作成する際にプライマリキーがないテーブルを処理する](https://aws.amazon.com/blogs/database/handle-tables-without-primary-keys-while-creating-amazon-aurora-mysql-or-amazon-rds-for-mysql-zero-etl-integrations-with-amazon-redshift/)」を参照してください。
+ Amazon Redshift VARCHAR データ型の最大長は 65,535 バイトです。ソースのコンテンツがこの制限に収まらない場合、レプリケーションは実行されず、テーブルのステータスは失敗になります。データベースパラメータ `TRUNCATECOLUMNS` を `TRUE` に設定すると、列に収まるようにコンテンツを切り捨てることができます。`TRUNCATECOLUMNS` の設定の詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」と「[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html)」を参照してください。
ゼロ ETL 統合ソースと Amazon Redshift データベース間のデータ型の違いの詳細については、「Amazon Aurora ユーザーガイド」の「[Aurora と Amazon Redshift 間のデータ型の違い](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.querying.html#zero-etl.data-type-mapping)」を参照してください。**
Aurora のソースについては、「*Amazon Aurora ユーザーガイド*」の「[制限](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.html#zero-etl.reqs-lims)」も参照してください。
Amazon RDS のソースについては、「**Amazon RDS ユーザーガイド」の「[制限](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/zero-etl.html#zero-etl.reqs-lims)」も参照してください。
## ゼロ ETL 統合ソースが DynamoDB である場合の考慮事項
Amazon Redshift との DynamoDB ゼロ ETL 統合には、以下の制限が適用されます。
+ DynamoDB のテーブル名が 127 文字を超えるとサポートされません。
+ DynamoDB ゼロ ETL 統合からのデータは、Amazon Redshift の SUPER データ型列にマッピングされます。
+ 127 文字を超えるパーティションキーまたはソートキーの列名はサポートされていません。
+ DynamoDB からのゼロ ETL 統合は、1 つの Amazon Redshift データベースにのみマッピングできます。
+ パーティションキーとソートキーの場合、精度とスケールの最大値は (38,18) です。DynamoDB の数値データ型は、最大 38 の精度をサポートしています。Amazon Redshift も最大 38 の精度をサポートしていますが、Amazon Redshift のデフォルトの 10 進精度/スケールは (38,10) です。つまり、値のスケール値は切り捨てられる場合があります。
+ ゼロ ETL 統合を正常に実行するには、DynamoDB 項目内の個々の属性 (名前と値で構成) が 64 KB を超えることはできません。
+ 有効化すると、ゼロ ETL 統合により、DynamoDB テーブル全体を Amazon Redshift データベースにエクスポートします。この初期プロセスが完了するまでにかかる時間は、DynamoDB テーブルのサイズによって異なります。ゼロ ETL 統合により、その後は DynamoDB から Amazon Redshift への更新が、DynamoDB の増分エクスポートを使用して段階的にレプリケートされます。つまり、Amazon Redshift にレプリケートされる DynamoDB データは、自動的に最新に保たれます。
現在、DynamoDB ゼロ ETL 統合の最小レイテンシーは 15 分です。ゼロ ETL 統合にゼロ以外の `REFRESH_INTERVAL` を設定することにより、さらに増やすことができます。詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」および「[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html)」を参照してください。
Amazon DynamoDB ソースについては、「*Amazon DynamoDB デベロッパーガイド*」の「[前提条件と制限](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB-zero-etl.html#RedshiftforDynamoDB-zero-etl-prereqs)」も参照してください。
## ゼロ ETL 統合のソースが Salesforce、SAP、ServiceNow、Zendesk などのアプリケーションである場合の考慮事項
Amazon Redshift との統合のソースが Salesforce、SAP、ServiceNow、Zendesk などのアプリケーションである場合は、次の点を考慮してください。
+ アプリケーションソースからのテーブル名と列名が 127 文字を上回る場合、これらの名前はサポートされません。
+ Amazon Redshift VARCHAR データ型の最大長は 65,535 バイトです。ソースのコンテンツがこの制限に収まらない場合、レプリケーションは実行されず、テーブルのステータスは失敗になります。データベースパラメータ `TRUNCATECOLUMNS` を `TRUE` に設定すると、列に収まるようにコンテンツを切り捨てることができます。`TRUNCATECOLUMNS` の設定の詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」と「[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html)」を参照してください。
ゼロ ETL 統合のアプリケーションソースと Amazon Redshift データベース間のデータ型の違いの詳細については、「*AWS Glue デベロッパーガイド*」の「[ゼロ ETL 統合](https://docs.aws.amazon.com/glue/latest/dg/zero-etl-using.html)」を参照してください。
+ アプリケーションとのゼロ ETL 統合の最小レイテンシーは 1 時間です。ゼロ ETL 統合にゼロ以外の `REFRESH_INTERVAL` を設定することにより、さらに増やすことができます。詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html)」および「[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html)」を参照してください。
アプリケーションとのゼロ ETL 統合のソースについては、「*AWS Glue デベロッパーガイド*」の「[ゼロ ETL 統合](https://docs.aws.amazon.com/glue/latest/dg/zero-etl-using.html)」も参照してください。
## ゼロ ETL 統合ターゲットを復元する際の考慮事項
スナップショットまたは復旧ポイントから同じサーバーレス名前空間に Amazon Redshift Serverless 名前空間を復元すると、名前空間に関連付けられたゼロ ETL 統合が自動的に維持されます。ターゲット Amazon Redshift データベース内のデータがソースと一致するように、復元後に完全な再同期が開始されます。以下の考慮事項に注意してください。
+ スナップショットを別の名前空間に復元しても、統合は維持されません。
+ 復元後、Amazon Redshift は、維持されているすべてのゼロ ETL 統合に対して完全な再同期を実行します。再同期中、データインジェストのパフォーマンスが一時的に低下する可能性があります。
+ ターゲットデータベースで履歴モードを使用する場合、スナップショットが作成されてから完全な再同期が完了するまでの間、レコードバージョンはキャプチャされません。再同期後、履歴モードでは通常のオペレーションが再開されます。この動作は、他の完全な再同期と同じです。詳細については、「[履歴モード](zero-etl-history-mode.md)」を参照してください。
+ スナップショットの作成後にゼロ ETL 統合が作成された場合、対応するデータベースがスナップショットに存在しないため、統合は復元後に `NEEDS_ATTENTION` 状態になります。これを解決するには、統合を含む最新のスナップショットから復元するか、統合を削除します。
+ スナップショットの作成後にゼロ ETL 統合が削除された場合、統合は復元されません。スナップショットのデータベースは維持されますが、削除できます。
+ スナップショットの作成後にテーブルレベルのフィルターが変更された場合、復元されたターゲットは、スナップショット作成時のフィルターではなく、統合からの現在のフィルターを使用します。
+ 復元中に統合の維持をオプトアウトするには、AWS マネジメントコンソールの復元ページの **[統合の維持]** チェックボックスをオフにします。AWS CLI を使用している場合は、[restore-from-snapshot](https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromSnapshot.html) または [restore-from-recovery-point](https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromRecoveryPoint.html) API オペレーションを呼び出すときに `--no-maintain-integration` パラメータを設定します。オプトアウトすると、統合は復元後に `FAILED` 状態になります。統合を削除して再作成できます。
+ この機能は、同じサーバーレス名前空間に復元された場合にのみ Amazon Redshift Serverless に適用されます。プロビジョニングされたクラスターのスナップショット復元では、ゼロ ETL 統合は維持されません。