Comprendre les architectures data lake et lakehouse modernes sur Azure.
Les flashcards combinées à la répétition espacée renforcent la mémorisation active. Vous révisez au bon moment, vous retenez plus durablement, et vous mesurez vos progrès carte après carte.
Carte 1
Centraliser des données brutes hétérogènes pour des usages analytiques futurs
Explication
Le Data Lake vise surtout à stocker massivement des données brutes multi‑sources pour permettre des usages évolutifs sans modélisation préalable stricte.
Erreur fréquente
Confondre Data Lake avec un entrepôt déjà modélisé prêt pour la BI classique.
Carte 2
Fournir des données fiabilisées optimisées pour la consommation analytique
Explication
Le Data Warehouse est conçu pour exposer des données nettoyées, cohérentes et performantes pour la BI et le reporting.
Erreur fréquente
Penser qu’un Data Warehouse doit conserver l’intégralité de toutes les données brutes.
Carte 3
Le premier privilégie le schema-on-read plutôt que le schéma en étoile figé
Explication
Le Data Lake tolère des structures variées et reporte l’interprétation du schéma à la lecture, contrairement au Data Warehouse.
Erreur fréquente
Croire qu’un Data Lake doit répliquer le même schéma dimensionnel que le Data Warehouse.
Carte 4
Il applique des contraintes de schéma fortes directement sur les tables de fichiers
Explication
Le Lakehouse ajoute une couche transactionnelle et de gouvernance de schéma au‑dessus du stockage objet brut.
Erreur fréquente
Assimiler le Lakehouse à un simple Data Lake sans contrôle de schéma.
Carte 5
Il exploite du stockage objet économique séparé de la puissance de calcul
Explication
La séparation compute‑storage et l’usage de stockage objet réduisent les coûts par rapport à une base MPP toujours active.
Erreur fréquente
Penser que les coûts d’un Lakehouse proviennent surtout du stockage plutôt que du calcul consommé.
Carte 6
L’ingestion massive de données brutes pour data science exploratoire
Explication
Les explorations data science tirent parti d’un stockage flexible et peu contraint sur le schéma.
Erreur fréquente
Forcer un modèle dimensionnel complet avant même de connaître les usages exploratoires.
Carte 7
Combiner workloads BI et data science sur des tables gouvernées uniques
Explication
Le Lakehouse permet de servir rapports, dashboards et notebooks depuis les mêmes tables fiables.
Erreur fréquente
Utiliser un Lakehouse uniquement comme stockage de fichiers sans tirer parti de la couche tabulaire.
Carte 8
ADLS Gen2 expose une hiérarchie de dossiers de type système de fichiers
Explication
ADLS Gen2 permet une arborescence avec chemins et répertoires logiques, facilitant l’organisation des données analytiques.
Erreur fréquente
Considérer qu’ADLS Gen2 et Blob Storage ont exactement les mêmes fonctionnalités de hiérarchie.
Carte 9
Contrôler finement l’accès lecture/écriture par dossier et fichier
Explication
Les ACL POSIX permettent de définir des permissions granulaires indépendamment des rôles sur le compte de stockage.
Erreur fréquente
S’appuyer uniquement sur les rôles RBAC du compte sans configurer les ACL POSIX nécessaires.
Carte 10
Utiliser l’identité Azure AD pour sécuriser et auditer l’accès aux fichiers
Explication
L’intégration Azure AD permet un contrôle d’accès basé sur l’identité et une meilleure traçabilité des usages.
Erreur fréquente
Continuer à partager des clés d’accès stockage au lieu de basculer sur l’authentification Azure AD.
Créez votre compte Memia pour débloquer ce deck et lancer vos sessions de révision avec suivi de progression.