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.
En enhetlig dataplattform är beroende av konsekventa standarder för inmatning, transformering och publicering så att ledare kan lita på data för analys och AI. Rekommendation: Upprätta organisationsomfattande standarder som styr vilka data som kommer in i OneLake, hur team förfinar dessa data och hur reglerade dataprodukter når konsumenter (se bild 1). Använd den här artikeln som en checklista för att tillämpa den här rekommendationen:
Bild 1. Tre steg för att ange driftstandarder för data.
1. Ange datainmatningsstandarder
OneLake fungerar som den centrala datasjön för analys och AI i Microsoft Fabric, så ledare måste kontrollera vad som kommer in. Rekommendation: Ange tydliga gränser så att team endast matar in data som stöder definierade affärsresultat. Använd följande checklista för att tillämpa den här rekommendationen.
Vilka data sammanfogar du? Dataenifiering i OneLake innebär att välja data som stöder en dataprodukt som är kopplad till ett mätbart affärsresultat. Metodtips: Ta endast data till OneLake om de stöder en dataprodukt och lägger till affärsvärde. Behandla datainmatning som ett produktbeslut i stället för en teknisk standard. Beslutsvägledning: Bestäm dig för att mata in data när de förklarar eller mäter en affärsprocess eller ett resultat som ledare spårar. Välj att lämna data i driftsystem eller avdelningslagring när det inte finns något aktivt användningsfall. Det här valet minskar kostnaderna för lagring och styrning.
Behåll samarbets- och kunskapsinnehåll i Microsoft 365. Microsoft 365-data stöder Microsoft 365 Copilot-agenter. Dessa agenter hämtar dokument, e-postmeddelanden och samarbetsartefakter samtidigt som de respekterar befintliga behörigheter. Se Microsoft 365 Copilot-arkitektur. Metodtips: Använd Microsoft 365 som arkivhandlingssystem för innehåll vars primära syfte är samarbete, referens eller kunskapshämtning. Använd Microsoft 365-implementeringsguiden för att förbereda dessa data.
Integrera driftdatabaser via mönster som stöds. Driftdatabaser tillhandahåller ofta analys- och AI-scenarier, men direkt åtkomst skapar risk och instabilitet. Metodtips: Använd mönster som stöds av Microsoft Fabric, till exempel genvägar för virtuell åtkomst och spegling för replikerad åtkomst. Azure-databaser kräver ofta spegling för tillförlitlig integrering. Beslutsvägledning: Välj genvägar när virtuell åtkomst uppfyller prestandabehoven. Välj spegling när analysprestanda, isolering eller nedströms återanvändning kräver en fysisk kopia i OneLake.
Integrera befintliga datasjöar. Många organisationer använder redan datasjöar, till exempel Azure Data Lake Storage (ADLS), Google Cloud Storage eller Amazon S3. Metodtips: Behandla befintliga sjöar som en del av den enhetliga dataegendomen i stället för att tvinga fram omedelbar migrering. Använd genvägar eller spegling. Beslutsvägledning: Bestäm baserat på beredskap och risk. Välj genvägar för att undvika duplicering. Välj spegling när konsekvens, prestanda eller efterlevnad uppväger dupliceringskostnaden.
Surface Azure Databricks-utdata i OneLake. Azure Databricks skapar ofta redan förädlad analysdata. Bästa praxis: Håll Databricks-pipelines på plats och presentera slutliga guldutdata i OneLake. Beslutsvägledning: Välj genvägar för att undvika replikering och när fjärråtkomst uppfyller behoven. Välj spegling när styrnings- eller förbrukningsmönster kräver lokala data.
Separera internt och externt dataintag. Interna analysdata och externa data kräver olika kontroller. Metodtips: Skapa separata arbetsytor eller sjöområden för externa dataprodukter. Lagra endast godkända externa datauppsättningar på dessa platser. Beslutsvägledning: Bestäm tidigt om data stöder interna beslut eller extern delning. Välj fysisk separation för att minska oavsiktlig exponering och förenkla tvingande av säkerhetsprinciper.
2. Ange standarder för datatransformering
Att hämta data till OneLake är bara det första steget. Det verkliga värdet kommer från att omvandla rådata till högkvalitativa, färdiga dataprodukter. Ledare utformar inte pipelines, men de definierar plattformar och arkitekturstandarder som förhindrar fragmentering. Rekommendation: Standardisera omvandlingsplattformar och framtvinga en konsekvent förfiningsarkitektur. Använd följande checklista för att tillämpa den här rekommendationen:
2.1. Använda rätt dataplattform
Ditt val av plattform ställer driftkrav för dina dataprodukter i Microsoft- och Azure-miljöer. Rekommendation: För varje dataprodukt balanserar du enkelhet och integrering med behovet av specialiserade tekniska funktioner. Använd följande checklista för att tillämpa den här rekommendationen:
Nätverksarkitektur (standard). Fabric tillhandahåller integrerade datateknik-, analys- och BI-motorer som fungerar direkt på OneLake, som fungerar som den enhetliga reglerade dataegendomen för organisationen. Best practice: Använd Fabric för standardanalys, rapportering och dataförberedelse. Föredra inbyggda Fabric-motorer såsom Dataflows Gen2, Spark och SQL för att förenkla åtkomstkontroll, spårbarhet och kostnadshantering. Använd OneLake som enda lagringslager. Beslutsvägledning: Välj Infrastruktur när kraven passar inbyggda funktioner och när ledarskap värdesätter enhetlig styrning och fakturering. Acceptera begränsad anpassning i utbyte mot lägre driftkostnader.
Azure Databricks. Många föredrar Azure Databricks. Den stöder storskalig bearbetning och avancerade maskininlärningsscenarier. Metodtips: Fortsätt att använda Databricks där expertis eller skalning redan finns. Kräv utdata för att landa i OneLake eller ansluta via OneLake-genvägar så att styrning, säkerhet och identifiering förblir centraliserade. Beslutsvägledning: Välj Databricks när Fabric inte uppfyller de aktuella kraven. Acceptera högre integrering och kompetensomkostnader som kompromiss.
Framtvinga gränser för plattformsägarskap. Rensa plattformsgränser förhindrar duplicerad kostnad och inkonsekvent logik mellan system. Metodtips: Tilldela ansvaret för varje arbetsbelastningsklass till en plattform. Kräv en arkitekturgranskning innan du godkänner plattformsoberoende bearbetning. Beslutsvägledning: Bestäm vilken plattform som äger inmatnings-, transformerings- och analysresultat. Förhindra duplicerade omvandlingar och överlappande pipelines som levererar samma affärsresultat.
2.2. Tillämpa medallion arkitektur
Medaljongarkitekturen etablerar förtroende, konsekvens och styrning för alla dataprodukter genom att definiera en tydlig utveckling från rådata till affärsklara utdata. Rekommendation: Kräv att alla dataprodukter i OneLake följer en brons-, silver- och guldstruktur och förbjuder genvägar som kringgår dessa lager. Använd följande checklista för att tillämpa den här rekommendationen:
Mandatera ett bronsskikt som referenssystem (rå inmatning): Bronsskiktet samlar in data precis som det anländer till OneLake och bevarar ursprunglig källautentitet. Metodtips: Lagra data som endast tillägg och oföränderliga. Förhindra korrigeringar eller berikning i det här skedet. Kräv att varje inkommande dataset hamnar först i brons. Beslutsvägledning: Bestäm att brons endast finns för att bevara sanningen från källsystem. Acceptera långsammare användbarhet i utbyte mot granskning och spårbarhet.
Etablera silverlagret som den pålitliga vyn. Silverlagret innehåller verifierade, standardiserade och rensade data som teamen förlitar sig på för konsekvent analys. Metodtips: Tillämpa datakvalitetsregler, formatjustering och grundläggande affärsverifiering. Dokumentera silverdatauppsättningar tydligt och hantera ändringar via styrningsprocesser. Beslutsvägledning: Välj silver som det auktoritativa rensade lagret. Förhindra team från att återupparbeta rådata på egen hand, vilket skapar motstridiga tolkningar.
Guld (affärskontext, dataprodukter): Certifiera gulddatauppsättningar som affärsdataprodukter. Guldlagret levererar reglerade dataprodukter som ledare använder för beslut, prestandaspårning och rapportering. Metodtips: Justera gulddata efter godkända affärsdefinitioner och mått. Optimera strukturer för förbrukning. Registrera varje gulddatauppsättning som en dataprodukt i Microsoft Purview med ägarskap, syfte och uppdateringsinformation. Beslutsvägledning: Bestäm att alla datauppsättningar som används mellan team eller för beslut måste finnas i guld. Avvisa ohanterade eller ocertifierade datauppsättningar som kringgår styrning.
Skapa sanerade produkter för extern användning. Extern delning kräver avsiktlig separation från interna driftdata. Metodtips: Skapa kurerade datauppsättningar som tar bort eller maskerar känsliga fält och minskar detaljinformationen där det behövs. Tilldela ägarskap och använd tydliga etiketter, till exempel offentlig eller extern användning. Lagra dessa datauppsättningar på godkända platser. Beslutsvägledning: Välj att behandla externa datauppsättningar som oberoende produkter. Acceptera ytterligare styrningssteg för att minska juridiska och säkerhetsrisker.
Fabric stöder den här modellen via materialiserade sjövyer som automatiskt kan hantera omvandlingarna. Se Medallion Lakehouse Architecture in Fabric. En analysarkitektur finns i Analys från slutpunkt till slutpunkt med Microsoft Fabric.
Tabell. Exempel på medaljongarkitektur. Guldskiktet kombinerar data från två datauppsättningar.
| Dataset | Skikt | Exempel på data | Vad hände |
|---|---|---|---|
| Försäljningstransaktioner | Brons | OrderID=984321 · StoreID=17 · Belopp="1.200" · TxnDate="2026-01-05T14:32:09Z" | Den här posten kom från säljsystemet exakt som den skickades. Belopp är text. Tidsstämpeln följer systemformatet. Ingen betydelse har tillämpats. |
| Silver | OrderID=984321 · StoreID=17 · Amount=1200.00 · TxnDate=2026-01-05 | Transaktionen är standardiserad och validerad. Mängden är numerisk. Datum följer företagets regler. Data är nu tillförlitliga. | |
| Arkivreferens | Brons | StoreID="17" · RegionName="EAST" | Den här posten kom från ett lokaliseringssystem. Formateringen återspeglar källan. |
| Silver | StoreID=17 · Region=Öst | Butiksidentifierare överensstämmer med försäljningsdata. Regionvärdena är rensade och konsekventa. | |
| Dagliga intäkter per region | Guld | Region=Öst · Date=2026-01-05 · TotalRevenue=425000 | Det här värdet kombinerar silverförsäljningstransaktioner med silverlagringsreferensdata. Enskilda poster sammanfattas för att besvara en affärsfråga. |
2.3. Överväg ett anpassningsbart guldskikt
Adaptivt guld ingår här som ett framåtblickande övervägande. Tanken är att du använder AI-agenter för att skapa guldskikt. Agenter kan observera mönster som du kanske inte kan. Om användarna ofta ber om "främsta kundproblem per region per månad" kan AI-agenter materialisera datamängden. Den här funktionen tillhandahålls inte direkt i Microsoft Fabric i dag. Det skulle kräva att du skapar en anpassad AI-agent som fungerar på Fabric- och Power BI-telemetri.
3. Ange standarder för publicering av dataprodukter
Publiceringsstandarder definierar hur din organisation exponerar betrodda dataprodukter via Microsoft Fabric OneLake och Microsoft Purview. Målet är att skala återanvändning, framtvinga styrning och minska risken för analys- och AI-arbetsbelastningar. Rekommendation: Upprätta en enda publiceringsstandard som gör varje godkänd dataprodukt identifierbar, styrd och tydligt avsedd för en definierad målgrupp före bred användning. Använd följande checklista för att tillämpa den här rekommendationen:
Standardisera publikationen via OneLake Catalog. OneLake Catalog ger en enhetlig åtkomstyta för dataprodukter över Fabric och externa bearbetningsplattformar, till exempel Databricks. Bästa praxis: Använd OneLake som standardkörnings- och förbrukningsskikt för alla godkända dataprodukter. Behandla Microsoft Purview som arkivhandlingssystem för styrnings- och affärsdefinitioner. Med den här justeringen kan Power BI, Fabric-dataagenter och Azure AI Search använda data konsekvent samtidigt som centraliserad styrningssynlighet aktiveras.
Se till att det går att identifiera. Upptäcktsbarhet säkerställer att beslutsfattare och konsumenter kan hitta betrodda dataprodukter utan att förlita sig på informell kunskap. Bästa praxis: Konfigurera synligheten för Fabric-arbetsytan så att relevanta målgrupper kan upptäcka objekt. De behöver inte åtkomst, bara möjligheten att begära åtkomst. Aktivera arbetsflöden för Purview-åtkomstbegäran så att användarna kan begära behörighet direkt från katalogen. Beslutsvägledning: Välj bred upptäckbarhet när målet är återanvändning mellan domäner. Välj begränsad identifiering när regel- eller konfidentialitetsbegränsningar gäller. Balansera synligheten med åtkomstkontroller i stället för att dölja tillgångar.
Förbjud berikning av metadata vid publicering. Metadata ger kontext som gör det möjligt för ledare att utvärdera lämplighet, förtroende och återanvändning av en dataprodukt. Metodtips: Kräv beskrivande metadata vid publicering. Använd taggar i Fabric för att klassificera produkter efter företagsdomän eller initiativ. Se till att beskrivningar förklarar syftet och dataomfånget. Den här metoden stöder katalogsökning och förbättrar förtroendet för återanvändning. Beslutsvägledning: Bestäm om metadatakraven förblir minimala eller framtvingar ett standardschema. Välj ett standardschema när organisationen kör flera domäner och behöver konsekvens. Välj en lättare metod för tidiga mognadssteg.
Godkänna och certifiera när det är lämpligt. Definiera kriterier för godkännande och certifiering. Bekräftelse signalerar förtroendenivån och styrningsmognaden till organisationen. Bästa praxis: Använd Rekommenderad för att ange rekommenderade produkter inom domänen. Använd Certifierad för att ange produkter som har godkänts i en formell styrningsgranskning. Tillämpa certifiering på Gold-datauppsättningar som stöder rapportering av chefer eller kritisk analys. Referens vägledning för fabric-godkännande vid godkännande. Beslutsvägledning: Bestäm vilka produkter som måste certifieras. Välj obligatorisk certifiering för verkställande eller regelmässiga arbetsbelastningar. Välj valfri certifiering när hastighet och experimentering prioriteras. Acceptera långsammare registrering som kompromiss för högre förtroende.
Publicera som en dataprodukt i Purview. Purview-dataprodukter ger en vy på högre nivå som grupperar tillgångar i en hanterad produktlivscykel. Metodtips: Skapa en Purview-dataproduktpost för varje publicerad dataprodukt. Inkludera produktnamn, beskrivning, ägare, kvalitetsstatus och relaterade tillgångar, till exempel tabeller, modeller och rapporter. Referensdataprodukter i enhetlig katalog. Beslutsvägledning: Bestäm om Purview-dataprodukter krävs för alla publicerade tillgångar eller endast för strategiska produkter. Välj fullständig täckning när portföljens synlighet är viktig. Välj selektiv täckning när styrningskapaciteten är begränsad.
Deklarera avsedd målgrupp och användning. Tydlig avsikt förhindrar missbruk och stöder efterlevnad i analys- och AI-scenarier. Metodtips: Kräv att varje dataprodukt anger sin avsedda målgrupp och arbetsbelastningstyp som stöds. Ange intern användning, partner eller offentlig användning. Identifiera AI-, analys-, BI- eller offentliga webbscenarier. Använd Purview-metadata, ordlistetermer och känslighetsetiketter tillsammans för att uttrycka den här avsikten konsekvent. Beslutsvägledning: Bestäm om extern användning eller agentanvändning kräver extra godkännande. Välj striktare godkännande när data lämnar organisationens gränser. Acceptera långsammare publicering som kompromiss för minskad risk.