Valg af en notebook-kerne i Microsoft Fabric

Notebooks i Microsoft Fabric understøtter tre kernetyper: Python, Spark og T-SQL. Spark-kernen understøtter fire sprog—PySpark, SparkSQL, Scala og SparkR—alle understøttet af den samme Spark-beregning. Denne guide fokuserer på valget mellem Python-kernen og Spark-kernen, da disse kerner er de mest almindelige valg til dataingeniørarbejdsbelastninger. Begge kører i samme notebook-oplevelse, men adskiller sig i beregningsmodel, skalerbarhed, motorfunktioner og Delta Lake-kompatibilitet. Denne guide giver en balanceret evaluering, der hjælper dig med at vælge den rigtige kerne – og undgå almindelige misforståelser om omkostninger og ydeevne.

Vigtigt!

Valget af notebook-kerne handler ikke kun om pris eller datastørrelse. Computekonfiguration, Delta Lake-funktionskrav, motormodenhed og forventet datavækst spiller alle vigtige roller i at træffe den rigtige beslutning.

Forstå dine beregningsmuligheder

En almindelig misforståelse er, at Python-kernen altid er billigere end Spark-kernen til små dataarbejdsbelastninger. I virkeligheden afhænger omkostningerne af, hvordan du konfigurerer beregningen for hver kerne.

Python-kerneberegning

Python-kernen kører på en enkelt-node-maskine, der som standard har 2 vCores (1 CU) og kan konfigureres til at starte med op til 64 vCores (32 CU). Dette miljø har ingen distribueret eksekvering. Startpuljen initialiseres på cirka 5 sekunder, hvilket gør den hurtig til interaktivt arbejde.

Spark-kerneberegning

Spark-kernen bruger Spark-pools med flere konfigurationsmuligheder:

Klyngekonfiguration vCores tilgængelige for eksekutorer Sessionens starttidspunkt CU'er forbrugt efter sessionsstart
Starterpulje (standard) 8-core worker-noder, autoskalering aktiveret; starter som en enkelt node og skalerer proaktivt til en dedikeret arbejder inden for få minutter efter sessionens start ~5 sekunder 8 CU'er (minimum, opskalering efter proaktiv)
Enkelt-node*, 8-vCore (via Starter pool) 8-core executor og driver deler samme node ~5 sekunder (med forvarmet pool) 4 CU'er
Enkelt-node*, 4-vCore custom pool 4-kerne udfører og driver deler samme node Kræver en brugerdefineret pulje; Sessionsstarten varer typisk mellem 3-5 minutter 2 CU'er
Multi-node brugerdefineret pool Skæl med klyngestørrelse Sessionens start varer typisk mellem 3-5 minutter Varierer

Når man bruger starterpoolen, starter en enkeltnode 8-vCore Spark-session på cirka 5 sekunder—svarende til Python-kernen. En enkelt-node Spark-klynge holder omkostninger svarende til Python-kernen, samtidig med at den giver adgang til alle Spark-native funktioner, inklusive Native Execution Engine (NEE).

Bemærkning

Der er to måder at konfigurere enkelt-node Spark-pools på. For de fleste arbejdsbelastninger anbefales det typisk at bruge den første metode, Overprovisioned single-node. Den anden metode, Classic single-node, er bedre, når der er drivertunge processer, men begrænser mængden af ressourcer, som Spark-eksekutører kan bruge.

  • Overprovisioneret enkelt-node: start med en Spark Pool (altså Starter Pool) konfigureret med autoskalering og dynamisk allokering aktiveret med autoskalering sat til 1 til > 1 noder. Opret et Environment-element, der refererer til Spark Pool, og sæt antallet af eksekutører til 1. Notebooks, der bruger dette miljø, provisionerer med en enkelt-node Spark-klynge, hvor både driveren og eksekveren deler alle ressourcer.
  • Klassisk enkeltnode: opret en Spark Pool med maksimalt antal noder sat til 1. Denne konfiguration fungerer med autoskalering og dynamisk allokering aktiveret eller deaktiveret, da valget ikke påvirker provisioneringsstrategien. Notebooks, der bruger denne Spark Pool, har 50% v-kerner tildelt driveren og 50% tildelt som eksekvere.

