Exporter une table DynamoDB en CSV

DynamoDB n'a pas de bouton natif « exporter en CSV ». Chaque valeur revient enveloppée dans le JSON marshallé de DynamoDB — {"S": "..."}, {"N": "123"}, {"M": {...}} — et une table peut contenir des maps, listes et ensembles imbriqués sans représentation évidente en colonnes plates. Donc « exporter DynamoDB en CSV », ce sont en réalité deux problèmes : sortir les items, puis aplatir le JSON typé en lignes. Ni la console ni l'export managé ne font la seconde étape pour toi.

Ce guide commence par la méthode qui fait les deux étapes pour toi, puis couvre les trois voies via l'outillage AWS et quand chacune est le bon choix.

Comment exporter une table DynamoDB en CSV ?

Le plus rapide : ouvre la table dans DynoTable, filtre sur les lignes que tu veux, et exporte le résultat en CSV en un clic — descripteurs de type déballés et valeurs imbriquées aplaties pour toi (Méthode 1). Pour le construire avec l'outillage AWS à la place : scanne avec la CLI et remodèle avec jq pour une petite table (Méthode 2), utilise l'export S3 managé pour les grandes tables (Méthode 3), ou écris un petit script quand tu as besoin d'un formatage sur mesure (Méthode 4).

CSV filtré / formaté (un sous-ensemble de colonnes, seulement certains items) : un export GUI (Méthode 1) ou un script. L'export S3 managé te donne la table entière, non filtrée.
Petite table, ad hoc, terminal uniquement : AWS CLI scan + jq (Méthode 2). Ça va tant que les attributs imbriqués ne se pointent pas.
Grande table (Go et plus) : l'export DynamoDB vers S3 (Méthode 3), puis convertis le dump. Il s'exécute de manière asynchrone et ne consomme aucune capacité de lecture — mais il produit du DynamoDB JSON, pas du CSV.

Méthode 1 : export en un clic dans DynoTable

DynoTable traite l'export comme une partie de la navigation : exécute ou filtre une requête, appuie sur ⌘⇧E (ou le bouton Export dans la barre d'outils de l'onglet), et choisis ce qui sort :

Formats : CSV (une ligne par item, avec en-têtes — les ensembles se sérialisent en tableaux JSON dans une cellule), JSON et NDJSON. JSON/NDJSON sortent démarshallés (un simple "count": 3) ou en DynamoDB-JSON marshallé quand tu as besoin d'un aller-retour sans perte qui préserve les grands nombres.
Périmètres : les lignes actuellement chargées, seulement ta sélection, ou la correspondance complète du filtre — chaque item que ta requête matche, streamé directement depuis DynamoDB plutôt que seulement ce qui est à l'écran. Ce dernier est l'export filtré que le snapshot S3 managé ne sait pas faire.
Destination : presse-papiers ou fichier. Pour les prises ponctuelles, un clic droit sur une ligne et Copy as… met du CSV, JSON, NDJSON ou DynamoDB-JSON directement dans le presse-papiers, sans dialogue.

Le dialogue d'export de DynoTable : format (CSV / JSON / NDJSON), périmètre de la sélection à la correspondance complète du filtre, et destination presse-papiers ou fichier.

Les problèmes d'aplatissement qui cassent les voies DIY ci-dessous sont gérés : les descripteurs de type sont déballés, les maps et listes imbriquées sont aplaties, et les colonnes renommées se propagent aux en-têtes du CSV. Les gros exports se détachent et tournent en arrière-plan — streamés sur disque ligne par ligne, survivant aux changements d'onglet et même à un rechargement de l'app — donc un export multi-gigaoctets n'a jamais à tenir en mémoire.

C'est un client DynamoDB de bureau, le même outil que tu utilises déjà pour parcourir la table ; vois comment il se compare aux autres GUI DynamoDB. Quand ne l'utiliserais-tu pas ? Quand l'export doit tourner sans surveillance dans un pipeline — c'est à ça que sert la voie script (Méthode 4).

