Beslutsguide för Microsoft Fabric: kopieringsaktivitet, kopieringsjobb, dataflöde, Händelseström eller Spark

Använd den här referensguiden och exempelscenarier som hjälper dig att avgöra om du behöver en kopieringsaktivitet, ett kopieringsjobb, ett dataflöde, en Händelseström eller Spark för dina Microsoft Fabric-arbetsbelastningar.

Kopiera aktivitet, Kopiera jobb, dataflöde, Eventstream och Spark-egenskaper

Scenarier

Läs följande scenarier för att få hjälp med att välja hur du ska arbeta med dina data i Fabric.

Scenario 1:

Leo, en datatekniker, behöver mata in en stor mängd data från externa system, både lokalt och i molnet. Dessa externa system omfattar databaser, filsystem och API:er. Leo vill inte skriva och underhålla kod för varje anslutning eller dataflyttningsoperation. Han vill följa medaljonglagrets bästa praxis, med brons, silver och guld. Leo har ingen erfarenhet av Spark, så han föredrar dra och släpp användargränssnittet så mycket som möjligt, med minimal kodning. Och han vill också bearbeta data enligt ett schema.

Det första steget är att hämta rådata till bronsskiktets lakehouse från Azure-dataresurser och olika källor från tredje part (t.ex. Snowflake Web, REST, AWS S3, GCS osv.). Han vill ha ett konsoliderat lakehouse, så att alla data från olika LOB- (linjefunktioner), lokala och molnkällor finns på en enda plats. Leo granskar alternativen och väljer pipelinekopieringsaktivitet som lämpligt val för sin råa binära kopia. Det här mönstret gäller både historisk och inkrementell datauppdatering. Med kopieringsaktivitet kan Leo läsa in Gold-data till ett datavaruhus utan att skriva kod om behovet uppstår. Pipelines ger datainmatning i hög skala som kan flytta data av petabyte-skala. Kopieringsaktivitet är det bästa valet med lågt kodbehov och inget kodbehov för att flytta petabyte av data till lakehouses och datamagasin från olika typer av källor, antingen ad hoc eller via en tidsplan.

Scenario 2

Mary är datatekniker med djup kunskap om de olika analysrapporteringskraven för LOB. Ett team högre upp i kedjan har framgångsrikt implementerat en lösning för att migrera flera LOB:ers historiska och inkrementella data till en gemensam dataplattform. Mary har fått i uppgift att rensa data, tillämpa affärslogik och läsa in dem i flera mål (till exempel Azure SQL DB, ADX och ett lakehouse) som förberedelse för sina respektive rapporteringsteam.

Mary är en erfaren Power Query-användare och datavolymen ligger i det låga till medelhöga intervallet för att uppnå önskad prestanda. Dataflöden tillhandahåller gränssnitt utan kod eller låg kod för att mata in data från hundratals datakällor. Med dataflöden kan du transformera data med över 300 alternativ för datatransformering och skriva resultatet till flera mål med ett lättanvänt användargränssnitt med hög visuell användning. Mary granskar alternativen och bestämmer sig för att det är meningsfullt att använda Dataflow Gen 2 som sitt föredragna transformeringsalternativ.

Scenario 3

Prashant, en dataintegrerare med djup expertis inom affärsprocesser och system. Ett överordnat team har exponerat händelsedata från affärsprogram som meddelanden som kan användas via underordnade system. Prashant har tilldelats att integrera händelsedata från affärsprogram i Microsoft Fabric för beslutsstöd i realtid.

Med tanke på den medelhöga till höga datavolymen och organisationens önskemål om lösningar utan kod söker Prashant ett sätt att sömlöst vidarebefordra händelser när de inträffar utan att hantera extraheringsscheman. För att uppfylla detta behov väljer han Eventstreams i Microsoft Fabric. Eventstreams i Real-Time Intelligence-upplevelsen möjliggör datainmatning, transformering och routning i realtid till olika mål – allt utan att skriva någon kod.

Scenario 4

Adam är datatekniker och arbetar för ett stort detaljhandelsföretag som använder ett lakehouse för att lagra och analysera sina kunddata. Som en del av sitt jobb ansvarar Adam för att bygga och underhålla de pipelines som extraherar, transformerar och läser in data i sjöhuset. Ett av företagets affärskrav är att utföra kundgranskningsanalyser för att få insikter om sina kunders upplevelser och förbättra sina tjänster.

Adam bestämmer sig för att det bästa alternativet är att använda Spark för att skapa extrakt- och transformeringslogik. Spark tillhandahåller en distribuerad databehandlingsplattform som kan bearbeta stora mängder data parallellt. Han skriver ett Spark-program med Python eller Scala, som läser strukturerade, halvstrukturerade och ostrukturerade data från OneLake för kundgranskningar och feedback. Programmet rensar, transformerar och skriver data till Delta-tabeller i lakehouset. Data är sedan redo att användas för nedströmsanalys.

Scenario 5

Rajesh, en datatekniker, har till uppgift att mata in inkrementella data från en lokal SQL Server till en Azure SQL Database. Rajeshs lokala SQL Server-instans har redan Change Data Capture (CDC) aktiverat på nyckeltabeller.

Rajesh letar efter en enkel guidedriven lösning med låg kod som gör att han kan:

• Välj flera inbyggda CDC-aktiverade källtabeller
• Initiera en inledande fullständig laddning
• Växla automatiskt till inkrementella datainläsningar baserat på CDC
• Schemalägga datauppdateringar för återkommande uppdateringar

Han vill undvika att skriva anpassad kod eller hantera komplexa orkestreringar. Helst vill han ha en "5x5 guide" där han kan utföra installationen med bara några klick.

Rajesh väljer funktionen Kopiera jobb i Microsoft Fabric. Med stöd för lokal gateway ansluter han säkert till sin SQL Server, väljer önskade tabeller och konfigurerar flödet för att landa i azure SQL-måldatabasen.

Kopieringsjobbet ger en upplevelse med låg friktion och skalbar dataflytt som uppfyller Rajeshs krav utan att behöva underhålla komplexa pipelines.

Relaterat innehåll

• Så här kopierar du data med kopieringsaktivitet
• Snabbstart: Skapa ditt första dataflöde för att hämta och transformera data
• Så här skapar du en Apache Spark-jobbdefinition i Fabric
• Så här skapar du en Eventstream i Infrastrukturresurser