Meilleures pratiques pour l’agent d’ingénierie des données Fabric (Project Osmos) - aperçu

Utilisez ces bonnes pratiques pour définir des résultats complets, protéger les données du lakehouse, rendre les réexécutions prévisibles et exiger des tâches de l’agent d’ingénierie des données Fabric (Project Osmos) des preuves mesurables de réussite.

Important

L’agent d’ingénierie des données (Project Osmos) est en aperçu. Les fonctionnalités de prévisualisation sont publiées avec des capacités limitées et sont soumises à des conditions supplémentaires distinctes pour les prévisualisations. Ils ne sont pas destinés à la production, ne sont pas soumis à des accords de niveau de service, et peuvent être disponibles uniquement dans certaines régions. Pour plus d’informations, consultez les informations d’aperçu de Microsoft Fabric.

Définir le résultat complet d’un projet

La compétence définit le résultat du Project comme suit :

Décrivez la tâche complète d’ingénierie des données de bout en bout. L’agent d’ingénierie des données le reçoit comme un seul projet.

Définissez le résultat complet plutôt que seulement la première étape de mise en œuvre. Incluez ces cinq éléments :

Élément Question à répondre Exemple
Objectif Quel résultat devrait-il exister une fois la tâche terminée ? Créez un tableau mensuel des dépenses fournisseurs.
Sources Quelles données la tâche devrait-elle utiliser ? Lisez les fichiers CSV des factures et la table Delta des fournisseurs.
Transformations Quelles règles la tâche devrait-elle appliquer ? Standardisez les identifiants fournisseurs, rejetez les dates invalides, rejoignez les fournisseurs et agrégez les dépenses mensuelles.
Outputs Qu’est-ce que la tâche doit créer ou mettre à jour ? Écrivez monthly_supplier_spend et sauvegardez le carnet de transformation.
Validation Comment un agent d’ingénierie des données peut-il prouver son succès ? Rapprochez les totaux des factures, vérifiez les clés en double et signalez les lignes rejetées.

Utilisez ce modèle :

<goal>. Read <sources>. Apply <transformations>.
Create or update <outputs>. Validate <success criteria>. Preserve
<important constraints>.

Fixer des limites explicites

Indiquez quelles sources l’agent d’ingénierie des données peut lire, quelles destinations il peut écrire, et quels artefacts existants il doit préserver. Identifiez toute contrainte de schéma, de rétention, de traitement régional ou de règle métier qui affecte la tâche.

Les autorisations Fabric et OneLake restent la limite d’autorisation. N'incluez pas d'identifiants, de jetons d'accès, d'en-têtes d'autorisation ou de données sensibles dans un résultat Project.

Rédigez un résultat spécifique du projet

Les exemples suivants de résultats Project combinent un objectif, des sources, des transformations, des résultats, des contraintes et des critères de validation.

Exploration des données

Profile the customer_events table without modifying it.
Summarize schema, row count, date range, null rates, duplicate event IDs,
category distributions, and outliers. Save the analysis in a notebook.

Importation de fichiers

Ingest JSON files from Files/device-events. Flatten the
event payload, standardize timestamps to UTC, quarantine malformed records,
write valid rows to device_events_bronze, and report processed, accepted,
and rejected counts.

Transformation des données

Join Orders, OrderLines, Customers, and Products. Create
a Delta table named sales_order_detail with calculated line revenue and margin.
Validate referential integrity, duplicate order-line keys, and source-to-output
revenue totals.

Correction de la qualité des données

Assess customer_master for missing identifiers, invalid
email addresses, duplicate customers, and inconsistent country codes. Propose
a safe remediation plan, apply the approved changes to a staged table, and
produce before-and-after quality metrics.

Modernisation des schémas

Migrate the legacy_sales table to a documented schema
with typed dates, decimal monetary values, and standardized region codes.
Preserve the source table, create a tested notebook, and reconcile record
counts and revenue totals.

Charge incrémentielle

