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 ?
