DynamoDB vers Redshift : trois méthodes pour migrer vos données

Prérequis et configuration

Ce tutoriel suppose que vous disposez des éléments suivants :

• Une expérience préalable d’AWS et des outils et techniques associés. 
• Une compréhension de base des bases relationnelles et NoSQL. 
• Une certaine familiarité avec SQL.
• La connaissance d’au moins un langage de programmation sera un atout.

Les méthodes de migration s’appuieront sur plusieurs services AWS cœurs, notamment :

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

Le cours AWS Cloud Technology and Services vous aidera à démarrer si vous débutez sur AWS.

La plupart des étapes seront réalisées dans la console de gestion AWS. Cependant, vous pouvez également exécuter les étapes décrites via l’interface en ligne de commande AWS (CLI) ou un SDK AWS. Libre à vous d’effectuer la migration dans l’environnement de travail de votre choix.

Préparer DynamoDB à la migration

Avant de migrer, il est important de considérer la structure des tables DynamoDB et leurs différences avec les bases relationnelles :

• Les éléments constitutifs des tables DynamoDB sont les items (similaires aux lignes en base relationnelle). 
• Chaque item contient un ou plusieurs attributs, chacun représentant un élément de donnée. 
• Comme en relationnel, les tables DynamoDB ont des clés primaires, identifiants uniques de chaque item. Une clé primaire peut être une clé de partition seule, ou la combinaison clé de partition + clé de tri.
• Caractéristique clé : les tables DynamoDB sont schemaless, chaque item pouvant avoir ses propres attributs.

Nous utiliserons une table Products simple pour illustrer la migration. Voici les données au format JSON : 

	{
    	"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"
	}

Deux points importants à noter :

• Le product_id servira de clé primaire.
• Les attributs diffèrent entre les deux items, le premier ne contenant pas l’attribut description.

Ces données sont ajoutées à une table dans DynamoDB dans le cadre de la configuration.

Items d’une table DynamoDB. Image de l’auteur

Configurer Amazon Redshift

Créez ensuite une table dans Redshift pour recevoir les données de DynamoDB. 

1. Accédez à la console Redshift et sélectionnez “Create cluster.”

AWS vous permet de définir différents paramètres avant de lancer le cluster. Dans ce tutoriel, nous nous concentrerons sur ceux nécessaires à la migration.

Création d’un cluster Redshift dans la console Redshift. Image de l’auteur

2. Choisissez le type et le nombre de nœuds adaptés au volume de données à analyser.

Pour migrer la table Products, une capacité CPU minimale et un seul nœud suffisent.

Personnalisation de la configuration du cluster Redshift. Image de l’auteur

3. Définissez l’identifiant et le mot de passe administrateur du cluster.

Conservez ces identifiants en lieu sûr : ils seront nécessaires pour accéder au cluster via d’autres services AWS.

Personnalisation de la configuration du cluster Redshift. Image de l’auteur

4. Enfin, associez un rôle IAM au cluster.

Ce rôle doit contenir des politiques autorisant le cluster à lire les tables DynamoDB et à créer des tables dans Redshift. 

Attribution d’un rôle IAM au cluster Redshift. Image de l’auteur

5. Une fois le cluster créé, ouvrez le Query Editor et créez la table qui accueillera les données de DynamoDB via la commande CREATE :

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

Adaptez la commande ci-dessus selon vos données et pensez aux contraintes complémentaires éventuelles.

Et voilà ! Vous pouvez commencer à transférer les données.

Méthode 1 : transfert de données de DynamoDB vers Redshift avec la commande COPY

Amazon Redshift met à disposition la commande COPY, qui charge dans une table des données provenant d’une source AWS donnée.

1. Exécutez la migration avec la commande COPY. 

La syntaxe de la commande est la suivante :

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

Pour ajouter les données de la table Products de DynamoDB à la table Products de Redshift, on peut utiliser :

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

Avantages de la commande COPY

La commande COPY est l’une des méthodes les plus simples pour déplacer des données de DynamoDB vers Redshift. Elle nécessite peu de configuration et reste accessible aux profils avec peu d’expérience en pipelines ETL. 

