Amazon Redshift ne prendra plus en charge la création de nouveaux UDFs Python à partir du patch 198. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement jusqu’au 30 juin 2026. Pour plus d’informations, consultez le billet de blog .

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.

Référencement des tables Iceberg dans Amazon Redshift

Amazon Redshift propose plusieurs méthodes pour référencer les tables Apache Iceberg stockées dans votre lac de données. Vous pouvez utiliser des schémas externes pour créer des références aux bases de données du catalogue de données contenant des tables Iceberg, ou utiliser une notation en trois parties pour accéder directement aux catalogues montés automatiquement.

Utilisation de schémas externes pour référencer les tables Iceberg

Les schémas externes permettent de référencer les tables de votre catalogue de données depuis Amazon Redshift. Lorsque vous créez un schéma externe, vous établissez une connexion entre votre base de données Amazon Redshift et une base de données Data Catalog spécifique qui contient vos tables Iceberg.

Pour créer un schéma externe pour les tables Iceberg :

CREATE EXTERNAL SCHEMA schema_name
FROM DATA CATALOG
DATABASE 'glue_database_name'
IAM_ROLE 'arn:aws:iam::account-id:role/role-name';

Après avoir créé le schéma externe, vous pouvez interroger les tables Iceberg à l'aide d'une notation en deux parties :

SELECT * FROM schema_name.iceberg_table_name;

Vous pouvez également associer des tables Iceberg à des tables Amazon Redshift locales :

SELECT r.customer_id, i.order_date, r.customer_name
FROM local_customers r
JOIN schema_name.iceberg_orders i 
ON r.customer_id = i.customer_id;

Utilisation de la notation en trois parties avec des catalogues montés automatiquement

Three-part la notation vous permet de référencer directement des tables dans des catalogues montés automatiquement sans créer de schémas externes. Cette méthode est particulièrement utile lorsque vous travaillez avec des compartiments de table Amazon S3 fédérés avec. AWS Lake Formation Pour plus d'informations sur la configuration du montage automatique du catalogue de données, consultez Simplifier l'accès aux objets externes dans Amazon Redshift à l'aide du montage automatique du. AWS Glue Data Catalog

La syntaxe de la notation en trois parties est la suivante :

"catalog_name".database_name.table_name

Par exemple, pour interroger une table Iceberg dans un catalogue de tables Amazon S3 monté automatiquement :

SELECT * FROM "my_table_bucket@s3tablescatalog".my_database.my_iceberg_table;

Pour plus d'informations sur l'intégration des compartiments de tables Amazon S3 à Amazon Redshift, consultez la section Intégration des tables S3 à Amazon Redshift dans le guide de l'utilisateur Amazon S3.

Vous pouvez également référencer des tables dans le catalogue racine monté automatiquementawsdatacatalog, qui fournit un accès direct aux bases de données et aux tables enregistrées dans AWS Glue Data Catalog :

SELECT * FROM awsdatacatalog.my_database.my_iceberg_table;

Pour plus d'informations sur l'utilisation du catalogue awsdatacatalog racine, consultez les sections Querying the AWS Glue Data Catalog dans le Amazon Redshift Management Guide et Managing Data Catalog namespaces dans AWS Lake Formation le Guide du développeur.

Vous pouvez également utiliser l'USEinstruction pour définir un catalogue et une base de données par défaut pour les compartiments de tables Amazon S3 :

USE "my_table_bucket@s3tablescatalog".my_database;
SELECT * FROM my_iceberg_table;

Pour définir un chemin de recherche pour la résolution du schéma avec les buckets de tables Amazon S3, procédez comme suit :

USE "my_table_bucket@s3tablescatalog";
SET search_path TO my_database;
SELECT * FROM my_iceberg_table;

Bonnes pratiques pour référencer les tables Iceberg

Une table Apache Iceberg est une entité logique unique composée de plusieurs fichiers : un fichier de métadonnées racine (metadata.json), des listes de manifestes, des fichiers manifestes et des fichiers de données (généralement .parquet). Le fichier de métadonnées racine sert de point d'entrée et contient des références à tous les autres fichiers composant la table. Lorsque vous accordez à Amazon Redshift l'accès à une table Iceberg, Amazon Redshift utilise le fichier de métadonnées racine pour découvrir et lire tous les fichiers de données référencés. Si Amazon Redshift a accès au fichier de métadonnées racine, il suppose et exige également l'accès à tous les fichiers de données sous-jacents. Cela est conforme à la conception d'Iceberg, où l'accès au niveau de la table est l'unité d'autorisation prévue.

Pour améliorer les performances des requêtes, Amazon Redshift met en cache les fichiers de métadonnées Iceberg (y compris le fichier de métadonnées racine, les listes de manifestes et les fichiers de manifeste) en mémoire. Le fichier de métadonnées racine (metadata.json) est revalidé par rapport à Amazon S3 selon un intervalle configurable (TTL). Une fois le TTL expiré, Amazon Redshift exécute une demande Amazon S3 HEAD sur le fichier de métadonnées racine afin de vérifier que le rôle IAM y a toujours accès et que le fichier n'a pas été modifié. Si la vérification des autorisations échoue ou si le fichier a changé, l'entrée mise en cache est supprimée et les métadonnées sont extraites à nouveau d'Amazon S3. Le fichier de métadonnées racine étant le point d'entrée pour tous les accès aux tables, cette revalidation sert de porte d'autorisation pour l'ensemble de la table. Les listes de manifestes et les fichiers de manifestes sont mis en cache sans revalidation TTL indépendante ; leur validité d'accès est dérivée de la vérification des autorisations des métadonnées racine. Cela signifie que si vous révoquez les autorisations Amazon S3 sur une table Iceberg, les requêtes peuvent continuer à aboutir pendant un maximum de 2 minutes tout en utilisant les métadonnées mises en cache.

Amazon Redshift valide régulièrement l'accès au fichier de métadonnées racine mis en cache, mais ne valide ni n'assure la cohérence entre les autorisations au niveau des métadonnées et au niveau du fichier de données dans votre compartiment Amazon S3. Il est de la responsabilité du client de s'assurer que les autorisations sont appliquées de manière cohérente dans tous les fichiers constituant une table Iceberg.

Pour éviter cela, prenez en compte les meilleures pratiques suivantes lorsque vous référencez des tables Iceberg dans Amazon Redshift :

Modèles de référencement courants

Les exemples suivants illustrent les modèles courants de référencement des tables Iceberg :

Agrégation des données dans plusieurs tables Iceberg :

SELECT 
    region,
    SUM(sales_amount) as total_sales,
    COUNT(*) as transaction_count
FROM data_lake.sales_transactions
WHERE transaction_date >= '2024-01-01'
GROUP BY region
ORDER BY total_sales DESC;

Joindre des tables Iceberg à des tables Amazon Redshift locales :

SELECT 
    c.customer_name,
    c.customer_tier,
    SUM(o.order_amount) as total_orders
FROM customers c
JOIN data_lake.order_history o ON c.customer_id = o.customer_id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY c.customer_name, c.customer_tier;

Utilisation de la notation en trois parties avec des requêtes complexes :

WITH recent_orders AS (
    SELECT customer_id, order_date, order_amount
    FROM "analytics_bucket@s3tablescatalog".ecommerce.orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '7 days'
)
SELECT 
    customer_id,
    COUNT(*) as order_count,
    AVG(order_amount) as avg_order_value
FROM recent_orders
GROUP BY customer_id
HAVING COUNT(*) > 1;