DynamoDB-Tabelle nach CSV exportieren (4 Wege)

DynamoDB hat keinen nativen „Nach CSV exportieren"-Button. Jeder Wert kommt in DynamoDBs marshalltem JSON verpackt zurück — {"S": "..."}, {"N": "123"}, {"M": {...}} — und eine Tabelle kann verschachtelte Maps, Listen und Sets ohne offensichtliche Flachspalten-Darstellung enthalten. „DynamoDB nach CSV exportieren" sind also in Wahrheit zwei Probleme: die Items herausholen und dann das typisierte JSON zu Zeilen plätten. Weder die Konsole noch der verwaltete Export erledigt den zweiten Schritt für dich.

Dieser Guide beginnt mit dem Weg, der beide Schritte für dich erledigt, und behandelt dann die drei AWS-Tooling-Routen und wann welche die richtige Wahl ist.

Wie exportiere ich eine DynamoDB-Tabelle nach CSV?

Öffne die Tabelle in DynoTable, filtere auf die gewünschten Zeilen und exportiere das Ergebnis mit einem Klick nach CSV — Typ-Deskriptoren ausgepackt und verschachtelte Werte für dich geplättet (Methode 1). Baust du es stattdessen aus AWS-Tooling: Scanne mit der CLI und forme mit jq um für eine kleine Tabelle (Methode 2), nutze den verwalteten S3-Export für große Tabellen (Methode 3) oder schreibe ein kurzes Skript, wenn du individuelles Umformen brauchst (Methode 4).

Gefiltertes / geformtes CSV (eine Teilmenge der Spalten, nur manche Items): ein GUI-Export (Methode 1) oder ein Skript. Der verwaltete S3-Export gibt dir die ganze Tabelle, ungefiltert.
Kleine Tabelle, ad hoc, nur Terminal: AWS CLI scan + jq (Methode 2). Funktioniert, bis verschachtelte Attribute auftauchen.
Große Tabelle (GBs+): DynamoDB-Export nach S3 (Methode 3), dann den Dump konvertieren. Er läuft asynchron und verbraucht keine Lesekapazität — gibt aber DynamoDB-JSON aus, kein CSV.

Methode 1: Ein-Klick-Export in DynoTable

DynoTable behandelt den Export als Teil des Durchstöberns: Führe eine Abfrage aus oder filtere sie, drücke ⌘⇧E (oder den Export-Button in der Tab-Toolbar) und wähle, was rausgeht:

Formate: CSV (eine Zeile pro Item, mit Headern — Sets serialisieren als JSON-Arrays innerhalb einer Zelle), JSON und NDJSON. JSON/NDJSON kommen unmarshallt (schlicht "count": 3) oder als marshalltes DynamoDB-JSON, wenn du einen verlustfreien Round-Trip brauchst, der große Zahlen bewahrt.
Umfänge: die aktuell geladenen Zeilen, nur deine Auswahl oder der volle Filtertreffer — jedes Item, das deine Abfrage matcht, direkt aus DynamoDB gestreamt statt nur das, was auf dem Bildschirm ist. Letzteres ist der gefilterte Export, den der verwaltete S3-Snapshot nicht kann.
Ziel: Zwischenablage oder Datei. Für schnelle Einmal-Grabs rechtsklicke eine Zeile, und Copy as… legt CSV, JSON, NDJSON oder DynamoDB-JSON direkt in die Zwischenablage, ohne Dialog.

DynoTables Export-Dialog: Format (CSV / JSON / NDJSON), Umfang von der Auswahl bis zum vollen Filtertreffer und Zwischenablage oder Datei als Ziel.

Die Plätt-Probleme, an denen die DIY-Routen unten brechen, sind erledigt: Typ-Deskriptoren werden ausgepackt, verschachtelte Maps und Listen geplättet, und umbenannte Spalten fließen in die CSV-Header durch. Große Exporte lösen sich ab und laufen im Hintergrund — Zeile für Zeile auf die Platte gestreamt, Tab-Wechsel und sogar einen App-Reload überlebend — ein Multi-Gigabyte-Export muss also nie in den Speicher passen.

