DynamoDB zu Redshift: Drei Methoden für die Datenmigration

Voraussetzungen und Setup

Dieses Tutorial setzt Folgendes voraus:

• Erfahrung mit AWS sowie verwandten Tools und Techniken. 
• Grundlegendes Verständnis von relationalen und NoSQL-Datenbanken. 
• Vertrautheit mit SQL.
• Kenntnisse in mindestens einer Programmiersprache sind von Vorteil.

Die Migrationsmethoden binden einige zentrale AWS-Services ein, darunter:

• Identity and Access Management (IAM)
• DynamoDB
• Redshift
• S3
• Glue
• Lambda

Der Kurs AWS Cloud Technology and Services hilft dir beim Einstieg, falls du neu bei AWS bist.

Der Großteil der Schritte wird in der AWS Management Console durchgeführt. Die im Tutorial gezeigten Schritte lassen sich jedoch auch über die AWS Command Line Interface (CLI) oder ein AWS Software Development Kit (SDK) ausführen. Wähle für die Migration die Arbeitsumgebung, die dir am besten passt.

DynamoDB für die Migration vorbereiten

Bei der Vorbereitung der Migration solltest du die Komponenten von DynamoDB-Tabellen und deren Unterschiede zu relationalen Datenbanken berücksichtigen:

• Die Bausteine von DynamoDB-Tabellen sind Items (vergleichbar mit Zeilen in relationalen Datenbanken). 
• Items enthalten ein oder mehrere Attribute, die jeweils ein Datenelement repräsentieren. 
• Wie relationale Tabellen besitzen DynamoDB-Tabellen Primärschlüssel, die jedes Item eindeutig identifizieren. Ein Primärschlüssel kann aus einem einzelnen Partitionsschlüssel oder aus Partitions- und Sortierschlüssel bestehen.
• Ein zentrales Merkmal von DynamoDB-Tabellen ist ihre Schemafreiheit: Jedes Item kann eigene Attribute besitzen.

Im Tutorial verwenden wir eine einfache Tabelle Products, um die Migration zu demonstrieren. Die Daten liegen im JSON-Format vor: 

	{
    	"product_id": "P001",
    	"category": "Electronics",
    	"price": 700,
    	"product_name": "Phone"
	},
	{
    	"product_id": "P002",
    	"category": "Electronics",
    	"description": "The laptop is a Macbook.",
    	"price": 1000,
    	"product_name": "Laptop"
	}

Zwei Punkte sind wichtig:

• Das product_id dient als Primärschlüssel.
• Die Attribute der beiden Items sind nicht identisch, da beim ersten Item das Attribut description fehlt.

Diese Daten werden im Setup in eine Tabelle in DynamoDB geschrieben.

DynamoDB-Tabellen-Items. Bild: Autorin/Autor

Amazon Redshift einrichten

Als Nächstes wird eine Tabelle in Redshift eingerichtet, die die Daten aus der DynamoDB-Tabelle aufnimmt. 

1. Öffne die Redshift-Konsole und wähle „Create cluster“.

AWS ermöglicht, vor dem Start des Clusters verschiedene Parameter festzulegen. Für dieses Tutorial konzentrieren wir uns auf die Einstellungen, die für die Migration notwendig sind.

Cluster in der Redshift-Konsole erstellen. Bild: Autorin/Autor

2. Wähle Knotentyp und Anzahl der Knoten passend zum Datenvolumen.

Für die Migration der Tabelle Products reicht geringe CPU-Kapazität und ein einzelner Knoten aus.

Cluster-Konfiguration anpassen. Bild: Autorin/Autor

3. Lege Admin-Benutzername und Passwort für den Cluster fest.

Bewahre die Zugangsdaten sicher auf. Du brauchst sie später, um über andere AWS-Services auf den Cluster zuzugreifen.

Cluster-Konfiguration anpassen. Bild: Autorin/Autor

4. Weisen dem Cluster eine IAM-Rolle zu.

Die IAM-Rolle benötigt Richtlinien, die dem Cluster das Lesen von DynamoDB-Tabellen und das Erstellen von Tabellen in Redshift erlauben. 

IAM-Rolle dem Redshift-Cluster zuweisen. Bild: Autorin/Autor

