Apache Spark i Azure Machine Learning

Artikel
04/07/2024

Azure Machine Learning-integrering med Azure Synapse Analytics ger enkel åtkomst till distribuerade beräkningsresurser via Apache Spark-ramverket. Den här integreringen erbjuder följande Apache Spark-databehandlingsupplevelser:

Serverlös Spark-beräkning
Bifogad Synapse Spark-pool

Serverlös Spark-beräkning

Med Apache Spark-ramverket är Azure Machine Learning serverlös Spark-beräkning det enklaste sättet att utföra distribuerade databehandlingsuppgifter i Azure Machine Learning-miljön. Azure Machine Learning erbjuder ett fullständigt hanterat, serverlöst Apache Spark-beräkningskluster på begäran. Användarna kan undvika behovet av att skapa en Azure Synapse-arbetsyta och en Synapse Spark-pool.

Användare kan definiera resurser, inklusive instanstyp och Apache Spark-körningsversion. De kan sedan använda dessa resurser för att komma åt serverlös Spark-beräkning, i Azure Machine Learning-notebook-filer, för:

Några saker att tänka på

Serverlös Spark-beräkning fungerar bra för de flesta användarscenarier som kräver snabb åtkomst till distribuerade beräkningsresurser via Apache Spark. För att fatta ett välgrundat beslut bör användarna dock ta hänsyn till fördelarna och nackdelarna med denna metod.

Fördelar:

Inga beroenden för att skapa andra Azure-resurser för Apache Spark (Azure Synapse-infrastrukturen fungerar under huven).
Inga nödvändiga prenumerationsbehörigheter för att skapa Azure Synapse-relaterade resurser.
Inget behov av SQL-poolkvoter.

Nackdelar:

Ett beständiga Hive-metaarkiv saknas. Serverlös Spark-beräkning stöder endast minnesintern Spark SQL.
Inga tillgängliga tabeller eller databaser.
Azure Purview-integrering saknas.
Inga tillgängliga länkade tjänster.
Färre datakällor och anslutningsappar.
Ingen konfiguration på poolnivå.
Ingen bibliotekshantering på poolnivå.
Endast partiellt stöd för mssparkutils.

Konfiguration av nätverk

Om du vill använda nätverksisolering med Azure Machine Learning och serverlös Spark-beräkning använder du ett hanterat virtuellt nätverk.

Inaktivitetsperioder och nedrullningsmekanism

Vid den första starten kan en serverlös Spark-beräkningsresurs (kallstart) behöva tre till fem minuter för att starta själva Spark-sessionen. Den automatiserade serverlösa Spark-beräkningsetablering som backas upp av Azure Synapse orsakar den här fördröjningen. När den serverlösa Spark-beräkningen har etablerats och en Apache Spark-session startar, kommer efterföljande kodkörningar (varm start) inte att uppleva den här fördröjningen.

Spark-sessionskonfigurationen erbjuder ett alternativ som definierar en tidsgräns för sessioner (i minuter). Spark-sessionen avslutas efter en inaktivitetsperiod som överskrider den användardefinierade tidsgränsen. Om en annan Spark-session inte startar under de följande 10 minuterna kommer resurser som etablerats för den serverlösa Spark-beräkningen att avbrytas.

När den serverlösa Spark-beräkningsresursens nedrullning sker kräver inlämning av nästa jobb en kall start. Nästa visualisering visar vissa scenarier för sessions-inaktivitetsperiod och klusterrivning.

Conda-paket på sessionsnivå

En YAML-fil för Conda-beroende kan definiera många Conda-paket på sessionsnivå i en sessionskonfiguration. En session överskrider tidsgränsen om den behöver mer än 15 minuter för att installera Conda-paketen som definierats i YAML-filen. Det blir viktigt att först kontrollera om ett obligatoriskt paket redan är tillgängligt i Azure Synapse-basavbildningen. För att göra detta bör användarna följa länken för att fastställa vilka paket som är tillgängliga i basavbildningen för den Apache Spark-version som används:

Viktigt!

Azure Synapse Runtime för Apache Spark: Meddelanden

