WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Stratégies d'optimisation de requêtes SQL dans un écosystème Hadoop

( Télécharger le fichier original )
par Sébastien Frackowiak
Université de Technologie de COmpiègne - Master 2 2017
  

précédent sommaire suivant

2 INTRODUCTION

Créé en 2011, Hadoop s'est imposé depuis plusieurs années comme la principale plateforme Big Data. Il représente une réelle rupture dans le traitement des donnéeset il a modifié en profondeur la manière de concevoir et d'utiliser les entrepôts de données.

2.1 Entrepôt et Bases de Données Relationnelles

Un entrepôt de données traditionnel permet de stocker les données provenant de plusieurs applications d'un Système d'Information afin d'en tirer des enseignements et ainsi aider l'entreprise dans ses décisions.

La création d'un tel entrepôt de données impliquela mise en oeuvre d'une Base de Données Relationnelle dont lepréalable fondamental est sa modélisation. Modélisationqui tacitement met en exergue des clés (primaires et étrangères) et des index, ce qui favoriseune manière de requêter les données plutôt qu'une autre.En effet, sans entrer dans les détails du fonctionnement d'un Système de Gestion de Base de Données Relationnelle (SGBDR), il est important de signaler que le requêtage SQL de deux tables jointes l'une à l'autre s'effectue le plus souvent via leurs clés respectives. Ces clés traduisent des contraintes qui garantissent la cohérence des résultats et permettent l'utilisation des fonctions d'indexation qui accélèrent leur obtention.

Lorsque les volumes de données manipulées sont ceux du Big Data, nous pouvons nous permettre de nous passer de ces contraintes trop rigides.

2.2 Entrepôt et Bases de Données Big Data

Les technologies du Big Data permettent dorénavant de stocker sur des systèmes de fichiers distribués de grandes quantités de données, issues principalement de flux continus et de Bases de Données Relationnelles provenant de SI et d'organisations distinctes.

Des solutions exploitant le paradigme distribué MapReduce(qui fait notamment l'objet de ce mémoire) permettent l'interrogation de ces grandes quantités de données, de la même manière que sur un SGBDR classique, en utilisant le langage SQL. Dans ce cas de figure, les données sont structurées dans des tables formant un unique "puits de données", ce qui rend ainsi possible, au travers de jointures, des croisements de données issues d'applications et d'organisations différentes (au sein même d'Orange mais aussi en dehors d'Orange, provenant de l'Open Data par exemple). Avec un SGBDR classique, ce type de traitement aurait pu prendre des jours contre seulement quelques minutes aujourd'hui avec le Big Data.

Si dans une Base de Données Relationnelle, les jointures sont anticipées dès la phase de conception (par identification des clés et des index), ce n'est pas le cas pour un puits de données qui ne couvre aucun cas d'usage de prime abord. De ce fait, les champs utilisés pour joindre deux tables n'expriment aucune contrainte (il s'agit d'une fonction propre aux clés primaires et étrangères des SGBDR) et ne sont pas indexés (il serait hasardeux d'anticiper un plan d'indexation particulier sachant que la conception du puits de données ne préjuge en rien de la manière dont il sera requêté). C'est donc une nouvelle manière d'optimiser les requêtes qui doit être pensée.

précédent sommaire suivant











9Impact, le film from Onalukusu Luambo on Vimeo.



Visitez Arcy sur Cure

Camping du Saucil a(Villeneuve sur Yonne)