Amazon Redshift, la base de données orientée colonne pour le Data Warehouse par AWS

Amazon Redshift logo
LinkedIn 0
Twitter
Facebook 0
Google+ 0

Amazon Web Services (AWS) a révolutionné la manière de déployer les infrastructures IT. En introduisant la notion d’infrastructure à la demande, scalable et cela à un coût maitrisé, AWS a bouleversé les pratiques traditionnelles de l’informatique.

AWS propose une multitude de services managés et de moteurs de bases de données différents pour couvrir tous les patterns d’usages de la data. L’offre de service RDS couvre les usages classiques des SGBD transactionnels avec Aurora (moteur PostgreSQL ou MySQL). La base de données managée AWS Neptune couvre les besoins de bases en Graph, DynamoDB assure la fonction de base de données NoSQL, tandis que la nouvelle base Amazon Timestream est capable de gérer les séries temporelles (Time series database).

Le domaine Data Warehousing (entrepôt de données) est quant à lui couvert par la plateforme de bases de données managées Amazon Redshift. C’est cette dernière que nous allons analyser plus en détail aujourd’hui.

 

Introduction à AWS Redshift

Amazon Redshift est présentée par AWS comme un service de data warehouse entièrement managé, capable de gérer des volumes de données de l’ordre du petabyte. On peut dès lors parler de « Big Data », même si ce terme a été utilisé à outrance. En se basant sur un standard du marché (PostgreSQL), cette base est capable de s’interfacer avec l’ensemble de l’écosystème des outils décisionnels existants. Son principe repose sur une architecture massivement parallèle répartie sur de multiples nœuds (MPP) et faisant appel à un stockage en mode colonne de la donnée.

Les fonctionnalités d’Amazon Redshift

La donnée est stockée dans une base de données relationnelle (mais pas uniquement… nous verrons cela par la suite) et est requêtable via le langage SQL. Les requêtes sont analysées par l’optimiseur et réparties sur les différents nœuds qui composent le cluster. Si vous êtes familiers avec le langage SQL, vous n’avez rien à apprendre puisque Redshift est basé sur le moteur PostgreSQL. Outre sa facilité d’utilisation et de déploiement, AWS met en avant les fonctionnalités suivantes :

  • Architecture Massivement Parallèle (MPP)
  • Tolérance de panne
  • Intégration avec des outils tiers
  • Haute tolérance à des charges concurrente mixtes
  • Audit et compliance
  • Isolation réseau

 

Sous le capot d’Amazon Redshift

Afin de comprendre les qualités mises en avant par AWS, penchons nous sous le capot et regardons ce qu’il y a dans le moteur de Redshift. Redshift est un fork de PostgreSQL 8.0.2. Outre les modifications du moteur en lui-même, la syntaxe SQL peut différer quelque peu de PostgreSQL, il faut donc bien veiller à comprendre les différences en se référant à ce document : Amazon Redshift and PostgreSQL

Une base de données orientée colonne

Contrairement aux bases de données classiques, un SGBD orienté colonne stocke ses données en les regroupant par colonnes au lieu de les regrouper par lignes. Les bases de données orientées colonnes sont particulièrement utiles pour les entrepôts de données, les applications analytiques ou Big Data, car elles permettent d’obtenir des temps de réponses très rapides à des requêtes extrêmement complexes.

Principe

Un système de base de données relationnelle doit présenter ses données sous une forme de table à deux dimensions, en lignes et colonnes. Par exemple :

Table employees :

id Prenom Nom Salaire
1 John Doe 4000
2 Jane Daniels 10000
3 Harry Potter 5000
4 Mike Smith 2000

Dans un SGBD orienté lignes, les données seront stockées de la manière suivante :

1,John,Doe,4000;

2,Jane,Daniels,10000;

3,Harry, Potter,5000;

4,Mike,Smith,2000;

Dans un SGBD en colonnes, les mêmes données seront stockées de la manière suivante :

1,2,3,4;

John, Jane, Harry,Mike;

Doe, Daniels, Potter, Smith;

4000,10000,5000,2000;

Avantages

L’un des principaux avantages d’une base de données en colonnes tient à ce que les données peuvent être fortement compressées, car les blocs de données contiennent des types de données identiques. La compression permet donc une exécution particulièrement rapide des opérations en colonnes, notamment MIN, MAX, SUM, COUNT et AVG.

Autre avantage de cette technologie, un SGBD en colonnes est auto-indexé. A données égales, il occupe donc moins d’espace disque qu’une base de données relationnelle qui nécessite des indexes.

Requêtes Select

Si l’on réalise la requête suivante, ne ramenant qu’une seule colonne de la table précédente :

select Nom from Employees;

Avec un stockage en ligne, nous devons balayer l’ensemble blocks stockant les 4 lignes de la table, et donc des données inutiles. Avec un stockage en colonne, seuls les blocs de données contenant la colonne « Nom » sont balayés.

Par contre, si l’on effectue la requête suivante :

select * from Employees where Nom=’Doe’;

