Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Använd dessa bästa praxis för att definiera kompletta resultat, skydda lakehouse-data, göra repriser förutsägbara och kräva mätbara bevis på framgång från Fabric data engineering-agentens (Project Osmos) uppgifter.
Important
Data engineering-agenten (Project Osmos) är i förhandsvisning. Förhandsvisningsfunktioner släpps med begränsade möjligheter och omfattas av separata kompletterande förhandsvisningsvillkor. De är inte avsedda för produktionsbruk, omfattas inte av serviceavtal och kan vara tillgängliga endast i utvalda regioner. Mer information finns i Förhandsversionsinformation för Microsoft Fabric.
Definiera ett komplett Project-resultat
Färdigheten definierar Projektresultat på följande sätt:
Beskriv den kompletta end-to-end-dataingenjörsuppgiften. Data engineering-agenten tar emot det som ett projekt.
Definiera det fullständiga resultatet istället för bara det första implementeringssteget. Inkludera dessa fem element:
| Element | Fråga att besvara | Example |
|---|---|---|
| Mål | Vilket resultat bör finnas när uppgiften slutförs? | Skapa en månatlig tabell för leverantörsutgifter. |
| Sources | Vilken data bör uppgiften använda? | Läs fakturans CSV-filer och tabellen Suppliers Delta. |
| Transformations | Vilka regler bör uppgiften följa? | Standardisera leverantörs-ID, avvisa ogiltiga datum, gå med i leverantörer och aggregera månatliga utgifter. |
| Outputs | Vad ska uppgiften skapa eller uppdatera? | Skriv monthly_supplier_spend och spara transformationsanteckningsboken. |
| Validation | Hur ska en dataingenjörsagent bevisa framgång? | Stämm av fakturasummor, kontrollera dubblettnycklar och rapportera avvisade rader. |
Använd den här mallen:
<goal>. Read <sources>. Apply <transformations>.
Create or update <outputs>. Validate <success criteria>. Preserve
<important constraints>.
Sätt tydliga gränser
Ange vilka källor dataingenjöragenten kan läsa, vilka destinationer den kan skriva till och vilka befintliga artefakter den måste bevara. Identifiera eventuella schema-, retention-, regional-processing- eller affärsregelbegränsningar som påverkar uppgiften.
Fabric- och OneLake-tillstånd förblir auktorisationsgränsen. Inkludera inte inloggningsuppgifter, åtkomsttokens, auktorisationshuvuden eller känslig data i ett Project-resultat.
Skriv ett specifikt Project-resultat
Följande exempel på Project-resultat kombinerar ett mål, källor, transformationer, utdata, begränsningar och 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.
Filinmatning
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.
Dataomvandling
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.
Datakvalitetsåterställning
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.
Modernisering av scheman
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.
Stegvis inlä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.
Medallionarkitektur
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älj ett säkert skrivmönster
När du skapar en uppgift, välj ett skrivmönster som matchar uppgiftens påverkan och reversibilitet:
- Klona och promota: Testa ändringar mot en kopia innan verifierad utdata flyttas på plats.
- Uppställningstabell: Skriv resultaten separat för granskning eller ett kontrollerat befordringssteg.
- Iterera på plats: Ändra målobjektet direkt. Använd endast när du förstår risk- och återhämtningsplanen.
- Deduplikering vid omkörning: Använd en stabil affärsnyckel för att förhindra duplicerade poster.
- Låst schema: Avvisa oväntade schemaändringar.
- Typbreddningsschema: Tillåt kompatibel breddning samtidigt som godtyckliga ändringar förhindras.
Fabric-behörigheter förblir den hårda auktorisationsgränsen. Lita inte bara på Project-resultatet för att skydda kritisk data.
Gör repriser förutsägbara
Berätta för data engineering-agenten hur den ska hantera data som den tidigare behandlat. Använd stabila affärsnycklar och ange om en omkörning ska misslyckas, lägga till ny data, deduplicera poster, slå ihop ändringar eller ersätta målet.
För inkrementella uppgifter, be om antal insatta, uppdaterade, oförändrade och avvisade poster. Bevara källdata och verifierade utdata om inte ersättning är en explicit del av det begärda resultatet.
Plan för användning av delad kapacitet
Project Osmos använder både språkmodelltokens och Spark-beräkning för att implementera och validera ett resultat. Med kapacitetsbaserad Spark-fakturering delar detta arbete resurser med andra arbetsbelastningar på kapaciteten. Hög användning kan påverka orelaterat arbete genom kapacitetsbegränsning.
- Börja med ett komplett, avgränsat resultat på representativ data. Mät både språkmodell- och Spark-förbrukning innan du ökar datavolymen eller antalet samtidiga uppgifter.
- Be din kapacitetsadministratör att granska utnyttjande och strypning i appen Fabric Capacity Metrics. Använd Project Osmos capacity consumption för att hitta båda användningskomponenterna.
- Sprid ut inskick av uppgifter för att undvika hektiska perioder och begränsa hur många uppgifter du kör samtidigt. Ett separat arbetsområde på samma kapacitet ger inte beräkningsisolering. Om du behöver kapacitetsisolering, samarbeta med din administratör för att utvärdera en separat tilldelad kapacitet.
- För bursty Spark-arbete, be din kapacitetsadministratör utvärdera on-demand-fakturering för Spark. Där det stöds och är aktiverat använder Spark separat fakturerad serverless beräkning istället för den delade Fabric-kapaciteten. Administratören konfigurerar en maximal CU-gräns för Spark.
On-demand-fakturering ändrar Sparks faktureringsmodell, inte språkmodellens faktureringsmodell. Dess maximala CU-gräns är inte en total uppgiftsbudget eller en gräns för Project Osmos-tokenförbrukning. Gå igenom konfigurationskrav och varningar om jobbavbokning innan du ändrar inställningen.
För mer information om beteendet vid delad kapacitet, se Fabric throttling.