Sources de données prises en charge pour l'exploration - AWS Glue

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.

Sources de données prises en charge pour l'exploration

Des crawlers peuvent analyser les magasins de données basés sur les fichiers et sur les tables suivants.

Type d'accès utilisé par l'crawler Magasins de données
Client en mode natif

  • Amazon Simple Storage Service (Amazon S3)

  • Amazon DynamoDB

  • Delta Lake 2.0.x

  • Apache Iceberg 1.5

  • Apache Hudi 0.14
JDBC

Amazon Redshift

Snowflake

Au sein d'Amazon Relational Database Service (RDSAmazon) ou en externe à Amazon RDS :

  • Amazon Aurora

  • MariaDB

  • Microsoft SQL Server

  • Mon SQL

  • Oracle

  • Poster SQL
Client MongoDB

  • MongoDB

  • Atlas MongoDB

  • Amazon DocumentDB (compatible avec MongoDB)
Note

Actuellement, AWS Glue ne prend pas en charge les crawlers pour les flux de données.

Pour les magasins de données MongoDBJDBC, MongoDB Atlas et Amazon DocumentDB (compatibles avec MongoDB), vous devez spécifier une AWS Glue connexion que le robot d'exploration peut utiliser pour se connecter au magasin de données. Pour Amazon S3, vous pouvez éventuellement spécifier une connexion de type Network (Réseau). Une connexion est un objet de catalogue de données qui stocke des informations de connexion, telles que les informations d'identificationURL, les informations Amazon Virtual Private Cloud, etc. Pour de plus amples informations, veuillez consulter Connexion aux données.

Les versions des pilotes prises en charge par le robot d'exploration sont les suivantes :

Produit (langue française non garantie) pilote compatible avec Crawler
Poster SQL 42.2.1
Amazon Aurora Identique aux pilotes de crawler natifs
MariaDB 8.0.13
Microsoft SQL Server 6.1.0
Mon SQL 8.0.13
Oracle 11.2.2
Amazon Redshift 4.1
Snowflake 3,13,20
MongoDB 4.7.2
Atlas MongoDB 4.7.2

Voici quelques remarques sur les différents magasins de données.

Amazon S3

Vous pouvez choisir d'explorer un chemin dans votre compte ou dans un autre compte. Si tous les fichiers Amazon S3 d'un dossier ont le même schéma, l'crawler crée une table. De plus, si l'objet Amazon S3 est partitionné, une seule table de métadonnées est créée et les informations de partition sont ajoutées à Data Catalog pour cette table.

Amazon S3 et Amazon DynamoDB

Les robots d'exploration utilisent un rôle AWS Identity and Access Management (IAM) pour obtenir l'autorisation d'accéder à vos magasins de données. Le rôle que vous transmettez à l'crawler doit avoir l'autorisation d'accéder aux chemins Amazon S3 et aux tables Amazon DynamoDB analysés.

Amazon DynamoDB

Lorsque vous définissez un crawler à l'aide de la console AWS Glue, vous spécifiez une table DynamoDB. Si vous utilisez le AWS GlueAPI, vous pouvez spécifier une liste de tables. Vous pouvez choisir d'analyser un petit échantillon des données uniquement pour réduire les temps d'exécution de l'crawler.

Delta Lake

Pour chaque magasin de données Delta Lake, vous précisez comment créer les tables Delta :

  • Créer des tables natives : permettre l'intégration avec les moteurs de requêtes qui prennent directement en charge l'interrogation du journal de transactions Delta. Pour plus d'informations, veuillez consulter la rubrique Interrogation des tables Delta Lake.

  • Créer des tables avec des liens symboliques : créer un dossier _symlink_manifest avec les fichiers manifestes partitionnés par les clés de partition, en fonction des paramètres de configuration spécifiés.

Iceberg

Pour chaque magasin de données Iceberg, vous spécifiez un chemin Amazon S3 qui contient les métadonnées de vos tables Iceberg. Si le Crawler découvre des métadonnées de table Iceberg, il les enregistre dans le catalogue de données. Vous pouvez définir un calendrier pour que le Crawler mette à jour les tables.

Vous pouvez définir les paramètres suivants pour le magasin de données :

  • Exclusions : permet d'ignorer certains dossiers.

  • Profondeur maximale d'indexation : définit la limite de profondeur que le Crawler peut indexer dans votre compartiment Amazon S3. La profondeur maximale d'indexation par défaut est de 10 et la profondeur maximale que vous pouvez définir est de 20.

Hudi