Ydeevne efter arbejdsbelastningsskala

Benchmarks, der sammenligner Fabric Spark med Native Execution Engine med enkelt-maskine Python-motorer (som Pandas, DuckDB eller Polars) på tværs af end-to-end ELT-arbejdsbelastninger, viser klare mønstre baseret på dataskala:

Dataskala (komprimeret) Motorfordel
Ultra-lille (< ~140 MB) Enkeltmaskine Python-motorer (DuckDB, Polars) er hurtigere.
Lille (~1–2 GB) Python-motorer har stadig en fordel, men Fabric Spark med NEE bliver konkurrencedygtig, efterhånden som antallet af tilgængelige kerner for hver motor øges, især til skrivningstunge operationer.
Lille-mellemstor (~10–13 GB) Fabric Spark med Native Execution Engine er konkurrencedygtig med eller hurtigere end de fleste enkelt-maskine motorer. Enkeltmaskine Python-motorer kan løbe ind i out-of-memory (OOM) fejl ved lavere vCore-antal.
Medium og derover (~100 GB+) For de fleste arbejdsbelastninger er Fabric Spark med Native Execution Engine den hurtigste og mest pålidelige motor.

Skalering ud over små data

Overvej hastigheden af datavækst, når du vælger en motor. Ikke-distribuerede Python-motorer fungerer godt til virkelig små data, men at migrere din kode, når data overstiger deres grænser, er dyrt. At starte med Spark på en enkeltnode-konfiguration lader dig skalere problemfrit ud til en multi-node-konfiguration uden at omskrive dine dataingeniør-pipelines.

Delta Lake-kompatibilitet

Delta Lake-kompatibilitet er en afgørende overvejelse, når man vælger en motor. Fabric Spark har indbygget, fuldt udstyret Delta Lake-understøttelse, mens Python-motorer kan have betydelige huller:

Vigtigt!

Følgende funktionsstøttetabel afspejler tilstanden for hver motor pr. juni 2026 og er baseret på direkte test mod Fabric Spark Runtime 1.3 og 2.0. Det open source software (OSS) Python-økosystem til Delta Lake bevæger sig hurtigt – delta-rs, DuckDB og Polars udgiver alle hyppige udgivelser, der periodisk tilføjer udvidet understøttelse af Delta-protokollen. Verificér altid mod den aktuelle dokumentation og udgivelsesnoter for hver motor, før du stoler på en specifik funktion i produktion:

