Amazon Redshift ne prendra plus en charge l'utilisation des UDF Python après le 30 juin 2026. Nous allons commencer à l'appliquer par étapes. Pour plus d'informations sur les détails de la fin de vie de Python et des options de migration, consultez le billet de blog publié le 30 juin 2025.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Fonctionnalités d'Apache Iceberg v3 dans Amazon Redshift

Amazon Redshift prend en charge les tables Apache Iceberg v3. Iceberg v3 introduit les valeurs de colonne par défaut, le suivi du lignage des lignes et les vecteurs de suppression. Vous pouvez créer de nouvelles tables v3 ou mettre à niveau les tables v2 existantes vers la v3.

Les tables Iceberg v3 utilisent la même syntaxe SQL pour les requêtes et les opérations DML (INSERT, DELETE, UPDATE, MERGE) que les tables v2. Les fonctionnalités décrites sur cette page sont spécifiques à Iceberg v3.

Création d'une table Iceberg v3

Pour créer une table Iceberg v3, spécifiez 'format-version'='3' dans la clause TABLE PROPERTIES :

CREATE TABLE external_schema.table_name (
  column_name data_type [DEFAULT literal_value] [, ...]
)
USING ICEBERG
LOCATION 's3://your-bucket-name/prefix/'
[PARTITIONED BY [[column_name | transform_function]], ...]
TABLE PROPERTIES ('format-version'='3'
    [, 'compression_type'='compression_value']);

Exemple :

CREATE TABLE my_schema.orders (
  id int,
  status varchar DEFAULT 'pending',
  priority int DEFAULT 0
)
USING ICEBERG
LOCATION 's3://amzn-s3-demo-bucket/orders/'
TABLE PROPERTIES ('format-version'='3');

Si vous ne spécifiez pas de format-version, Amazon Redshift crée la table sous la forme Iceberg v2.

Mise à niveau de la v2 vers la v3

Vous pouvez mettre à niveau une table Iceberg v2 existante vers la v3 :

ALTER TABLE iceberg_table
SET TABLE PROPERTIES ('format-version' = '3');

La mise à niveau de la version du format est une opération qui ne concerne que les métadonnées. Les fichiers de données existants ne sont pas réécrits. Les fichiers de suppression positionnelle v2 existants restent valides et sont appliqués pendant les lectures. La première opération d'écriture après une mise à niveau génère des valeurs de lignage de lignes pour l'ensemble de la table. Lors des opérations DELETE, UPDATE ou MERGE suivantes, Amazon Redshift fusionne les suppressions positionnelles de la v2 en vecteurs de suppression pour les fichiers de données concernés par l'opération.

Limitations

Valeurs de colonne par défaut

Les valeurs de colonne par défaut ne sont prises en charge que pour les tables Iceberg v3. Amazon Redshift renvoie une erreur si vous spécifiez une valeur par défaut dans une table Iceberg v2.

Les valeurs par défaut indiquent une valeur littérale à laquelle une colonne revient lorsqu'aucune valeur explicite n'est présente. Vous pouvez ainsi ajouter de nouvelles colonnes à une table existante sans avoir à réécrire les fichiers de données. Les lectures de fichiers de données précédemment écrits renvoient automatiquement la valeur par défaut pour la nouvelle colonne. La valeur par défaut est également écrite lorsqu'une instruction DML omet la colonne ou spécifie DEFAULT comme valeur.

Seules les valeurs littérales sont prises en charge par défaut. Les types de données imbriqués ne prennent pas en charge les valeurs par défaut.

CREATE TABLE AS SELECT n'hérite pas des valeurs de colonne par défaut de la table source. Pour définir les valeurs par défaut de la nouvelle table, utilisez ALTER TABLE ALTER COLUMN SET DEFAULT après la création.

Définition des valeurs par défaut lors de la création de la table

CREATE TABLE external_schema.table_name (
  column_name data_type DEFAULT literal_value [, ...]
)
USING ICEBERG
LOCATION '...'
TABLE PROPERTIES ('format-version'='3');

Ajouter une colonne avec une valeur par défaut

ALTER TABLE iceberg_table
ADD COLUMN column_name data_type DEFAULT literal_value;

Les fichiers de données existants renvoient la valeur par défaut pour la colonne nouvellement ajoutée sans nécessiter de réécriture des données.

Modifier ou supprimer une valeur par défaut

ALTER TABLE iceberg_table
ALTER COLUMN column_name SET DEFAULT literal_value;