5. Wechsle nach dem Erstellen des Clusters in den Query-Editor und lege mit dem Befehl CREATE die Zieltabelle für die DynamoDB-Daten an:

CREATE TABLE Products (
	product_id VARCHAR(50) PRIMARY KEY,
	category VARCHAR(50),
	description VARCHAR(100),
	price INT,
	product_name VARCHAR(50),
	stock_quantity INT
);

Passe den obigen Befehl an deine Zieldaten an und berücksichtige weitere nötige Constraints.

Das war’s! Du kannst mit der Datenübertragung starten.

Methode 1: Datenübertragung von DynamoDB nach Redshift mit dem COPY-Befehl

Amazon Redshift bietet den COPY-Befehl, der Daten aus einer AWS-Quelle in eine Tabelle lädt.

1. Führe die Migration mit dem COPY-Befehl aus. 

Die Syntax lautet:

COPY <table_name>
FROM <dynamo_db_table_path>
IAM_ROLE 'arn:aws:iam::<aws-account-id>:role/<role-name>'
REGION <region_name>';

Um Daten aus der DynamoDB-Tabelle Products in die Redshift-Tabelle Products zu laden, kannst du den Befehl wie folgt anpassen:

COPY Products
FROM 'dynamodb://Products'
IAM_ROLE  'arn:aws:iam::<1234567890>:role/<dynamo_db_redshift_role>'
REGION ‘us-east-1’

Vorteile des COPY-Befehls

Der COPY-Befehl ist eine der einfachsten Methoden, um Daten von DynamoDB nach Redshift zu verschieben. Der Einrichtungsaufwand ist gering und die Handhabung auch für Personen ohne große Erfahrung im Aufbau von ETL-Pipelines gut machbar. 

Zudem erfolgt die Übertragung direkt, sodass keine weiteren AWS-Services nötig sind.

Nachteile des COPY-Befehls

Der größte Nachteil ist, dass sich das Mapping der Attribute aus der DynamoDB-Tabelle auf die Felder der Redshift-Tabelle nicht konfigurieren lässt. Diese fehlende Flexibilität kann dazu führen, dass der COPY-Befehl Felder in Redshift weglässt oder falsch zuordnet. 

Außerdem überträgt der Befehl alle Daten in einem Batch. Wenn bereits Datensätze nach Redshift migriert wurden, ist das ineffizient – redundante Übertragungen erhöhen Laufzeit und Speicherkosten.

Methode 2: Datenübertragung von DynamoDB nach Redshift mit AWS Glue

AWS Glue ist ein Service zum Erstellen von Extract-Transform-Load-(ETL)-Pipelines. Mit einem ETL-Job lassen sich Daten von DynamoDB nach Redshift übertragen.

Wenn du neu bei Glue bist, empfiehlt sich das Tutorial Getting Started with AWS Glue.

In dieser Anleitung lesen wir die Tabelle Products in DynamoDB ein, speichern das Ergebnis als CSV-Datei in einem S3-Bucket und laden die Daten anschließend in die Redshift-Tabelle Products. 

1. Öffne die S3-Konsole und erstelle einen Bucket für die CSV-Datei.

AWS S3-Konsole. Bild: Autorin/Autor

2. Öffne die AWS Glue-Konsole und wähle in der linken Navigation „ETL jobs“, um den Job zu erstellen. 

AWS Glue-Konsole. Bild: Autorin/Autor

3. Wähle den Modus zur Job-Erstellung.

AWS bietet drei Modi: Visual ETL, Notebook und Script Editor. Je nach Erfahrung kannst du per Drag-and-drop (Visual ETL), in einer interaktiven Umgebung (Notebook) oder durch pures Coding (Script Editor) arbeiten.

Glue-Jobs lassen sich manuell in Python oder Spark schreiben. Wenn du in diesen Sprachen weniger geübt bist, ist Visual ETL eine gute Wahl, da sich Jobs rein per Klick konfigurieren lassen.

Der Glue-Job in diesem Tutorial wird im Code-Editor in Python erstellt. Wenn dich die Visual-ETL-Variante interessiert, schau in die AWS-Dokumentation.

