Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Bruk disse beste praksisene til å definere komplette resultater, beskytte lakehouse-data, gjøre repriser forutsigbare, og kreve målbar bevis på suksess fra Fabric data engineering-agentens (Project Osmos)-oppgaver.
Important
Data engineering-agenten (Project Osmos) er i forhåndsvisning. Forhåndsvisningsfunksjoner slippes med begrensede muligheter og er underlagt separate tilleggsforhåndsvisningsvilkår. De er ikke ment for produksjonsbruk, er ikke underlagt serviceavtaler, og kan være tilgjengelige kun i utvalgte regioner. For mer informasjon, se Microsoft Fabric forhåndsvisningsinformasjon.
Definer et komplett Project-resultat
Ferdigheten definerer Project-resultat som følger:
Beskriv den komplette ende-til-ende dataingeniøroppgaven. Dataingeniøragenten mottar det som ett prosjekt.
Definer det komplette resultatet, ikke bare det første implementeringssteget. Inkluder disse fem elementene:
| Element | Spørsmål å svare på | Eksempel |
|---|---|---|
| Mål | Hvilket utfall bør eksistere når oppgaven er fullført? | Lag en månedlig tabell for leverandørutgifter. |
| Kilder | Hvilke data bør oppgaven bruke? | Les faktura-CSV-filer og tabellen Suppliers Delta. |
| Transformasjoner | Hvilke regler bør oppgaven følge? | Standardiser leverandør-ID-er, avvis ugyldige datoer, bli med leverandører, og aggreger månedlige utgifter. |
| Utdata | Hva bør oppgaven opprette eller oppdatere? | Skriv monthly_supplier_spend og lagre transformasjonsnotatboken. |
| Validering | Hvordan bør en dataingeniøragent bevise suksess? | Avstemme fakturatotaler, sjekk duplikatnøkler, og rapporter avviste rader. |
Bruk denne malen:
<goal>. Read <sources>. Apply <transformations>.
Create or update <outputs>. Validate <success criteria>. Preserve
<important constraints>.
Sett eksplisitte grenser
Angi hvilke kilder dataingeniøragenten kan lese, hvilke destinasjoner den kan skrive til, og hvilke eksisterende artefakter den må bevare. Identifiser eventuelle skjema-, retention-, regionalprosesserings- eller forretningsregelbegrensninger som påvirker oppgaven.
Fabric- og OneLake-tillatelser forblir autorisasjonsgrensen. Ikke inkluder legitimasjon, tilgangstokens, autorisasjonsheaders eller sensitive data i et Project-resultat.
Skriv et spesifikt Project-resultat
Følgende eksempler på Project-resultater kombinerer et mål, kilder, transformasjoner, utdata, begrensninger og valideringskriterier.
Datautforskning
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.
Filinntak
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.
Datakvalitetsutbedring
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.
Skjema-modernisering
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.
Trinnvis innlasting
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.
Medaljongarkitektur
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.
Velg et trygt skrivemønster
Når du oppretter en oppgave, velg et skrivemønster som matcher effekten og reversibiliteten til oppgaven:
- Kloning og promotering: Test endringer mot en kopi før du flytter verifisert output på plass.
- Staging-tabell: Skriv resultatene separat for gjennomgang eller et kontrollert opprykkssteg.
- Iterer på stedet: Modifiser målet direkte. Bruk kun når du forstår risiko- og gjenopprettingsplanen.
- Dedupliserer rerun: Bruk en stabil forretningsnøkkel for å forhindre dupliserte poster.
- Låst skjema: Avvis uventede skjemaendringer.
- Typeutvidelsesskjema: Tillat kompatibel utvidelse samtidig som vilkårlige endringer forhindres.
Fabric-tillatelser forblir den harde autorisasjonsgrensen. Ikke stol kun på Project-resultatet for å beskytte kritiske data.
Gjør repriser forutsigbare
Fortell dataingeniøragenten hvordan den skal håndtere data den tidligere har behandlet. Bruk stabile forretningsnøkler og spesifiser om en ny kjøring skal feile, legge til nye data, deduplisere poster, slå sammen endringer eller erstatte målet.
For inkrementelle oppgaver, be om antall innsatte, oppdaterte, uendrede og avviste poster. Bevar kildedata og verifiserte utdata med mindre erstatning er en eksplisitt del av det forespurte resultatet.
Plan for bruk av delt kapasitet
Project Osmos bruker både språkmodelltokens og Spark compute for å implementere og validere et resultat. Med kapasitetsbasert Spark-fakturering deler dette arbeidet ressurser med andre arbeidsbelastninger på kapasiteten. Høy utnyttelse kan påvirke ikke-relatert arbeid gjennom kapasitetsbegrensning.
- Start med et komplett, avgrenset resultat på representative data. Mål både språkmodell- og Spark-forbruket før du øker datavolumet eller antall samtidige oppgaver.
- Be kapasitetsadministratoren din om å gjennomgå utnyttelse og throttling i Fabric Capacity Metrics-appen. Bruk Project Osmos kapasitetsforbruk for å finne begge forbrukskomponentene.
- Forskyv oppgaveinnleveringer for å unngå travle perioder, og begrens hvor mange oppgaver du starter samtidig. Et separat arbeidsområde på samme kapasitet gir ikke beregningsisolasjon. Hvis du trenger kapasitetsisolering, samarbeid med administratoren din for å evaluere en separat tildelt kapasitet.
- For bursty Spark-arbeid, be kapasitetsadministratoren din vurdere fakturering på forespørsel for Spark. Der det støttes og er aktivert, bruker Spark separat fakturert serverløs beregning i stedet for delt Fabric-kapasitet. Administratoren konfigurerer en maksimal CU-grense for Spark.
On-demand-fakturering endrer Spark-faktureringsmodellen, ikke språkmodellen. Dens maksimale CU-grense er ikke et totalt oppgavebudsjett eller en grense for Project Osmos-tokenforbruk. Gjennomgå konfigurasjonskrav og avbestillingsvarsler før du endrer innstillingen.
For mer informasjon om delt kapasitetsatferd, se Fabric throttling.