Delta Lake-funktion Stof spark delta-rs (Python) DuckDB Polare
Læs Delta-tabeller
Skriv Delta-tabeller ✅ Tilføje, overskriv (inkl. prædikatbaseret), OPDATER, SLET, FLET SAMMEN ⚠️ INSERT only (kræver ATTACH ... (TYPE delta, READ_WRITE)ikke ); ingen UPDATE/DELETE/MERGE; brug delta-rs til andre skriveoperationer ⚠️ Appender, overskriv (inkl. prædikatbaseret), kun sammenfletting; ingen OPDATERING/SLET
ACID-garantier / Optimistisk Concurrency Control ⚠️ INSERT er kun append; ingen indfødt konfliktdetektion; Brug delta-r'er med versionsfastning til læse-så-skrive-isolering ⚠️ OCC på skrivninger; Polars-læsninger ligger uden for transaktionsgrænsen – kræver eksplicit versions-pinning for læsning-så-skrive-isolering
Skemaudvikling ved skrivning ❌ Ingen skemaudvikling på INSERT
Kolonnetilknytning
Sletningsvektorer (læs)
Sletningsvektorer (skriv)
Typeudvidelse (læs)
Typeudvidelse (skriv)
Filspring
Opdelte skrivninger ❌ Brug delta-rs til at skrive med partitionering
Væskeklyngedannelse (skriv)
Tidsrejser
GENOPRET ❌ Brug delta-rs til at gendanne tabeller ❌ Brug delta-rs til at gendanne tabeller
Overfladisk klon (skab)
Overfladisk klon (læs)
Rækkesporing ⚠️ Læsninger og skrivninger lykkes, men rækkesporing _metadata er ikke tilgængelig; pipelines, der er afhængige af row_id for deduplikering eller ændringsdatafangst (CDC), skal bruge Spark til at læse ⚠️ Læsninger og skrivninger lykkes, men rækkesporing _metadata er ikke tilgængelig; pipelines, der er afhængige af row_id for deduplikering eller CDC, skal bruge Spark til at læse ⚠️ Læsninger og skrivninger lykkes, men rækkesporing _metadata er ikke tilgængelig; pipelines, der er afhængige af row_id for deduplikering eller CDC, skal bruge Spark til at læse
Identitetskolonner (læs)
Identitetskolonner (skriv)
Genererede kolonner (læs)
Genererede kolonner (skriv)
Skift datafeed (læs) ❌ Brug delta-rs til at læse ændringsdatafeedet ❌ Brug delta-rs til at læse ændringsdatafeedet
Skift datafeed (skriv)
V2 checkpoints (læs)
V2 checkpoints (skriv)
Checkpoint-interval ✅ Konfigurerbar (standard 10) ⚠️ Configurable (standard 100) ❌ INSERT skriver ikke checkpoints; Log vokser ubegrænset uden ekstern vedligeholdelse via delta-r'er ⚠️ Configurable (standard 100)
OPTIMER ❌ Brug delta-r'er til optimering ❌ Brug delta-r'er til optimering
Automatisk komprimering
VAKUUM ❌ Risiko: ophobning af forældreløse filer ❌ Risiko: ophobning af forældreløse filer ❌ Risiko: ophobning af forældreløse filer
VACUUM LITE ❌ Brug delta-r'er til vakuum-light ❌ Brug delta-r'er til vakuum-light

Nøgleimplikationer:

  • Nyere Delta-funktioner: Understøttelse af nyere Delta Lake-funktioner – herunder typeudvidelse, v2-checkpoints, væskeklyngedannelse, identitetskolonner, Change Data Feed-skrivninger og overfladiske klonlæsninger – er inkonsekvent eller fraværende på tværs af OSS Python-motorer. Hvis din datapipeline afhænger af nogen af disse funktioner, så brug Fabric Spark. Behandl Python-motorer som et supplement til Spark til specifikke arbejdsbelastninger (letvægtslæsninger, lokal udvikling, simple appends) frem for som en generel erstatning.

  • Sletningsvektorer: Sletningsvektorer er en bedste praksis for Delta-tabeller (aktiveret som standard fra Fabric Spark Runtime 2.0), da de i høj grad forbedrer ydeevnen af MERGE-, UPDATE- og DELETE-operationer via en merge-on-read-strategi. Ingen Python-motor (delta-rs, DuckDB eller Polars) understøtter skrivning af deletionsvektorer. Hvis du bruger en hvilken som helst Python-motor til at skrive til tabeller med deletionsvektorer aktiveret, støder du på kompatibilitetsfejl.

  • ACID-garantier: Ikke alle Python-motorer tilbyder native ACID-garantier. Delta-rs understøtter optimistisk samtidighedskontrol (OCC) til sammenfletting, opdatering og sletning. Dog kræver cross-engine pipelines, hvor DuckDB eller Polars udfører læsningen og delta-rs skriver eksplicit versionspinning på begge sider for at opretholde læse-skrive-isolation. DuckDB INSERT er en append-only operation uden konfliktdetektion.

  • Checkpointing: Ikke alle Python-motorer skriver checkpoints, og de motorer, der gør, starter som standard for hver 100 commits i stedet for Sparks standard for hver 10. commit. DuckDB INSERT skriver aldrig checkpoints, hvilket får Delta-transaktionsloggen til at vokse ubegrænset. Overvej at sætte et lavere checkpoint-interval i delta-rs og Polars, og kør periodisk delta-rs-vedligeholdelse for tabeller skrevet af DuckDB.

  • Rækkesporing: Alle Python-motorer kan læse fra og skrive til tabeller med rækkesporing aktiveret, men kolonnen_metadata, der indeholder row_id og row_commit_version er ikke tilgængelig uden for Spark. Pipelines, der er afhængige af row_id deduplikering eller CDC, skal bruge Spark til læsning.

  • OPTIMIZE og VACUUM: Python-motorer er afhængige af biblioteket deltalake til komprimering og vakuum. Selvom delta-r'er kan være hurtige til disse operationer, introducerer denne tilgang ekstra afhængighedsstyring, og operationerne er ikke direkte orkestrerede, som de er i Spark. Tabeller skrevet udelukkende via Python-motorer opsamler små filer og ubegrænsede transaktionslogfiler uden eksplicit vedligeholdelse.

  • Overfladiske kloner: Python-motorer understøtter ikke læsetabeller oprettet via en overfladisk klon på grund af absolutte begrænsninger i stiopløsning. Ingen Python-engine understøtter at lave overfladiske kloner.