4. Weise dem Job eine IAM-Rolle zu. 

Für dieses Tutorial braucht die Rolle Zugriff auf DynamoDB, Redshift und S3. 

IAM-Rolle für den Glue-Job zuweisen. Bild: Autorin/Autor

5. Nach dem Erstellen des Jobs wechsle zum Tab „Job details“ und fülle die Basis-Eigenschaften aus.

Glue-Jobdetails ausfüllen. Bild: Autorin/Autor

Hier legst du u. a. die Data Processing Units (DPUs), Wiederholungsversuche und das Timeout fest. Im Tutorial bleiben wir bei den Standardwerten. Passe die Parameter an die Anforderungen deines Jobs an. 

6. Wechsle zum Tab „Script“ und implementiere deine Logik. 

Der ETL-Job zur Migration der Products-Daten führt folgenden Code aus:

import boto3
import csv
import time
import os
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.context import SparkContext
from awsglue.utils import getResolvedOptions
import sys
# initialize Glue context
args = getResolvedOptions(sys.argv, ["JOB_NAME"])
sc = SparkContext()
glueContext = GlueContext(sc)
job = Job(glueContext)
job.init(args["JOB_NAME"], args)
# initialize DynamoDB client and scan the table
dynamodb = boto3.client('dynamodb', region_name=os.getenv('AWS_REGION'))
response = dynamodb.scan(TableName=os.getenv('DYNAMODB_TABLE'))
# extract and write data to a CSV file
items = response['Items']
csv_file = '/tmp/products.csv'
# write each row in the table
with open(csv_file, mode='w', newline='') as file:
	writer = csv.writer(file)
	writer.writerow(['product_id', 'category', 'description', 'product_name', 'stock_quantity', 'price'])
	for item in items:
    	writer.writerow([
        	item.get('product_id', {}).get('S', ''),
        	item.get('category', {}).get('S', ''),
        	item.get('description', {}).get('S', ''),
        	item.get('product_name', {}).get('S', ''),
        	item.get('stock_quantity', {}).get('N', 0),
        	item.get('price', {}).get('N', 0)
    	])
# upload the csv file to S3
s3 = boto3.client('s3', region_name=os.getenv('AWS_REGION'))
bucket_name = os.getenv('S3_BUCKET_NAME')
s3_key = 'products/products.csv'
s3.upload_file(csv_file, bucket_name, s3_key)
# wait for the file to upload before continuing
time.sleep(10)
# load data into Redshift using the COPY command
redshift = boto3.client('redshift', region_name=os.getenv('AWS_REGION'))
copy_command = f"""
	COPY Products FROM 's3://{bucket_name}/{s3_key}'
	IAM_ROLE 'arn:aws:iam::{os.getenv('AWS_ACCOUNT_ID')}:role/{os.getenv('REDSHIFT_ROLE')}'
	FORMAT AS CSV
	IGNOREHEADER 1;
"""
cluster_id = os.getenv('REDSHIFT_CLUSTER_ID')
database = os.getenv('REDSHIFT_DATABASE')
db_user = os.getenv('REDSHIFT_DB_USER')
# execute the copy statement
response = redshift.execute_statement(
	ClusterIdentifier=cluster_id,
	Database=database,
	DbUser=db_user,
	Sql=copy_command
)
# Commit the job
job.commit()

Schritt für Schritt macht das Skript Folgendes:

1. Richtet mit der Bibliothek awsglue den Job zur Ausführung ein
2. Greift mit boto3, dem Python-SDK für AWS, auf die DynamoDB-Tabelle zu
3. Schreibt die Items in den Speicher und exportiert sie als CSV in den S3-Bucket
4. Greift mit boto3 auf den Redshift-Cluster zu
5. Erstellt und führt einen COPY-Befehl aus, der die CSV-Daten in die Redshift-Tabelle lädt

Hinweis: Der Beispielcode zeigt eine von vielen möglichen Umsetzungen. AWS Glue ist flexibel – baue die ETL-Pipeline so, dass sie genau zu deinem Bedarf passt. 

7. Speichere den Code und klicke auf „Run“, um den Job auszuführen.

Script-Editor für den Glue-Job. Bild: Autorin/Autor

