Datalake comparaison - 5 Snowflake

Dans ce chapitre nous allons nous consacrer à la solution Snowflake.

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
    Dans l’architecture choisie les données et la puissance de calcul sont séparées. Encore une fois il s’agit d’une architecture distribuée qui fonctionne sur le même principe que ce que nous avons vu auparavant.
    La différence se situe au niveau de la séparation des données et des espaces de calcul ce qui permet à Snowflake de pouvoir proposer un système de coût à l’utilisation qui séduira plus d’une entreprise. En effet, si aucune requête n’est lancée alors l’entreprise ne paiera que l’espace de stockage des données. L’utilisation du stockage web Amazon, Azur et bientôt Google permet à Snowflake de pouvoir proposer un espace de stockage fiable, très performant et très bon marché. Cela permet aussi à Snowflake de se concentrer sur le traitement des données et c’est pourquoi cette jeune société s’est fait rapidement un nom dans ce domaine. C’est une solution fiable (stockage de données et ressources cloud) et semble très économique pour les entreprises. En fait ce coût à l’utilisation est redoutable car il permet de faire des POC ou des maquettes à prix réduit et donc de découvrir la solution et de l’adopter par la suite. Beaucoup d’éditeurs sûrs de leur solution propose ce genre d’argument commercial. Cette solution utilise le SQL.

    1. BigData
      Un système distribué sur un espace de stockage cloud, des ressources de calcul dans le cloud aussi tout est pensé pour pouvoir traiter des gros volumes de données. Le seul point faible de la solution est semble-t-il le fait que les données ne soient pas directement dans l’unité de calcul cela force la solution à charger les données dans les unités de calcul et fait perdre un temps précieux. A première vue c’est une erreur mais cela a deux avantages, le premier est que le prix est ajustable à l’utilisation et le deuxième octroie plus de souplesse et c’est ce que nous voyons dans le chapitre Datawarehouse.
    2. Datawarehouse
      Que les données ne soient pas directement dans les unités de calcul permet à la solution de pouvoir utiliser les données de manières intelligentes. Dans les précédentes pages nous avons vu que l’inconvénient des solutions où les données sont déjà réparties dans les unités de traitements c’est justement que la répartition des données n’est pas flexible elle se fait selon un index principal ou selon des critères pas toujours limpides et figent les données à un endroit. Cela empêche bien souvent de faire des jointures. Le choix de Snowflake de séparer les données et la puissance de calcul force la solution à lire les données et à répartir ces données sur les unités de calcul à chaque traitement et cela lui permet de faire des groupements de données en adéquation avec la demande et donc de pouvoir choisir quelles données mettre dans quelle unité de calcul et de ce fait de pouvoir réaliser une jointure. Ce système doit montrer ses limites quand il y a beaucoup de jointures en même temps et il faudra sûrement couper les requêtes complexes en plusieurs étapes mais sur le papier Snowflake peut réaliser ce que les solutions précédentes ne pouvaient pas faire (jointures) et donc Snowflake peut servir de datawarehouse. D’ailleurs il tire son nom de cette particularité : Snowflake (ou flocon de neige en français) est l’autre nom utilisé pour le schéma en étoile.
    3. Reporting
      Snowflake de par son architecture ne peut pas proposer de requête en dessous de quelques secondes. En effet, le temps d’organiser les données dans les unités de calcul et de récupérer les résultats de toutes ses unités de calcul pour les consolider empêche le système d’être ultra réactif sur les requêtes simples. Bien entendu sur les grosses requêtes cela est ultra performant mais il est rare de faire du reporting sur des grosses requêtes et généralement le travail en amont est bien préparé pour que les rapports s’affichent extrêmement rapidement. A part si Snowflake propose un système de cache il faudra coupler cette base de données avec des outils de reporting ayant leur propre stockage de données intermédiaire. Comme il y a tous les drivers qui vont bien ODBC et JDBC toutes devraient être compatibles. 
    4. Datalake
      Cet outil est un très bon candidat pour un datalake, son coût à l’utilisation reflète bien l’usage que l’on a d’un datalake. Le seul reproche qu’on pourrait lui faire est l’absence de stockage de données non structurées mais nous prônons la structuration des données le plus tôt possible pour faciliter et optimiser leur utilisation, ce n’est pas un vrai problème.
    5. Base de données Applicative
      Même son nom le dit, c’est une base de données qui a été pensée et développée pour faire du datawarehouse et une visite sur le site de la solution ne laisse planer aucun doute : c’est une base de données décisionnelle et pas une base de données applicative.
  2. Utilisateurs
    Le langage utilisé est SQL ANSI ce qui est parfait pour les utilisateurs, c’est ce qu’on appelle le SQL standard. Il existe une interface web pour faire les requêtes et elle est très bien faite, tout y est et cette interface respecte les codes du domaine, un utilisateur d’outil de requêtage trouvera rapidement ses marques. En revanche le fait qu’il faille allumer et éteindre le service pour économiser de l’argent est très pénible et va entraîner forcément des oublis et de la frustration utilisateur. 
  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 allumer et éteindre le service manuellement pour bénéficier du coût à la “demande”. Cette gestion va vite être pénible pour les administrateurs
  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 pour faire fonctionner cet outil.
  6. Droits et sécurité
    Encore une fois nous voyons ici tout le sérieux de cette entreprise, tous les droits sont là : base de données, schéma, table, vues… Un propriétaire est défini sur chaque objet et c’est lui qui a le privilège de donner des droits. Les codes sont respectés. Nous n’avons pas vu de droits sur les lignes mais nous rêvons nous n’avons encore jamais rencontré cela nul part sur cette couche, généralement ce besoin est réglé par l’outil de restitution mais comme les bases de données sont ouvertes de plus en plus aux partenaires, aux clients, aux fournisseurs, aux collaborateurs nous sommes persuadés que les éditeurs de bases de données le feront dans l’avenir. L’outil est compatible SAML ce qui évitera aux utilisateurs de devoir apprendre un nouveau mot de passe.
  7. Logs et alertes
    Les logs sont disponibles dans l’outil de requêtage et sont déjà bien fournies. De plus ( nous aimons beaucoup) des logs sont générés dans des tables de la base de données ce qui permet toutes les fantaisies : analyse avec des requêtes et récupération des logs avec un connecteur pour les charger dans un outil de log centralisé...
  8. Coût et gestion
    La séparation des données et du traitement de celles ci permet à Snowflake de proposer un coût à l’utilisation et cela octroie la possibilité aux entreprises de toutes tailles de s’équiper de cet outil. Snowflake fonctionne par crédit soit pré acheté soit facturé au mois selon leur utilisation. Le calcul de la consommation se fait ainsi il faut choisir la taille de son unité de calcul (nombre de processeurs) et démarrer le “warehouse”, chaque taille de warehouse correspond un nombre de processeurs de 1 à 128 (toutes les puissance de 2). Choisir un grand ou un petit warehouse ne devrait pas changer le prix des grosses requêtes puiqu’elles mettent moins de temps le service est coupé plus tôt, le nombre d’opérations reste le même. Le fait que Snowflake propose le coût à la seconde après la première minute est une très bonne chose. Côté stockage nous avons le choix entre deux propositions qui vont du simple au double et la documentation reste assez floue sur cet aspect. Nous savons juste que les tailles des données SQL sont compressées pour diminuer le coût de stockage et que l’utilisateur a le choix de compresser ou non le résultat d’une requête qu’il souhaiterait stocker en CSV pour une utilisation ultérieure.
  9. Fin d’utilisation
    Nous faisons que de louer le sérieux de cette entreprise et encore une fois pour cette partie elle ne déroge pas à la règle : il y a tout export des données vers Azure, AWS et Google en csv, tout est prévu chapeau.
  10. Documentation et API
    Encore une fois nous ne sommes pas déçus du sérieux de cette partie : la documentation est claire, bien fournie, rapide et simple d’utilisation, elle comporte de nombreux exemples, il manque la traduction en plusieurs langues mais nous cherchons la petite bête. Côté API il y a un connecteur python qui peut faire l’office d’API mais c’est maigre.

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
Snowflake
4
4,5
4
4

3,5

2,5
5
5
5
3,5
5
4

Conclusion : Cette base de données est pensée pour être une plateforme de gestion de données et fait rudement bien son travail. De plus l’éditeur est jeune et dynamique. Cette plateforme est à suivre elle devrait nous réserver des bonnes surprises dans les mois à venir.

 Plan :
1 introduction
5 SnowFlake


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