Dela via

Beslutsguide för Microsoft Fabric: kopieringsaktivitet, dataflöde eller Spark

  • Artikel

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.

Relaterat innehåll