Build an incremental load from Files/orders-daily into
the Orders Delta table. Deduplicate by order_id and modified_at, update changed
orders, preserve unchanged rows, save the notebook, and validate inserted,
updated, unchanged, and rejected counts.

Architecture en médaillon

Build bronze, silver, and gold layers for product,
inventory, and supplier files. Preserve raw inputs in bronze, standardize and
deduplicate entities in silver, create a gold inventory-risk table, save all
notebooks, and validate each layer.

Choisissez un modèle d’écriture sûr

Lorsque vous créez une tâche, sélectionnez un motif d’écriture qui correspond à l’impact et à la réversibilité de la tâche :

  • Clonage et promotion : Testez les modifications sur une copie avant de mettre en place le résultat validé.
  • Tableau de mise en scène : Rédigez les résultats séparément pour examen ou une étape de promotion contrôlée.
  • Itération sur place : Modifie directement la cible. À utiliser uniquement lorsque vous comprenez le plan de risque et de récupération.
  • Déduplication lors de la réexécution : Utilisez une clé métier stable pour éviter les doublons d’enregistrements.
  • Schéma verrouillé : Rejeter les changements inattendus du schéma.
  • Schéma d’élargissement de type : Permettre un élargissement compatible tout en empêchant des changements arbitraires.

Les permissions Fabric restent la limite stricte d’autorisation. Ne vous fiez pas uniquement au résultat du Project pour protéger les données critiques.

Rendez les rediffusions prévisibles

Expliquez à l’agent d’ingénierie des données comment gérer les données qu’il a traitées auparavant. Utilisez des clés métier stables et spécifiez si une reprise doit échouer, ajoutez de nouvelles données, dédupliquez les enregistrements, fusionnez les modifications ou remplacez la cible.

Pour les tâches incrémentales, demandez le nombre de dossiers insérés, mis à jour, non modifiés et rejetés. Préservez les données sources et les sorties vérifiées, sauf si le remplacement fait explicitement partie du résultat demandé.

Plan d’utilisation de la capacité partagée

Project Osmos utilise à la fois des jetons de modèles de langage et la capacité de calcul Spark pour implémenter et valider le résultat attendu. Avec la facturation Spark basée sur la capacité, ce travail partage les ressources avec d’autres charges de travail sur la capacité. Une forte utilisation peut affecter d’autres tâches non liées via la limitation de la capacité.

  1. Commencez par un résultat complet et borné sur des données représentatives. Mesurez à la fois la consommation du modèle de langage et de Spark avant d’augmenter le volume de données ou le nombre de tâches simultanées.
  2. Demandez à votre gestionnaire de capacité de vérifier l’utilisation et la limitation dans l’application Fabric Capacity Metrics. Utilisez la consommation de capacité de Project Osmos pour trouver les deux composantes d’utilisation.
  3. Échelonnez les soumissions de tâches pour éviter les périodes chargées, et limitez le nombre de tâches que vous lancez simultanément. Un espace de travail séparé sur la même capacité ne fournit pas d’isolation de calcul. Si vous avez besoin d’isolation de capacité, travaillez avec votre administrateur pour évaluer une capacité assignée séparément.
  4. Pour les charges de travail Spark intermittentes, demandez à votre responsable de capacité d’évaluer la facturation à la demande pour Spark. Lorsque cela est supporté et activé, Spark utilise un calcul serverless facturé séparément au lieu de la capacité Fabric partagée. L’administrateur configure une limite maximale de CU pour Spark.

La facturation à la demande modifie le modèle de facturation Spark, et non le modèle de facturation du modèle de langage. Sa limite maximale de CU n'est pas un budget total pour la tâche ni une limite sur la consommation de tokens Project Osmos. Examinez les exigences de configuration et les avertissements d’annulation de tâche avant de modifier le paramètre.

Pour plus d’informations sur le comportement de capacité partagée, voir limitation du débit dans Fabric.

Contenu connexe

  • Dernière mise à jour :