De plus, le transfert étant direct, il n’est pas nécessaire d’intégrer d’autres services AWS.

Limites de la commande COPY

Le principal inconvénient est l’impossibilité de configurer le mapping entre attributs DynamoDB et colonnes Redshift. Ce manque de flexibilité peut entraîner des omissions ou des mappages erronés dans Redshift. 

En outre, la commande transférant tout le jeu de données en un seul lot, l’opération est inefficace si certaines lignes ont déjà été migrées : cela génère des transferts redondants, allonge les temps de traitement et augmente les coûts de stockage.

Méthode 2 : transfert de données de DynamoDB vers Redshift avec AWS Glue

AWS Glue est un service conçu pour créer des pipelines d’extraction, transformation et chargement (ETL). Vous pouvez transférer des données de DynamoDB vers Redshift en créant un job ETL.

Si vous débutez avec Glue, consultez le tutoriel Getting Started with AWS Glue.

Dans ce guide, nous lirons la table Products dans DynamoDB, stockerons le résultat dans un bucket S3 au format CSV, puis chargerons ces données dans la table Products de Redshift. 

1. Allez dans la console S3 et créez un bucket pour héberger le fichier CSV.

Console AWS S3. Image de l’auteur

2. Accédez à la console AWS Glue et, dans le menu de gauche, sélectionnez “ETL jobs” pour créer votre job. 

Console AWS Glue. Image de l’auteur

3. Choisissez le mode de création du job ETL.

AWS propose trois modes : Visual ETL, Notebook et Script editor. Chaque mode s’adresse à des niveaux d’expertise différents : interface glisser-déposer (Visual ETL), environnement interactif (Notebook) ou code brut (Script Editor).

Les jobs Glue peuvent être écrits manuellement en Python ou Spark. Si vous maîtrisez moins ces langages, Visual ETL est un bon choix : la configuration se fait à la souris.

Dans ce tutoriel, le job Glue sera écrit en Python dans un éditeur de code. Pour l’option Visual ETL, consultez la documentation AWS.

4. Assignez un rôle IAM à ce job. 

Le rôle IAM doit disposer des accès à DynamoDB, Redshift et S3 pour que le tutoriel s’exécute correctement. 

Attribution d’un rôle IAM au job Glue. Image de l’auteur

5. Après avoir créé le job, ouvrez l’onglet “Job details” et renseignez les propriétés de base.

Paramétrage des détails du job Glue. Image de l’auteur

Vous pouvez y définir les DPUs (Data Processing Units), le nombre de relances et le délai d’expiration. Nous conserverons les valeurs par défaut ici, mais adaptez ces paramètres à vos besoins. 

6. Passez à l’onglet “Script” et écrivez votre logique. 

Le job ETL qui migre la table Products exécutera le code suivant :

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()

Détaillons ce que fait le script, étape par étape :

1. Initialiser le job avec la bibliothèque awsglue
2. Accéder à la table DynamoDB via boto3, le SDK Python d’AWS
3. Écrire les items en mémoire et les exporter en CSV dans le bucket S3
4. Accéder au cluster Redshift avec boto3
5. Rédiger et exécuter une commande COPY pour insérer les données du CSV dans la table Redshift

Remarque : cet exemple illustre une façon de réaliser la migration. AWS Glue est très flexible et permet de construire un pipeline ETL adapté à vos besoins. 

7. Une fois le code écrit, enregistrez puis cliquez sur “Run” pour exécuter le job.

Editeur de script du job Glue. Image de l’auteur

8. Suivez la progression dans l’onglet “Runs”, où les erreurs éventuelles apparaîtront. 

Vérifiez le statut du job et consultez les logs pour confirmer la bonne exécution.

Onglet Runs d’AWS Glue affichant un job terminé. Image de l’auteur

Une fois le job validé, vous pouvez l’exécuter à la demande ou le programmer, pour une migration plus efficace et automatisée.

Avantages de Glue

AWS Glue offre de nombreuses options de personnalisation pour créer des jobs sur mesure. Il permet également de planifier des exécutions périodiques (par exemple, quotidiennes) pour automatiser. Enfin, Glue s’intègre à de nombreux autres services, ce qui facilite les interactions avec d’autres sources que DynamoDB si besoin. 