ALTER TABLE iceberg_table
ALTER COLUMN column_name DROP DEFAULT;

SET DEFAULT modifie la valeur par défaut d'une colonne existante. La nouvelle valeur par défaut s'applique aux fichiers de données écrits après la modification. Les fichiers de données existants continuent d'utiliser la valeur par défaut précédente.

DROP DEFAULT supprime la valeur par défaut d'une colonne. Après cette opération, les nouvelles écritures n'appliquent plus de valeur par défaut à la colonne. Les fichiers de données qui ne contiennent pas la colonne continuent de renvoyer la valeur par défaut initiale de la colonne.

Comportement INSERT

Lorsque vous insérez des lignes sans spécifier de colonne ayant une valeur par défaut, la valeur par défaut est écrite dans le fichier de données.

SHOW TABLE

SHOW TABLE affiche les valeurs par défaut dans sa sortie.

Lignage des lignes

Le lignage des lignes n'est pris en charge que pour les tables Iceberg v3. Il fournit deux pseudo-colonnes qui suivent l'identité des lignes et l'historique des modifications. Ces colonnes sont gérées automatiquement par Amazon Redshift. Vous ne définissez pas leurs valeurs.

Pseudo-columns

Interrogation du lignage des lignes

Les colonnes de lignage des lignes doivent être nommées explicitement dans la liste SELECT. Ils ne sont pas inclus dans SELECT *.

SELECT _row_id, _last_updated_sequence_number, *
FROM my_schema.my_iceberg_v3_table;

Vous pouvez utiliser des colonnes de lignage de lignes dans les clauses WHERE, ORDER BY, GROUP BY et JOIN :

SELECT *
FROM my_schema.my_iceberg_v3_table
WHERE _last_updated_sequence_number >= 3
ORDER BY _row_id;

Comportement sur les tables non v3

Lorsque vous interrogez une table non-Iceberg v3, _row_id et _last_updated_sequence_number renvoyez NULL.

Comportement après la mise à niveau de la version 2 vers la v3

Pour les tables mises à niveau d'Iceberg v2 vers v3, les valeurs de lignage des lignes ne sont pas immédiatement disponibles pour les données antérieures à la mise à niveau. Les deux _row_id et _last_updated_sequence_number renvoyez NULL jusqu'à la première opération d'écriture après la mise à niveau, qui génère des valeurs de lignage de lignes pour l'ensemble de la table. Cette opération ne concerne que les métadonnées et ne réécrit pas les fichiers de données existants.

Comportement d'écriture

Le lignage des lignes est automatiquement renseigné par Amazon Redshift pour toutes les opérations d'écriture (INSERT, CTAS, UPDATE, MERGE). Chaque ligne reçoit un numéro unique _row_id et _last_updated_sequence_number reflète le numéro de séquence de l'instantané du commit qui a écrit la ligne.

Limitations

Vecteurs de suppression

Les vecteurs de suppression sont le mécanisme utilisé par Iceberg v3 pour suivre les suppressions au niveau des lignes. Ils remplacent les fichiers de suppression positionnelle utilisés par Iceberg v2.

Lorsque vous exécutez DELETE, UPDATE ou MERGE sur une table Iceberg v3, Amazon Redshift enregistre les positions des lignes supprimées dans des vecteurs de suppression au lieu d'écrire des fichiers de suppression positionnels distincts. Ceci est géré automatiquement. Aucune modification de la syntaxe SQL n'est requise.

Comment fonctionnent les vecteurs de suppression

Un vecteur de suppression est un bitmap compressé qui enregistre les positions de lignes supprimées dans un fichier de données. Les vecteurs de suppression sont stockés dans des fichiers Puffin au même emplacement S3 que les données de la table. Chaque fichier de données possède au plus un vecteur de suppression.

Lors de la lecture d'un tableau Iceberg v3, Amazon Redshift applique automatiquement des vecteurs de suppression pour exclure les lignes supprimées des résultats des requêtes.

Avantages par rapport à la suppression positionnelle de fichiers

Comportement après la mise à niveau de la version 2 vers la v3

Après la mise à niveau d'une table d'Iceberg v2 vers la v3, les fichiers de suppression positionnelle v2 existants restent valides et sont appliqués lors des lectures. Lors des opérations d'écriture suivantes (DELETE, UPDATE ou MERGE), Amazon Redshift fusionne les suppressions positionnelles v2 existantes dans des vecteurs de suppression, comme défini par la spécification Iceberg.

Limitations