Motormodenhed og Microsoft-understøttelse

Fabric Spark-støtte

Fabric Spark er Microsoft egen fork af open source Apache Spark. Microsoft vedligeholder og leverer runtime, hvilket betyder:

  • Microsoft understøtter Spark og Delta Lakes interne systemer end-to-end, inklusive Native Execution Engine (NEE), som er bygget på Velox og Apache Gluten.
  • Du kan åbne supporttickets for Spark-adfærd, forespørgselsplaner, hukommelsesproblemer og motorfejl.
  • Ydelsesforbedringer leveres løbende som en del af Fabric-runtime-opdateringer – din eksisterende kode bliver hurtigere uden kodeændringer.

Python-motorunderstøttelse

Microsoft vedligeholder ikke en fork af OSS Python-motorer som DuckDB eller Polars. Understøttelsen er begrænset til problemer i de OneLake-integrationer, der leveres som en del af Fabric-runtime, såsom autentificering eller adgang til filsystemet. Hvis du støder på en ydelsesregression, en motorfejl eller et ødelagt API mellem biblioteksversioner, skal du engagere dig direkte med open source-fællesskaberne for disse biblioteker.

Operationel modenhed

Erfaring fra den virkelige verden med at opbygge ende-til-ende ELT-benchmarks med disse motorer fremhæver meningsfulde forskelle i operationel modenhed:

  • Spark: Kode skrevet til én runtime-version kører uden ændringer på nyere versioner og yder hurtigere takket være kontinuerlig Microsoft-ingeniørinvestering. Spark UI og Fabric-telemetrien giver live overvågning med fuld indsigt i aktive forespørgsler, udførelsesplaner og historiske jobkørsler.
  • DuckDB og Polars: API- og adfærdsændringer mellem versioner kan kræve koderefaktorering, efterhånden som motorerne modnes og API'erne udvikler sig. Begge motorer mangler live-overvågning – når et job varer længere end forventet, findes der ikke noget tilsvarende Spark-brugerfladen til at forstå, hvad der sker. Autentificering til OneLake kan kræve versionsspecifikke løsninger.
  • Overhead for sammensatte datastak: At bruge DuckDB eller Polars til en fuld ELT-arbejdsgang betyder typisk at sammensætte flere biblioteker (for eksempel DuckDB til datascanning og transformation, delta-rs til skrivning og vedligeholdelse). Bibliotekskompatibilitet skal opretholdes mellem komponenterne og bør overvejes, hver gang bibliotekets version opgraderes ud over det, der leveres i runtime.