Pour chaque magasin de données Hudi, vous spécifiez un chemin Amazon S3 qui contient les métadonnées de vos tables Hudi. Si le Crawler découvre des métadonnées de table Hudi, il les enregistre dans le catalogue de données. Vous pouvez définir un calendrier pour que le Crawler mette à jour les tables.

Vous pouvez définir les paramètres suivants pour le magasin de données :

  • Exclusions : permet d'ignorer certains dossiers.

  • Profondeur maximale d'indexation : définit la limite de profondeur que le Crawler peut indexer dans votre compartiment Amazon S3. La profondeur maximale d'indexation par défaut est de 10 et la profondeur maximale que vous pouvez définir est de 20.

Note

Les colonnes d'horodatage avec millis en tant que types logiques seront interprétées comme bigint, en raison d'une incompatibilité avec Hudi 0.13.1 et les types d'horodatage. Une solution pourrait être fournie dans la prochaine version de Hudi.

Les tables Hudi sont classées comme suit, avec des implications spécifiques pour chacune d'entre elles :

  • Copie sur écriture (CoW) : les données sont stockées dans un format en colonnes (Parquet) et chaque mise à jour crée une version des fichiers lors d'une écriture.

  • Fusion sur lecture (MoR) : les données sont stockées à l'aide d'une combinaison des formats en colonnes (Parquet) et basés sur les lignes (Avro). Les mises à jour sont consignées dans des fichiers delta basés sur les lignes et sont compressées si nécessaire pour créer de nouvelles versions des fichiers en colonnes.

Avec les ensembles de données CoW, chaque fois qu'une mise à jour est apportée à un enregistrement, le fichier qui contient l'enregistrement est réécrit avec les valeurs mises à jour. Avec un jeu de données MoR, chaque fois qu'une mise à jour a lieu, Hudi écrit uniquement la ligne du registre modifié. Le type de stockage MoR est mieux adapté aux charges de travail donnant lieu à de nombreuses écritures ou modifications avec moins de lectures. Le type de stockage CoW est mieux adapté aux charges de travail lourdes en lecture sur des données qui changent moins fréquemment.

Hudi propose trois types de requêtes pour accéder aux données :

  • Requêtes d'instantané : requêtes qui affichent le dernier instantané de la table à partir d'une action de validation ou de compactage donnée. Pour les tables MoR, les requêtes d'instantané exposent l'état le plus récent de la table en fusionnant les fichiers de base et delta de la dernière tranche de fichiers au moment de la requête.

  • Requêtes progressives : les requêtes ne portent que sur les nouvelles données écrites dans la table, depuis une validation/un compactage donné. Cela fournit efficacement des flux de modifications pour activer les pipelines de données (Data Pipelines) progressives.

  • Requêtes à lecture optimisée : pour les tables MoR, les requêtes portent sur les dernières données compactées. Pour les tables CoW, les requêtes portent sur les dernières données validées.

Pour les tables Copy-On-Write, les robots créent une seule table dans le catalogue de données avec le serde. ReadOptimized org.apache.hudi.hadoop.HoodieParquetInputFormat

Pour les tables Fusion sur lecture, le Crawler crée deux tables dans le catalogue de données pour le même emplacement de table :

  • Une table avec un suffixe _ro qui utilise le ReadOptimized org.apache.hudi.hadoop.HoodieParquetInputFormat serde.

  • Une table avec suffixe _rt qui utilise le RealTime Serde pour permettre les requêtes Snapshot :. org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat

MongoDB and Amazon DocumentDB (compatible avec MongoDB)

Les versions 3.2 et ultérieures de MongoDB sont prises en charge. Vous pouvez choisir d'analyser un petit échantillon des données uniquement pour réduire les temps d'exécution de l'crawler.

Base de données relationnelle

L'authentification est effectuée à l'aide d'un nom d'utilisateur et d'un mot de passe de base de données. En fonction du type de moteur de base de données, vous pouvez choisir quels objets sont analysés, comme les bases de données, les schémas et les tables.

Snowflake

Le JDBC robot Snowflake prend en charge l'exploration de la table, de la table externe, de la vue et de la vue matérialisée. La définition de la vue matérialisée n'est pas renseignée.

Pour les tables externes Snowflake, le crawler n'effectue l'analyse que s'il pointe vers un emplacement Amazon S3. Outre le schéma de la table, le crawler analyse également l'emplacement, le format de fichier et la sortie d'Amazon S3 sous forme de paramètres de table dans la table du catalogue de données. Notez que les informations de partition de la table externe partitionnée ne sont pas renseignées.

ETLn'est actuellement pas pris en charge pour les tables du catalogue de données créées à l'aide du robot Snowflake.