Stockage des données : quel système pour quel usage – partie 2

Traitements batchs

Le premier champ dans lequel s’applique ces principes était anciennement appelé OLAP (On Line Analytical Processing), dénomination désuète mais décrit bien l’objectif de ces traitements. Le besoin de traiter des volumes importants de données a été évoqué pour la première fois en 2013 par des chercheurs de google avec un principe :  MapReduce. Il existe actuellement une implémentation propriétaire reposant sur Google File System et une implémentation OpenSource, Hadoop.

MapReduce est un modèle de programmation auquel est associé une implémentation pour le traitement et la génération de volume de données importants à l’aide d’algorithmes distribués dans un cluster. Dans l’implémentation open source, le stockage et la distribution des données est effectué grâce à HDFS et l’orchestration des traitements est assurée par Yarn. A côté des principes cités plus haut (distribution des données et des traitements) Hadoop apporte en plus la gestion des erreurs. Le domaine d’application de ce type de technologie obéit à la règle des 3 V (Volume, Velocity, Variety). Elle s’explique elle même. Les exemples concrets qu’on donne souvent sont les centres de recherches comme les télescopes géants ou les accélérateurs de particules (génération quotidienne de pétaoctets de données).

Les implémentations MapReduce ne sont toutefois pas sans défaut. Le seul traitement qu’ils permettent est … MapReduce. C’est leur force mais aussi leur faiblesse. Tout traitement exige une lecture sur disque ce qui est handicapant pour les traitements itératifs. La seule interface de programmation native pour l’implémentation opensource Hadoop est fournie dans le langage ©Java. Les autres interfaces de programmation utilisent le module de streaming. Ils fonctionnent en récupérant les E/S standards. Enfin, lors de l’édition 2014 de Google IO, Google a annoncé qu’il n’utilisait plus MapReduce mais dataflow en interne. Toutefois, il n’est pas dit que les implémentations MapReduce disparaîtront demain. Malgré ces défauts, le projet reste dynamique avec une communauté nombreuse et un écosystème riche. Il restera à minima un système de stockage de donnée distribué extrêmement scalable.

Spark permet de répondre aux limitations de Hadoop. Il offre la possibilité de stocker les données en mémoire dans des RDD (Resilient Distributed Datasets). Il fournit un panel de traitements riches (filter, join, groupByKey, …). Ces deux éléments facilitent les traitements par rapport aux implémentations MapReduce. Malgré tout, Spark n’est pas dénué de défauts. La gestion de la mémoire peut par exemple s’avérer délicate.

Traitements transactionnel

L’émergence des traitements transactionnels est aussi le fait des grands du web : Google avec Bigtable en 2004 et Amazon avec DynamoDB en 2007.

L’axe utilisé le plus souvent pour aborder les traitements transactionnels OLTP est le modèle proposé pour le stockage des données. On en distingue actuellement 3 : clé-valeur, document et column.

Cette classification est insuffisante pour pouvoir faire un choix. Il faut lui adjoindre les critères suivants

  • le query model,
  • Le réplication model,
  • Le consistency model
  • le triplet type de licence, support, communauté

Au départ, les systèmes NoSQL étaient caractérisés par des API de requêtage simples. Ils se sont enrichis avec le temps mais ils restent néanmoins limités par rapports aux SGBDR. Nous n’évoquerons pas les API de type Hive, Pig, Impala, Apache Drill ou SparkQL dont le domaine d’application est davantage porté sur l’analytique.

Le modèle de réplication est également très important. Citons les deux modes les plus fréquents : Master/Slave et Masterless. Un système masterless est plus facilement scalable car tous les noeuds sont identiques donc un ajout de noeud est plus facile. Un mode de réplication master/slave demandera plus de travail pour un rajout de noeud car tous les noeuds ne sont pas identiques.

Quand arrive l’heure du choix, les décisions ne sont pas toujours prises de façon rationnelle. Nous ne vivons pas en autarcie et il est difficile de résister à la  communication et au marketing. Il y a des choix plus maintream que d’autres. Cette attitude est compréhensible car elle permet à terme de bénéficier du momentum de  la communauté. Elle est moins risquée dans les startups car ces structures ont une exigence de Time To Market court. L’organisation du travail y favorise le principe de one person deployment, le fameux mouton à 5 pattes dont les connaissances vont du front-end au déploiement continu en passant par la gestion du cloud. Il l’est un peu moins pour les grandes structures dans un univers ou ce qui est mainstream change tous les trois mois. Ces entreprises imposent souvent des contraintes qui peuvent sembler ennuyeuses. Mais elles ont des exigence d’homogénéité de parc afin de  limiter le risque d’explosion des coûts de structure en cas de multiplication des choix. En clair, si une entreprise a un service IT de 5000 personnes et que chacun choisit ce qu’il veut, elle se retrouvera  rapidement dans une situation délicate.

