Trois pratiques pour doper vos requêtes SQL en 2020

Cette chronique a été rédigée pour vous. Dans cette chronique, nous allons vous montrer 3 approches à utiliser pour doper efficacement la performance de vos requêtes SQL.

Pourquoi avez-vous du mal avec vos requêtes SQL ?

A ce stade, vous savez que la baisse des coûts de stockage des données dans Hadoop fait du HDFS l’option la plus profitable en termes de coûts financiers pour le stockage et le traitement des données.  Traditionnellement, lorsqu’on est parvenu à stocker les données dans un Data warehouse, l’interrogation des données consiste souvent à exécuter des requêtes SQL sur le serveur. Ainsi, l’interrogation classique de données se fait à l’aide du SQL.

Le problème c’est que de base, le SQL est un langage ensembliste. Son exécution est très appropriée pour l’interrogation des données qui entretiennent des liens métiers forts. Lorsqu’il est utilisé dans un environnement distribué tel qu’un cluster Hadoop, les problèmes de latence qu’on observe partout dans les projets Big Data sont alors inévitables.

En réalité, l’interrogation efficace des données en environnement Big Data et dans un cluster Hadoop en particulier suit un ensemble de principes que vous devez connaître et respecter scrupuleusement si vous souhaitez garder vos métiers contents.

Il existe 3 grandes approches d’interrogation de données en Big Data. Ce sont ces  3 approches qui structurent cette  chronique :

•  les Moteur SQL sur Hadoop :

l’exécution des jobs sur Hadoop en utilisant le SQL ou un langage similaire (nativement ou pas)

• le SQL natif sur Hadoop :

l’exécution native du code SQL directement sur le HDFS sans aucune transformation en job de calcul massivement parallèle

• les  Moteurs relationnels distribués sur Hadoop :

l’utilisation d’un SGBD MPP (Massively Parallel Processing) tel que Teradata ou GreenPlum qui est capable d’exécuter le SQL sur un cluster

Les bases de l’interrogation des données en Big Data

Avant toute plongée en eaux profondes, revenons sur les fondements de l’interrogation de données à large échelle. Vous devez savoir que dans l’interrogation classique de données, ce sont des requêtes ensemblistes, des opérations d’algèbres linéaires telles que la projection, l’union, l’intersection, les jointures, qui sont exécutées sur la base de données à travers le SQL. En environnement distribué par contre, l’interrogation des données repose sur ce qu’on appelle un modèle de calcul.

D’une façon générale, un modèle de calcul est un modèle algorithmique, c’est-à-dire une façon de penser le découpage d’une requête en tâches exécutables dans un ordinateur. En environnement distribué comme dans un cluster Hadoop, le modèle de calcul est un modèle algorithmique qui permet de découper les requêtes en tâches indépendantes qui s’exécutent simultanément dans le cluster.

En effet, pour qu’une requête profite du parallélisme offert par un cluster, il faut que le modèle de calcul qui permet de traduire cette requête en tâches respecte 2 conditions :

• il faut qu’il soit capable de découper les requêtes en tâches indépendantes.

Ainsi, chaque tâche n’entretiendra aucun lien avec les autres tâches et pourra s’exécuter indépendamment sur un nœud du cluster. La montée à l’échelle se fera alors simplement par augmentation du nombre des tâches et/ou du nombre de nœuds dans le cluster.  C’est d’ailleurs cette condition d’indépendance qui différencie le traitement massivement parallèle d’un cluster du traitement multi-threading.

• Il faut que le modèle soit exécutable sur les CPU.

En effet, conceptuellement parlant, il peut être simple de définir la solution à un problème. Mais la solution ainsi conçue peut ne pas être pratique. Le modèle de calcul doit pouvoir s’exécuter dans le cluster, tout en tenant compte des contraintes de ressources, de haute disponibilité, de tolérance aux pannes, des habilitations des utilisateurs et de sécurité.

Le MapReduce est le modèle de calcul de base utilisé dans l’interrogation des données en environnement distribué (dans un cluster). Cela signifie que par défaut, quand vous lancez une requête sur un cluster Hadoop, cette requête est transformée en job MapReduce et exécutée sur le cluster. Le MapReduce est un modèle très simple qui découpe l’exécution d’une requête en 3 phases interdépendantes : le Map, le Shuffle et le Reduce. Ainsi, toute requête exécutée dans un cluster passe par 3 phases : une phase Map, où les données sont transformées en paires de <clés ; valeurs>, une phase Shuffle, où les paires ainsi obtenues sont triées, et une phase Reduce où les paires triées sont agrégées selon une fonction d’agrégation (la SOMME, MOYENNE, etc.). La figure résume mieux l’exécution d’une requête selon le modèle de calcul MapReduce.

A cause de sa simplicité, le MapReduce est à la base de quasiment tous les modèles de calcul utilisés actuellement pour exécuter des requêtes sur le cluster. A cette phrase, vous vous demandez peut-être :

« Juvénal, si le MapReduce suffit pour gérer l’exécution des requêtes, pourquoi la problématique d’interrogation de données en Big Data se pose-t’elle alors ?  »

Si la problématique se pose, c’est pour deux raisons simples :

Problème #1 : Le MapReduce n’est pas adapté à tous types de requêtes. Par exemple, les requêtes relatives aux travaux d’analyse de données (Machine Learning, Data Science, etc…), très itératifs pour la plupart, sont très difficilement parallélisable et ne peuvent pas [facilement] s’exécuter en MapReduce.

Problème #2 :  L’écriture des jobs MapReduce n’est pas à la portée des métiers. En effet, l’écriture d’une requête en MapReduce demande l’utilisation d’un langage évolué tel que Java ou Scala. De plus, elle nécessite la connaissance poussée de la programmation distribuée. Les personnes qui exécutent les requêtes au jour le jour dans une entreprise, ce sont les métiers. Il peut s’agir du contrôleur de gestion qui souhaite avoir le total des ventes du mois, le Product Owner  qui souhaite faire de la recette pour son projet, les testeurs, qui souhaitent faire de la qualification fonctionnelle, etc… Tout ce public n’a pas pour compétence de base la programmation distribuée.

C’est principalement pour répondre à ces 2 besoins que de nouvelles approches de traitement de données en environnement distribué et des extensions du MapReduce ont été créées.