Evolution des architectures décisionnelles avec Big Data

Architecture décisionnelle « traditionnelle »
Catégorie de solutions : Oracle, SQL Server, MySQL, Informatica, Datastage, …

L’architecture décisionnelle « traditionnelle » fonctionne comme un pipeline d’alimentation par étages des systèmes opérationnels jusqu’aux datamarts. Chaque étage dispose de son modèle de données spécialisé optimisé pour sa mission, pour garantir des performances idéales à chaque étage.
Plus le volume de données manipulé par chacun des étages augmente, plus le système ETL doit être capable de fournir un débit important.
Cette architecture est performante lorsque le volume de données à transférer entre chaque étage reste limité, mais se transforme en voie de garage lorsque la taille des photos opérationnelles quotidienne augmente. Cela vient du fait que le système décisionnel va passer principalement son temps à transférer des données plutôt qu’à les traiter.
L’architecture décisionnelle « traditionnelle » est adaptée aux volumes de données stables et aux chaines d’industrialisation de production d’indicateurs stable dans le temps.

Architecture In Memory
Catégorie de solutions : Qlicview, ActivePivot, HANA, …

L’architecture d’un système In Memory repose sur la capacité à monter en RAM l’ensemble des données à analyser dans un système unique qui assure l’ensemble des fonctions décisionnelles.
Cette architecture In Memory a été rendue possible par l’évolution des capacités RAM des serveurs et la diminution sa diminution des coûts. Un serveur commodity hardware peut posséder très facilement jusqu’à 512 Go de RAM , en 2012.
Pour dépasser cette limite, deux types d’architecture In Memory ont émergée :
• Distribuée : les données sont partitionnées sur plusieurs machines de type commodity hardware
• Approche appliance : les données sont montées en mémoire sur des systèmes capables de supporter plusieurs To de RAM.
Les fichiers d’entrée sont conservés pour assurer le stockage persistant. Les disques SSD, dont la capacité peut atteindre 200 Go en version commodity (< 300 USD) , permettent de bénéficier d’un débit de chargement 10 fois supérieur à celui d’un disque dur HDD. Les données In Memory n’ont plus besoin d’être stockées.
L’architecture des processeurs multi-core permet de traiter un grand nombre de requêtes en parallèle sans la contention qu’on observerait avec les I/O des disques durs.
Cette architecture permet d’offrir des services d’analyses performants, même en temps réel (mise à jour des données et re-calcul au fil de l’eau des agrégats) et de simulation.

Architecture Massivement Parallèle
Catégorie de solutions : Hadoop,Teradata

L’architecture Massivement Parallèle repose sur la division du stockage et des traitements sur une grille de serveurs. Les données sont stockées par bloc et répliqués entre les serveurs et les traitements (script SQL et code de calculs) sont transférés sur les serveurs impliqués par le traitement. La donnée ne bouge pas d’un serveur à l’autre, c’est le code de traitement (d’un volume toujours très faible) qui se déplace. Ce principe s’appelle la colocalisation entre traitements et données.
L’architecture Massivement Parallèle permet de stocker une quantité de données immenses (sans limites) et de manière élastique. Plus la taille de la grille augmente, plus sa capacité de traitement augmente.
Hadoop est une solution Massivement Parallèle Open Source, conçue pour fonctionner sur du commodity hardware.
L’architecture massivement parallèle est idéale et nécessaire pour des systèmes qui vont dépasser la dizaine de 10 To et au-delà.
Elle permet également de mettre en œuvre des traitements particulièrement complexes (datamining & machine learning, simulation numérique, …)

L’évolution des technologies hardware (RAM, multi-core, SSD, parallel computing) et software (architecture distribuée) est en train de fondamentalement bouleverser le paysage des architectures décisionnelles et de datamining.
L’architecture décisionnelle « traditionnelle » avec sa base de données n’est plus l’unique architecture de référence. Il existe à présent 3 architectures de référence complémentaire à maitriser : base de données, In Memory et massivement parallèle. Ces 3 architectures continuent cependant à partager un facteur de taille, à savoir la qualité de données.
Si on s’intéresse enfin à la dimension humaine associée à ces changements, la mobilisation est à l’ordre du jour :
- Les équipes de production doivent à présent être capable de maitriser des infrastructures unitairement plus simples, mais de plus grande taille à base de commodity hardware ou du matériel spécifique (appliance).
- Les équipes de développement doivent comprendre comment utiliser la puissance du massivement In Memory et de la programmation parallèle, en se détachant progressivement des bases de données relationnelles.
- Les centres de compétences décisionnelles doivent pouvoir accompagner ces équipes à maitriser les évolutions profondes de la technologie, pour tirer profit au mieux de ces architectures et des réductions de coûts qu’elles offrent pour des systèmes de plus en plus puissants.