En tant que DBA, demandons-nous ce qu’est le « Big Data ». Pourquoi les bases de données sont NoSQL ? Pourquoi les jobs doivent être écrits en Java et MapReduce ? Qu’est-ce qui peut être si gros que ça ne rentre pas dans des machines Oracle Exadata associées jusqu’à 18 racks de chacun 672 To de disques ?
Peut-être que je deviens vieux car ce n’est pas la première fois que j’entends que les bases de données relationnelles ne fonctionnent pas ! Le Big Data est le sujet à la mode, au sommet du pic de la courbe de « hype » du Gartner en 2014 ; prêt à retomber. Mais passionné par notre travail, nous ne pouvons pas simplement ignorer le Big Data. Il faut prendre en compte le point de vue qu’il apporte sur les difficultés que nous rencontrons… Certains d’entre-nous ont déjà embrassé le « Big Data » et d’autres le feront encore !
C’est exactement le propos de cette série de 13 : « Comprendre les détails du fonctionnement d’Hadoop, une des technologies clé du Big Data ». Il y a beaucoup à apprendre et avant de descendre dans les détails, arrêtons nous quelques instants. Qu’est-ce que nous avons, nous DBAs en commun avec le Big Data ?

Nous sommes des Big DBAs…

Le Big Data se répend partout, des organisations Internet aux télécoms, à la banque, au secteur public et bien plus encore. C’est une collection d’infrastructures et d’algorithmes qui ont été inventés et créés pour adresser certains des enjeux… que nous DBA rencontrons depuis des années. Parce que la plupart d’entre-nous gère des dizaines de tera-octets sinon des centaines stockés dans des bases de données relationnelles. Nous sommes déjà des Big DBAs :

• Volume : les tailles des bases de données explosent, les tailles des bases de données relationnelles
• Variété : les informations sont stockés dans une multitude de formats : les données relationnelles co-existent avec des documents, des photos, de la video, de fichiers XML, les structures géographiques et plus récemment, les structures JSON, les ontologies web et le web des données (Linked Data) Toutes ces données sont traitées ensemble
• Vitesse : les systèmes d’acquisition sont de plus en plus rapides ; les chargements dans les systèmes décisionnels ou transactionnels sont massifs et s’appuient sur des informations générés par d’autres systèmes
• Valeur : la multitude des données n’a qu’un intérêt faible. Et pourtant, dans ce bruit, il existe des signaux forts de pannes qu’il est possible de prévenir, de clients prêts à acheter, de fraudeurs prêts à passer à l’acte, de personnes prêtes à tomber amoureuses…

Et pourtant, si les problèmes sont similaires, l’angle est différent… Et, en tant que DBA, nous devons, plus que quiconque y porter attention, en comprendre les tenants et les aboutissants. Alors observons ce que le Big Data apporte de neuf pour en tirer parti. Observons quand il est préférable de l’utiliser.

Les ruptures technologiques du Big Data

Le Big Data est né de la réussite de Google et des descriptions des modèles utilisés à cette occasion : GFS, MapReduce et BigTable. De nombreuses organisations ont depuis commencé et reconstruit des plateformes « from scratch », cassant au passage certains postulats acceptés depuis des décennies. Si bien que les ruptures technologiques sont, plus que tout autre chose, ce qui rassemble Amazon DynamoDB et Apache Hadoop. Car après tout, à moins d’être un âne, personne ne pense que perdre la consistence des données, la gestion transactionnelle ou le SQL n’a d’intérêt en soi… En revanche, sacrifier ces propriétés peut être la clé à de nouvelles capacités des systèmes d’informations et de problèmes que nous rencontrons :

• en tant que DBA, nous avons tous expérimenté le fait que les performances des applications qui s’appuient sur des systèmes transactionnels rencontrent des limites, sinon des murs, avec la croissance de l’activité et des volumes. Les applications nécessitent alors des ré-écritures partielles. En cassant les modèles transactionnels et la consistence des données, les bases de données NoSQL fournissent avec un réel succès, et moyennant certaines contraintes, des systèmes dont les capacités de montée en charge ne sont pas altérées par l’activité et les volumes de données. Vous pouvez le vérifier par vous-même.
• en tant que DBA, nous avons vécu la difficulté et le temps nécessaire pour modéliser et faire évoluer des systèmes décisionnels et entrepôt de données. En autorisant la collecte les données en vrac dans un système décrit comme un « lac de données », un système comme Hadoop permet de construire des systèmes de collecte extrêmement rapides et de transformer les expériences des systèmes décisionnels. Ces données sont collectées avant même d’être décrites et exploitées. Le concept de « schema on read » en opposition au « schema on write » des systèmes décisionnels classiques permet de faire évoluer des systèmes en quelques heures contre plusieurs jours ou semaines de manière classique…
• En tant que DBA, nous avons tous l’expérience de systèmes construit sur mesure et basés sur des licences coûteuses et du matériel spécialisé. Les approches cloud, standard et open-source des infrastructures Big Data transforment ces expériences projets et permettent d’ajouter des ressources simplement, temporairement sans phénomène de rupture…

En plus d’être une réelle opportunité pour certains d’entre-nous, le Big Data est donc un des terrains sur lesquel se développent des changements technologiques importants. Les outils qui en découlent et en découleront compléteront sans doute prochainement l’arsenal de nos outils de DBA. Parfois, en complément. D’autres fois, de manière indépendante des approches classiques. Souvent aussi, sans doute, de manière intégrée, à l’instar des bases de données organisées en colonnes, hier technologies du « Big Data » et désormais technologie « classique » des bases de données Oracle avec l’option Oracle In-Memory.

Pourquoi commencer ce voyage ?

• (Cet article) Big Data et ruptures technologiques (1/13)
• Compiler Hadoop pour Oracle Linux 7 (2/13)
• Construire un cluster Hadoop (3/13)
• Comprendre et utiliser HDFS (4/13)
• Développer et déployer un job MapReduce (5/13)
• Développer une application Yarn (6/13)
• Améliorer une application Yarn (7/13)
• Scripts Pig et Pig DataFu (8/13)
• Exemple d’utilisation de SQL avec Hive (9/13)
• Intégrer les données relationnelles avec Sqoop (10/13)
• Mahout et algorithmes d’analyse prédéfinis (11/13)
• Spark : Hadoop et In-Memory (12/13)
• Les projets BigData (13/13)

Le Big Data est un domaine en pleine évolution. Là comme ailleurs, ne croyez pas ce qu’on vous raconte ! Faîtes vous une opinion par vous-même : personne ne veut réellement abandonner les propriétés ACID ou le langage SQL ; au contraire, les projets Big Data ré-intègrent quand c’est possible, ce type de propriétés. Par ailleurs, ce n’est pas parce que c’est « Big » que c’est « Beau » et ne peut pas être remis en question. Avec Yarn et Spark, Hadoop a déjà abandonné MapReduce pour un modèle bien plus évolué. Google a d’ailleurs annoncé, lui aussi, avoir abandonné MapReduce pour un modèle plus évolué. Preuve, s’il en fallait, que les technologies Big Data sont loin d’être figées et que l’ordre établi peut toujours être remis en question.
N’hésitez pas à lire les articles qui suivront. N’hésitez pas non plus à partager vos humeurs si vous êtes un DBA, que vous soyez intéressé ou non par le Big Data !