Es ist ein Desktop-DynamoDB-Client, dasselbe Tool, mit dem du die Tabelle ohnehin durchstöberst; siehe den Vergleich mit anderen DynamoDB-GUIs. Wann würdest du es nicht nutzen? Wenn der Export unbeaufsichtigt in einer Pipeline laufen muss — dafür ist die Skript-Route (Methode 4) da.

Methode 2: AWS-CLI-Scan + jq

Für eine kleine Tabelle kannst du sie scannen und die Ausgabe mit jq umformen. Ein Scan liest jedes Item der Tabelle und liefert es in Seiten von bis zu 1 MB; die CLI folgt der Paginierung automatisch für dich (AWS-Docs: Scanning tables).

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

Der Haken steckt in dieser jq-Zeile: Du musst .id.S, .name.S, .price.N von Hand schreiben — an jedem Typ-Deskriptor (S, N, B, BOOL, M, L, SS, NS, BS) des Attributs vorbeigreifen, um den rohen Wert zu bekommen. Das ist machbar für eine flache Tabelle mit drei String-Spalten. Es zerfällt in dem Moment, in dem du Folgendes hast:

Verschachtelte Maps/Listen — {"M": {...}} oder {"L": [...]} haben keine einzelne Spalte zum Plätten; @csv verschluckt sich, oder du JSON-enkodierst die Zelle von Hand.
Sets — {"SS": ["a","b"]} ist ein Array, kein Skalar.
Sparse-Attribute — DynamoDB ist schemalos, Item A kann also ein price haben und Item B nicht. Deine feste Spaltenliste lässt Spalten stillschweigend fallen oder verschiebt sie.

Es gibt außerdem gar kein --output csv — die Ausgabeformate der CLI sind json, yaml, text, table und off, und keines versteht DynamoDB-Typen. Du brauchst also weiterhin jq (oder ein Skript), um die Typ-Tags zu entfernen. Das ist der Kerngrund, warum „DynamoDB-Tabelle per AWS CLI nach CSV exportieren" jenseits des Trivialfalls nie ein Einzeiler ist.

