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.

• 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 både Runtime 1.1 og Runtime 1.2 på Microsoft Fabric-platformen.

	Kørsel 1.1	Kørsel 1.2	Kørsel 1.3
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,10
Delta Lake	2.2.0	2.4.0	3.0.0
R	4.2.2	4.2.2	I/R

Besøg Runtime 1.1 eller Runtime 1.2 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:

1. De giver en differentieret ydeevne i forbindelse med skrivning af arbejdsbelastninger og optimerer skriveprocessen.
2. 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.

Alle nye arbejdsområder bruger som standard den nyeste kørselsversion, som i øjeblikket er Runtime 1.2.

Hvis du vil ændre kørselsversionen på arbejdsområdeniveau, skal du gå til Arbejdsområde Indstillinger > Dataudvikler ing/Science > Spark Compute > Workspace Level Default og vælge den ønskede kørsel fra de tilgængelige indstillinger.

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 kørselsændringer 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.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

Versionsstyring

Vores kørselsversionsnummerering, der er tæt relateret til Semantic Versioning, følger en lidt anden tilgang. Den overordnede runtime-version svarer til den overordnede Apache Spark-version. Runtime 1 svarer derfor til Spark version 3. På samme måde vil den kommende Runtime 2 være i overensstemmelse med Spark 4.0. Det er vigtigt at bemærke, at der kan forekomme ændringer mellem de aktuelle kørselstider, Runtime 1.1 og Runtime 1.2, herunder tilføjelse eller fjernelse af forskellige biblioteker. Derudover tilbyder vores platform en funktion til administration af biblioteker, der giver brugerne mulighed for at installere de ønskede biblioteker.

Relateret indhold

• Runtime 1.3 (Spark 3.5, Java 11, Python 3.10, Delta Lake 3.0)
• Runtime 1.2 (Spark 3.4, Java 11, Python 3.10, Delta Lake 2.4)
• Runtime 1.1 (Spark 3.3, Java 8, Python 3.10, Delta Lake 2.2)