Apache Spark Runtimes i Fabric
Microsoft Fabric Runtime er en Azure-integreret platform, der er baseret på Apache Spark, som muliggør udførelse og administration af datakonstruktion og datavidenskabsoplevelser. Den kombinerer vigtige komponenter fra både interne kilder og kilder med åben kildekode, hvilket giver kunderne en omfattende løsning. For nemheds skyld henviser vi til Microsoft Fabric Runtime drevet af Apache Spark som Fabric Runtime.
Overordnede komponenter i Fabric Runtime:
Apache Spark – et effektivt distribueret databehandlingsbibliotek med åben kildekode, der muliggør databehandling og analyseopgaver i stor skala. Apache Spark leverer en alsidig platform med høj ydeevne til datakonstruktion og datavidenskabsoplevelser.
Delta Lake – et lagerlag med åben kildekode, der leverer ACID-transaktioner og andre funktioner til datapålidelighed til Apache Spark. Delta Lake er integreret i Fabric Runtime og forbedrer databehandlingsfunktionerne og sikrer ensartet data på tværs af flere samtidige handlinger.
Native Execution Engine – er en transformerende forbedring af Apache Spark-arbejdsbelastninger, der giver betydelige forbedringer af ydeevnen ved direkte at køre Spark-forespørgsler på lakehouse-infrastrukturen. Den er integreret uden problemer og kræver ingen kodeændringer og forhindrer, at leverandøren låser sig fast, og det understøtter både Parquet- og Delta-formater på tværs af Apache Spark-API'er i Runtime 1.3 (Spark 3.5). Dette program øger forespørgselshastighederne op til fire gange hurtigere end den traditionelle OSS Spark, som det fremgår af TPC-DS 1TB-benchmarken, hvilket reducerer driftsomkostningerne og forbedrer effektiviteten på tværs af forskellige dataopgaver – herunder dataindtagelse, ETL, analyser og interaktive forespørgsler. Den er bygget på Metas Velox og Intels Apache Gluten og optimerer ressourceanvendelsen, samtidig med at den håndterer forskellige databehandlingsscenarier.
Pakker på standardniveau til Java/Scala, Python og R – pakker, der understøtter forskellige programmeringssprog og -miljøer. Disse pakker installeres og konfigureres automatisk, så udviklere kan anvende deres foretrukne programmeringssprog til databehandlingsopgaver.
Microsoft Fabric Runtime er bygget på et robust operativsystem med åben kildekode, der sikrer kompatibilitet med forskellige hardwarekonfigurationer og systemkrav.
Nedenfor finder du en omfattende sammenligning af vigtige komponenter, herunder Apache Spark-versioner, understøttede operativsystemer, Java, Scala, Python, Delta Lake og R, for Apache Spark-baserede runtimes på Microsoft Fabric-platformen.
Tip
Brug altid den nyeste version af ga-runtime til din produktionsarbejdsbelastning, som i øjeblikket er Runtime 1.3.
Kørsel 1.1 | Kørsel 1.2 | Kørsel 1.3 | |
---|---|---|---|
udgivelsesfase | EOSA | GA | GA |
Apache Spark | 3.3.1 | 3.4.1 | 3.5.0 |
Operativsystem | Ubuntu 18.04 | Mariner 2.0 | Mariner 2.0 |
Java | 8 | 11 | 11 |
Scala | 2.12.15 | 2.12.17 | 2.12.17 |
Python | 3,10 | 3,10 | 3.11 |
Delta Lake | 2.2.0 | 2.4.0 | 3,2 |
R | 4.2.2 | 4.2.2 | 4.4.1 |
Besøg Runtime 1.1, Runtime 1.2 eller Runtime 1.3 for at udforske detaljer, nye funktioner, forbedringer og migreringsscenarier for den specifikke kørselsversion.
Fabric-optimeringer
I Microsoft Fabric inkorporerer både Spark-programmet og Delta Lake-implementeringerne platformspecifikke optimeringer og funktioner. Disse funktioner er designet til at bruge oprindelige integrationer på platformen. Det er vigtigt at bemærke, at alle disse funktioner kan deaktiveres for at opnå standardfunktionalitet for Spark og Delta Lake. Fabric Runtimes til Apache Spark omfatter:
- Den komplette version af Apache Spark med åben kildekode.
- En samling af næsten 100 indbyggede forbedringer af forespørgselsydeevnen. Disse forbedringer omfatter funktioner som cachelagring af partitioner (aktivering af FilSystem-partitionscachen for at reducere metastore-kald) og Cross Join to Projection of Scalar Subquery.
- Indbygget intelligent cache.
I Fabric Runtime for Apache Spark og Delta Lake er der oprindelige skrivefunktioner, der tjener to vigtige formål:
- De giver en differentieret ydeevne i forbindelse med skrivning af arbejdsbelastninger og optimerer skriveprocessen.
- De er som standard V-Order-optimering af Delta Parquet-filer. Delta Lake V-Order-optimering er afgørende for at levere fremragende læseydeevne på tværs af alle Fabric-motorer. Hvis du vil have en dybere forståelse af, hvordan den fungerer, og hvordan du administrerer den, skal du se den dedikerede artikel om Delta Lake-tabeloptimering og V-Order.
Understøttelse af flere kørselstidspunkter
Fabric understøtter flere kørselstider og giver brugerne fleksibiliteten til problemfrit at skifte mellem dem, så risikoen for uoverensstemmelser eller afbrydelser minimeres.
Som standard bruger alle nye arbejdsområder den nyeste kørselsversion, som i øjeblikket er Runtime 1.3.
Hvis du vil ændre kørselsversionen på arbejdsområdeniveau, skal du gå til Indstillinger for arbejdsområde>Indstillinger for Data engineering/Science>Spark. Vælg den ønskede kørselsversion under fanen Environment under de tilgængelige indstillinger. Vælg Gem for at bekræfte markeringen.
Når du har foretaget denne ændring, fungerer alle systemoprettede elementer i arbejdsområdet, herunder Lakehouses, SJDs og Notesbøger, ved hjælp af den nyvalgte kørselsversion på arbejdsområdeniveau fra og med den næste Spark-session. Hvis du i øjeblikket bruger en notesbog med en eksisterende session til et job eller en lakehouse-relateret aktivitet, fortsætter spark-sessionen, som den er. Men fra næste session eller job anvendes den valgte kørselsversion.
Konsekvenser af ændringer af kørsel på Spark-indstillinger
Generelt sigter vi mod at overføre alle Spark-indstillinger. Men hvis vi identificerer, at Spark-indstillingen ikke er kompatibel med Runtime B, udsender vi en advarselsmeddelelse og afstår fra at implementere indstillingen.
Konsekvenser af kørselsændringer for biblioteksstyring
Generelt er vores tilgang at overføre alle biblioteker fra Runtime A til Runtime B, herunder både offentlig og brugerdefineret kørsel. Hvis Python- og R-versionerne forbliver uændrede, skal bibliotekerne fungere korrekt. For Jars er der dog en betydelig sandsynlighed for, at de muligvis ikke fungerer på grund af ændringer i afhængigheder og andre faktorer, f.eks. ændringer i Scala, Java, Spark og operativsystemet.
Brugeren er ansvarlig for at opdatere eller erstatte alle biblioteker, der ikke fungerer sammen med Runtime B. Hvis der er en konflikt, hvilket betyder, at Runtime B indeholder et bibliotek, der oprindeligt er defineret i Runtime A, vil vores biblioteksadministrationssystem forsøge at oprette den nødvendige afhængighed for Runtime B baseret på brugerens indstillinger. Men byggeprocessen mislykkes, hvis der opstår en konflikt. I fejlloggen kan brugerne se, hvilke biblioteker der forårsager konflikter, og foretage justeringer af deres versioner eller specifikationer.
Opgrader Delta Lake-protokol
Delta Lake-funktioner er altid bagudkompatible, så tabeller, der er oprettet i en lavere Delta Lake-version, kan interagere problemfrit med højere versioner. Men når visse funktioner er aktiveret (f.eks. ved hjælp delta.upgradeTableProtocol(minReaderVersion, minWriterVersion)
af metoden , kan fremadkompatibilitet med lavere Delta Lake-versioner være kompromitteret. I sådanne tilfælde er det vigtigt at ændre arbejdsbelastninger, der refererer til de opgraderede tabeller, så de stemmer overens med en Delta Lake-version, der bevarer kompatibiliteten.
Hver Delta-tabel er knyttet til en protokolspecifikation, der definerer de funktioner, den understøtter. Programmer, der interagerer med tabellen, enten til læsning eller skrivning, er afhængige af denne protokolspecifikation for at afgøre, om de er kompatible med tabellens funktionssæt. Hvis et program mangler muligheden for at håndtere en funktion, der er angivet som understøttet i tabellens protokol, kan det ikke læse fra eller skrive til tabellen.
Protokolspecifikationen er opdelt i to særskilte komponenter: læseprotokollen og skriveprotokollen. Besøg siden "Hvordan administrerer Delta Lake funktionskompatibilitet?" for at læse detaljer om den.
Brugerne kan udføre kommandoen delta.upgradeTableProtocol(minReaderVersion, minWriterVersion)
i PySpark-miljøet og i Spark SQL og Scala. Denne kommando giver dem mulighed for at starte en opdatering af Delta-tabellen.
Det er vigtigt at bemærke, at når brugerne udfører denne opgradering, modtager de en advarsel, der angiver, at opgradering af Delta-protokolversionen er en ikke-eversibel proces. Det betyder, at når opdateringen er udført, kan den ikke fortrydes.
Opgraderinger af protokolversioner kan potentielt påvirke kompatibiliteten af eksisterende Delta Lake-tabellæsere, -forfattere eller begge dele. Det anbefales derfor, at du fortsætter med forsigtighed og kun opgraderer protokolversionen, når det er nødvendigt, f.eks. når du indfører nye funktioner i Delta Lake.
Derudover bør brugerne kontrollere, at alle aktuelle og fremtidige produktionsarbejdsbelastninger og -processer er kompatible med Delta Lake-tabeller ved hjælp af den nye protokolversion for at sikre en problemfri overgang og forhindre eventuelle afbrydelser.
Delta 2.2 vs. Delta 2.4-ændringer
I den nyeste Fabric Runtime, version 1.3 og Fabric Runtime, version 1.2, er standardtabelformatet (spark.sql.sources.default
) nu delta
. I tidligere versioner af Fabric Runtime, version 1.1 og på alle Synapse Runtime for Apache Spark, der indeholder Spark 3.3 eller nyere, blev standardtabelformatet defineret som parquet
. Se tabellen med Konfigurationsdetaljer for Apache Spark for at se forskellene mellem Azure Synapse Analytics og Microsoft Fabric.
Alle tabeller, der oprettes ved hjælp af Spark SQL, PySpark, Scala Spark og Spark R, opretter som standard tabellen delta
, når tabeltypen udelades. Hvis scripts eksplicit angiver tabelformatet, respekteres det. Kommandoen USING DELTA
i Spark opretter tabelkommandoer bliver overflødig.
Scripts, der forventer eller antager parquettabelformat, skal revideres. Følgende kommandoer understøttes ikke i Delta-tabeller:
ANALYZE TABLE $partitionedTableName PARTITION (p1) COMPUTE STATISTICS
ALTER TABLE $partitionedTableName ADD PARTITION (p1=3)
ALTER TABLE DROP PARTITION
ALTER TABLE RECOVER PARTITIONS
ALTER TABLE SET SERDEPROPERTIES
LOAD DATA
INSERT OVERWRITE DIRECTORY
SHOW CREATE TABLE
CREATE TABLE LIKE