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.
Ingestion et interrogation de 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 des 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. Ainsi, Amazon Redshift permet des analyses efficaces sur des données relationnelles et semi-structurées stockées telles que JSON.
Amazon Redshift offre deux formes de prise en charge des données semi-structurées : le type de données SUPER et Amazon Redshift Spectrum.
Utilisez le type de données SUPER si vous devez insérer ou mettre à jour de petits lots de données JSON avec une faible latence. Utilisez également SUPER lorsque votre requête nécessite une cohérence forte, des performances de requête prévisibles, une prise en charge des requêtes complexes et une facilité d’utilisation avec des schémas évolutifs et des données sans schéma.
En revanche, utilisez Amazon Redshift Spectrum avec un format de fichier ouvert si votre requête de données nécessite une intégration avec AWS d'autres services et avec des données principalement stockées dans Amazon S3 à des fins d'archivage.
Cas d’utilisation pour le type de données SUPER
La prise en charge des données semi-structurées à l’aide du type de données SUPER dans Amazon Redshift offre des performances, une flexibilité et une facilité d’utilisation supérieures. Les cas d’utilisation suivants aident à illustrer comment utiliser un support de données semi-structurées avec SUPER.
Insertion rapide et flexible de données JSON – Amazon Redshift prend en charge les transactions rapides qui peuvent analyser JSON et le stocker sous forme de valeur SUPER. Les transactions d’insertion peuvent opérer jusqu’à cinq fois plus vite que les mêmes insertions dans des tables qui ont fragmenté les attributs de SUPER en colonnes conventionnelles. Par exemple, supposons que le JSON entrant soit de la forme {« a » :…, « b » :…, « c » :..., etc.}. Vous pouvez considérablement accélérer les performances d’insertion en stockant le JSON entrant dans une table TJ avec une seule colonne SUPER S, au lieu de le stocker dans une table conventionnelle TR avec des colonnes « a », « b », « c », et ainsi de suite. Lorsqu’il y a des centaines d’attributs dans le JSON, l’avantage de performances du type de données SUPER devient substantiel.
En outre, le type de données SUPER n’a pas besoin d’un schéma régulier. Vous n’avez pas besoin d’analyser et de nettoyer le JSON entrant avant de le stocker. Par exemple, supposons qu’un fichier JSON entrant possède un attribut « c » de type chaîne de caractères et d’autres qui possèdent un attribut « c » de type entier, sans le type de données SUPER. Dans ce cas, vous devez soit séparer les colonnes c_string et c_int, soit nettoyer les données. En revanche, avec le type de données SUPER, toutes les données JSON sont stockées pendant l’ingestion sans perte d’informations. Plus tard, vous pouvez utiliser l’extension PartiQL de SQL pour analyser les informations.
Requêtes flexibles pour découverte – Après avoir stocké vos données semi-structurées (telles que JSON) dans une valeur de données SUPER, vous pouvez les interroger sans imposer de schéma. Vous pouvez utiliser le typage dynamique et la sémantique laxiste de PartiQL pour exécuter vos requêtes et découvrir les données profondément imbriquées dont vous avez besoin, sans avoir à imposer un schéma avant la requête.
Requêtes flexibles pour les opérations d’extraction, de chargement, de transformation (ETL) en vues matérialisées conventionnelles – Après avoir stocké vos données non schématiques et semi-structurées dans SUPER, vous pouvez utiliser les vues matérialisées PartiQL pour introspecter les données et les fragmenter en vues matérialisées.
Les vues matérialisées avec les données fragmentées sont un bon exemple d’avantages en termes de performances et de convivialité pour vos cas d’analyse classiques. 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 le fonctionnement du type de données SUPER avec les vues matérialisées, consultez Utilisation du type de données SUPER avec des vues matérialisées.
Vous pouvez appliquer des politiques de masquage dynamique des données aux valeurs scalar figurant sur les chemins des colonnes de type SUPER. Pour plus d’informations sur le masquage dynamique des données, consultez Masquage dynamique des données. Pour plus d’informations sur l’utilisation du masquage dynamique des données avec le type de données SUPER, consultez Utilisation du masquage dynamique des données avec des chemins de type de données SUPER (version préliminaire).
Pour plus d’informations sur le type de données SUPER, consultez Type SUPER.
Pour obtenir des exemples de l’utilisation du type de données SUPER, consultez les sous-sections de cette rubrique, en commençant par Jeu de données échantillon SUPER.
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 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 que les colonnes scalaires habituelles. Pour plus d’informations sur le type de données SUPER, consultez Type SUPER.
Ingérer JSON sans schéma dans SUPER – Grâce à la souplesse du type de données semi-structurées SUPER, Amazon Redshift peut recevoir et intégrer des JSON sans schéma dans une valeur SUPER. Par exemple, Amazon Redshift peut ingérer la valeur JSON [10.5, « first »] dans une valeur SUPER [10.5, « first »], c’est-à-dire un tableau contenant un decimal 10.5 et un varchar « first » Amazon Redshift. Amazon Redshift peut ingérer le JSON dans une valeur SUPER en utilisant l’instruction COPY ou la fonction JSON parse, telle que json_parse(’[10.5, « first »]’). 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 de schéma lors de l’ingestion des structures irrégulières de 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 sa 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 à PartiQL, les constructions SQL familières combinent de manière transparente l’accès aux données SQL classiques, sous forme de tableaux, 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 du traitement des requêtes sans schéma et laxiste rend PartiQL idéal pour les applications d’extraction, de chargement et de transfert (ELT) pour lesquelles votre requête SQL évalue les données JSON qui sont ingérées dans les colonnes SUPER.
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 ont un attribut nested_schemaful_example dans un 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. En outre, certaines valeurs peuvent être stockées en dehors des tableaux.
Pour plus d’informations sur les fonctions prenant en charge le type de données SUPER, consultez les rubriques suivantes :
Considérations relatives aux données Super
Lorsque vous travaillez avec des données SUPER, tenez compte des points suivants :
Utilisez le pilote JDBC version 1.2.50, le pilote ODBC version 1.4.17 ou ultérieure, et le pilote Amazon Redshift Python version 2.0.872 ou ultérieure.
Pour plus d’informations sur les pilotes JDBC, consultez Configuration d’une connexion JDBC.
Pour plus d’informations sur les pilotes ODBC, consultez Configuration d’une connexion ODBC.
Retrouvez les exemples de schémas utilisés dans les rubriques suivantes à l’adresse Jeu de données échantillon SUPER.
Tous les exemples de code SQL utilisés dans les rubriques suivantes sont inclus avec le même préfixe S3 pour le téléchargement. Ceux-ci comprennent le langage de définition de données (DDL) et les instructions COPY, ainsi que certaines requêtes modifiées TPC-H qui fonctionnent avec SUPER.
Pour afficher ou télécharger les fichiers SQL, procédez de l’une des manières suivantes :
Téléchargez le fichier SQL du tutoriel SUPER
et le fichier TPC-H . En utilisant la CLI Amazon S3, exécutez la commande suivante. Vous pouvez utiliser votre propre chemin d’accès.
aws s3 cp s3://redshift-downloads/semistructured/tutorialscripts/semistructured-tutorial.sql /target/path aws s3 cp s3://redshift-downloads/semistructured/tutorialscripts/super_tpch_queries.sql /target/path
Pour plus d’informations sur les configurations SUPER, consultez Configurations SUPER.
