Microsoft Fabric-beslutningsvejledning: kopiér aktivitet, dataflow eller Spark
Brug denne referencevejledning og eksempelscenarierne til at hjælpe dig med at beslutte, om du har brug for en kopiaktivitet, et dataflow eller Spark til dine Microsoft Fabric-arbejdsbelastninger.
Kopiér egenskaber for aktivitet, dataflow og Spark
| Pipelinekopiaktivitet | Dataflow gen 2 | Gnist | |
|---|---|---|---|
| Use case | Data lake- og data warehouse-migrering, dataindtagelse, letvægtstransformation |
Dataindtagelse, datatransformation, data wrangling, dataprofilering |
Dataindtagelse, datatransformation, databehandling, dataprofilering |
| Primær udviklerperson | Datatekniker, dataintegrator |
Datatekniker, dataintegrator, forretningsanalytiker |
Datatekniker, dataforsker, dataudvikler |
| Kompetencesæt for primær udvikler | ETL SQL JSON |
ETL M SQL |
Spark (Scala, Python, Spark SQL, R) |
| Kode skrevet | Ingen kode, lav kode |
Ingen kode, lav kode |
Kode |
| Datamængde | Lav til høj | Lav til høj | Lav til høj |
| Udviklingsgrænseflade | Guiden Lærred |
Power-forespørgsel | Notebook Spark-jobdefinition |
| Kilder | Mere end 30 forbindelser | Mere end 150 forbindelser | Hundredvis af Spark-biblioteker |
| Destinationer | 18+ forbindelser | Lakehouse, Azure SQL-database, Azure Data Explorer, Azure Synapse-analyse |
Hundredvis af Spark-biblioteker |
| Transformationskompleksitet | Lav: lightweight – typekonvertering, kolonnetilknytning, flette/opdele filer, fladt hierarki |
Lav til høj: Mere end 300 transformationsfunktioner |
Lav til høj: understøttelse af oprindelige Spark- og open source-biblioteker |
Gennemse følgende tre scenarier for at få hjælp til at vælge, hvordan du arbejder med dine data i Fabric.
Scenarie1
Leo, der er datatekniker, skal hente en stor mængde data fra eksterne systemer, både i det lokale miljø og cloudmiljøet. Disse eksterne systemer omfatter databaser, filsystemer og API'er. Leo vil ikke skrive og vedligeholde kode for hver connector- eller dataflytningshandling. Han ønsker at følge medaljonslag bedste praksis med bronze, sølv og guld. Leo har ingen erfaring med Spark, så han foretrækker brugergrænsefladen for træk og slip så meget som muligt med minimal kodning. Og han vil også behandle dataene efter en tidsplan.
Det første trin er at hente rådata ind i lakehouse-bronzelaget fra Azure-dataressourcer og forskellige tredjepartskilder (f.eks. Snowflake Web, REST, AWS S3, GCS osv.). Han ønsker et konsolideret lakehouse, så alle data fra forskellige LOB-, lokale og cloudkilder er placeret ét sted. Leo gennemgår indstillingerne og vælger pipelinekopiaktivitet som det relevante valg for sin rå binære kopi. Dette mønster gælder for både historisk og trinvis opdatering af data. Med kopiaktivitet kan Leo indlæse Gold-data til et data warehouse uden kode, hvis behovet opstår, og pipelines giver dataindtagelse i høj skala, der kan flytte petabyte-skaleringsdata. Kopiér aktivitet er det bedste valg med lav kode og ingen kode for at flytte petabytes af data til lakehouses og warehouses fra sorter af kilder, enten ad hoc eller via en tidsplan.
Scenarie2
Mary er datatekniker med en dyb viden om de mange rapporteringskrav til LOB-analyse. Et upstream-team har implementeret en løsning til migrering af flere LOB's historiske og trinvise data til et fælles lakehouse. Mary har fået til opgave at rense dataene, anvende forretningslogik og indlæse dem på flere destinationer (f.eks. Azure SQL DB, ADX og et lakehouse) som forberedelse til deres respektive rapporteringsteams.
Mary er en erfaren Power Query-bruger, og datamængden er i det lave til mellemste interval for at opnå den ønskede ydeevne. Dataflow indeholder grænseflader uden kode eller lavt kodeformat til indtagelse af data fra hundredvis af datakilder. Med dataflow kan du transformere data ved hjælp af mere end 300 indstillinger for datatransformation og skrive resultaterne til flere destinationer med en brugervenlig, yderst visuel brugergrænseflade. Mary gennemgår indstillingerne og beslutter, at det giver mening at bruge Dataflow Gen 2 som sin foretrukne transformationsmulighed.
Scenarie3
Adam er datatekniker, der arbejder for en stor detailvirksomhed, der bruger et lakehouse til at gemme og analysere sine kundedata. Som en del af sit job er Adam ansvarlig for at bygge og vedligeholde de datapipelines, der udtrækker, transformerer og indlæser data i lakehouse. Et af virksomhedens forretningsmæssige krav er at udføre kundegennemgangsanalyser for at få indsigt i deres kunders oplevelser og forbedre deres tjenester.
Adam beslutter, at den bedste løsning er at bruge Spark til at bygge ekstrakt- og transformationslogik. Spark leverer en distribueret databehandlingsplatform, der kan behandle store mængder data parallelt. Han skriver et Spark-program ved hjælp af Python eller Scala, som læser strukturerede, halvstrukturerede og ustrukturerede data fra OneLake for kundeanmeldelser og feedback. Programmet renser, transformerer og skriver data til Delta-tabeller i lakehouse. Dataene er derefter klar til at blive brugt til downstreamanalyse.