Une meilleure façon d'interroger les données DynamoDB avec SQL | TechTarget (2023)

Interroger DynamoDB avec SQL : à la manière d'Amazon

La seule façon d'interroger efficacement et efficacement les données DynamoDB dans AWS est de les exporter vers un système qui gère un dialecte SQL complet et peut interroger les données d'une manière qui n'est pas trop lente. Les deux meilleures options pour le système de destination sont :

• Redshift d'Amazon, qui possède son propre mécanisme de stockage des données. C'est la recommandation par défaut et l'option la moins chère.
• Amazone Athéna, ce qui vous oblige à placer des fichiers dans Amazon S3 pourrequête contre.

L'option Redshift, illustrée dans un article de blogici, n'est pas considérablement plus facile ou meilleure que l'option Athena. Le moyen le plus simple d'envoyer des données à Redshift consiste à utiliser la commande COPY, mais Redshift ne prend pas en charge les types de données complexes qui sont courants dans DynamoDB. Le moyen le plus flexible d'obtenir des données de DynamoDB vers Redshift consiste à les envoyer via S3, ce qui signifie que ce qui est détaillé dans le billet de blog mentionné précédemment n'est qu'une partie du processus pour les transmettre à Redshift.

Comme de nombreux processus dans AWS, il existe plusieurs façons d'envoyer des données de DynamoDB vers S3, comme l'utilisation d'Amazon Data Pipeline, d'Amazon Elastic MapReduce ou de la fonctionnalité DynamoDB Export to S3. Pour les besoins de cet article, nous utiliserons la fonctionnalité Exporter vers S3 dans DynamoDB car il s'agit de l'option la plus simple.

Ci-dessous se trouve le tableau que nous allons exporter. Il contient plus de 35 000 éléments et sa taille dépasse 4 Go. La table contient des types de données de carte et de liste, en plus de colonnes de type chaîne, nombre et booléen plus traditionnelles.

Exporter de DynamoDB vers S3

Pour commencer, vous devrez peut-être activer la nouvelle console DynamoDB -- qui est répertoriée comme nouvelle à la date de publication -- en choisissant "Essayer la nouvelle console de prévisualisation" sur le côté gauche de l'ancienne console. Après avoir choisi une table dans l'aperçu de la console DynamoDB, sélectionnez l'onglet intitulé "Exportations et flux".

Après avoir choisi cela, vous aurez le choix "Exporter vers S3" et vous pourrez ensuite configurer votre exportation en définissant la destinationGodet S3. Pour cette procédure pas à pas, les valeurs par défaut ci-dessous conviennent.

Après avoir cliqué sur « Exporter », le processus démarre et vous pouvez le surveiller dans la console DynamoDB. Dans cet exemple, l'exportation a pris environ sept minutes.

L'étape suivante consiste à interroger les données dans Athena. Tout d'abord, vous devez permettre à Athena de reconnaître les données. La documentation d'Athena se concentre sur la façon dontvous pouvez définir manuellement le schémapour vos fichiers JSON. AWS propose un service appeléColle AWS, conçu pourdécouvrir automatiquement le schémade votre exportation, mais cela ne le fait pas très bien pour Athena. Dans ce cas, nous devrons définir manuellement le schéma.

Utiliser AWS Glue

Malheureusement, pour utiliser AWS Glue, vousdoit avoir un point de terminaison de cloud privé virtuel (VPC) S3 configuré, même si vous n'utilisez pas d'Amazon VPC pour autre chose. Dans le service VPC, cliquez sur "Points de terminaison". Utilisez les étapes de configuration indiquées ci-dessous pour créer et ajouter un nouveau point de terminaison.

Nous pouvons maintenant accéder au service AWS Glue, qui offre la possibilité d'ajouter des tables à l'aide d'un robot d'exploration.

Ensuite, parcourez le flux de travail Glue. Utilisez les valeurs par défaut et sélectionnez le dossier dans lequel les données ont été placées.

Ensuite, ajoutez une nouvelle connexion réseau qui utilise le VPC que nous avons configuré dans S3. Choisissez le dossier dans S3 qui correspond à l'exportation spécifique que nous avons précédemment créée.