Une grande entreprise est souvent organisée en couches qui ne parlent  pas toujours le même langage. Et nous savons bien que les problèmes commencent lorsqu’il y a rupture de protocole. Dans les grandes structures, ces technologies  doivent impliquer fortement l’exploitation qui sera en charge du bon fonctionnement des applications en production. Gérer un cluster constitué de dizaine ou de centaine de machines est un métier aussi bien dans le mode on premise que dans le cloud (architecture des clusters, load-balancing,  provisionning, propagation des properties, contraintes de sécurité, connaissance du provider cloud choisi,  …).

Un choix doit donc  prendre en compte tous ses paramètres sans compter bien entendu qu’ils devront être mis en regard avec les règles métier en insistant sur deux éléments clés : le besoin d’un contexte transactionnel fort (ou pas) et les contraintes en terme de temps de réponse pour les utilisateurs en terme de percentile. C’est le client qui impose ses règles et c’est lui qui a raison parce que c’est lui qui paye.

Et pour conclure

L’idée de ce talk n’était donc pas de fournir des solutions toutes faites. Ça n’est pas possible ni en 15 minutes ni en 3 jours. Ce choix dépend de plusieurs facteurs qui sont variables en fonction du contexte. Et aucune solution n’est à écarter d’emblée. L’intelligence doit nous pousser à éviter les attitudes dogmatiques et les querelles de chapelle. Les bases de données relationnelles bénéficient de dizaines d’année de R&D et constituent un choix parmi d’autres. Lorsqu’on veut partager des données, parfois dans un contexte multiutilisateurs, es questions à se poser seraient plutôt :

  • mon modèle sera-t-il plus ou moins structuré ?
  • mon modèle sera-t-il amené à évoluer ?
  • quels sont les impératifs de scalabilité, la nécessité de scalabilité n’étant pas uniquement la réponse à une volumétrie gigantesque. mais aussi l’obligation de maîtriser le temps de réponse en fonction de l’augmentation de la charge ou des traitements ?
Tagged with: ,
Posted in Uncategorized

Stockage des données : quel système pour quel usage – partie 1

J’ai donné il y a quelques jours, pour la première  fois, un quicky lors de la 6ème édition de Devoxx. L’exercice est difficile. Le temps de parole est en effet limité à 15 minutes. De plus, les quickies se déroulent en même temps que le déjeuner. C’est donc un des rares moments de pause. Le speaker se retrouve alors dans la situation de l’acteur de stand-up dans un bar avec un public buvant son coup : il a 5 minutes pour capturer l’attention de la salle. Mais revenons sur le fond et reprenons en détail le déroulé du talk.

A la fin des années 70, le stockage de données était essentiellement fait dans des bases hiérarchiques.  Ce mode avait pour défaut d’être rigide. Il était difficilement adaptable en cas de nécessité de modification du modèle de données. Les travaux de Codd ont permis de répondre à cette problématique par le développement de systèmes permettant d’utiliser des données de différentes façons, y compris des manières qui n’étaient pas prévues lorsque l’application a été écrite (Curt Monash), des systèmes moins rigides en somme. Les bases de données relationnelles sont donc arrivées à point nommé. Elles ont commencé à s’imposer au début des années 80 même si elles souffraient de problème de performance. Elles offraient et offrent toujours d’ailleurs une souplesse dans la manipulation des données grâce à deux éléments clés :

  • Indépendance entre le modèle logique constitué de tables et sa représentation physique qui manipule des fichiers.
  • Algèbre relationnelle qui met à disposition des opérateurs relationnels (sélection,  projection et  jointure) et des opérateurs ensemblistes (union, intersection, différence).

Ces éléments permettent une manipulation logique des données grâce au langage SQL. Les SGBDR ont ainsi un avantage fondamental et souvent oublié qui découle de l’indépendance entre la représentation logique et l’implémentation physique.  C’est le choix optimal des algorithmes de parcours des tables en fonction de leur taille. Si on fait par exemple une jointure entre deux tables, les algorithmes choisis seront différents selon que les tables jointes sont volumineuses ou de petite taille (respectivement hash match ou nested loop).  L’activation de ce comportement demande parfois un paramétrage comme l’activation des statistiques, paramétrage à la portée de tout bon DBA ou utilisateur averti.

L’autre élément clé apporté par les SGBDR est la gestion transparente des transactions.

Toutefois, les bases de données ne scalent que verticalement. Ce type de scalabilité coûte cher. Notons toutefois qu’il y a des initiatives pour permettre la scalabilité horizontale pour les SGBDR comme Greenplum ou Cockroachdb.

C’est pour répondre à cet impératif de scalabilité horizontale que les systèmes dits NoSQL ont été créés. Ils autorisent des lectures inconsistantes au profit de la disponibilité et de la partition tolerance (coupures réseau). La répartition de la charge est assurée grâce au partitionnement des données ou sharding. La tolérance aux pannes est assurée grâce à la réplication. Le nombre de machine pouvant être potentiellement important, ces systèmes sont censés être hébergés sur du commodity hardware pour en réduire le coût.

