Beslutningsveiledning for Microsoft Fabric: kopier aktivitet, dataflyt eller Spark
Bruk denne referanseveiledningen og eksempelscenarioene for å hjelpe deg med å avgjøre om du trenger en kopiaktivitet, en dataflyt eller Spark for Microsoft Fabric-arbeidsbelastninger.
Kopier egenskaper for aktivitet, dataflyt og Spark
| kopiaktivitet for datasamlebånd | dataflyt gen 2 | Spark | |
|---|---|---|---|
| Brukstilfelle | Datainnsjø- og datalageroverføring, datainntak, lett transformasjon |
Datainntak, datatransformasjon, data wrangling, dataprofilering |
Datainntak, datatransformasjon, databehandling dataprofilering |
| Primær utviklerpersonlighet | Dataingeniør, dataintegrator |
Dataingeniør, dataintegrator, forretningsanalytiker |
Dataingeniør, dataforsker, datautvikler |
| Primær utviklerferdighet | ETL, SQL JSON |
ETL, M, SQL |
Spark (Scala, Python, Spark SQL, R) |
| kode skrevet | Ingen kode, lav kode |
Ingen kode, lav kode |
Kode |
| datavolum | Lav til høy | Lav til høy | Lav til høy |
| development interface | Trollmann lerret |
Power Query | Notisbok Spark-jobbdefinisjon |
| kilder | 30+ koblinger | 150+ koblinger | Hundrevis av Spark-biblioteker |
| mål | 18+ koblinger | Lakehouse, Azure SQL-database, Azure Data Explorer, Azure Synapse-analyse |
Hundrevis av Spark-biblioteker |
| transformasjonskompleksitet | Lav: lett – typekonvertering, kolonnetilordning, slå sammen/dele filer, flate ut hierarki |
Lav til høy: 300+ transformasjonsfunksjoner |
Lav til høy: støtte for opprinnelige Spark- og åpen kildekode-biblioteker |
Se gjennom følgende tre scenarier for å få hjelp til å velge hvordan du arbeider med dataene i Fabric.
Scenario1
Leo, en dataingeniør, må innta et stort volum data fra eksterne systemer, både lokalt og i skyen. Disse eksterne systemene inkluderer databaser, filsystemer og API-er. Leo ønsker ikke å skrive og vedlikeholde kode for hver kobling eller databevegelsesoperasjon. Han ønsker å følge medaljonglagenes beste praksis, med bronse, sølv og gull. Leo har ingen erfaring med Spark, så han foretrekker dra og slipp brukergrensesnittet så mye som mulig, med minimal koding. Og han ønsker også å behandle dataene etter en tidsplan.
Det første trinnet er å få rådataene inn i lakehouse-bronselaget fra Azure-dataressurser og ulike tredjepartskilder (for eksempel Snowflake Web, REST, AWS S3, GCS osv.). Han vil ha et konsolidert innsjøhus, slik at alle dataene fra ulike LOB-, lokale og skykilder befinner seg på ett sted. Leo gjennomgår alternativene og velger kopiaktivitet for datasamlebånd som det riktige valget for sin rå binære kopi. Dette mønsteret gjelder både for historisk og trinnvis dataoppdatering. Med kopieringsaktivitet kan Leo laste inn Gold-data til et datalager uten kode hvis behovet oppstår, og datasinntak i høy skala som kan flytte petabyte-skaladata. Kopier aktivitet er det beste lavkode- og ikke-kodevalget for å flytte petabytes med data til lakehouses og varehus fra varianter av kilder, enten ad hoc eller via en tidsplan.
Scenario 2
Mary er en dataingeniør med en dyp kunnskap om de mange LOB analytiske rapporteringskravene. Et oppstrøms team har implementert en løsning for å overføre flere LOB-historiske og trinnvise data til et felles lakehouse. Mary har fått i oppgave å rengjøre dataene, bruke forretningslogikk og laste dem inn i flere destinasjoner (for eksempel Azure SQL DB, ADX og et lakehouse) som forberedelse for sine respektive rapporteringsteam.
Mary er en erfaren Power Query-bruker, og datavolumet er i det lave til mellomstore området for å oppnå ønsket ytelse. Dataflyter gir ingen kode eller grensesnitt med lav kode for inntak av data fra hundrevis av datakilder. Med dataflyter kan du transformere data ved hjelp av 300 + datatransformasjonsalternativer, og skrive resultatene til flere mål med et brukervennlig, svært visuelt brukergrensesnitt. Mary ser gjennom alternativene og bestemmer seg for at det er fornuftig å bruke Dataflyt Gen 2 som hennes foretrukne transformasjonsalternativ.
Scenario 3
Adam er en dataingeniør som arbeider for et stort detaljhandelselskap som bruker et lakehouse til å lagre og analysere kundedataene. Som en del av jobben er Adam ansvarlig for å bygge og vedlikeholde datasamlebånd som trekker ut, transformerer og laster inn data i lakehouse. Et av selskapets forretningskrav er å utføre analyser for kundegjennomgang for å få innsikt i kundenes erfaringer og forbedre tjenestene deres.
Adam bestemmer seg for at det beste alternativet er å bruke Spark til å bygge ekstrakt- og transformasjonslogikken. Spark gir en distribuert databehandlingsplattform som kan behandle store mengder data parallelt. Han skriver et Spark-program ved hjelp av Python eller Scala, som leser strukturerte, halvstrukturerte og ustrukturerte data fra OneLake for kundeanmeldelser og tilbakemeldinger. Programmet renser, transformerer og skriver data til Delta-tabeller i lakehouse. Dataene er deretter klare til bruk for nedstrømsanalyse.