Glue a besoin d'un AWS Identity and Access Management(IAM) rôlepour accéder au compartiment S3. Le service explique comment en créer un.

Nous ferons en sorte que ce robot s'exécute à la demande, car il ne regarde que cette exportation spécifique.

Nous devons créer une base de données pour qu'Athena puisse voir et demander à Glue de regrouper les schémas compatibles afin qu'ils s'agrègent en une seule table, ce que nous avons exporté.

Enfin, nous sommes prêts à sauver le crawler.

Et nous pouvons maintenant l'exécuter.

Au bout de six minutes, c'est terminé. Ensuite, nous passons au service Athena et voyons un message d'erreur indiquant que nous devons configurer un emplacement de requête S3, ce qui n'est pas quelque chose qu'on nous avait dit de faire au préalable.

Nous créons donc un emplacement pour stocker les requêtes afin de répondre au message d'erreur. Ensuite, nous pouvons tenter d'interroger les données identifiées par Glue. Cependant, nous avons rencontré une autre erreur car les données du tableau étaient trop complexes pour que Glue les identifie correctement.

Glue construit une structure trop complexe pour qu'Athéna puisse la lire.

Définir manuellement un schéma

Si AWS Glue n'identifie pas correctement votre schéma, définissez-le manuellement. Voici une définition simple de quelques champs de niveau supérieur dans la table DynamoDB.

Et maintenant nous pouvons l'interroger.

Bien que nous puissions interroger les données ici, ce n'est pas idéal. Chaque enregistrement se trouve sous un élément de niveau supérieur, ce qui signifie que vous devez définir l'intégralité de l'enregistrement en tant que type complexe. Les enregistrements ne peuvent pas être stockés en tant que types simples, ce qui est certainement possible dans ce scénario ; c'est aussi la norme pour ce que vous vous attendez à voir dans une base de données. Par exemple, vous ne pouvez pas simplement définir certains champs de niveau supérieur comme des chaînes ou des nombres entiers, car l'élément de niveau supérieur est en fait une carte.

De plus, il n'est pas possible de saisir une carte ou une liste au format JSON et de simplement l'étendre ou d'en extraire des données si nécessaire. Si vous souhaitez y accéder, vous devez définir entièrement la structure entière afin que chaque champ que vous demandez soit un scalaire. Vous devez également gérer le casting de non-chaînes chaque fois que vous souhaitez les utiliser.

De plus, l'exportation est une exportation ponctuelle, ce qui signifie qu'elle n'est pas automatiquement exportée à chaque fois. Si vous ajoutez des champs n'importe où dans les enregistrements DynamoDB, vous devrez redéfinir l'ensemble de l'appel "CREATE EXTERNAL TABLE".

Interroger DynamoDB avec SQL : Fivetran et BigQuery

Une approche totalement différente de ce problème consiste à utiliser un service dédié qui transfère les données d'un magasin de données à un autre et à utiliser un service d'interrogation des données similaire à Athena mais plus complet.

Fivetran est unservice ETL entièrement géréqui copie les données régulièrement (toutes les 15 minutes) d'un endroit à un autre. Pour utiliser Fivetran, vous devez d'abord connecter un magasin de données de destination. Dans le cadre de cet exemple, nous utiliserons BigQuery, l'une des bases de données "big data" basées sur le cloud les plus anciennes et les plus populaires. Cependant, vous pouvez connecter Fivetran à d'autres bases de données, telles que Snowflake ou même Redshift.

Pour BigQuery, en supposant que vous ayez activé l'accès à BigQuery dans Google Cloud et que vous ayez un projet Google Cloud, il vous suffit d'ajouter un utilisateur Fivetran à votre projet Google Cloud et de donner à cet utilisateur l'accès à BigQuery.

Déplacer des données de DynamoDB vers BigQuery avec Fivetran

Pour connecter Fivetran à DynamoDB, parcourez leur assistant et autorisez Fivetran à lire les tables DynamoDB que vous prévoyez de copier en dehors de DynamoDB. Tout d'abord, créez une stratégie IAM dans AWS pour Fivetran à l'aide d'un ID personnalisé que Fivetran a attribué à votre compte Fivetran.