8. Überwache den Fortschritt im Tab „Runs“. Dort werden Fehler und Probleme angezeigt. 

Prüfe den Status und die Logs, um sicherzustellen, dass alles wie erwartet gelaufen ist.

AWS Glue-Tab „Runs“ mit abgeschlossenem Job. Bild: Autorin/Autor

Ist der Job erfolgreich, kannst du ihn nach Bedarf manuell starten oder zeitgesteuert ausführen – für eine effiziente und automatisierte Migration.

Vorteile von Glue

AWS Glue bietet umfangreiche Möglichkeiten zur Anpassung, sodass du Jobs genau auf deine Anforderungen zuschneiden kannst. Jobs lassen sich außerdem periodisch planen (z. B. täglich) und automatisieren. Dank Integration mit vielen weiteren Services kannst du neben DynamoDB auch andere Quellen einbinden. 

Nachteile von Glue

Die Konfiguration eines ETL-Jobs in Glue erfordert Aufwand und Zeit. Auch wenn du nicht zwingend programmieren musst, ist Know-how nötig, um bestimmte Features – etwa die AWSGlue-Bibliothek oder ein SDK – auszuschöpfen. 

Zudem laufen Glue-Jobs selten auf Anhieb fehlerfrei – plane Zeit fürs Troubleshooting ein. Und: Ohne Kontrolle können die Kosten schnell steigen. Stelle nur die wirklich benötigten Ressourcen bereit. 

Methode 3: Datenübertragung von DynamoDB nach Redshift mit DynamoDB Streams

DynamoDB Streams zeichnet Änderungen an DynamoDB-Tabellen in Echtzeit auf. Damit kannst du die Redshift-Tabelle automatisch aktualisieren, sobald sich in DynamoDB etwas ändert. 

Details zur Nutzung findest du in der AWS-Dokumentation.

Für diese Lösung brauchst du Zugriff auf AWS DynamoDB, Redshift und Lambda. Eine Lambda-Funktion wird ausgelöst, sobald in der DynamoDB-Tabelle Products ein Item hinzugefügt oder geändert wird. 

So gehst du vor: 

1. Öffne die Lambda-Konsole und wähle „Create Function“.

AWS Lambda-Konsole. Bild: Autorin/Autor

2. Gib die Basisinformationen zur Funktion an, inklusive Programmiersprache und IAM-Rolle.

Die Rolle benötigt Zugriff auf Lambda, DynamoDB und Redshift.

Lambda-Funktion konfigurieren. Bild: Autorin/Autor

3. Füge nach dem Erstellen der Funktion die DynamoDB-Tabelle (hier: Products) als Trigger hinzu.

Das Diagramm sollte nun so aussehen:

Trigger zur Lambda-Funktion hinzufügen. Bild: Autorin/Autor

4. Wechsle in den Tab „Configuration“ und erhöhe Speicher und Laufzeit, da die Standardwerte oft nicht ausreichen.

Trigger-Konfiguration für die Lambda-Funktion. Bild: Autorin/Autor

5. Schreibe im Tab „Code“ die Migrationslogik in der gewünschten Sprache.

Das folgende Snippet zeigt ein mögliches Lambda-Beispiel in Python:

import boto3
import os
import json
def lambda_handler(event, context):
	# Initialize the Redshift Data API client
	redshift_client = boto3.client('redshift-data')
	# Redshift cluster details 
	cluster_id = os.environ['REDSHIFT_CLUSTER_ID']
	database = os.environ['REDSHIFT_DB_NAME']
	user = os.environ['REDSHIFT_USER']
	# IAM role ARN that has access to Redshift Data API
	role_arn = os.environ['REDSHIFT_ROLE_ARN']
    
	# Process DynamoDB stream records
	for record in event['Records']:
    	if record['eventName'] in ['INSERT', 'MODIFY']:
        	new_image = record['dynamodb']['NewImage']
        	product_id = new_image['product_id']['S']
        	category = new_image['category']['S']
        	description = new_image['description']['S']
        	price = float(new_image['price']['N'])
        	product_name = new_image['product_name']['S']
        	stock_quantity = int(new_image['stock_quantity']['N'])
       	 
        	# SQL query to insert data into Redshift
        	query = f"""
            	INSERT INTO products (product_id, category, description, price, product_name,   stock_quantity)
            	VALUES ('{product_id}', '{category}', '{description}', {price}, '{product_name}', {stock_quantity});
        	"""
       	 
        	# Execute the query using Redshift Data API
        	response = redshift_client.execute_statement(
            	ClusterIdentifier=cluster_id,
            	Database=database,
            	DbUser=user,
            	Sql=query
        	)
       	 
        	# Log the statement ID for tracking
        	print(f'Started SQL statement with ID: {response["Id"]}')
    
	return {
    	'statusCode': 200,
    	'body': 'SQL statements executed successfully'
	}