Méthode 2 : AWS CLI scan + jq

Pour une petite table, tu peux la scanner et remodeler la sortie avec jq. Un Scan lit chaque item de la table et le renvoie par pages d'au plus 1 Mo ; la CLI suit la pagination pour toi automatiquement (doc AWS : Scanning tables).

aws dynamodb scan --table-name MyTable --output json \
  | jq -r '.Items[] | [.id.S, .name.S, .price.N] | @csv' \
  > out.csv

Le piège est dans cette ligne jq : tu dois écrire à la main .id.S, .name.S, .price.N — en passant à travers le descripteur de type de chaque attribut (S, N, B, BOOL, M, L, SS, NS, BS) pour atteindre la valeur brute. C'est gérable pour une table plate à trois colonnes de chaînes. Ça s'effondre dès que tu as :

Des maps/listes imbriquées — {"M": {...}} ou {"L": [...]} n'ont aucune colonne unique où s'aplatir ; @csv s'étrangle, ou tu encodes la cellule en JSON à la main.
Des ensembles — {"SS": ["a","b"]} est un tableau, pas un scalaire.
Des attributs épars — DynamoDB est sans schéma, donc l'item A peut avoir un price et l'item B non. Ta liste de colonnes fixe perd ou désaligne des colonnes silencieusement.

Il n'existe pas non plus de --output csv du tout — les formats de sortie de la CLI sont json, yaml, text, table et off, et aucun ne comprend les types DynamoDB. Donc il te faut quand même jq (ou un script) pour retirer les tags de type. C'est la raison de fond pour laquelle « exporter une table DynamoDB en CSV via l'AWS CLI » n'est jamais un one-liner au-delà du cas trivial.

Pour exporter une table plus grande de cette façon sans y passer la journée, parallélise le scan avec --segment / --total-segments (doc AWS : Parallel scan — DynamoDB « assigne les items aux segments en appliquant une fonction de hachage à la clé de partition de chaque item », donc les segments peuvent être inégaux), et lis la pagination pour ne pas t'arrêter à la première page de 1 Mo.

Méthode 3 : export DynamoDB vers S3 (grandes tables)

Pour les tables d'une taille réelle, l'export managé vers Amazon S3 est le bon outil. Il exporte un snapshot depuis n'importe quel point de ta fenêtre de récupération à un instant donné (PITR) — donc PITR doit être activé sur la table d'abord, sinon l'export échoue avec PointInTimeRecoveryUnavailableException —, s'exécute de manière asynchrone, et ne consomme aucune unité de capacité de lecture, donc n'a aucun impact sur le débit ou la disponibilité de ta table (doc AWS : « Les exports sont asynchrones, ils ne consomment pas d'unités de capacité de lecture (RCU) et n'ont aucun impact sur les performances et la disponibilité de la table » ; « Tu dois activer PITR sur ta table pour utiliser la fonctionnalité d'export »). C'est aussi ce que l'action Exports to S3 de la console déclenche sous le capot : la console n'est qu'une façade de la même API, donc elle porte la même exigence PITR et la même sortie JSON.

aws dynamodb export-table-to-point-in-time \
  --table-arn arn:aws:dynamodb:us-east-1:123456789012:table/MyTable \
  --s3-bucket my-export-bucket \
  --export-format DYNAMODB_JSON

Le seul piège : l'export S3 ne produit pas de CSV. Il n'écrit que du DynamoDB JSON ou de l'Amazon Ion, en fichiers gzippés au format JSON-lines (un item par ligne), plus des fichiers manifest (doc AWS : format de sortie de l'export — les fichiers de données sont écrits en .json.gz, « le format est JSON lines », aux côtés de manifest-summary.json / manifest-files.json). Il te faut encore une étape de conversion après :

