Comment une requête SQL interroge un Datalake : voyage au cœur des couches physiques et logiques

🔗 Comment une requête SQL interroge un Datalake : voyage au cœur des couches physiques et logiques

Lorsqu’un utilisateur exécute une simple requête SQL sur une plateforme de données du type Datalake ou Lakehouse, un enchaînement de mécanismes complexes se met en place en arrière-plan pour fournir une réponse en quelques secondes. Mais comment cette magie opère-t-elle réellement ? Comment une plateforme de données interprète-t-elle des fichiers bruts répartis sur un stockage distribué comme s’il s’agissait de tables relationnelles ?

Dans cet article, nous allons décortiquer ce processus en explorant les trois couches fondamentales impliquées :
👉 la couche de requêtage,
👉 la couche logique (catalogue de métadonnées),
👉 et la couche physique (stockage).

Pour illustrer le tout, nous nous appuierons sur un exemple simple et universel.

⚙️ 1. Le moteur de requête (Query Engine)

C’est lui qui exécute les requêtes SQL. Lorsqu’un utilisateur lance une instruction comme :

le moteur de requête est chargé de transformer cette requête en opérations distribuées, d’interroger les métadonnées, d’accéder aux fichiers, de filtrer les résultats, puis de renvoyer la réponse.

🔧 Exemples de moteurs de requêtes :

• Sur AWS : Amazon Athena, Amazon EMR, Glue Jobs, etc

• Sur Azure : Azure Synapse SQL

• Sur Hadoop / On-premise : Hive, Impala, Apache Spark SQL

• Cloud universel : Trino, Presto, Dremio, Azure Databricks

📚 2. La couche logique : le catalogue de métadonnées

Pour interpréter correctement les fichiers stockés dans le Datalake, le moteur de requête a besoin de connaître leur structure : nom des colonnes, types, format de fichier, séparateur, emplacement, etc.
C’est le catalogue de métadonnées, souvent appelé Metastore ou Catalog, qui centralise ces informations.

🎓 Rôle du Metastore :

• Indique le format des fichiers (CSV, Parquet, Delta, ORC…)

• Spécifie les types de colonnes

• Donne le chemin d’accès aux données sur le stockage (par exemple s3://bucket/path/ ou hdfs://path/)

• Sert de référence unique pour tous les moteurs de traitement

🧰 Exemples de catalogues techniques :

• Sur AWS : AWS Glue Data Catalog

• Sur Azure : Azure Purview

• Sur Cloudera : Hive Metastore (HMS)

• Autres : Unity Catalog (Databricks)

🗃️ 3. La couche physique : le stockage des données

C’est ici que résident les fichiers bruts — souvent dans des formats comme CSV, Parquet, ORC ou Delta Lake — stockés dans un système de fichiers distribué.

Le moteur de requête, une fois informé par le catalogue de la structure des fichiers, accède au stockage et lit uniquement les blocs nécessaires pour répondre à la requête.

🗄️ Exemples de stockages Datalake :

• Sur AWS : Amazon S3

• Sur Azure : Azure Data Lake Storage Gen2 (ADLS)

• Sur Hadoop : HDFS (Hadoop Distributed File System)

• Cloud-native ou hybride : MinIO, Google Cloud Storage, etc

🔄 Illustration complète du processus

Prenons un exemple : l’utilisateur exécute la requête suivante :

Voici comment la plateforme traite cette requête :

1. Le moteur de requête (ex. Hive, Athena, Synapse, Spark) reçoit la requête.

2. Il interroge le catalogue de métadonnées (ex. Hive Metastore, Glue, Unity Catalog) pour connaître :

   • Le chemin des fichiers (hdfs://datasource/personnes/)

   • Le format (CSV)

   • Le séparateur (;)

   • Le schéma (nom : string, âge : int)

3. Une fois le schéma connu, le moteur lit les fichiers du Datalake depuis le stockage (ex. HDFS ou S3).

4. Il filtre les lignes selon la condition age = 37.

5. Il retourne les résultats à l’utilisateur.

🧠 Pourquoi cette architecture est-elle puissante ?

Cette approche offre plusieurs avantages majeurs :

✅ Séparation des responsabilités :
Le moteur de traitement, le stockage et la gouvernance des métadonnées sont découplés. Cela améliore la flexibilité et l’évolutivité.

✅ Interopérabilité :
Plusieurs moteurs (Spark, Hive, Presto, etc.) peuvent interroger les mêmes données sans duplication, via un catalogue partagé.

✅ Ouverture et évolutivité :
L’utilisation de formats ouverts (Parquet, Delta, ORC…) et de systèmes distribués permet d’exploiter la puissance du cloud ou du on-premise.

✅ Gouvernance centralisée :
Les catalogues de métadonnées permettent d’appliquer des règles de qualité, sécurité, traçabilité (via des outils comme Apache Ranger ou Purview).

📌 En résumé

Une simple requête SQL dans un Datalake repose en réalité sur un trio puissant :

Cette architecture est aujourd’hui le socle de la majorité des plateformes modernes de données à grande échelle, qu’elles soient déployées dans le cloud ou sur site.

Mehdi TAZI – CTO & Data Architect a BI-NEWVISION