Vejledning til beslutninger

Brug Python-kernen, når

  • Dine data er små – under cirka 1 GB komprimeret – og rå ydeevne på enkelt-maskine motorer betyder mest.
  • Du bygger letvægts API-orkestrering, REST/gRPC-integrationer eller control-flow automation, hvor distribueret beregning tilføjer unødvendig overhead.
  • Du laver hurtig interaktiv udforskning af små datasæt, hvor ad hoc forespørgselsforsinkelse er prioriteten.
  • Din arbejdsbyrde kræver en ældre Python-version end den, der leveres i den nuværende Fabric Spark-runtime.
  • Du forstår og accepterer Delta Lake-funktionsbegrænsningerne i den Python-engine, du bruger.

Brug Spark-kernen, når

  • Dine data er 1 GB eller større i komprimeret form, eller du forventer, at dataene vokser til den skala.
  • Du har brug for fuld Delta Lake-kompatibilitet, inklusive slettevektorer, kolonnemapping, typeudvidelse, OPTIMIZE, VACUUM og ACID-garantier.
  • Du har brug for produktionsfunktioner som miljøvariabler, item-baseret biblioteksstyring, høj samtidighed og FAIR eller first-in, first-out (FIFO) jobplanlægning.
  • Du har brug for live overvågning og fuld operationel oversigt over kørende opgaver.
  • Du er afhængig af oprindelige Spark-API'er, f.eks. MLlib, Spark SQL eller Spark Streaming.
  • Du ønsker Microsoft end-to-end support til din databehandlingsmotor.
  • Du vil gerne kunne skalere fra enkelt-node til multi-node beregning uden at omskrive koden.
  • Du skal lave notesbøger i PySpark, SparkSQL, Scala eller SparkR.

Tips

For arbejdsbelastninger på eller over 1 GB komprimeret skala, overvej at starte med en enkeltnode 8-vCore Spark-klynge ved brug af starterpoolen. Du får næsten øjeblikkelige starttider for sessioner, fulde Fabric Spark-funktioner inklusive NEE, og muligheden for at skalere til multi-node efter behov – alt imens du kun kører på én node som Python-kernen.

Vigtige forskelle ved et hurtigt overblik

Kategori Python-kerne Spark-kerne
Standardberegning 2-vCore enkelt-node virtuel maskine (VM) (skalerbar op til 64 vCores) Starterpulje: 8-vCore worker-noder med autoscale
Minimum enkelt-node-konfiguration 2 vCores 8 vCores (startpulje, ~5 sekunder start); 4 vCores (custom pool, længere start)
Opstartstid ~5 sekunder ~5 sekunder (startpool); længere for brugerdefinerede pools
Distribueret udførelse No Yes
Understøttede sprog Pyton PySpark, SparkSQL, Scala, SparkR
Python-versionen Flere versioner tilgængelige Knyttet til Fabric Spark runtime-versionen
Delta Lake (fuld funktionsunderstøttelse) No Yes
Live overvågning Begrænset Fuld (Jobovervågningsside + Spark UI)
Microsoft motorunderstøttelse Kun OneLake-integrationer Fuld runtime-understøttelse
Python-biblioteksadgang pip-installation Pip-installation + miljøelementer
Spark-native API'er (MLlib, streaming) No Yes
Produktionsfunktioner (miljøer, miljøer) Begrænset Fuld
Høj samtidighedsstøtte No Yes
V-orden for hurtige Direct Lake-semantiske modeller No Yes
Objektlagercache, der muliggør acceleration af gentagne læsninger Motorafhængig (DuckDB har indbygget cache, Polars har ikke) Ja (Intelligent cache)
Skalaer til multi-node No Yes

