Share via

Microsoft Fabric-beslutningsvejledning: kopiér aktivitet, dataflow eller Spark

  • Artikel

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.

Relateret indhold