La situation est inversée : le stockage en ligne ne nécessite la lecture que d’une seule page alors que le stockage en colonne en nécessite 4.

En résumé :

  • Le stockage en colonne est plus intéressant que le stockage en ligne pour les requêtes recherchant peu de colonnes de nombreuses lignes;
  • le stockage en ligne est plus intéressant que le stockage en colonne pour les requêtes recherchant de nombreuses colonnes de peu de lignes.
Mises à jour

Si l’on réalise un ajout de lignes :

insert into employees values (‘Bob’, ‘Dills’,’2500′);

Le stockage en colonne nécessite la mise à jour de 3 pages alors qu’une seule sera modifié pour le stockage en ligne.

A contrario sur une mise à jour de colonne :

update employees set salaire=’10000′;

Il ne faudra modifier qu’une page pour le stockage en colonne contre 4 pour le stockage en ligne.

En résumé, le stockage en colonne est particulièrement adapté aux charges décisionnelles où les traitements sont effectués par batchs et dans lesquels on procède à des lectures massives sur des colonnes précises et où l’on réalise des opérations d’agrégation de colonnes.

 

Une architecture massivement parallèle (Massively Parallel Processing – MPP)

Les architectures MPP font appel à un grand nombre de processeurs et/ou de serveurs pour coordonner les traitements de manière parallèle et simultanée.

Redshift se repose sur les architectures EC2 d’AWS pour se déployer sous forme de cluster. Il n’est d’ailleurs pas possible de déployer un nœud unique.

Un cluster Redshift est composé d’un nœud Leader ainsi que de nœuds sous-jacents (compute nodes).

Leader Node

Le nœud Leader est chargé de l’orchestration de la répartition des charges de requêtes et de la répartition des données sur les compute nodes. Il est en charge des communications avec les applications clientes et les compute nodes. Il parse les requêtes et détermine les plans d’exécutions optimaux pour les requêtes les plus complexes. Après avoir déterminé les différentes étapes de traitement de chaque requête, le nœud leader compile le code et distribue ce dernier vers les compute nodes et affecte des portions d’exécution de ce dernier à chacun des compute nodes.

Compute nodes

Les données sont réparties sur tous les compute nodes du cluster afin d’optimiser les opération de traitement parallèle. Chaque nœud possède son propre système d’exploitation, sa propre mémoire et propres disques de stockage. Il s’agit d’une architecture de type « Shared Nothing », aucune ressource n’est partagée entre les nœuds. La quantité de CPU, Mémoire et stockage dépend du type de nœud choisi à la création du cluster. Il est ensuite possible de modifier la capacité de traitement et de stockage d’un cluster en modifiant le type d’instance, le nombre de nœuds ou les deux à la fois.

Redshift assure une scalabilité quasi-linéaire. Ainsi, sous réserve de correctement paramétrer la distribution des données, un cluster de 8 compute nodes traitera la même charge de travail deux fois plus vite qu’un cluster de 4 compute nodes.

Node Slices

Chaque compute node est partitionné en « slices » (tranches). Une portion de la mémoire et du disque est allouée à chaque Slice afin d’y exécuter une part du workload soumis au nœud. Le nœud leader coordonne la répartition des traitements et des données sur chaque slice. Chaque slice travaille en parallèle, ce qui multiplié par le nombre de nœuds fait de Redshift une architecture MPP.

Lorsque l’on crée une table sous Redshift, on choisit une clé de distribution. Les lignes chargées dans cette table seront ventilées sur chaque slice en fonction de cette dernière. Le choix de cette clé de distribution est donc déterminante pour exploiter au mieux les capacités de traitement parallèle de Redshift.

 

Le modèle de coût

Amazon Redshift est la solution DataWarehouse dans le Cloud la moins coûteuse à l’heure actuelle. AWS promet un coût inférieur au 1/10 du coût des architectures équivalentes on-premise. On ne paye que ce qui est consommé et pas en avance. C’est donc la plateforme idéale pour lancer un POC à moindre frais afin d’évaluer le potentiel de la plateforme.

On opte alors soit pour :

  • la tarification à la demande qui permet d’éviter de payer des frais initiaux. On est alors facturé à l’heure, en fonction du type et du nombre de nœuds dans le cluster.
  • la tarification d’instance réservée qui permet d’économiser jusqu’à 75% des coûts par rapport au tarif à la demande en s’engageant à utiliser Redshift pendant une période de 1 à 3 ans.

Le détail de la tarification peut être consulté ici Tarification d’Amazon Redshift.

Une nouvelle fonctionnalité est apparue sur Amazon Redshift : Amazon Redshift Spectrum. Cette dernière permet de requêter directement depuis un cluster Redshift des données situées sur S3, comme on le ferait sur une plateforme Hadoop/HDFS/Hive. Le modèle de tarification est alors différent : AWS facture au volume d’octets analysés.

Nous nous pencherons dans un prochain article de blog sur cette fonctionnalité particulière qu’est Amazon Redshift Spectrum.

 

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *