SAP HANA (sur Amazon Web Services), l’in-memory pour booster l’analytique.

Nous vous proposons de parcourir les caractéristiques de HANA la base in-memory colonne développée par SAP, et vous inviter à connaître la solution au travers de l’offre de Amazon Web Services qui offre un terrain de jeu parfait pour un POC.

HANA : Une base colonne en mémoire

Avec l’avènement des nouvelles architectures matérielles vers 2005 ( CPU plus nombreux et plus rapides, RAM dépassant le TB ), les bases colonnes ont trouvé un support leur permettant de se développer industriellement. A ce jour, outre HANA, on peut citer Vertica ( HP ) ou Oracle ( option in-memory ) comme alternatives sur une machine Unix/Linux. Mais plus généralement, tous les grands éditeurs possèdent une option colonne dans leur catalogue et il est frappant d’observer qu’il n’existe pas (encore ?) de bases colonnes open source disponibles du type Cassandra ou Couchbase !

Les bases in-memory colonnes ont pour but d’optimiser l’OLAP, c’est-à-dire l’analytique en direct. Pour ce faire, elles se reposent sur les principales caractéristiques suivantes :

  • Un taux de compression de 10 ou plus sur les colonnes :

    En effet, l’entropie est beaucoup plus faible sur une colonne que sur une ligne, les données se « ressemblant » plus. Ainsi, des algorithmes de compression moins consommateurs en CPU ( RLE, bit-vector, dictionnary, … ) ont pu être mis en oeuvre pour profiter de cette faible entropie.
  • Une nouvelle localisation des données :

    Au démarrage de l’instance, les données sont chargées en RAM. Puis, la vectorisation des colonnes permet à ces dernières de résider dans les caches du processeur, d’où une accélération supplémentaire en terme d’accès à la donnée.
  • Une parallélisation accrue :

    Au niveau des processeurs, la technologie SIMD ( SingleInstructionMultipleData ) permet d’effectuer des opérations binaires entre les vecteurs.

HANA propose d’aller plus loin en se positionnant comme une base pouvant également gérer l’OLTP, un choix différent d’Oracle qui propose le mode colonne en complément du mode ligne.

Pour ce faire, SAP a introduit un concept de merge delta permettant de gérer les mises à jour unitaires et en masse. Pour les mises à jour unitaires, la zone delta est en mode ligne. Les données sont ensuite déversées dans la zone réservée aux mises à jour de masse, zone en mode colonne non optimisée. Enfin, les données rejoignent la zone principale de manière asynchrone. Sur ce point, l’éditeur doit encore faire ses preuves, la plupart des cas d’utilisation publiés étant relatifs à la BI.

Quel impact sur le développement ?

Le développement des requêtes se fait en SQL et les procédures stockées sont écrites en SQL Script. La grammaire SQL est déjà bien étoffée ( lien : http://help.sap.com/hana_appliance => SAP HANA SQL and System Views Reference). En revanche, le langa
ge SQL Script (SAP HANA SQLScript Reference ) est principalement dédié au traitement OLAP, en particulier les fonctions qui ne sont utilisables que pour les lectures afin de les paralléliser au mieux. Les procédures, quant à elles, permettent d’encapsuler les requêtes SQL de toute nature, mais il est encore pénalisant de gérer les transactions ( commit & rollback non autorisés ) au sein d’elles.


De plus, SAP met en avant un modèle analytique basé sur des attribute view ( dimensions ), des analytical view ( tables de fait ) et des calculation views ( calculs sur les tables de fait ) permettant de concevoir un modèle en étoile dans un contexte colonne. Les calculation views se basent sur des CE-Build In fonctions ou des requêtes SQL de lecture. Il existe aussi un outil de conception entièrement graphique qui permet de mettre en oeuvre ce modèle analytique.


Lancer son instance HANA dans AWS


Afin de promouvoir HANA, SAP propose de s’initier à ce produit via Amazon Web Services (AWS). L’instance HANA peut être déployée à Francfort ou en Virginie du Nord. Petite limite observée à ce jour, Il est préférable de déployer sur l’instance des Etats-Unis, pour surmonter des problèmes de disponibilité (machine non réservée perte de contexte à chaque arrêt / démarrage ). Elle repose sur une machine Linux Suse de type m2.4xlarge ( 8 vcpu, > 60 GB RAM ).


En termes de coût, l’instance HANA est gratuite et l’infrastructure mise à disposition par AWS payante (Remarque : le coût de possession sur ses propres infrastructures n’est pas sur ce modèle). A titre d’exemple, le coût peut être déchiffré de la manière suivante :

$1.080 par heure d’exécution ;
$0.05 par GB au-delà de 30 GB par mois ;
$0.05 pour un million d’IO au-delà de 2 millions d’IO par mois ;
$0.095 par GB ( snapshot ) au-delà de 1 GB par mois ;
Taxes (20 %).


opérationnel en 2 heures

En termes technique, la procédure est décrite à cette adresse : http://scn.sap.com/docs/DOC-28294 et permet d’être opérationnel en 2-3 jours, le temps d’initialiser le compte AWS. Si ce dernier existe déjà, l’installation est faite en quelques heures, le temps de se familiariser avec la version cloud d’HANA.
Bien que relativement simple d’appréhension, la création de l’instance HANA peut vous conduire à recevoir des erreurs délivrées par les web services d’AWS.

Exemple : lors de la configuration du compte AWS, vous pouvez tomber sur cette page:

Dans ce cas, contacter le support disponible sous AWS ; il est très réactif.
Une fois l’installation effectuée, l’instance se pilote via le site HANA Enterprise Cloud/Cloud Appliance Library :
HANA Enterprise Cloud

HANA STUDIO, client basé sur Eclipse, permet de développer, d’administrer et de monitorer l’instance HANA.
HANA Studio

Pour étudier cette solution, j’ai créé quelques tables en mode colonne ( nombre de colonnes variant entre 10 et 50, nombre de lignes variant entre quelques dizaines de milliers et 1 million ). Mon objectif n’était pas de tester des grandes tables ( plus de 1 GB en mode compressé ), mais de vérifier l’efficacité de la compression en mode colonne. Sur ce point, j’ai bien retrouvé des facteurs de 10 ou plus sur les colonnes non uniques.


D’autre part, je souhaitais étudier le SQL Script et ses limites pour la mise à jour. Je vous ai déjà parlé de la non gestion des transactions, mais il faut aussi savoir qu’il ne dispose pas de bulk collect. Si vous souhaitez l’équivalent, il vous faudra par exemple utiliser le mode batch de la couche JDBC. Comme alternative payante, vous pouvez utiliser SLT, un outil de réplication ou Data Services, un outil de chargement des données. Pour le chargement des fichiers, vous disposez aussi d’une commande import gratuite et optimisée ( thread, batch size ).


Enfin, je me suis intéressé à l’optimiseur colonne de HANA afin de mieux comprendre comment il fonctionne en terme de gestion des jointures ( jointure à 1 ou n colonnes ), d’utilisation des colonnes, de calculs d’agrégat. Pour ce faire, un outil indispensable : SAP HANA Plan Viz. Pour information, Hana dispose aussi d’un optimiseur ligne pour les tables en mode ligne et d’un optimiseur en mode OLAP pour le modèle analytique.

Changer de technologie c’est changer de paradigme

Avant de se lancer dans le grand bain, il faut appréhender ce nouveau type de solution en changeant de paradigme : le mode ligne n’est plus applicable ; il faut comprendre comment les opérations de lecture et d’écriture sont repensées et construire son modèle de données selon ces particularités. Un simple exemple très explicite: les index sont la plupart du temps inutiles en mode colonne.
Enfin, je vous conseille de lire ce post : http://scn.sap.com/community/hana-in-memory/blog/2013/12/29/6-golden-rules-for-new-sap-hana-developers.

Pour en savoir plus sur les bases colonnes et HANA :

  • Column-Oriented Database Systems : S.Harizopoulos, D.Abadi, P.Boncz [ VLDB 2009 Tutorial ];
  • The Design and Implementation of Modern Column-Oriented Database Systems: D.Abadi, P.Boncz, S.Harizopoulos, S.Idreos [ Foundations and Trends in Databases, 2012 ];
  • Building Advanced Data Model with SAP HANA: W.Steyn [ 2011 ];
  • Best-practices-for-sap hana data load: http://scn.sap.com/community/hana-in-memory/blog/2013/04/08/best-practices-for-sap-hana-data-load.

    • Stéphane NOTTER, Expert Architecture des données.



Hadoop User Group de Février [Compte-Rendu]

Le HUG de Paris se réunissait ce jeudi 13 février dans les locaux de Google. Le succès ne se dément pas de session en session avec un public toujours plus nombreux.

Au menu, deux présentations de solutions techniques et un retour d’expérience décliné sur plusieurs projets représentatifs.

1re session technique : Hadoop sur Google Compute Engine

La présentation et les démonstrations de Google portent un même message: GCE est une plateforme mature pour faire tourner Hadoop. Ceci inclut les opérations de lancement / monitoring / extinction un cluster. La couverture fonctionnelle se veut aussi complète que celle de Amazon MapReduce (nous avons été invités faire la comparaison) et surtout plus performante. Cela se traduit notamment en supprimant les opérations de migration des données entre le stockage pur et l’espace d’exécution de Hadoop. En plus clair : les instructions Pig, Hive, MapReduce s’exécutent directement sur le Google Cloud Storage.

2ème partie : le retour d’expérience d’EDF

C’est une équipe du département R&D de l’opérateur national qui présente ses travaux. Oui, c’est le département Recherche et développement, mais les travaux engagés depuis 3 ans sur hadoop et son écosystème ont donné des garanties suffisantes pour en faire une des approches technologiques de choix pour une grande diversité de sujets présents et à venir:

  • Modélisation, Analyse et Prévision des consommations électriques en captant les informations de compteurs intelligents,
    o L’approche astucieuse de transformation de séries temporelles (très complexes à traiter en l’état) en chaines de caractères permet de bénéficier de tous les mécanismes d’analyse de modèles (corrélation, identification d’anomalies, prédictions…)
    o EDF a créé une librairie spécifique pouvant être exploité dans Hive, l’idée étant comme souvent de donner un niveau fonctionnel aux manipulations de données qui les rendent facilement utilisable pour des équipes ‘métier’ ou ‘statistique’.
    o Les débuts de l’architecture Hadoop ont été modestes, comme souvent, mais même à partir d’un cluster de petite taille on arrive à valider un modèle qui montera facilement en capacité. A ceci s’ajoute que le premier défi était de trouver une solution qui offrirait une capacité de stockage en ligne avec les futures avalanches de données ; désormais c’est la polyvalence de la solution et le coût bien moindre que des solutions d’éditeurs qui sont les atouts mis en avant par l’équipe R&D.
  • Analyse de l’e-réputation de EDF par acquisition de données textuelles qui cheminent dans un processus : Analyse sémantique, regroupement par thèmes (clusterisation) avec du Machine Learning (Mahout), puis visualisation (http://sigmajs.org/).
  • Prise en main de Storm et application à la prévision de consommation en mixant des sources de données diverses (Consommation électrique, profil client issu du CRM, données météorologiques, réseaux sociaux) : le cas d’application est parlant, avec un ROI potentiel très palpable… la mise en œuvre n’est pas si simple.

3ème et dernière ‘session’ : Apache Phoenix, un projet de ‘portage’ du SQL sur HBase.

L’ambition du projet est de bénéficier de la puissance de HBase sans souffrir de la technicité requise encore aujourd’hui pour vraiment exploiter cette base de données ‘Colonne’ posée sur Hadoop.

Au vu de la technicité de la présentation, on perçoit bien que c’est un sacré tour de force et que certains compromis sont néanmoins nécessaires pour transformer une base NoSQL en un système exploitable avec un SQL presque standard… A suivre, sachant que certaines questions émergent naturellement:

  • Jusqu’à quel point les briques Hadoop doivent-elles intégrer des problématiques plus habituellement liées au transactionnel ?
  • Les bases NoSQL (colonne, document, clé-valeur) pensées pour des usages précis ne vont-elles pas perdre en crédibilité à force d’être utilisées hors de leur champ de prédilection, souvent au travers de casse-têtes de développement et d’exploitation?


Livre Blanc ‘BigData au service du Système d’information’

Voici un billet qui sort des habituelles présentations de cas techniques, mais Il en représente d’une certaine manière l’aboutissement. Il a en effet pour objectif de donner la vision que nous avons, à Infotel, des enjeux relatifs au « BigData pour le Système d’Information ».

Nous travaillons auprès de grands groupes dans une diversité de technologies et de cas métiers très importante. Nous sommes impliqués de ce fait sur des projets sensibles, au coeur des SI, qui associent bien souvent des exigences très élevées en performance, en volume de données à traiter, et en rapidité d’évolution fonctionnelle.

Le BigData commence à bouleverser dans des proportions nouvelles nos habitudes. Enjeux, opportunités, stratégies de mise en oeuvre… voici ce que nous vous proposons de parcourir au travers de ce livre blanc.

Vous pouvez le télécharger ici : http://infotel.com/services/big-data-360/


Nous vous en souhaitons une lecture profitable et sommes à votre disposition pour en discuter avec vous.

Hubert STEFANI



Retour sur DevoxxFR 2013

Voilà, c’est notre deuxième participation au DevoxxFR (sur deux éditions) et, bien qu’il y ait des redondances d’une année sur l’autre, l’impression qui s’en dégage est celle d’un souffle de fraîcheur et une volonté positive de bouger les lignes; Concrètement, être confronté à la fine fleur du développement et ses retours d’expérience sur des cas très pointus ne peut qu’être profitable :

  • Cela ouvre l’esprit quant à l’application sur nos projets présents ou à venir,
  • On capte indéniablement l’énergie positive qui se dégage de ces success story (… On peut aussi apprendre à la ‘Failure Conference’ http://france.thefailcon.com/) ,
  • On entrevoit notamment ce qui fait les succès des ‘Grands Du Web’ et comment on peut en tirer parti pour nos projets qui doivent composer avec un historique pas toujours simple à adresser

Comprendre les technologies qui motorisent les grands du Web

Exemple : L’utilisation de briques BigData pour booster son architecture et lui permettre de faire face aux défis de volumétrie que nous observons et qui n’en finiront plus de déferler :

  • Hadoop / Storm / Mahout,
  • Implémentation de solutions ‘Cloud’ : CloudBees, Google App Engine…
  • Du SQL au NoSQL (avec des morceaux de ElasticSearch dedans)

Bien plus que Java et la JVM

Toucher concrètement du doigt les nouvelles technologies (plus ou moins matures… il faut savoir faire le tri) donne une furieuse envie de faire bouger les lignes parfois un peu trop rigides (Architecture, Pratiques de développement)… à faire avec discernement bien entendu.

Par exemple : On a pu observer la poursuite de la montée en puissance du JavaScript et sa professionnalisation; on peut naturellement retenir cette approche pour :

  • L’écriture de tests d’acceptance (KarmaJS, PhantomJS, Mocha, Chai…),
  • La réalisation d’applications pures JS + CSS / HTML5 avec Angular / Ember /Backbone.

Autre observation: on en finit plus également de constater les mérites des langages fonctionnels pour leur expressivité et leur robustesse (Scala , Haskell…) et globalement les bénéfices de regarder plus loin que le seul langage Java.
Les combats épiques de Frameworks (Grails vs Play ! ) et de langages ont été à la fois réjouissants et instructifs : il faut juger constamment les technologies qu’on utilise ou qu’on pourrait utiliser et les mettre en perspective de nos propres enjeux.

et après DevoxxFR ?

Dans les jours à venir, nous reviendrons en détail sur un certain nombre de conférences et ateliers, en attendant notre conclusion est la suivante :

Il est nécessaire de cultiver son ouverture aux technologies et méthodes qui nous permettent de mieux répondre aux défis posés par nos projets :

  • C’est plus valorisant de constater qu’une de nos propositions a pu répondre positivement à une problématique (Performance, Accélération des livraisons, Qualité globale),
  • C’est une manière concrète de montrer à notre client et à nos collègues la valeur ajoutée que l’on apporte, au-delà du rôle frustrant à terme de ‘simple réalisateur’.

Cette curiosité et ce savoir-faire se cultivent continuellement (blogs, tutoriaux, projets), mais également au travers des Groupes d’utilisateurs (Java UG, Hadoop UG, Mongo UG, Android UG….) et DevoxxFR constitue un des moments incontournables pour avoir un aperçu de l’effervescence de ces éco-systèmes.



Cloud à devoxxFr: approche composite ou monolithique ?

Deux approches Cloud (parmi d’autres)

DevoxxFr a été l’occasion d’une revue très large des technologies en connexion avec les sujets chauds du moment : le Mobile, les frameworks de haute productivité (Grails et Play par notamment), le futur de Java, les langages de la JVM présents et à venir (Scala, Groovy, Ceylon), le NoSQL, et bien entendu le CLOUD !

A ce titre, je reviendrais sur deux présentations qui montrent la diversité des solutions proposées quand on se penche sur les offres PAAS (Platform As A Service) :

  • Un retour d’expérience sur Google App Engine , par Didier Girard et Ludovic Champenois, mettant en avant la richesse de la solution, qui regroupe toutes les briques techniques susceptibles d’être exploitées ;
  • Une approche composite, menée par Cyrille Leclerc, qui s’est attaché à construire une application en choisissant un fournisseur différent pour chacun des aspect techniques (Base de données, moteur Web, Analyse de logs, ressources statiques, emails ).

Google app engine

L’approche Google a les avantages d’une solution entièrement propriétaire :

  • Tous les éléments sont réunis dans une plateforme (Mail, données, Moteur de servlet ).
  • Les outils de développements (sous eclipse) sont matures, vraiment opérationnels (de ma propre expérience) et demandent peu ou pas de configuration,
  • Les performances sont au rendez-vous, puisque les briques techniques sont optimisées entre elles (et qu’elles bénéficient du savoir-faire de Google en la matière qui n’est plus à démontrer). On peut même dire que, en respectant les bonnes pratiques (en utilisant autant que possible le cache par exemple), les temps de réponse sont excellents.
  • Et les inconvénients qui viennent avec :

    • Une obligation de se conformer à des standards spécifiques (notamment sur la persistance et le format BigTable de Google), avec des efforts notables d’abstraction vers des standards (JPA, JSR Cache).
    • Un seul fournisseur chez qui déployer son application ‘cloudisée’, par opposition à ce que VM Ware promeut au travers de cloud foundry.
    • Au global, une possibilité de se désengager peu aisée, notamment si la politique de tarif devait évoluer (ce sont des choses qui sont impérativement à envisager sur le long terme) ou bien si la structure du DataStore change.

    J’ai pu noter que, depuis mes premiers tests en 2009, cette plateforme avait évolué vers une solution vraiment complète et industrialisable; Par exemple les exécuteurs sont déclinés en ‘Front’ (traitant les requêtes Web) et ‘Back’ (qui peuvent supporter les traitements asynchrones, batch, plus gourmands en performance), avec la possibilité d’exporter les données.

    Un cloud composite

    Les offres sur le cloud sont pléthoriques et des offres dédiées pour chaque composant technique d’une application permettent d’envisager une construction sur-mesure.
    En partant des plateformes comme Heroku, Cloudbees, CloudFoundry et en se penchant sur les extensions possibles, on s’ouvre à des combinaisons très nombreuses ; On aura cependant à l’esprit des aspects structurants pour la bonne tenue de l’application en production et leur maîtrise à l’heure de faire le choix d’architecture:

    • La latence du réseau entre le serveur et la base de données (on les colocalisera, plutôt que d’avoir un serveur en Europe et une base de données aux Etats-Unis),
    • Le droit sous lequel les données sont stockées selon leur sensibilité (Cloud Français ; Cloud américain),
    • La gestion du cycle de vie des données (et les fonctionnalités d’export, pour des traitements BI dans ses infrastructures, par exemple),
    • La sécurité : ces offres sont forcément moins protégées que les DMZ personnalisées, et à chaque maillon de la solution cette question doit être posée,
    • De même pour les SLA (niveaux de service) : notre solution doit être résiliente, et supporter toutes les défaillances potentielles des chacun des différents fournisseurs,
    • Enfin, et non le moindre : la politique tarifaire ; les offres non bornées peuvent présenter des risques important lors de l’explosion de la charge de l’application.

    Sans décliner chacune des solutions techniques, on peut observer que les éléments suivants sont bien couverts par les offres cloud :

    • Database As A Service : Mongo HQ par exemple, avec des offres complémentaires de sauvegarde,
    • Stockage de fichiers : Amazon Web Service AWS S3 ou Microsoft Azure,
    • Search as a service :Solr avec WebSolr.
    • E-mail as a service : SendGrid , CritSend,
    • Monitorig as a service : AppDynamics

    Les projections de coûts d’utilisation sont vraiment bas, et servent notamment les petites structures ou celles qui démarrent, qui n’ont pas forcément à se poser la question de créer leur propre salle blanche et établir une équipe d’industrialisation. Attention cependant aux coûts cachés: la rareté des compétences, la maîtrise des données…

    Pour nos clients qui cherchent à mettre sur pied une application à forte volumétrie, sans forte pérennité (une campagne de publicité, une enquête à large spectre), ces approches semblent particulièrement appropriées et immédiatement disponilbes.