Azure Synapse Runtime för Apache Spark 3.2:
- EOLA-meddelandedatum: 8 juli 2023
- Supportdatum: 8 juli 2024. Efter det här datumet inaktiveras körningen.
För fortsatt support och optimala prestanda rekommenderar vi att du migrerar till

Kommentar

För ett Conda-paket på sessionsnivå:

kallstarten behöver cirka tio till femton minuter.
Den varma starten, med samma Conda-paket, behöver ungefär en minut.
Den varma starten, med ett annat Conda-paket, kommer också att behöva cirka tio till femton minuter.
Om paketet som du installerar är stort eller behöver en lång installationstid kan det påverka starttiden för Spark-instansen.
Det går inte att ändra versionen PySpark, Python, Scala/Java, .NET eller Spark.
Docker-avbildningar stöds inte.

Förbättra sessionens kalla starttid när du använder Conda-paket på sessionsnivå

Du kan förbättra spark-sessionens kalla starttid genom att ange konfigurationsvariabeln spark.hadoop.aml.enable_cache till true. Sessionens kallstart med Conda-paket på sessionsnivå tar vanligtvis 10 till 15 minuter när sessionen startar för första gången. Efterföljande kallstarter tar dock tre till fem minuter. Definiera konfigurationsvariabeln i användargränssnittet Konfigurera session under Konfigurationsinställningar.

Bifogad Synapse Spark-pool

En Spark-pool som skapats på en Azure Synapse-arbetsyta blir tillgänglig på Azure Machine Learning-arbetsytan med den anslutna Synapse Spark-poolen. Det här alternativet kan vara lämpligt för användare som vill återanvända en befintlig Synapse Spark-pool.

En bifogad Synapse Spark-pool till en Azure Machine Learning-arbetsyta kräver andra steg innan du kan använda poolen i Azure Machine Learning för:

En ansluten Synapse Spark-pool ger åtkomst till inbyggda Azure Synapse-funktioner. Användaren ansvarar för etablering, anslutning, konfiguration och hantering av Synapse Spark-pooler.

Spark-sessionskonfigurationen för en ansluten Synapse Spark-pool erbjuder också ett alternativ för att definiera en sessionstimeout (i minuter). Tidsgränsbeteendet för sessionen liknar beskrivningen i föregående avsnitt, förutom att de associerade resurserna aldrig rivs ned efter tidsgränsen för sessionen.

Definiera Spark-klusterstorlek

I Azure Machine Learning Spark-jobb kan du definiera Spark-klusterstorleken med tre parametervärden:

Antal utförare
Körskärnor
Körminne

Du bör betrakta en Azure Machine Learning Apache Spark-köre som likvärdig med Azure Spark-arbetsnoder. Ett exempel kan förklara dessa parametrar. Anta att du har definierat antalet utförare som 6 (motsvarande sex arbetsnoder), antalet körkärnor som 4 och körminnet som 28 GB. Ditt Spark-jobb har sedan åtkomst till ett kluster med totalt 24 kärnor och 168 GB minne.

Säkerställa resursåtkomst för Spark-jobb

För att få åtkomst till data och andra resurser kan ett Spark-jobb använda antingen en hanterad identitet eller en användaridentitetsgenomströmning. Den här tabellen sammanfattar de mekanismer som Spark-jobb använder för att komma åt resurser.

Spark-pool	Identiteter som stöds	Standardidentitet
Serverlös Spark-beräkning	Användaridentitet, användartilldelad hanterad identitet kopplad till arbetsytan	Användaridentitet
Bifogad Synapse Spark-pool	Användaridentitet, användartilldelad hanterad identitet kopplad till den anslutna Synapse Spark-poolen, systemtilldelad hanterad identitet för den anslutna Synapse Spark-poolen	Systemtilldelad hanterad identitet för den anslutna Synapse Spark-poolen

I den här artikeln beskrivs resursåtkomst för Spark-jobb. I en notebook-session använder både den serverlösa Spark-beräkningen och den anslutna Synapse Spark-poolen användaridentitetsgenomströmning för dataåtkomst under interaktiv dataomvandling.