Ordliste

  • ACID-transaktioner: Et sæt egenskaber (Atomicitet, Konsistens, Isolation, Holdbarhed), der sikrer, at databaseoperationer behandles pålideligt. Delta Lake implementerer ACID-semantik ved brug af optimistisk samtidighedskontrol og transaktionslogfiler.
  • Optimistisk Concurrency Control (OCC): En samtidighedsstrategi, hvor transaktioner forløber uden låsning og derefter ved commit-tidspunktet verificeres, at der ikke er sket modstridende ændringer. Delta Lake bruger OCC; cross-engine pipelines (for eksempel Polars-læsninger efterfulgt af delta-rs-skrivninger) kræver eksplicit versions-pinning for at opretholde isolation.
  • Autokomprimering: En Delta Lake-funktion i Fabric Spark-runtime, der automatisk sammenlægger små filer til større efter skriveoperationer, hvilket reducerer filfragmentering uden et separat OPTIME-trin.
  • Change Data Feed (CDF): En Delta Lake-funktion, der registrerer ændringer på rækkeniveau (indsætt, opdatering, slet) i en tabel og muliggør inkrementel databehandling og CDC-pipelines. Kun Fabric Spark understøtter skrivning af Change Data Feed (CDF) metadata; OSS Python-motorer kan læse, men ikke producere det.
  • Kolonnemapping: En Delta Lake-funktion, der tillader kolonner at blive omdøbt eller fjernet uden at omskrive de underliggende Parquet-filer. Understøttet af Fabric Spark; ikke understøttet af delta-rs eller Polars.
  • delta-rs: En open source Rust-implementering af Delta Lake-protokollen med Python-bindinger (deltalakePyPI-pakken). Tilbyder Delta læse-/skrive-understøttelse i OSS Python-miljøer, men har smallere funktionsdækning end delta-spark den, der understøtter Fabric Spark-runtime.
  • Sletningsvektorer: En Delta Lake-optimering, der bruger merge-on-read til at reducere mængden af data, der omskrives under MERGE, UPDATE og DELETE-operationer. Aktiveret som standard i Fabric Spark Runtime 2.0; understøttes ikke til skrivning af nogen OSS Python-motor.
  • FAIR planlægning: En Spark-planlægningspolitik, der fordeler klyngens ressourcer retfærdigt på tværs af samtidige job, så ingen enkelt job monopoliserer klyngen.
  • FIFO-planlægning: En Spark-planlægningspolitik, der udfører jobs i First-In-First-Out rækkefølge og giver prioritet til det først indsendte job.
  • Liquid Clustering: En Delta Lake-funktion, der inkrementelt omorganiserer data for optimal forespørgselsydelse uden at kræve eksplicit opdeling. Kun understøttet af Fabric Spark.
  • NEE (Native Execution Engine): En vektoriseret C++-forespørgselsmotor bygget på Velox og Apache Gluten, som accelererer Fabric Spark-arbejdsbelastninger. NEE er tilgængelig uden ekstra beregningsomkostninger og kræver ingen kodeændringer.
  • Rækkesporing: En Delta Lake-funktion, der tildeler en stable row_id and til row_commit_version hver række via en _metadata kolonne. Alle motorer kan læse fra og skrive til tabeller med rækkesporing aktiveret, men kun Fabric Spark kan få adgang til _metadata kolonneindholdet.
  • Spark pool: En delt compute-ressource til at køre distribuerede Spark-arbejdsbelastninger. Starterpoolen leverer forvarmede noder til næsten øjeblikkelige sessionsstarttider (~5 sekunder) med autoskalering aktiveret som standard.
  • V-orden: En Fabric-skriveoptimering, der sorterer og komprimerer Parquet-data på en måde, der forbedrer læseydelsen for Power BI Direct Lake-semantiske modeller og andre Fabric-læsestier.
  • Intelligent cache: En intelligent diskcache i Fabric Spark, der øger hastigheden af gentagne læsninger af de samme Delta-tabelfiler ved at cache fildata lokalt på eksekvernnoderne.