Module 3 — Jeux de données et magasins de données

Le module 1 a livré un espace de travail avec son compte de stockage attaché ; le module 2 a fourni le calcul. Il reste à donner à ces calculs quelque chose à mâcher : les ventes hebdomadaires par magasin et produit du fil rouge. Azure ML sépare volontairement deux notions : le magasin de données (où sont les octets) et l'actif de données (une référence versionnée à un sous-ensemble). C'est cette séparation qui rend le lignage traçable.

Magasins de données : la connexion, pas les fichiers

Un datastore est une connexion nommée vers un service de stockage Azure, avec ses identifiants. Il ne contient aucun fichier — c'est une adresse plus un secret. À la création du workspace, quatre magasins sont provisionnés automatiquement :

Nom par défaut	Service	Usage
workspaceblobstore	Azure Blob	données et artefacts
workspacefilestore	Azure Files	notebooks partagés
workspaceartifactstore	Blob	sorties de tâches
workspaceworkingdirectory	Files	dossier maison des instances

Pour le fil rouge, les ventes vivent dans un compte Azure Data Lake Storage Gen2 séparé, propriété de l'équipe Ventes. On l'enregistre comme cinquième magasin :

$schema: https://azuremlschemas.azureedge.net/latest/azureDataLakeGen2.schema.json
type: azure_data_lake_gen2
name: ds_ventes
account_name: dllakeventes
filesystem: bronze
credentials:
  tenant_id: 00000000-0000-0000-0000-000000000000
  client_id: 11111111-1111-1111-1111-111111111111
  client_secret: ${SECRET_FROM_KV}

Trois recommandations issues du terrain :

• Préférer l'identité gérée du workspace à un secret de principal de service : credentials: {} combiné avec un rôle Storage Blob Data Reader évite d'entretenir un secret dans le Key Vault
• Ne jamais coder en dur un secret dans le YAML : la CLI accepte les substitutions ${SECRET_FROM_KV} qui vont chercher dans le coffre
• Un magasin par domaine métier, jamais un magasin fourre-tout : lorsqu'un accès doit être retiré, on retire un magasin entier

Actifs de données : la référence versionnée

Un data asset est une référence pointant vers un chemin dans un magasin, avec une version, un nom et éventuellement un schéma. C'est cette référence — pas le chemin brut — qui est passée en entrée d'une tâche. Trois types coexistent :

• uri_file : un unique fichier (ventes/2026-01.parquet)
• uri_folder : un dossier complet (ventes/2026/), pratique pour un balayage
• mltable : une table logique, définie par un fichier MLTable qui décrit sources, schéma et transformations légères

Le type mltable est celui à connaître pour le fil rouge. Le fichier MLTable associé au jeu de ventes ressemble à ceci :

$schema: http://azureml/sdk-2-0/MLTable.json
type: mltable
paths:
  - pattern: "ventes/2024/*.parquet"
  - pattern: "ventes/2025/*.parquet"
  - pattern: "ventes/2026/*.parquet"
transformations:
  - read_parquet
  - keep_columns:
      columns: [date, magasin_id, produit_id, unites, chiffre_affaires]
  - convert_column_types:
      columns: date
      column_type: datetime

Enregistré comme actif nommé ventes_magasins, il devient une entrée réutilisable :

az ml data create --name ventes_magasins --version 3 \
  --type mltable --path ./mltable-ventes/

Dans la tâche du module 5, cette entrée sera référencée par azureml:ventes_magasins:3 — jamais par un chemin abfss:// en dur. Le lignage remonte alors du modèle enregistré jusqu'à la version exacte des données utilisées, ce qui est le vrai apport du MLTable face à un simple uri_folder.

Pourquoi MLTable plutôt qu'un URI direct

Un uri_folder fonctionne, mais le contenu du dossier peut changer sans qu'aucune version ne bouge. Le lignage devient alors mensonger : on croit rejouer avec les mêmes données, on rejoue avec des données différentes. MLTable fige la liste des fichiers correspondants et le schéma retenu ; c'est cette fixité qui permet un audit crédible.

Le mode d'accès : monté ou téléchargé

Une tâche qui consomme un actif choisit entre deux modes :

• mount : le stockage est exposé comme un système de fichiers local ; les lectures se font à la demande. Idéal pour un balayage sur un gros jeu dont chaque exécution ne lit qu'un sous-ensemble.
• download : la totalité de l'actif est copiée sur le disque du nœud avant que le script ne démarre. Plus rapide en lecture pour un petit jeu qu'on lit entièrement, plus lent au démarrage.

Le fil rouge lit toutes les ventes de 2024 à 2026 pour ré-entraîner : download est le bon choix, ce qui évite de saturer la bande passante réseau à chaque itération d'un balayage de 40 exécutions.

Le lignage automatique

Chaque tâche enregistre dans son manifeste la liste des actifs consommés et la liste des actifs produits. Le portail affiche ce graphe : cliquer sur le modèle enregistré remonte à la tâche, puis aux entrées, puis au fichier MLTable. C'est un audit gratuit — à condition que rien ne soit lu par un chemin brut hors actif.

En résumé

• Magasin de données = connexion + secret ; actif de données = référence versionnée à un contenu
• Préférer l'identité gérée à un principal de service, un secret en moins à faire tourner
• MLTable est la référence recommandée : elle fige la liste de fichiers et le schéma, prérequis à un lignage crédible
• Choisir mount pour un accès partiel à un gros jeu, download pour un petit jeu lu intégralement à chaque exécution

Le module suivant habille ces données de leur environnement d'exécution : bibliothèques Python et image conteneurisée reproductible.