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 aktiviteten Kopiera, dataflöde och Spark
| Pipelinekopieringsaktivitet | Dataflöde gen 2 | Spark | |
|---|---|---|---|
| Användningsfall | Migrering av datasjöar och informationslager, datainmatning, lättviktig transformering |
Datainmatning, datatransformering, dataomvandling, dataprofilering |
Datainmatning, datatransformering, databehandling, dataprofilering |
| Primär utvecklarpersona | Datatekniker, dataintegrerare |
Datatekniker, dataintegrerare, affärsanalytiker |
Datatekniker, dataexpert, datautvecklare |
| Primär kompetensuppsättning för utvecklare | ETL SQL JSON |
ETL M SQL |
Spark (Scala, Python, Spark SQL, R) |
| Kod skriven | 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änssnitt | Guiden Duk |
Power Query | Anteckningsboken Definition av Spark-jobb |
| Källor | Över 30 anslutningsappar | Över 150 anslutningsappar | Hundratals Spark-bibliotek |
| Destinationer | Över 18 anslutningsappar | Lakehouse, Azure SQL-databas, Azure Data Explorer, Azure Synapse-analys |
Hundratals Spark-bibliotek |
| Transformeringskomplexitet | 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 Infrastrukturresurser.
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 anslutningsapp eller dataflytt. 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 sjöhus, så att alla data från olika LOB-, 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 gulddata till ett informationslager utan kod om behovet uppstår och pipelines ger datainmatning i hög skala som kan flytta petabyteskalningsdata. aktiviteten Kopiera är det bästa valet med låg kod och ingen kod för att flytta petabyte med data till lakehouses och lager från sorter av källor, antingen ad hoc eller via ett schema.
Scenario 2
Mary är datatekniker med djup kunskap om de olika analysrapporteringskraven för LOB. Ett uppströmsteam har implementerat en lösning för att migrera flera LOB:s historiska och inkrementella data till ett gemensamt sjöhus. 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 läser in data i 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 lakehouse. Data är sedan redo att användas för nedströmsanalys.