Lorsqu’il s’agit de scaler des traitements, le principe est également très simple. Dans un premier temps, les données sont partitionnées. Ensuite, ce sont les traitements qui vont vers les données et non l’inverse à l’instar des traitements classiques.

Il faut aussi garder à l’esprit que, aussi bien pour les traitements de type batch ou analytique que pour les traitements transactionnels, l’idée est de maîtriser les temps de réponse lorsque la charge ou le volume des données traitées augmentent. Les systèmes NoSQL permettent donc de résoudre deux problèmes : le stockage de volumes importants et la maîtrise des temps de réponse en fonction de la charge ou des traitements.

Tagged with: ,
Posted in Uncategorized

JMagreb 2015

J’ai eu l’honneur et le plaisir de participer en tant que speaker à l’édition 2015 de JMaghreb qui est maintenant Devoxx Maroc suite au rebranding et à l’affiliation à la famille Devoxx . Ce fut de nouveau une très belle édition . On ne peut que remercier et féliciter l’équipe d’organisation (Badr, Faissal, Redouane, Mohammed … et tous les autres).

Les slides de ma présentation (Unit test my search) sont sur slide share.

Pour le code, j’ai enlevé la partie base de données relationnelle afin de simplifier le projet. Une version expurgée a donc été poussée  sur gitHub. Le projet comporte des containers dockers afin de pouvoir faire des tests d’intégration. Pour la base mongo, il est nécessaire

  • de créer une base (use catalog_db)
  • de créer une collection (db.createCollection(“phones”)

 

Pour adapter le projet aux dernières versions de mongodb (>= 3) : https://github.com/fakemongo/fongo.

Pour aller plus loin sur la partie elasticSearch : https://github.com/dadoonet/spring-elasticsearch. Les projets gitHub de David Pilato contiennent pas mal de tests unitaires avec différentes configurations.

Tagged with:
Posted in java, Uncategorized

Devops My code

Les slides

Pour celles et ceux qui n’aiment pas lire les blogs et qui veulent juste les slides, le lien est disponible en bas de page. Par contre, j’applique le principe de la gondole de supermarché : pour trouver le savon, il faut avant passer par le rayon bonbon, chips, bières.

Pourquoi ?

Depuis que j’assiste à des présentations techniques (plusieurs années au Paris JUG et dans différentes conférences), j’ai identifié différents types de présentations. La liste n’est bien entendue pas exhaustive mais voici les différents présentations qu’il est possible de voir:

  • Les évangélistes professionnels salariés d’éditeurs,
  • Les consultants poussés par leur boite dont la stratégie est la communication auprès de la communauté,
  • Le gars (la fille) qui vient de découvrir une librairie  ou un framework. Il y croit, il pense qu’elle va tout emporter et il veut en faire profiter le plus grand nombre,
  • Le gars, la fille qui sent qu’une nouvelle techno émerge et qui en communiquant sur son savoir-faire travaillera en même temps son faire-savoir,
  • Le retour d’expérience,

Ma présentation fait partie de la dernière catégorie. La matière provient de plus de trois ans d’expérience chez un des mes clients. J’ai en effet exercé durant plus de 3 ans la fonction d’architecte suivi de production chez un grand du web français. Je ne suis pas habilité à dire son nom. Sache seulement cher lecteur, qu’il est dans le secteur ferroviaire. Une de mes fonctions était de veiller à ce que les applications soient exploitables avant d’aller en production. J’ai donc créé une application démo simple et mis en lumière une partie des techniques mises en oeuvre.

Les slides

Tagged with:
Posted in devops, java

RTFM – JodaTime dayOfMonth or dayOfYear

Once I had the need of test data generation for elastic search. Since elasticsearch come with classes encapsulating JodaTime, I choosed it as my utils library for data management (java 1.7 is the target JVM in my project so no possibility to use new java 8 features for date et time management). My utils class for dates generation war very simple.

public static String getDateTimeAsString(int i) {
return DateTime.now().minusDays(i).toString("yyyy-MM-DD'T'HH:mm:ss");
}

I can then generate decreasing dates from now. But dates was generated with the day as dayOfMonth, WTF … ? After few minutes of search and googling, anwser come from formatting API. If you want a dayOfMonth, use dd (lower case). If you want daytOfYear (I don’t know who need this format but there is certainly someone), use DD (UpperCase).

Tagged with: , , ,
Posted in java

Hellow world

C’est le commencement de tout. Et bien on fait donc un hellow world pour initialiser le blog …

public class HelloWorld {

public static void main(String args[]){
System.out.println("hello world ...");
}
}
Posted in java

Hello world!

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can alway preview any post or edit you before you share it to the world.
Posted in java