Kurz gesagt: Die Funktion liest die von DynamoDB Streams protokollierten Inserts/Änderungen und schreibt sie per SQL-Query über einen Redshift-API-Client in die Redshift-Tabelle. 

Aus Sicherheitsgründen werden Schlüsselwerte (z. B. die Redshift-Cluster-ID) als Umgebungsvariablen gespeichert statt hardcodiert.

Mehr zu Umgebungsvariablen in Lambda findest du in der AWS-Dokumentation.

6. Deploye die Funktion und teste sie auf Fehler. 

Je nach Use Case lohnt es sich, eigene Testfälle zu entwerfen. 

Ergebnisse der Lambda-Ausführung. Bild: Autorin/Autor

Wenn die Lambda-Funktion läuft, musst du die DynamoDB-Tabelle so konfigurieren, dass sie die Funktion bei neuen oder geänderten Items ausführt.

7. Wähle die DynamoDB-Tabelle und öffne den Tab „Exports and streams“.

DynamoDB-Konsole: Tab „Exports and streams“. Bild: Autorin/Autor

8. Scrolle zu „DynamoDB stream details“ und klicke auf „Turn on“.

DynamoDB-Konsole: Exports and streams. Bild: Autorin/Autor

9. Wähle anschließend, welche Informationen im Stream protokolliert werden sollen.

Details zu DynamoDB Streams. Bild: Autorin/Autor

10. Nach dem Aktivieren des Streams scrolle auf derselben Seite weiter nach unten und erstelle den Trigger.

Trigger zum Aufrufen einer Lambda-Funktion in DynamoDB erstellen. Bild: Autorin/Autor

11. Wähle bei der Trigger-Konfiguration die zuvor erstellte Lambda-Funktion aus und klicke auf „Create trigger“.

Auszuwählende Lambda-Funktion für den Trigger. Bild: Autorin/Autor

Mit dieser Lösung werden Änderungen in der DynamoDB-Tabelle automatisch in Redshift übernommen – für konsistente Daten in Echtzeit. 

Vorteile von DynamoDB Streams

DynamoDB Streams ermöglichen eine Echtzeit-Synchronisation zwischen DynamoDB und Redshift. So bleiben Redshift-Tabellen ohne manuelle Eingriffe aktuell. 

Häufige Aktualisierungen sind damit möglich und können Anwendungen mit hohem Datendurchsatz unterstützen (z. B. Echtzeit-Dashboards). Außerdem sinkt das Risiko menschlicher Fehler bei jeder Iteration. 

Nachteile von DynamoDB Streams

Für die Einrichtung müssen mehrere AWS-Services konfiguriert werden, was zeitaufwändig sein kann. 

Da Lambda ein Function-as-a-Service-(FaaS)-Tool ist, brauchst du solide Kenntnisse in mindestens einer Programmiersprache. Zudem erhöhen die nötigen API-Aufrufe je Synchronisationslauf die Gesamtkosten – besonders bei häufigen Updates. Für Vollmigrationsläufe ganzer Tabellen ist diese Lösung weniger geeignet als für kleinere Änderungen. 

Datenmigration verifizieren

Datenvalidierung ist ein essenzieller Schritt nach dem Aufbau der Migrationslösung. Selbst wenn alle AWS-Services fehlerfrei laufen, können im Prozess logische Fehler, falsche Attributzuordnungen oder unvollständige Übertragungen auftreten. 

Die migrierten Daten müssen frei von solchen Problemen sein, damit Analysen in Redshift zuverlässig funktionieren.