Athena / Glue lisent le DynamoDB JSON exporté directement — pointe une table sur le préfixe S3, puis écris le CSV depuis un SELECT (c'est le pipeline habituel « exporter DynamoDB vers S3 puis vers CSV »). AWS note que « beaucoup de services AWS, comme Athena et AWS Glue, analyseront ce format automatiquement » (format de sortie de l'export).
Fais-le toi-même — décompresse les fichiers .gz, parse chaque ligne JSON, et aplatis-la (le même problème d'aplatissement que dans toutes les autres méthodes).

C'est aussi un snapshot de la table entière : il n'y a pas de filtre côté serveur pour n'exporter que certains items. Si tu as besoin d'un sous-ensemble, soit tu filtres après coup dans Athena, soit tu utilises une GUI (Méthode 1) / un script à la place.

Méthode 4 : un petit script (boto3 / Node)

Quand l'export doit tourner sans surveillance — un job nocturne, une étape de CI — un petit script bat tout ce qui précède. Le gain, c'est que les SDK AWS démarshallent le JSON typé pour toi : l'interface resource de boto3 et le DynamoDBDocumentClient du SDK JS renvoient un simple {"price": 2000} au lieu de {"price": {"N": "2000"}} (l'interface resource de boto3 rend « le typage des données implicite », d'après le guide AWS Python ; le DocumentClient JS « convertit les données de réponse annotées en types JavaScript natifs », d'après @aws-sdk/lib-dynamodb).

import boto3, csv

table = boto3.resource("dynamodb").Table("MyTable")
rows, resp = [], table.scan()
rows += resp["Items"]
while "LastEvaluatedKey" in resp:                  # paginate to the end
    resp = table.scan(ExclusiveStartKey=resp["LastEvaluatedKey"])
    rows += resp["Items"]

with open("out.csv", "w", newline="") as f:
    w = csv.DictWriter(f, fieldnames=["id", "name", "price"])
    w.writeheader()
    for r in rows:
        w.writerow({k: r.get(k) for k in w.fieldnames})

Deux décisions restent à ta charge, que le SDK ne peut pas prendre pour toi : comment aplatir les maps/listes imbriquées en colonnes (encoder la cellule en JSON ? mettre les clés en chemins pointés ?), et quoi faire des attributs épars (ici une clé manquante devient une cellule vide via r.get(k)). Et ne laisse pas tomber la boucle LastEvaluatedKey — un seul appel scan() ne renvoie que la première page de 1 Mo, donc sans elle tu n'exportes silencieusement qu'une partie de la table.

Même mise en garde que la Méthode 2 : un scan de table entière ici consomme toujours de la capacité de lecture et rivalise avec le trafic en direct. Pour une grande table, préfère la Méthode 3 et remodèle le dump.

Pièges : DynamoDB JSON vs CSV plat

Quelle que soit la méthode choisie, la même poignée de décalages entre le modèle de données de DynamoDB et un CSV plat va te mordre :

Les descripteurs de type. La sortie brute de l'API / CLI / export S3 enveloppe chaque valeur ({"S": "..."}, {"N": "123"}). Soit tu la déballes via un SDK, soit tu retires le descripteur toi-même. Le jeu complet est S, N, B, BOOL, NULL, M, L, SS, NS, BS — voir les types de données DynamoDB.
Les maps et listes imbriquées (M, L) peuvent s'imbriquer jusqu'à 32 niveaux de profondeur (doc AWS : types de données — liste et map « peuvent être imbriquées l'une dans l'autre, pour représenter des structures de données complexes jusqu'à 32 niveaux de profondeur ») et n'ont pas de forme naturelle en colonne unique. Décide d'avance : encoder la cellule en JSON, ou éclater les clés imbriquées en colonnes à chemins pointés (address.city).
Les ensembles (SS/NS/BS) sont des collections non ordonnées, pas des scalaires — AWS prévient que « l'ordre des valeurs au sein d'un ensemble n'est pas préservé » (types de données) — donc aplatis en chaîne délimitée et ne compte pas sur l'ordre des éléments.
Les attributs épars. DynamoDB est sans schéma, donc deux items peuvent avoir des attributs différents. Il n'y a pas de jeu de colonnes fixe ; fais l'union des clés sur tous les items, sinon les colonnes se désaligneront. C'est une conséquence directe du single-table design, où une table contient plusieurs formes d'entités.
La pagination. Scan (et Query) renvoient au plus 1 Mo par appel. Si tu ne boucles pas sur LastEvaluatedKey, tu n'exporteras silencieusement que la première page. Voir la pagination.
La précision des nombres. Les nombres DynamoDB portent jusqu'à 38 chiffres de précision et voyagent comme des chaînes (doc AWS : types de données : « Les nombres peuvent avoir jusqu'à 38 chiffres de précision » ; « Tous les nombres sont envoyés sur le réseau à DynamoDB sous forme de chaînes ») ; un tableur peut convertir de longs nombres ou identifiants en flottants et perdre des chiffres. Garde-les en texte.

