Beslutningsveiledning for Microsoft Fabric: kopier aktivitet, dataflyt eller Spark

  • Artikkel

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 Gnist
Brukseksempel Datainnsjø- og datalageroverføring,
datainntak,
lett transformasjon		 Datainntak,
datatransformasjon,
data wrangling,
dataprofilering		 Datainntak,
datatransformasjon,
databehandling,
dataprofilering
Primær utviklerperson Dataingeniør,
dataintegrator		 Dataingeniør,
dataintegrator,
forretningsanalytiker		 Dataingeniør,
dataforsker,
datautvikler
Ferdighetssett for primærutvikler 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
Utviklingsgrensesnitt Veiviseren
Lerret		 Power Query Bærbare
Spark-jobbdefinisjon
Kilder 30+ koblinger 150+ koblinger Hundrevis av Spark-biblioteker
Destinasjoner 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 ser gjennom 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 sitt 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.

Relatert innhold