Beslutsguide för Microsoft Fabric: kopieringsaktivitet, dataflöde eller Spark
Använd den här referensguiden och exempelscenarier som hjälper dig att avgöra om du behöver en kopieringsaktivitet, ett dataflöde eller Spark för dina Microsoft Fabric-arbetsbelastningar.
Egenskaper för kopieringsaktivitet, dataflöde och Spark
| Pipeline kopieringsaktivitet | Dataflöde Gen 2 | Spark | |
|---|---|---|---|
| Användningsfall | Migrering av datasjöar och informationslager, datainmatning lätt omvandling |
Datainmatning, datatransformering, databerarbetning dataprofilering |
Dataintag datatransformering, databehandling dataprofilering |
| Primär utvecklarpersona | Datatekniker, dataintegrerare |
Datatekniker, dataintegrerare, affärsanalytiker |
Datatekniker, data scientist datautvecklare |
| Primär utvecklarfärdighet | ETL, SQL JSON |
ETL, M, SQL |
Spark (Scala, Python, Spark SQL, R) |
| Skriven kod | Ingen kod, låg kod |
Ingen kod, låg kod |
Kod |
| Datavolym | Låg till hög | Låg till hög | Låg till hög |
| Utvecklingsgränssnittet | Trollkarl kanvas |
Power Query | Anteckningsbok Definition av Spark-jobb |
| källor | Över 30 kontakter | Över 150 anslutningar | Hundratals Spark-bibliotek |
| destinationer | 18+ kontakter | Lakehouse, Azure SQL-databas, Azure Data Explorer, Azure Synapse Analytics |
Hundratals Spark-bibliotek |
| Omvandlingskomplexitet | Låg: lightweight – typkonvertering, kolumnmappning, sammanfoga/dela filer, platta ut hierarki |
Låg till hög: Över 300 transformeringsfunktioner |
Låg till hög: stöd för interna Spark- och bibliotek med öppen källkod |
Läs följande tre scenarier för 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
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 skapa och underhålla de datapipelines som extraherar, transformerar och laddar in data i lagringssystemet lakehouse. 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.