FAQ

Quelle est la façon la plus rapide d'exporter une table DynamoDB en CSV ? Une GUI qui fait l'aplatissement pour toi : dans DynoTable, filtre la table, appuie sur ⌘⇧E, choisis CSV, et choisis un périmètre — des lignes sélectionnées jusqu'à chaque item que le filtre matche, streamé depuis DynamoDB. Les descripteurs de type et les valeurs imbriquées sont gérés automatiquement.

Comment exporter une table DynamoDB en CSV avec l'AWS CLI ? Scanne la table et remodèle la sortie avec jq (Méthode 2) : aws dynamodb scan → jq pour retirer le descripteur de type de chaque valeur → @csv. Il n'y a pas de --output csv conscient de DynamoDB, donc tu fais toujours le retrait des types toi-même, et ça casse sur les maps, listes et ensembles imbriqués.

Puis-je exporter une table DynamoDB directement en CSV depuis AWS ? Pas en une étape. La console et l'export S3 managé produisent tous deux du DynamoDB JSON ou de l'Amazon Ion, jamais du CSV. Il te faut toujours une étape de conversion — CLI + jq, un script, Athena/Glue sur le dump S3, ou une GUI qui fait l'aplatissement pour toi.

Comment exporter une table DynamoDB entière sans affecter la production ? Utilise la fonctionnalité d'export vers S3 (Méthode 3). Elle s'exécute de manière asynchrone et ne consomme aucune unité de capacité de lecture, donc ne rivalise pas avec le trafic en direct — contrairement à un Scan, qui est facturé contre le débit de ta table (doc AWS). Elle exige que PITR soit activé et exporte la table complète, pas un sous-ensemble filtré.

Comment exporter DynamoDB vers S3 en CSV ? L'export managé n'écrit que du DynamoDB JSON / Ion vers S3, donc « vers CSV » est un second saut : enregistre le préfixe d'export comme table Athena (ou Glue) et écris le CSV depuis un SELECT. Il n'y a pas de --export-format CSV.

Comment exporter DynamoDB vers Excel ? Exporte d'abord en CSV (n'importe quelle méthode ci-dessus), puis ouvre le CSV dans Excel — en gardant les longs identifiants numériques en texte pour qu'ils ne soient pas convertis en flottants. Il n'y a pas d'export .xlsx direct depuis DynamoDB ; DynoTable enregistre la vue courante directement dans un CSV prêt pour un tableur.

Pourquoi mon JSON exporté a-t-il des {"S": ...} et {"N": ...} partout ? C'est le format réseau de DynamoDB — chaque valeur est étiquetée avec un descripteur de type. Démarshalle-le avec un SDK, le convertisseur DynamoDB JSON, ou une GUI avant d'écrire le CSV. Le format réseau est le même que les données viennent de l'API, de la CLI ou de l'export S3.

Parcours, filtre et exporte tes propres tables en CSV avec DynoTable, ou déballe d'abord un échantillon de DynamoDB JSON dans le convertisseur JSON.