Inconvénients de Glue

Configurer un job ETL Glue demande souvent du temps et des efforts. Sans être indispensable, la programmation est nécessaire pour tirer parti de certaines fonctionnalités (bibliothèque AWSGlue, SDK). 

Par ailleurs, les jobs Glue ne réussissent pas toujours du premier coup : prévoyez du temps pour le débogage. Enfin, les coûts peuvent vite grimper si les ressources ne sont pas calibrées finement. 

Méthode 3 : transfert de données de DynamoDB vers Redshift avec DynamoDB Streams

DynamoDB Streams est une fonctionnalité qui trace en temps réel les modifications apportées aux tables DynamoDB. En l’utilisant, vous pouvez mettre à jour automatiquement votre table Redshift à chaque changement dans DynamoDB. 

Consultez la documentation AWS pour en savoir plus sur DynamoDB Streams.

Cette solution mobilise AWS DynamoDB, Redshift et Lambda. Ici, une fonction Lambda est déclenchée lorsqu’un item est ajouté ou modifié dans la table Products de DynamoDB. 

Voici les étapes : 

1. Accédez à la console Lambda et sélectionnez “Create Function.”

Console AWS Lambda. Image de l’auteur

2. Renseignez les informations de base de la fonction, dont le langage et le rôle IAM.

Le rôle doit avoir accès à Lambda, DynamoDB et Redshift.

Configuration de la fonction Lambda. Image de l’auteur

3. Après création, ajoutez la table DynamoDB (ici Products) comme déclencheur.

Le schéma devrait maintenant ressembler à ceci :

Ajout d’un déclencheur à la fonction Lambda. Image de l’auteur

4. Dans l’onglet configuration, allouez la mémoire et le temps d’exécution nécessaires, les valeurs par défaut étant souvent insuffisantes.

Configuration du déclencheur pour la fonction Lambda. Image de l’auteur

5. Dans l’onglet “Code”, écrivez la logique de migration dans le langage de votre choix.

Voici un exemple de fonction Lambda en 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'
	}

En bref, la fonction lit le journal des items ajoutés ou modifiés par DynamoDB Streams et applique ces changements à la table Redshift en exécutant une requête SQL via un client API Redshift. 

Par sécurité, les valeurs sensibles (p. ex. l’ID du cluster Redshift) sont stockées dans des variables d’environnement plutôt que codées en dur.

Pour en savoir plus sur les variables d’environnement dans Lambda, consultez la documentation AWS.

6. Déployez ensuite la fonction et testez-la pour déceler d’éventuelles erreurs. 

Selon le cas d’usage, concevez des scénarios de test adéquats. 

Résultats d’exécution de la fonction Lambda. Image de l’auteur

Une fois la fonction Lambda opérationnelle, configurez la table DynamoDB pour l’appeler à chaque ajout ou modification d’item.

7. Sélectionnez la table DynamoDB et ouvrez l’onglet “Exports and streams”.

Onglet Exports and streams dans la console DynamoDB. Image de l’auteur

8. Descendez jusqu’à “DynamoDB stream details” et cliquez sur “Turn on”.

Onglet Exports and streams de la console DynamoDB. Image de l’auteur

9. Quand cela est demandé, sélectionnez le type d’informations à journaliser dans DynamoDB Streams.

Écran des détails de stream DynamoDB. Image de l’auteur

10. Après activation du stream, faites défiler la page pour créer le déclencheur.

Création d’un déclencheur pour invoquer une fonction Lambda dans DynamoDB. Image de l’auteur

11. Lors de la configuration du déclencheur, choisissez la fonction Lambda créée, puis cliquez sur “Create trigger”.

Sélection d’une fonction Lambda à déclencher. Image de l’auteur

Avec cette approche, toute modification de la table DynamoDB est automatiquement répercutée dans Redshift, garantissant une cohérence des données en temps réel. 

Avantages de DynamoDB Streams