Ensuite, vous devez créer un rôle IAM auquel cette politique est attachée et la mettre à la disposition de Fivetran.

Ensuite, vous ajoutez un connecteur DynamoDB dans Fivetran en remplissant le nom de ressource Amazon pour le rôle.

Une fois que vous avez fait cela, Fivetran teste la connexion.

Ensuite, vous dites à Fivetran de synchroniser les tables. Dans cet exemple, la synchronisation initiale a pris 34 minutes.

Interroger des données dans BigQuery

Après la synchronisation initiale, BigQuery affiche tous les champs de niveau supérieur automatiquement extraits et définis.

Vous pouvez également extraire arbitrairement des champs plus profonds dans la structure du document à l'aide des fonctions JSON de BigQuery.

Fivetran met également automatiquement à jour la structure de la table dans BigQuery à mesure que des modifications sont apportées dans DynamoDB. Fivetran s'assure que BigQuery dispose de tout ce qui se trouve dans DynamoDB, toutes les 15 minutes.

Désavantages

Fivetran et BigQuery sont plus faciles à utiliser et constituent un choix plus solide que ce qu'offre AWS pour interroger les données DynamoDB avec SQL. Cependant, cette option présente certains inconvénients, notamment :

• C'est plus cher, principalement à cause de Fivetran -- BigQuery estprix comparableà Athéna.
• Lorsque les données se déplacent d'un cloud à un autre, Fivetran a besoin d'accéder à ces données, ce qui peut rendre la conformité difficile ou impossible, selon vos besoins.
• Il a un retard intégré car il y a des étapes coordonnées et dépendantes qui doivent être complétées pour récupérer les données nécessaires. Si vous avez besoin d'interroger les données plus rapidement, vous pouvez créer votre propre solution personnalisée basée sur les flux DynamoDB etAmazon Kinésis, mais ce sont tous des cas extrêmes par rapport au besoin plus général d'interroger DynamoDB avec SQL.

AWS : Trop grand pour échouer ?

L'option Fivetran et BigQuery soulève des questions sur la capacité d'AWS à être le meilleur de sa catégorie. Que doit faire AWS lorsqu'il dispose d'un service inférieur qui fait encore le travail en théorie ? Les équipes de projet sont si cloisonnées et réparties qu'il est très peu probable qu'AWS crée un autre service qui concurrence directement son outil existant. Mais il est également incroyablement difficile de voir comment AWS peut améliorer suffisamment Glue ou Athena pour être compétitif.

Les problèmes d'utilisabilité rencontrés par AWS avec Glue et Athena sont liés aux projets open source sous-jacents sur lesquels ces services sont basés - Apache Spark et Presto, respectivement. Par exemple, le moteur d'analyse Spark est hautement configurable. Il suppose que les utilisateurs savent coder et passeront du temps à apprendre le système. En revanche, Fivetran est opiniâtre et conçu pour la simplicité, de sorte que les utilisateurs doivent prendre le moins de décisions possible.

Cela devrait sonner l'alarme au sein d'AWS. S'il continue à proposer des logiciels open source en tant que services gérés, AWS pourrait avoir du mal à gagner contre des produits conçus en tant que services gérés à partir de zéro.

AWS a lancé la révolution de la fourniture d'infrastructures sous forme de services gérés, mais il n'a pas toujours conçu les options les meilleures et les plus utilisables avec ses offres de niveau supérieur. Cela donne finalement aux concurrents la possibilité de capter les revenus des clients et d'orienter ces utilisateurs vers d'autres plates-formes d'infrastructure.

Le calcul, le stockage et d'autres services d'infrastructure restent le pain quotidien d'AWS, mais ils sont également les plus fongibles pour les utilisateurs. Pour certaines entreprises, rester entièrement au sein d'AWS peut ne pas être une bonne décision si leur objectif est d'utiliser les meilleurs services disponibles, et cela pourrait créer un problème beaucoup plus important pour AWS.