Datalake comparaison - 7 redshift

Dans ce chapitre nous allons nous consacrer à la solution Redshift, une solution managée sur AWS, cette solution a été développée par Amazon et est de ce fait une exclusivité AWS.
Si vous voyez des erreurs commises dans ce comparatif veuillez nous adresser un mail à
contact@domwee.com nous nous efforcerons de corriger le plus rapidement possible.
  1. Architecture simplifiée
    L’architecture est originale elle mélange deux mondes qui semblent être opposés et essaye de tirer le meilleur parti des avantages de chacun, il s’agit d’une architecture distribuée de SGBDR et en l’occurrence de PostgreSQL.
    La distribution des données se fait soit selon une colonne définie en index soit de manière automatique. L’idée derrière cette architecture est d’essayer de tirer le meilleur des deux mondes et généralement quand on essaye de faire cohabiter des philosophies qui s’opposent on ne récolte généralement que le pire des deux mondes. Heureusement dans ce cas là les deux mondes sont complémentaires et ne sont pas vraiment opposés. Le coup de maître dans ce choix est le fait que AWS n’a pas eu besoin de réinventer la roue et possède d’emblée toutes les fonctions SQL de PostgreSQL ce qui assure une compatibilité avec beaucoup d’outils actuels qui utilisent le SQL comme langage. Ce choix conserve le problème de toute bases données d’ancienne génération à savoir le fait qu’il faut que le moteur de la base de données soit démarré en permanence sur tous les noeuds. Dans certains cas les bases de données ne servent qu’à lire les données pour les envoyer vers un autre noeud (citons les exemples suivants : jointures, sous requête et il y en a d’autres apparemment dans la documentation Resdhift fait de l’arrangement de données fréquemment) la lecture de données depuis une base de données n’apporte pas grand chose par rapport à un système de fichier classique, nous ne voyons donc pas l’intérêt de conserver autant de base de données PostgreSQL en fonctionnement constamment : c’est une perte d’énergie et d’argent. Comme pour BigQuery les données sont stockées en colonne. Redshift accepte les Update et les Delete et cela ne veut dire qu’une chose pour nous c’est que Redshift a renoncé à la compression de données. Cela a son avantage quand on manipule la granularité la plus fine mais cela perd un peu de sens quand on agrège les données.
    1. BigData
      Comme tout système distribué il est pensé pour faire du BigData. Cette solution s’appuie sur un moteur de SGBDR qui a fait ses preuves et qui séduit de plus en plus de monde. Certaines requêtes complexes avec des jointures va imposer au système de redistribuer les données ce qui devrait coûter un peu de temps à la requête mais en tout cas cette solution propose de faire des jointures et pour une base de données BigData c’est un gros avantage par rapport à beaucoup de concurrents. 
    2. Datawarehouse
      Cette base de données permet les jointures et les mises à jour. C’est un excellent candidat pour faire une base de données décisionnelle.
    3. Reporting
      Redshift de par son architecture distribuée est en théorie capable de bien gérer les pics de charge, hélas il n’y a aucune adaptation des ressources par rapport à la demande et donc nous sommes obligés d’anticiper les pics de charge et de faire tourner des ressources inutilement quand la demande est moins forte.
    4. Datalake
      Cet outil ferait un très bon datalake, il ne gère pas les données non-structurées mais ce n’est pas très important d’après nous. Le seul point noir de cette solution est le fait qu’il faille soit même définir à l’avance les ressources machines, il n’y aucun coût à la demande et pour un datalake qui sert de base d’outil d’analyse ponctuel cela va entraîner une sous utilisation des ressources et du gaspillage d’argent et d’électricité.
    5. Base de données Applicative
      Cette solution a été développée pour faire de l’analyse de données et pas pour faire des applications, cela dit nous ne voyons pas de lacune dans cette architecture qui empêcherait d’utiliser cette base de données en tant que base de données applicatives.
  2. Utilisateurs
    Le langage utilisé est SQL ANSI le standard que tous les data engineer utilisent. Amazon propose une interface web pour faire les requêtes qui répond aux attentes dans ce domaine. Rien à redire sur ce point Redshift fait parti des bons élèves. 
  3. Fonctionnalités additionnelles
    Ici ne seront traitées que les fonctionnalités natives présentent dans le moteur de la base de données, sinon ce tableau n’aura aucun sens puisqu’avec du développement ou des addons on pourrait tout faire avec n’importe quelle base de données.
    - Géographiques :
    - Graphes :
    - IP :
    - Window : Oui
    - ML : 
  4. Administrateur
    C’est une solution managée mais il faut surveiller l’utilisation parce que le choix de la puissance (nombre de noeuds) est manuel. Une trop grosse marge dans cette partie va conduire à une très grosse facture tandis que ne pas mettre assez d’argent va rendre l’outil inintéressant.
  5. Experts quand pourquoi
    Cette solution va sûrement nécessiter des experts au moment d’optimiser les coûts et le temps de certaines requêtes. Il n’est pas indispensable d’avoir des experts à temps plein.
  6. Droits et sécurité
    Niveau droits tout y est et à tous les niveaux, tables, schéma, base de données…
    Redshift fait fort sur ce point.
  7. Logs et alertes
    Les logs sont très complets trois tables sont créées par Redshift, une table qui recense les connexions, une table qui recense les changements de droits, les modifications sur les objets et une table qui recense les requêtes. Il y a une possibilité d’exporter ces logs vers S3 le système de stockage d’AWS. Le seul reproche que nous pourrions faire est sur le fait qu’il n’y a pas de système d’alerte prévu mais il est possible de s’en créer un maison vu que tout est stocké dans la base de données.
  8. Coût et gestion
    C’est le point faible de cette solution le coût parce que le coût ne s’adapte pas automatiquement à l’utilisation, il est aux nombre de nodes ouverts et c’est à vous de déterminer combien de nodes vous créez. Maintenant pour une petite structure avec le minimum de node pour un petit datawarehouse le prix est très abordable. Bref tout dépend vos besoins mais d’après nous Redshift pourrait faire mieux et d’autres solutions le surpassent dans ce domaine.
  9. Fin d’utilisation
    Redshift est le meilleur dans ce domaine, il a des fonctionnalités d’export avancées avec le choix du format, de la taille des fichiers à ne pas dépasser et la possibilité de chiffrer le fichier. Bref du très très bon on voudrait que toutes les solutions soient à ce niveau. Excellent travail.
  10. Documentation et API
    La documentation est bien fournie, il y a de nombreux exemples et elle est même traduite (du moins pour le français). Encore une fois Redshift faire fort. Côté API en revanche c’est un peu moins bien, il y a beaucoup de choses disponibles pour la configuration des clusters mais pas grand chose pour utiliser le produit malheureusement.