In diesem Abschnitt findest du Prüfungen und Techniken zur Kontrolle der migrierten Daten – am Beispiel der Tabelle Products. 

Spaltenstruktur und Datentypen prüfen

Stelle sicher, dass alle Spalten der DynamoDB-Tabelle in Redshift vorhanden und korrekt typisiert sind. 

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = Products;

Zeilenanzahl verifizieren

Vergleiche die Anzahl der Zeilen in der Redshift-Tabelle mit der Quelle, um die vollständige Übertragung zu bestätigen. 

SELECT COUNT(*) FROM your_table_name;

Datenvorschau

Als Alternative zur Spalten- und Typprüfung kannst du eine Vorschau ziehen und Unstimmigkeiten per Blickprüfung erkennen. 

SELECT product_id, category, price FROM your_table_name LIMIT 5;

Komplexe Geschäftslogik validieren

Für manche Datensätze reichen Vorschauen oder Counts nicht aus. Wenn du komplexere Kriterien prüfen musst, erstelle Views.  

Angenommen, die Tabelle Products sollte nie einen niedrigen Bestand an Elektronikartikeln aufweisen. Das lässt sich mit folgender Abfrage überwachen.

CREATE OR REPLACE VIEW low_stock_electronics AS
SELECT
	Product_id, product_name, category, stock_quantity, price,
FROM
	your_table_name
WHERE
	stock_quantity < 50 AND
	Category = ‘Electronics;

Performance in Redshift optimieren

Query-Performance zu optimieren ist entscheidend, um Insights effizient und kostengünstig zu gewinnen. Schreibe Abfragen speicherschonend und laufzeitarm – insbesondere, wenn dein Datensatz mit jeder Migration wächst. 

Hier sind einige Methoden zur Optimierung – erneut am Beispiel der Tabelle Products. 

Einen Distribution Key wählen

In Redshift bestimmen Distribution Keys, wie Daten über die Knoten in einem Cluster verteilt werden. Die passende Wahl kann Abfragen beschleunigen. 

Wenn die Tabelle Products häufig über product_id mit anderen Tabellen verknüpft wird, lohnt es sich, product_id als Distribution Key zu setzen. 

CREATE TABLE products (
	product_id VARCHAR(100),
	category VARCHAR(100),
	description VARCHAR(100),
	price INT,
	stock_quantity INT
)
DISTKEY(product_id);

Einen Sort Key wählen

Die richtige Wahl des Sort Keys beschleunigt gängige SQL-Operationen wie Filter und Joins. In Redshift kannst du einen Sort Key manuell wählen oder automatisch bestimmen lassen. Es gibt zusammengesetzte (Compound) und verschachtelte (Interleaved) Sort Keys. Der beste Ansatz hängt von deinen Abfragen ab. 

CREATE TABLE products (
	product_id VARCHAR(100),
	category VARCHAR(100),
	description VARCHAR(100),
	price INT,
	stock_quantity INT
)
COMPOUND SORTKEY(category, product_id);

Mehr zu Sort Keys findest du in der AWS-Dokumentation. 

Kompression nutzen

Bei der Kompression werden Daten mit weniger Bits codiert. Das spart Speicherplatz, ohne Information zu verlieren. 

Wenn du unsicher bist, welche Kompression passt, kann Redshift per Analyse die beste Codierung je Feld vorschlagen – mit folgendem Befehl:

ANALYZE COMPRESSION <table_name>;

Fazit und nächste Schritte

Die Migration von Daten aus DynamoDB nach Redshift ermöglicht es dir, die OLAP-Fähigkeiten von Redshift für komplexere Analysen zu nutzen. 

In diesem Tutorial hast du drei Migrationswege kennengelernt – jeweils mit Stärken und Schwächen. Wähle die beste Option, indem du Analyseziele, Datenrestriktionen und Budget sorgfältig abwägst, um die für deinen Use Case effektivste Lösung umzusetzen.

Ein guter nächster Schritt ist der Kurs Introduction to Redshift, um Grundlagen zu lernen oder aufzufrischen. Alternativ vertieft der Kurs AWS Security and Cost Management Themen, die alle AWS-Anwendenden beherrschen sollten.