Migrer son système décisionnel vers un environnement Big Data permet de dépasser les limites des bases de données traditionnelles en matière de montée en charge. Ainsi, les entreprises génèrent de nombreux bénéfices notamment lorsqu’il s’agit de migration dans le cloud.
Migration Big Data : performances linéaires et coûts prévisibles
Par leurs caractéristiques propres, les environnements Big Data apportent une alternative aux bases de données relationnelles (SGBDR), dès que celles-ci rencontrent des problématiques de performances ou de coûts. Effectivement, le coût de stockage est proche de zéro.
Une autre source d’économies peut être apportée par les technologies comme Hadoop : la structuration de données.
Contrairement aux SGBDR, où la structuration des données s’effectue en amont, avec les technologies Big Data, cette opération s’effectue à l’usage. Si on consolide N source de données, le choix d’un environnement Big Data permet d’économiser N opérations de structuration en entrée. Sans oublier évidemment le coût du matériel à proprement parler.
Avec Hadoop, les coûts sont prévisibles car les performances sont linéaires. Il est possible d’améliorer les temps de réponse d’un algorithme en augmentant le nombre de nœuds via une simple règle de trois. Une caractéristique qu’on ne retrouve pas dans les infrastructures classiques de SGBDR ou de data warehouse. Cette linéarité simplifie également les projections en matière de performances, ainsi que le déploiement des mises à jour (puisqu’il suffit de rajouter des nœuds de calcul).
> À LIRE AUSSI : Migration Hadoop : que faire de votre Hortonworks ?
Comme les technologies Big Data sont intrinsèquement peu adaptées aux applications transactionnelles, c’est dans le décisionnel que se situe la quasi-totalité des opportunités de migration. Et c’est aussi là que l’on trouve les volumétries de données les plus imposantes.
Pour les entreprises, l’opportunité offerte par les technologies Big Data est aussi l’occasion de remettre en cause les positions de certains éditeurs et de diminuer la dépendance à ces fournisseurs tout en s’attaquant au coût de licences associées.
Au-delà d’une simple migration technique
C’est le piège principal. Il est important de ne pas se contenter d’une simple migration technique, d’une simple traduction des scripts techniques.
Répliquer l’existant, c’est aller vers un échec assuré, car les logiques internes des technologies sont radicalement différentes. Par exemple, Spark ne gérant pas d’index, les jointures sont plutôt mal gérées sur le Big Data notamment sur des tables peu volumineuses (moins de 10Go) où les jointures seront plus lentes en Spark que dans des bases de données traditionnelles (à puissance égale).
Pour rendre la migration profitable, il faut donc en quelque sorte dénormaliser les bases de données. Rappelons qu’au lieu de modéliser les données en entrée (logique qui prévaut dans les bases relationnelles), le Big Data privilégie une approche dépendant de l’usage, donc les modélisations de données en sortie. Cela signifie que le métier qui utilise l’application doit aussi maîtriser les notions techniques intrinsèques au Big Data : la distribution des données et les latences réseau qui en découlent notamment. Une caractéristique qui impose une remise en cause des organisations séparant MOA et MOE vers des approches agiles, privilégiant les équipes mixtes.
En dehors de la remise en cause organisationnelle, le passage au Big Data va aussi se traduire par des coûts de migration. Ceux liés à la phase de fonctionnement en miroir des environnements de départ et de destination d’abord.
Sur la partie développement et le début de l’exploitation, on privilégie un fonctionnement en parallèle des deux environnements, avec une alimentation en Y de la donnée source. Ce ‘double run’ de deux systèmes décisionnels complets s’explique tant par la nécessité de sécuriser la migration que par le besoin de réécrire les scripts SQL qui fonctionnaient avec le ou les SGBDR et qui ne peuvent être réutilisés tels quels. Une phase où d’ailleurs, par sa flexibilité, le recours au Cloud montre toute sa pertinence, en facilitant le décommissionnement progressif des SGBDR et une montée en puissance graduelle du système technique de destination.
Recodage des scripts : un effort à ne pas négliger
Quoi qu’il en soit, cet effort de recodage des scripts représente un coût non négligeable. L’effort s’alourdit sensiblement si l’entreprise essaie de conserver ses scripts ETL tels quels.
La solution consiste plutôt à faire fonctionner cet outil en mode ELT (Extract, Load, Transfer), pour extraire et charger la donnée sur le système Big Data où elle sera transformée. Une logique qui fonctionne par exemple bien avec la solution de Talend, qui génère du code Java réexploitable dans Spark pour la transformation de données. Un élément intéressant notamment pour les organisations qui ont beaucoup investi sur des scripts de rejet ou de filtrage dans leur ETL.
Ce coût projet va peser sur la durée du retour sur investissement de la migration vers le Big Data.
Trois facteurs sont déterminants pour que l’opération soit rapidement rentable :
- prise en compte des coûts de licence sur les technologies traditionnelles,
- prise en compte de la valeur métier apportée par le Big Data car la migration vers de nouvelles technologies vient souvent sanctionner l’incapacité des SGBDR à répondre à certaines attentes des opérationnels,
- prise en compte des exigences pesant sur les organisations (exemple emblématique : le réglementaire).
La rédaction vous conseille
> Les 10 raisons d’une migration cloud dans un projet Big Data
