Zones et conteneurs de lac de données
Il est important de planifier la structure de vos données avant de les placer dans un lac de données. Quand vous avez un plan, vous pouvez utiliser efficacement la sécurité, le partitionnement et le traitement.
Pour obtenir une vue d’ensemble des lacs de données, consultez Vue d’ensemble d’Azure Data Lake Storage pour l’analytique à l’échelle du cloud.
Vue d’ensemble
Vos trois comptes Data Lake doivent s’aligner sur les couches classiques d’un lac de données.
| Numéro du lac | Calques | Nombre de conteneurs | Nom du conteneur |
|---|---|---|---|
| 1 | Brut | 1 | Accueil |
| 1 | Brut | 2 | Conformité |
| 2 | Enrichie | 1 | Standardisé |
| 2 | Organisé | 2 | Produits de données |
| 3 | Développement | 1 | Bac à sable analytique |
| 3 | Développement | # | Nombre de stockages principaux Synapse |
Le tableau précédent indique le nombre standard de conteneurs que nous recommandons par zone d’atterrissage des données. Cette recommandation comporte une exception : lorsque des stratégies de suppression réversible immuables ou différentes sont requises pour les données d’un conteneur. Ces exigences déterminent si d’autres conteneurs sont nécessaires.
Notes
Trois lacs de données sont illustrés dans chaque zone d’atterrissage des données. Le lac de données se trouve sur trois comptes de lac de données, et plusieurs conteneurs et dossiers, mais il représente un seul lac de données logique pour votre zone d’atterrissage de données.
Selon vos besoins, vous pouvez regrouper les couches brutes, enrichies et organisées dans un compte de stockage. Conservez un autre compte de stockage nommé « développement » pour que les consommateurs de données apportent d’autres produits de données utiles.
Pour plus d’informations sur la séparation des comptes de lac de données, consultez Comptes de stockage dans un lac de données logique.
Activez le Stockage Azure avec la fonctionnalité Espace de noms hiérarchique, qui vous permet de gérer efficacement les fichiers. La fonctionnalité d’espace de noms hiérarchique organise les objets et les fichiers d’un compte dans une hiérarchie de répertoires et de sous-répertoires imbriqués. Cette hiérarchie est organisée de la même façon que le système de fichiers sur votre ordinateur.
Lorsque votre moteur d'ingestion de données agnostique ou votre application d'accueil enregistre un nouveau système d'enregistrement, il crée les dossiers nécessaires au sein de conteneurs dans les couches de données brutes, enrichies et normalisées. Si une application de données alignée sur la source ingère les données, votre équipe d’application de données a besoin de votre équipe de zone d’atterrissage de données pour créer les dossiers et les groupes de sécurité. Placez un nom de principal de service ou une identité managée dans le bon groupe, puis attribuez un niveau d'autorisation. Documentez ce processus pour vos équipes chargées de la zone d'atterrissage des données et de l'application des données.
Pour plus d’informations sur les équipes, consultez Comprendre les rôles et les équipes pour l’analyse à l’échelle du cloud dans Azure.
Chaque produit de données doit avoir deux dossiers dans le conteneur de produits de données, détenus par votre équipe de produits de données.
La couche enrichie d'un conteneur normalisé contient deux dossiers par système source, répartis par classification. Avec cette structure, votre équipe peut stocker séparément des données qui ont différentes classifications de sécurité et de données, et leur attribuer un accès de sécurité différent.
Votre conteneur normalisé nécessite un dossier général pour les données confidentielles ou inférieures et un dossier sensible pour les données personnelles. Contrôlez l'accès à ces dossiers avec des listes de contrôle d’accès (ACL). Vous pouvez créer un jeu de données avec toutes les données personnelles supprimées et le stocker dans votre dossier général. Vous pouvez avoir un autre jeu de données comprenant toutes les données personnelles dans votre dossier sensible de données personnelles.
Une combinaison de listes de contrôle d’accès (ACL) et de groupes Microsoft Entra limite l’accès aux données. Ces listes et groupes contrôlent ce qui est accessible ou non par d’autres groupes. Les propriétaires de données et les équipes chargées de l'application des données peuvent approuver ou refuser l'accès à leurs ressources de données.
Pour plus d’informations, consultez Gestion de l’accès aux données et Données restreintes.
Avertissement
Certains produits logiciels ne prennent pas en charge le montage de la racine d’un conteneur de lac de données. En raison de cette limitation, chaque conteneur de lac de données dans les couches brutes, organisées, enrichies et les couches de développement doit avoir un seul dossier qui se ramifie vers plusieurs dossiers. Configurez avec précaution vos autorisations de dossier. Quand vous créez un dossier à partir de la racine, la liste ACL par défaut du répertoire parent détermine la liste ACL par défaut d’un répertoire enfant et la liste ACL d’accès. La liste ACL d’un fichier enfant n’a pas de liste ACL par défaut.
Pour plus d’informations, consultez Listes de contrôle d’accès (ACL) dans Azure Data Lake Storage Gen2.
Couche brute, ou Data Lake 1
Considérons la couche brute comme un réservoir qui stocke les données dans leur état naturel d’origine. Elles ne sont ni filtrées ni purifiées. Vous pouvez stocker les données dans leur format d’origine, par exemple JSON ou CSV. Sinon, il peut être rentable de stocker le contenu du fichier sous forme de colonne dans un format de fichier compressé, comme Avro, Parquet ou Databricks Delta Lake.
Ces données brutes sont immuables. Verrouillez vos données brutes et, si vous accordez des autorisations à des consommateurs, automatisés ou humains, vérifiez qu’elles sont en lecture seule. Vous pouvez organiser cette couche en utilisant un dossier par système source. Donnez à chaque processus d’ingestion un accès en écriture qu’au dossier associé.
Quand vous chargez des données à partir de systèmes sources dans la zone brute, vous pouvez choisir de faire les opérations suivantes :
- Chargements complets pour extraire un jeu de données complet.
- Chargements delta pour charger uniquement les données changées.
Indiquez le modèle de chargement que vous avez choisi dans votre structure de dossiers pour simplifier l’utilisation des consommateurs de vos données.
Les données brutes des systèmes sources pour chaque application de données alignées sur la source ou source du moteur d’ingestion automatisé atterrissent dans le dossier complet ou delta. Un processus d’ingestion ne doit avoir accès en écriture qu’à son dossier associé.
Les différences entre les chargements complets et les chargements delta sont les suivantes :
Chargement complet : les données complètes de la source peuvent être intégrées si :
- Le volume de données sur la source est petit.
- Le système source ne gère aucun champ d’horodatage qui identifie si des données ont été ajoutées, mises à jour ou supprimées.
- Le système source remplace chaque fois les données complètes.
Chargement delta : les données incrémentielles de la source peuvent être intégrées si :
- Le volume de données sur la source est grand.
- Le système source gère un champ d’horodatage qui identifie si des données ont été ajoutées, mises à jour ou supprimées.
- Le système source crée et met à jour les fichiers lors des changements de données.
Votre lac de données brutes est constitué de vos conteneurs d’atterrissage et de conformité. Chaque conteneur utilise une structure de dossiers 100 % obligatoire propre à son objectif.
Disposition du conteneur d’atterrissage
Votre conteneur d’atterrissage est réservé aux données brutes provenant d’un système source reconnu. Votre moteur d’ingestion indépendant des données ou une application de données alignée sur la source charge les données, qui sont inchangées et dans leur format d’origine pris en charge.
.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full
Conteneur de conformité de couche brute
Votre couche brute contient des données de qualité conformes. Quand des données sont copiées dans un conteneur d’atterrissage, le traitement et le calcul des données sont déclenchés pour copier les données du conteneur d’atterrissage dans le conteneur de conformité. Dans cette première étape, les données sont converties au format delta lake et atterrissent dans un dossier d'entrée. Quand le test de qualité des données s’exécute, les enregistrements qui sont validés sont copiés dans le dossier de sortie. Les enregistrements qui échouent sont placés dans un dossier d’erreur.
.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
Conseil
Réfléchissez aux scénarios où vous pouvez avoir à reconstruire une plateforme analytique à partir de zéro. Tenez compte des données les plus granulaires dont vous avez besoin pour reconstruire les magasins de données de lecture en aval. Veillez à mettre en place un plan de continuité d'activité et de reprise d'activité pour vos composants clés.
Couche enrichie ou Data Lake 2
Considérez la couche enrichie comme une couche de filtrage. Elle élimine les impuretés et peut également favoriser un enrichissement.
Votre conteneur de normalisation contient des systèmes d’enregistrement et des données master. Les dossiers sont d’abord segmentés par zone de sujet, puis par entité. Les données sont disponibles dans des tables fusionnées et partitionnées, optimisées pour la consommation analytique.
Conteneur normalisé
.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}
Notes
Cette couche de données est considérée comme la couche argent ou la source de données en lecture. Les données de cette couche n’ont pas subi de transformation autre que le test de qualité des données, la conversion du lac de données et l’alignement du type de données.
Le diagramme suivant montre le flux de lacs de données et de conteneurs des données sources vers un conteneur normalisé.
Couche organisée ou Data Lake 2
Votre couche organisée est votre couche de consommation. Elle est optimisée pour l’analytique au lieu de l’ingestion ou le traitement des données. La couche organisée peut stocker des données dans des datamarts dénormalisés ou des schémas en étoile.
Les données de votre conteneur standardisé sont transformées en produits de données de haute valeur, servis à vos consommateurs de données. Ces données ont une structure. Elles peuvent être servies aux consommateurs en l’état (par exemple, des notebooks de science des données) ou à travers un autre magasin de données de lecture, comme Azure SQL Database.
Utilisez des outils, comme Spark ou Data Factory, pour faire de la modélisation dimensionnelle au lieu de le faire dans votre moteur de base de données. Cette utilisation des outils devient un point clé si vous souhaitez que votre lac devienne la seule source de vérité.
Si vous faites de la modélisation dimensionnelle en dehors de votre lac, vous pouvez republier des modèles dans votre lac pour des raisons de cohérence. Cette couche ne remplace pas un entrepôt de données. En règle générale, son niveau de performance n’est pas adapté aux tableaux de bord dynamiques ni à l’analytique interactive pour les utilisateurs finaux ou le grand public. Cette couche est idéale pour les analystes internes ou les scientifiques des données qui exécutent des requêtes ou des analyses improvisées à grande échelle, ou pour les analystes avancés qui n’ont pas d’exigences de rapport soumises à une contrainte de temps. Dans la mesure où les coûts de stockage de votre lac de données sont inférieurs à ceux de votre entrepôt de données, il peut être rentable de conserver des données granulaires de bas niveau dans votre lac. Stockez les données agrégées dans votre entrepôt. Générez ces agrégations avec Spark ou Azure Data Factory. Rendez-les persistantes dans votre lac de données avant de les charger dans votre entrepôt de données.
Les ressources de données de cette zone sont généralement soumises à une gouvernance stricte et sont bien documentées. Attribuez des autorisations par service ou fonction, puis organisez les autorisations par groupe de consommateurs ou datamart.
Conteneur de produits de données
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
Conseil
Quand vous faites atterrir des données dans un autre magasin de données de lecture comme Azure SQL Database, vérifiez que vous avez une copie de ces données dans vos données organisées. Les utilisateurs de votre produit de données sont guidés vers votre magasin de données de lecture principal ou votre instance Azure SQL Database, mais ils peuvent également explorer les données avec des outils supplémentaires si vous mettez les données à disposition dans votre lac de données.
Couche de développement ou lac de données trois
Vos consommateurs de données peuvent apporter d'autres produits de données utiles avec les données ingérées dans votre conteneur normalisé.
Dans ce scénario, votre plateforme de données peut allouer une zone de bac à sable analytique à ces consommateurs. Dans le bac à sable, ils peuvent générer des insights précieux en utilisant les données organisées et les produits de données qu'ils apportent. Par exemple, si une équipe de science des données souhaite déterminer la meilleure stratégie de placement de produit dans une nouvelle région, elle peut ajouter d’autres produits de données, comme les données démographiques des clients et les données d’utilisation de produits similaires dans cette région. L’équipe peut utiliser les insights commerciaux à forte valeur ajoutée de ces données pour analyser l’adéquation du produit au marché et la stratégie d’offre.
Notes
La zone de bac à sable analytique est une zone de travail destinée à une personne ou un petit groupe de collaborateurs. Les dossiers de la zone de bac à sable comportent un ensemble spécial de stratégies qui empêche toute tentative d'utiliser cette zone dans le cadre d'une solution de production. Ces stratégies limitent le stockage total disponible et la durée de stockage des données.
La qualité et l’exactitude de ces produits de données sont généralement inconnues. Ils sont encore classés comme produits de données, mais sont temporaires et concernent seulement le groupe d’utilisateurs qui utilise les données.
Quand ces produits de données arrivent à maturité, votre entreprise peut les promouvoir dans votre couche de données organisées. Pour que vos équipes chargées des produits de données restent responsables des nouveaux produits de données, fournissez-leur un dossier dédié sur votre zone de données organisée. Elles peuvent stocker les nouveaux résultats dans le dossier et les partager avec d’autres équipes au sein de votre organisation.
Notes
Pour chaque espace de travail Azure Synapse que vous créez, utilisez Data Lake 3 pour créer un conteneur comme stockage principal. Ce conteneur empêche les espaces de travail Azure Synapse d’interférer avec la limite de débit de votre zone organisée et de la zone enrichie.
Exemple de flux de données vers les produits et le bac à sable analytique
Le diagramme suivant compile les informations de cet article et montre comment les données circulent vers un bac à sable analytique et de produits de données.
