Best practices for Fabric data engineering-agenten (Project Osmos) - forhåndsvisning

Brug disse bedste praksisser til at definere komplette resultater, beskytte lakehouse-data, gøre genudsendelser forudsigelige og kræve målbar dokumentation for succes fra Fabric data engineering-agentens (Project Osmos) opgaver.

Vigtig

Data engineering-agenten (Project Osmos) er i preview. Forhåndsvisningsfunktioner udgives med begrænsede muligheder og er underlagt separate supplerende forhåndsvisningsvilkår. De er ikke beregnet til produktionsbrug, er ikke underlagt service-level agreements og kan kun være tilgængelige i udvalgte regioner. For mere information, se Microsoft Fabric forhåndsvisningsinformation.

Definér et komplet Project-resultat

Færdigheden definerer Project-resultatet som følger:

Beskriv den komplette end-to-end data engineering-opgave. Data engineering-agenten modtager det som ét projekt.

Definér det komplette resultat frem for kun det første implementeringstrin. Inkluder disse fem elementer:

Element Spørgsmål, der skal besvares Eksempel
Mål Hvilket resultat bør der opstå, når opgaven er fuldført? Lav en tabel over leverandørudgifter.
Kilder Hvilke data bør opgaven bruge? Læs faktura-CSV-filer og tabellen Suppliers Delta.
Transformationer Hvilke regler bør opgaven følge? Standardiser leverandør-ID'er, afvis ugyldige datoer, tilslut leverandører og aggreger månedlige udgifter.
Output Hvad skal opgaven oprette eller opdatere? Skriv monthly_supplier_spend og gem transformationsnotesbogen.
Validering Hvordan skal data engineering-agenten bevise succes? Afstem fakturasummer, tjek dubletter nøgler og rapporter afviste rækker.

Brug denne skabelon:

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

Sæt eksplicitte grænser

Angiv hvilke kilder dataingeniøragenten kan læse, hvilke destinationer den kan skrive til, og hvilke eksisterende artefakter den skal bevare. Identificer eventuelle skema-, retention-, regional-processing- eller forretningsregelbegrænsninger, der påvirker opgaven.

Fabric- og OneLake-tilladelser forbliver autorisationsgrænsen. Inkluder ikke legitimationsoplysninger, adgangstoks, autorisationsheaders eller følsomme data i et Project-resultat.

Skriv et specifikt Project-resultat

Følgende eksempler på Project-resultater kombinerer et mål, kilder, transformationer, output, begrænsninger og valideringskriterier.

Udforskning af data

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.

Filindlæsning

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.

Datatransformering

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.

Datakvalitetsafhjælpning

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.

Skemamodernisering

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.

Trinvis indlæsning

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.

Medaljonarkitektur

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.

Vælg et sikkert skrivemønster

Når du opretter en opgave, vælg et skrivemønster, der matcher opgavens effekt og reversibilitet:

  • Klon og promover: Test ændringer mod en kopi, før verificeret output flyttes på plads.
  • Iscenesættelsestabel: Skriv resultaterne separat til gennemgang eller et kontrolleret forfremmelsestrin.
  • Iterer på stedet: Modificerer målet direkte. Brug kun, når du forstår risikoen og genopretningsplanen.
  • Deduplikering af genkørsel: Brug en stabil forretningsnøgle for at forhindre duplikerede poster.
  • Låst skema: Afvis uventede skemaændringer.
  • Typeudvidelsesskema: Tillad kompatibel udvidelse, mens vilkårlige ændringer forhindres.

Fabric-tilladelser forbliver den hårde autorisationsgrænse. Stol ikke kun på Project-resultatet for at beskytte kritiske data.

Gør genudsendelser forudsigelige

Fortæl data engineering-agenten, hvordan den skal håndtere data, som den tidligere har behandlet. Brug stabile forretningsnøgler og specificér, om en genkørsel skal fejle, tilføje nye data, deduplikere poster, merge ændringer eller erstatte målet.

For inkrementelle opgaver, bed om antal indsatte, opdaterede, uændrede og afviste poster. Bevar kildedata og verificerede output, medmindre udskiftning er en eksplicit del af det ønskede resultat.

Plan for brug af delt kapacitet

Project Osmos bruger både sprogmodeltokens og Spark-beregning til at implementere og validere et resultat. Med kapacitetsbaseret Spark-fakturering deler dette arbejde ressourcer med andre arbejdsbelastninger på kapaciteten. Høj udnyttelse kan påvirke ikke-relateret arbejde gennem kapacitetsbegrænsning.

  1. Start med et komplett, afgrænset resultat på repræsentative data. Mål både sprogmodel- og Spark-forbrug, før du øger datamængden eller antallet af samtidige opgaver.
  2. Bed din kapacitetsadministrator om at gennemgå udnyttelse og throttling i Fabric Capacity Metrics-appen. Brug Project Osmos kapacitetsforbrug til at finde begge forbrugskomponenter.
  3. Forskyd opgaveafleveringer for at undgå travle perioder, og begræns hvor mange opgaver du starter på én gang. Et separat arbejdsområde på samme kapacitet giver ikke beregningsisolering. Hvis du har brug for kapacitetsisolering, skal du samarbejde med din administrator om at vurdere en separat tildelt kapacitet.
  4. For ustabilt Spark-arbejde, bed din kapacitetsadministrator om at evaluere on-demand-fakturering for Spark. Hvor det understøttes og aktiveres, bruger Spark separat faktureret serverløs compute i stedet for den delte Fabric-kapacitet. Administratoren konfigurerer en maksimal CU-grænse for Spark.

On-demand fakturering ændrer Spark-faktureringsmodellen, ikke sprogmodellen. Dens maksimale CU-grænse er ikke et samlet opgavebudget eller en grænse for Project Osmos-tokenforbrug. Gennemgå konfigurationskrav og jobaflysningsadvarsler , før indstillingen ændres.

For mere information om adfærd ved delt kapacitet, se Fabric throttling.

Relateret indhold

  • Sidst opdateret den