Datalake comparaison - 8 SAP Hana

Dans ce chapitre nous allons nous consacrer à la solution SAP HANA cette solution est disponible à la fois hébergée dans le cloud ou peut être installée en local ou dans n’importe quel datacenter privé.
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 ultra fournie (voire complexe) et montre que SAP a vraiment bien travaillé et sur le papier propose une solution alléchante techniquement. Elle s’inspire du fonctionnement d’un ordinateur classique avec l’utilisation de la RAM et son SWAP 

    Nous n’avons pas voulu reproduire le schéma nous même et l’avons copié du site de SAP (https://help.sap.com/viewer/fc5ace7a367c434190a8047881f92ed8/2.0.03/en-US/d8d14ef53e244f6cabd10dd3f5e8c11e.html). Il y a de nombreux serveurs à mettre en place comme par exemple le serveur d’index qui recense où se trouve chaque donnée ou le preprocesseur serveur qui indexe les données texte pour faire des recherches rapides. Bref nous retrouvons beaucoup de composants d’un système d’exploitation classique et mettre au point une telle base de données n’a pas dû être une chose facile. Revenons à ce qui nous préoccupe le plus comment sont stockées et traitées les données. La particularité de cette base de données est de tout charger en mémoire vive. Les données stockées et les données à traiter. Nous avons vu que la base de données peut être répartie ce qui veut dire qu’il n’y a pas de limite de mémoire et permet de répartir les données sur plusieurs serveurs. En effet le gros risque des bases de données in memory c’est de dépasser la capacité de mémoire vive du serveur. Hana a apparemment tout prévu et se comporte comme un ordinateur classique en cas de dépassement de mémoire le système sauvegarde des données rarement utilisées sur le disque dur et les chargera de nouveau en mémoire vive en cas de besoin c’est ce qu’on appelle swaper les données et quand un ordinateur fait cela nous pouvons vous dire qu’il est vraiment très lent. Nous n’avons pas vu de distribution de données à l’intérieur des tables nous pensons donc que Hana a opté pour tout charger en mémoire. Sur le papier comme il n’y a pas de temps de lecture des données cela a l’air exceptionnel mais nous avons peur que l’utilisation soit en réalité une galère sans nom. Il semblerait logique que l’idéal pour cette base de données soit des serveurs surdimensionnés avec le plus de RAM et de processeurs possibles pour éviter le transfert de données entre serveurs ce qui annulerait l’intérêt de précharger les données en mémoire sinon on devrait les faire passer par le réseau d’un serveur à l’autre et le réseau jouerait le goulot d’étranglement et on se retrouverait dans une situation désastreuse surtout si on doit faire transiter une énorme table d’un serveur à l’autre, il n’y aurait aucune parallélisation possible et on se retrouverait à attendre longtemps.
    Le démarrage de la base de données doit être assez long s’il faut que le système charge en mémoire toutes les données, attention aux arrêts machines, nous espérons que la sauvegarde ne se fasse pas à froid.
    1. BigData
      Cette solution est souvent appelée la solution BigData de SAP et s’il n’y a aucune distribution de données entre serveurs sur les grosses tables (comme nous le présentons) nous ne sommes pas d’accord avec cette affirmation, pour nous le bigdata passe par la parallélisation des traitements et pas par le chargement des données en mémoire. Cette solution va très bien se débrouiller au début mais la croissance des données va forcément poser problème à cette solution basée uniquement sur une ressource limitée dans un ordinateur à savoir la mémoire vive. Car elle n’est pas extensible à l’infinie. Le streaming pose question aussi, nous sommes sûrs que la base est capable de gérer beaucoup de mises à jour en mémoire mais le problème qui se pose c’est : si le serveur doit redémarrer les données en mémoire sont perdues ou sinon cela veut dire que chaque donnée modifiée est aussi répercutée sur un support pérenne : disque dur et sans architecture distribuée cela ne fonctionnera pas. 
    2. Datawarehouse
      Cette base de données est en revanche une machine de guerre pour un datawarehouse elle devrait y faire des merveilles mais dans ce cas il faut bien prévoir l’accroissement des données et c’est tout l’enjeu des bases in memory.
    3. Reporting
      Côté reporting les requêtes devraient être ultra rapides mais en revanche si tout n’est que sur un seul serveur nous avons peur que les pics de charge ne soient pas bien géré.
    4. Datalake
      Cet outil ne ferait pas un bon datalake, un datalake doit pouvoir réagir à la demande, dans certains cas il a de grosses requêtes à un autre moment il est au repos. Cette architecture lourde ne permet pas de l’allumer ou l’éteindre à la demande ni de changer le nombre d’unité de calculs facilement, l’intérêt de Hana réside à tout charger en mémoire tout le temps par conséquent à traiter des données qui sont très souvent utilisées.
    5. Base de données Applicative
      Cette base de données a été créée pour le traitement de données chaudes (fréquemment utilisées), c’est la vocation des bases de données in memory et contrairement à ce que communique SAP nous pensons que c’est dans la gestion d’application que cette base de données excelle, d’ailleurs n’a-t-elle pas été développée pour héberger SAP à l’origine et qui est à notre connaissance la plus grosse application vendue au monde?
  2. Utilisateurs
    Le langage utilisé est SQL ANSI, bref le standard que tous les data analysts utilisent. Nous n’avons pas vu d’interface à proprement parlé pour Hana, nous avons un doute sur la simplicité de faire des requêtes sans outil additionnel. 
  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 : Oui
    - Graphes : Oui
    - IP :
    - Window : Oui
    - ML : 
  4. Administrateur
    C’est une solution soit managée soit non mais dans tous les cas il faut surveiller la croissance des données et l’utilisation mémoire en permanence. Vu le nombre de serveurs et de services l’administration ne doit pas être simple.
  5. Experts quand pourquoi
    Nous l’avons vu cette base de données peut tout faire il est même possible choisir le type de stockage d’une table en ligne ou en colonnes, cette base de données est tellement complète qu’elle en devient extrêmement complexe. Nous avons l’impression qu’elle est vraiment utilisée à son plein potentiel qu'avec une armée d’experts.
  6. Droits et sécurité
    Niveau droits tout y est et à tous les niveaux, tables, schéma, base de données, vues…
    Hana fait fort sur ce point. Il y a aussi une connexion à l’active directory et à SAML.
  7. Logs et alertes
    Nous avons l’impression que les logs sont restés dans les années 2000, tout semble être stocké dans des fichiers répartis sur chacun des serveurs utilisés.
  8. Coût et gestion
    C’est le point faible de cette solution le coût, déjà les coûts de licence sont pharaoniques et le coût du matériel nécessaire au fonctionnement est gargantuesque. A cela il faut une armée d’administrateurs pour le version non managées et dans tous les cas il faut de bons experts pour monter en compétences et faire fonctionner le système correctement.
  9. Fin d’utilisation
    La commande export permet d’exporter en CSV tous les éléments de Hana : tables et vues. Il est possible de chiffrer les exports pour plus de sécurité
  10. Documentation et API
    En faisant des recherches je suis plus facilement trouvé sur des sites d’experts que sur la documentation officielle, et les rares fois où nous avons trouvé de la documentation officielle nous nous sommes retrouvés à ouvrir une sur-fenêtre dans le navigateur, l’expérience ne nous a pas convaincue et nous sommes restés sur notre faim. Les API sont existantes mais semblent limitées.
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
SAP Hana
2
5
3,5
2

2,5

1
2
5
1
0,5
5
2

Conclusion : Nous sommes assez bluffés par le travail réalisé par SAP, cette base de données propose le plus de fonctionnalités que toutes les autres solutions analysées dans ce comparatifs. Nous n’imaginions pas que SAP se soit lancé dans une telle entreprise. Le pari est réussi mais hélas à trop vouloir en faire nous jugeons cette base de données trop complexe et le prix de licence, d’accompagnement et d’infrastructure qu’elle nécessite rend cette base de données presque inaccessible car le coût est difficilement justifiable, cela nous fait penser à un objet de luxe que seuls les plus fortunés sont fiers d’exhiber.

 Plan :
1 introduction


8 SAP Hana
9 CloudSpanner
10 conclusion

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