Um eine ganze größere Tabelle auf diesem Weg zu exportieren, ohne dass es den ganzen Tag dauert, parallelisiere den Scan mit --segment / --total-segments (AWS-Docs: Parallel scan — DynamoDB „weist Items Segmenten zu, indem es eine Hash-Funktion auf den Partition Key jedes Items anwendet", Segmente können also ungleich sein), und lies Paginierung, damit du nicht bei der ersten 1-MB-Seite aufhörst.

Methode 3: DynamoDB-Export nach S3 (große Tabellen)

Für Tabellen jeder ernsthaften Größe ist der verwaltete Export nach Amazon S3 das richtige Werkzeug. Er exportiert einen Snapshot von einem beliebigen Punkt deines Point-in-Time-Recovery-(PITR)-Fensters — PITR muss also zuerst auf der Tabelle aktiviert sein, sonst schlägt der Export mit PointInTimeRecoveryUnavailableException fehl —, läuft asynchron und verbraucht keine Lesekapazitätseinheiten, hat also null Einfluss auf Durchsatz oder Verfügbarkeit deiner Tabelle (AWS-Docs: „Exporte sind asynchron, sie verbrauchen keine Lesekapazitätseinheiten (RCUs) und haben keinen Einfluss auf Tabellenleistung und -verfügbarkeit"; „Du musst PITR auf deiner Tabelle aktivieren, um die Exportfunktion zu nutzen"). Das ist auch das, was die Exports to S3-Aktion der Konsole unter der Haube auslöst: Die Konsole ist nur ein Frontend für dieselbe API, trägt also dieselbe PITR-Anforderung und dieselbe JSON-Ausgabe.

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

Der eine Fallstrick: Der S3-Export gibt kein CSV aus. Er schreibt ausschließlich DynamoDB-JSON oder Amazon Ion, als gezippte Dateien im JSON-Lines-Format (ein Item pro Zeile), plus Manifest-Dateien (AWS-Docs: export output format — Datendateien werden als .json.gz geschrieben, „das Format ist JSON Lines", neben manifest-summary.json / manifest-files.json). Du brauchst danach weiterhin einen Konvertierungsschritt:

Athena / Glue lesen das exportierte DynamoDB-JSON direkt — richte eine Tabelle auf das S3-Präfix und schreibe CSV aus einem SELECT (das ist die übliche „DynamoDB nach S3, dann nach CSV"-Pipeline). AWS merkt an, dass „viele AWS-Services wie Athena und AWS Glue dieses Format automatisch parsen" (Format der Export-Ausgabe).
Selbst bauen — die .gz-Dateien entpacken, jede JSON-Zeile parsen und plätten (dasselbe Plätt-Problem wie bei jeder anderen Methode).

Es ist außerdem ein Full-Table-Snapshot: Es gibt keinen serverseitigen Filter, um nur manche Items zu exportieren. Brauchst du eine Teilmenge, filterst du entweder nachträglich in Athena oder nutzt stattdessen eine GUI (Methode 1) / ein Skript.

Methode 4: ein schnelles Skript (boto3 / Node)

Wenn der Export unbeaufsichtigt laufen muss — ein Nightly-Job, ein CI-Schritt — schlägt ein kleines Skript alles oben. Der Gewinn: Die AWS-SDKs unmarshallen das typisierte JSON für dich: boto3s Resource-Interface und der DynamoDBDocumentClient des JS-SDK liefern schlicht {"price": 2000} statt {"price": {"N": "2000"}} (boto3s Resource-Interface macht „die Datentypisierung implizit", laut AWS-Python-Guide; der JS-DocumentClient „konvertiert annotierte Antwortdaten in native JavaScript-Typen", laut @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})

Zwei Entscheidungen bleiben bei dir, die das SDK dir nicht abnehmen kann: wie du verschachtelte Maps/Listen zu Spalten plättest (die Zelle JSON-enkodieren? die Schlüssel dot-pathen?) und was mit Sparse-Attributen passiert (hier wird ein fehlender Schlüssel per r.get(k) zur leeren Zelle). Und lass die LastEvaluatedKey-Schleife nicht weg — ein einzelner scan()-Aufruf liefert nur die erste 1-MB-Seite, ohne sie exportierst du also stillschweigend nur einen Teil der Tabelle.

Derselbe Vorbehalt wie bei Methode 2: Ein Full-Table-scan verbraucht auch hier Lesekapazität und konkurriert mit Live-Traffic. Für eine große Tabelle bevorzuge Methode 3 und forme den Dump um.

Fallstricke: DynamoDB-JSON vs. flaches CSV

Egal welche Methode du wählst, dieselbe Handvoll Diskrepanzen zwischen DynamoDBs Datenmodell und einem flachen CSV wird dich beißen:

Typ-Deskriptoren. Rohe API-/CLI-/S3-Export-Ausgabe verpackt jeden Wert ({"S": "..."}, {"N": "123"}). Entweder packst du ihn über ein SDK aus oder entfernst den Deskriptor selbst. Der vollständige Satz ist S, N, B, BOOL, NULL, M, L, SS, NS, BS — siehe DynamoDB-Datentypen.
Verschachtelte Maps und Listen (M, L) können bis zu 32 Ebenen tief verschachteln (AWS-Docs: data types — Liste und Map „können ineinander verschachtelt werden, um komplexe Datenstrukturen bis zu 32 Ebenen tief darzustellen") und haben keine natürliche Einzelspalten-Form. Entscheide vorab: die Zelle JSON-enkodieren oder verschachtelte Schlüssel in dot-gepfadete Spalten auffalten (address.city).
Sets (SS/NS/BS) sind ungeordnete Sammlungen, keine Skalare — AWS warnt: „die Reihenfolge der Werte innerhalb eines Sets bleibt nicht erhalten" (Datentypen) — plätte also zu einem getrennten String und verlasse dich nicht auf die Elementreihenfolge.
Sparse-Attribute. DynamoDB ist schemalos, zwei Items können also unterschiedliche Attribute haben. Es gibt keinen festen Spaltensatz; vereinige die Schlüssel über alle Items, sonst verrutschen Spalten. Das ist eine direkte Folge von Single-Table-Design, bei dem eine Tabelle mehrere Entity-Formen hält.
Paginierung. Scan (und Query) liefern höchstens 1 MB pro Aufruf. Wenn du nicht über LastEvaluatedKey schleifst, exportierst du stillschweigend nur die erste Seite. Siehe Paginierung.
Zahlenpräzision. DynamoDB-Zahlen tragen bis zu 38 Stellen Präzision und reisen als Strings (AWS-Docs: data types: „Zahlen können bis zu 38 Stellen Präzision haben"; „Alle Zahlen werden über das Netzwerk als Strings an DynamoDB gesendet"); Tabellenkalkulationen können lange Zahlen oder IDs in Floats zwingen und Stellen verlieren. Behalte sie als Text.

FAQ

Was ist der schnellste Weg, eine DynamoDB-Tabelle nach CSV zu exportieren? Eine GUI, die das Plätten für dich erledigt: Filtere in DynoTable die Tabelle, drücke ⌘⇧E, wähle CSV und einen Umfang — von den ausgewählten Zeilen bis zu jedem Item, das der Filter matcht, aus DynamoDB gestreamt. Typ-Deskriptoren und verschachtelte Werte werden automatisch behandelt.

Wie exportiere ich eine DynamoDB-Tabelle per AWS CLI nach CSV? Scanne die Tabelle und forme die Ausgabe mit jq um (Methode 2): aws dynamodb scan → jq, um den Typ-Deskriptor jedes Werts zu entfernen → @csv. Es gibt kein DynamoDB-bewusstes --output csv, das Typ-Entfernen machst du also immer selbst, und es bricht an verschachtelten Maps, Listen und Sets.

Kann ich eine DynamoDB-Tabelle direkt aus AWS nach CSV exportieren? Nicht in einem Schritt. Konsole und verwalteter S3-Export produzieren beide DynamoDB-JSON oder Amazon Ion, nie CSV. Du brauchst immer einen Konvertierungsschritt — CLI + jq, ein Skript, Athena/Glue über den S3-Dump oder eine GUI, die das Plätten für dich erledigt.

Wie exportiere ich eine ganze DynamoDB-Tabelle, ohne die Produktion zu beeinträchtigen? Nutze das Export-nach-S3-Feature (Methode 3). Es läuft asynchron und verbraucht keine Lesekapazitätseinheiten, konkurriert also nicht mit Live-Traffic — anders als ein Scan, der gegen den Durchsatz deiner Tabelle gemessen wird (AWS-Docs). Es erfordert aktiviertes PITR und exportiert die volle Tabelle, keine gefilterte Teilmenge.

Wie exportiere ich DynamoDB als CSV nach S3? Der verwaltete Export schreibt nur DynamoDB-JSON / Ion nach S3, „nach CSV" ist also ein zweiter Hop: Registriere das Export-Präfix als Athena- (oder Glue-)Tabelle und schreibe CSV aus einem SELECT. Es gibt kein --export-format CSV.

Wie exportiere ich DynamoDB nach Excel? Exportiere zuerst nach CSV (jede Methode oben) und öffne das CSV dann in Excel — behalte lange numerische IDs als Text, damit sie nicht in Floats gezwungen werden. Es gibt keinen direkten .xlsx-Export aus DynamoDB; DynoTable speichert die aktuelle Ansicht direkt als spreadsheet-taugliches CSV.

Warum hat mein exportiertes JSON überall {"S": ...} und {"N": ...}? Das ist DynamoDBs Wire-Format — jeder Wert trägt einen Typ-Deskriptor. Unmarshalle es mit einem SDK, dem DynamoDB-JSON-Konverter oder einer GUI, bevor du CSV schreibst. Das Wire-Format ist dasselbe, egal ob die Daten aus der API, der CLI oder dem S3-Export kamen.

Durchstöbere, filtere und exportiere deine eigenen Tabellen nach CSV mit DynoTable, oder packe zuerst eine Probe DynamoDB-JSON im JSON-Konverter aus.