DynamoDB Streams permet une synchronisation temps réel entre DynamoDB et Redshift. Vos tables Redshift restent à jour sans intervention manuelle. 

Les mises à jour fréquentes de Redshift peuvent ainsi alimenter des applications à fort débit de données (p. ex. tableaux de bord temps réel) et réduire le risque d’erreur humaine à chaque itération. 

Inconvénients de DynamoDB Streams

Cette solution exige la configuration de plusieurs services AWS, ce qui peut prendre du temps. 

Lambda étant un service FaaS (Function as a Service), une bonne maîtrise d’un langage de programmation est requise. Chaque itération de synchronisation impliquant des appels API, les coûts peuvent s’accumuler rapidement en cas de mises à jour fréquentes. Enfin, cette approche est plus pertinente pour des mises à jour incrémentales que pour des migrations complètes de tables. 

Vérifier la migration des données

La validation est une étape essentielle après la mise en place d’une migration. Même si les services AWS s’exécutent sans erreur, des problèmes non détectés peuvent subsister : incohérences logiques, mappages d’attributs incorrects, transferts incomplets, etc. 

Les données migrées doivent être exemptes de ces erreurs pour garantir la fiabilité des analyses dans Redshift.

Voici quelques vérifications et techniques pour auditer les données migrées, à partir de la table Products. 

Valider la structure des colonnes et les types

Assurez-vous que toutes les colonnes de la table DynamoDB sont bien présentes dans Redshift et avec les bons types. 

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

Vérifier le nombre de lignes

Confirmez la complétude du transfert en comparant le nombre de lignes dans Redshift avec la source. 

SELECT COUNT(*) FROM your_table_name;

Prévisualiser les données

Vous pouvez également prévisualiser les données pour repérer rapidement toute anomalie. 

SELECT product_id, category, price FROM your_table_name LIMIT 5;

Valider une logique métier complexe

Des prévisualisations ou de simples comptages ne suffisent pas toujours. Pour des critères plus élaborés, créez des vues.  

Par exemple, supposons que la table Products ne doive jamais avoir un stock faible pour l’électronique. Le suivi peut se faire ainsi :

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;

Optimiser les performances dans Redshift

Optimiser les performances des requêtes est essentiel pour extraire des insights rapidement et à coût maîtrisé. Des requêtes sobres en mémoire et rapides à exécuter deviennent cruciales au fur et à mesure que le volume de données augmente. 

Voici quelques leviers d’optimisation, illustrés avec la table Products. 

Choisir une clé de distribution

Dans Redshift, la clé de distribution détermine comment les données sont réparties entre les nœuds du cluster. Un bon choix peut réduire le temps d’exécution des requêtes. 

Par exemple, si la table Products est fréquemment jointe à d’autres tables via product_id, il est pertinent d’utiliser product_id comme clé de distribution à la création de la table. 

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

Choisir une clé de tri

Le choix de la clé de tri améliore les opérations SQL courantes (filtres, jointures). Dans Redshift, vous pouvez la définir manuellement ou laisser Redshift la sélectionner. Deux types existent : compound sort key et interleaved sort key. Le meilleur choix dépend des requêtes cibles. 

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

Pour plus d’infos sur les clés de tri, consultez la documentation AWS. 

Utiliser la compression

La compression consiste à encoder les données avec moins de bits. La table occupe ainsi moins de stockage tout en conservant l’information. 

Si vous hésitez sur le type de compression, Redshift peut analyser et proposer le meilleur encodage pour chaque colonne via :

ANALYZE COMPRESSION <table_name>;

Conclusion et prochaines étapes

Migrer des données de DynamoDB vers Redshift permet de tirer parti des capacités OLAP de Redshift pour des analyses plus complexes. 

Nous avons présenté trois approches, chacune avec ses atouts et limites. Pour choisir la meilleure, évaluez soigneusement vos besoins analytiques, vos contraintes de données et votre budget afin d’opter pour la solution la plus pertinente.

Une bonne prochaine étape est de suivre le cours Introduction to Redshift, pour découvrir ou revoir les fondamentaux. Le cours AWS Security and Cost Management est également très utile pour toute personne travaillant avec AWS.