Les notes vont de 0 à 5 (5 étant la meilleure)

1.1
B
I
G
D
A
T
A
1.2
DWH
1.3
R
E
P
O
R
T
1.4
D
A
T
A
L
A
K
1.5
A
P
P
S
2
U
T
I
L
I
S
A
3
F
O
N
C
T
+
4
A
D
M
5
E
X
P
E
R
T
6
D
R
O
I
T
S
7
L
O
G
S
8
C
O
U
T
9
F
I
N
10
D
O
C
Redshift
3,5
4
4
3,5

4,5

3
5
5
5
2,5
5
4

Conclusion : C’est une très bonne solution, il y a de très bonnes idées derrière, cette base de données peut tout faire, c’est un très bon choix pour ceux qui veulent faire beaucoup de choses différentes avec un seul outil. Attention au coût si vous vous lancez dans de la grosse volumétrie.

 Plan :
1 introduction
6 BigQuery
7 Redshift


Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Datalake comparaison - 10 Conclusion

Franchement nous avions d’énormes à priori avant de commencer ce comparatif et honnêtement le résultat nous surprend nous même. Toutes les solutions analysées présentent des intérêts et aucune ne peut prétendre être la solution ultime, c’est d’ailleurs celle qui veut tout faire à la fois qui pour nous est la moins intéressante. Nous ne pouvons que saluer les efforts d’innovations que les différents éditeurs ont trouvées et nous les remercions de proposer des outils qui permettent de traiter nos chères données. En effet nous parlons toujours comme si LA donnée était une seule entité et devait se traiter de la même manière mais c’est faux il y a plusieurs types de données : les chaudes qui sont consommées immédiatement, les froides qu’on ne va voir qu’une fois de temps en temps, il y a aussi des données qui servent à tirer des tendances, il y a des données qui servent à savoir ce qu’il s’est passé pour trouver une cause au problème, il y a des données confidentielles, il y a d...
Lire la suite

Load Balancer

Image
Le load balancer est un composant majeur dans Google Cloud platform , Il participe comme son nom l’indique à router les utilisateurs sur une ressource disponible. Il participe également à la bonne santé du système complet car son premier rôle est de servir de point d’entrée ce qui simplifie grandement la vie des utilisateurs et des développeurs. C’est un aiguilleur qui dirige les utilisateurs vers la bonne ressource. C’est un organe essentiel  d’une solution cloud. De plus lors d’un changement de logiciel ou de mise à niveau cela évite aux utilisateurs de devoir changer leurs raccourcis et leurs habitudes. Il permet donc de faire des déploiements sans rupture de service. Après le déploiement, les utilisateurs ne changent rien à leurs habitudes et le load balancer envoie toutes leurs demandent à la nouvelle application et un lien direct peut être mis en place pour certains utilisateurs qui ont encore besoin de se connecter à l’ancienne application. ...
Lire la suite

Data loss prevention API

Image
Les entreprises traitent de plus en plus leur données automatiquement. Plusieurs profils peuvent être amenés à “jouer” avec leurs données : data scientists internes, data scientists externes ou entreprises spécialisées dans ce domaine. Par faute de temps ou par manque d’outil les données fournies ne sont pas toujours pré traitées et sont souvent envoyées telles quelles, or cela a deux inconvénients : le premier (que tout le monde avait trouvé) transmettre des informations importantes inutiles et donc augmenter le risque de fuite d’information, Le deuxième c’est qu’une donnée trop riche nuit à son traitement. Je donne un exemple pour un ordinateur un numéro de téléphone est une suite de 4 numéros et s’ils ne sont pas contextualisé il prendra cela pour 4 numéros de 2 chiffres. Dans certains cas il est préférable de remplacer ces 4 séries de chiffres par un libellé comme NumTéléphone pour faire comprendre à l’algorithme que c’est l’information de la présence de numéro...
Lire la suite