Données semi-structurées dans Amazon Redshift - Amazon Redshift
Bonnes pratiques pour travailler avec des données semi-structuréesConcepts pour l’utilisation des types de données SUPER Considérations relatives à l'utilisation de données de type SUPER

Amazon Redshift ne prendra plus en charge la création de nouveaux Python UDFs à compter du 1er novembre 2025. Si vous souhaitez utiliser Python UDFs, créez la version UDFs antérieure à cette date. Le Python existant UDFs continuera à fonctionner normalement. 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.

Données semi-structurées dans Amazon Redshift

En utilisant la prise en charge des données semi-structurées dans Amazon Redshift, vous pouvez ingérer et stocker des données semi-structurées dans vos entrepôts de données Amazon Redshift. En utilisant le type de données SUPER et le langage PartiQL, Amazon Redshift étend les capacités de l’entrepôt des données pour s’intégrer aux sources de données SQL et NoSQL. Amazon Redshift permet ainsi d'effectuer des analyses efficaces sur les données stockées relationnelles et semi-structurées telles que le JSON. Pour plus d'informations sur l'intégration d'Amazon Redshift à partiQL, consultez. partiQL : langage de requête compatible avec SQL pour Amazon Redshift

Amazon Redshift propose deux formes de support de données semi-structurées : le type de données SUPER et Amazon Redshift Spectrum.

Vous pouvez interroger des données semi-structurées en les ingérant dans Amazon Redshift et en les stockant dans le type de données SUPER ou en utilisant Amazon Redshift Spectrum pour interroger les données stockées dans Amazon S3.

Bonnes pratiques pour travailler avec des données semi-structurées

Tenez compte des meilleures pratiques suivantes lorsque vous travaillez avec des données semi-structurées.

  • Nous vous recommandons de définir les options de enable_case_sensitive_identifier configuration enable_case_sensitive_super_attribute et sur true lorsque vous travaillez avec des données SUPER. Pour plus d’informations, consultez enable_case_sensitive_super_attribute et enable_case_sensitive_identifier.

  • Utilisez la commande COPY pour charger les données des compartiments Amazon S3 dans les colonnes Amazon Redshift SUPER.

  • Utilisez le typage dynamique PartiQL et une sémantique laxiste pour exécuter des requêtes ad hoc sur des valeurs de données SUPER sans avoir à imposer de schéma avant de lancer des requêtes. Pour plus d'informations sur la saisie dynamique, voirTypage dynamique. Pour plus d'informations sur la sémantique laxiste, voir. Sémantique laxiste

  • Déchiquetez les données sans schéma et semi-structurées en vues matérialisées à l'aide de partiQL si vous prévoyez d'interroger fréquemment les données. Lorsque vous effectuez des analyses sur les données fragmentées, l’organisation en colonnes des vues matérialisées Amazon Redshift offre de meilleures performances. En outre, les utilisateurs et les outils de Business Intelligence (BI) qui exigent un schéma conventionnel pour les données ingérées peuvent utiliser des vues (matérialisées ou virtuelles) comme présentation conventionnelle des données.

    Une fois que vos vues matérialisées PartiQL ont extrait les données trouvées dans JSON ou SUPER dans des vues matérialisées en colonnes conventionnelles, vous pouvez interroger les vues matérialisées. Pour plus d'informations sur les vues matérialisées, consultezVues matérialisées dans Amazon Redshift. Pour plus d’informations sur le fonctionnement du type de données SUPER avec les vues matérialisées, consultez Type de données SUPER et vues matérialisées.

Concepts pour l’utilisation des types de données SUPER

Vous trouverez ci-après quelques concepts de types de données Amazon Redshift SUPER.

Comprendre le type de données SUPER dans Amazon Redshift – Le type de données SUPER est un type de données Amazon Redshift qui permet le stockage de tableaux et de structures sans schéma qui contiennent des scalaires Amazon Redshift et éventuellement des tableaux et structures imbriqués. Le type de données SUPER peut stocker nativement différents formats de données semi-structurées, tels que le JSON ou des données provenant de sources orientées document. Vous pouvez ajouter une nouvelle colonne SUPER pour stocker des données semi-structurées et écrire des requêtes qui accèdent à la colonne SUPER, ainsi qu'aux colonnes scalaires habituelles. Pour plus d’informations sur le type de données SUPER, consultez Type SUPER.

Ingérer du JSON sans schéma dans SUPER — Grâce au type de données SUPER semi-structuré flexible, Amazon Redshift peut recevoir et ingérer du JSON sans schéma dans des colonnes contenant le type de données SUPER. Par exemple, vous pouvez ingérer la valeur JSON [10.5, “first”] dans une colonne de type de données SUPER à l'aide de la commande COPY. La colonne contiendrait une valeur SUPER de[10.5, ‘first’]. Vous pouvez également ingérer du JSON en utilisantFonction JSON_PARSE. COPY et json_parse ingèrent tous deux JSON en utilisant une sémantique d’analyse stricte par défaut. Vous pouvez également construire des valeurs SUPER, y compris des tableaux et des structures, en utilisant les données de base de données elles-mêmes.

La colonne SUPER ne nécessite aucune modification du schéma lors de l'ingestion des structures flexibles du JSON sans schéma. Par exemple, lors de l’analyse d’un flux de clics, vous stockez d’abord dans la colonne SUPER des structures « click » avec les attributs « IP » et « time ». Vous pouvez ajouter un attribut « ID client » sans modifier votre schéma afin d’ingérer de telles modifications.

Le format natif utilisé pour le type de données SUPER est un format binaire qui nécessite moins d'espace que la valeur JSON sous forme textuelle. Cela permet d’accélérer l’ingestion et le traitement en cours d’exécution des valeurs SUPER lors des requêtes.

Interrogez les données SUPER avec partiQL — partiQL est une extension rétrocompatible de SQL-92 que de nombreux services utilisent actuellement. AWS Grâce à l'utilisation de partiQL, les constructions SQL habituelles combinent de manière fluide l'accès aux données SQL tabulaires classiques et aux données semi-structurées de SUPER. Vous pouvez effectuer la navigation dans les objets et les tableaux et désimbriquer les tableaux. PartiQL étend le langage SQL standard pour exprimer et traiter de manière déclarative les données imbriquées et multivaluées.

PartiQL est une extension de SQL où les données imbriquées et non schématiques des colonnes SUPER sont des citoyens de première classe. PartiQL n’exige pas que toutes les expressions de requêtes soient vérifiées par type lors de la compilation de la requête. Cette approche permet aux expressions de requêtes qui contiennent le type de données SUPER d’être typées dynamiquement pendant l’exécution de la requête lorsque les types réels des données contenues dans les colonnes SUPER sont accédés. De plus, PartiQL fonctionne dans un mode laxiste dans lequel les incohérences de type ne provoquent pas d’échecs, mais renvoient null. La combinaison d'un traitement des requêtes sans schéma et laxiste rend partiQL idéal pour les applications d'extraction, de chargement, de transformation (ELT) dans lesquelles votre requête SQL évalue les données JSON ingérées dans les colonnes SUPER.

Pour plus d'informations sur PartiQL pour Amazon Redshift, consultez. partiQL : langage de requête compatible avec SQL pour Amazon Redshift Pour plus d'informations sur la saisie dynamique, voirTypage dynamique. Pour plus d'informations sur le traitement laxiste des requêtes, consultezSémantique laxiste.

Intégration avec Redshift Spectrum – Amazon Redshift prend en charge plusieurs aspects de PartiQL lors de l’exécution de requêtes Redshift Spectrum sur JSON, Parquet et d’autres formats comportant des données imbriquées. Redshift Spectrum ne supporte que les données imbriquées qui ont des schémas. Par exemple, avec Redshift Spectrum, vous pouvez déclarer que vos données JSON possèdent l'attribut nested_schemaful_example dans le schéma. ARRAY<STRUCT<a:INTEGER, b:DECIMAL(5,2)>> Le schéma de cet attribut détermine que les données contiennent toujours un tableau, qui contient une structure avec un nombre entier a et un nombre décimal b. Si les données changent pour inclure plus d’attributs, le type change également. En revanche, le type de données SUPER ne nécessite aucun schéma. Vous pouvez stocker des tableaux avec des éléments de structure ayant des attributs ou des types différents. Les valeurs peuvent également être stockées en dehors des tableaux.

Considérations relatives à l'utilisation de données de type SUPER

Lorsque vous travaillez avec des données SUPER, tenez compte des points suivants :

Pour plus d’informations sur les configurations SUPER, consultez Configurations SUPER.