Anpassa din befintliga Apache Spark-kod för Azure Databricks

Den här artikeln beskriver de ändringar som krävs för att anpassa befintliga Apache Spark-arbetsbelastningar som ska köras på Azure Databricks. Oavsett om du flyttar till Azure Databricks från ett lokalt kluster, anpassad molnbaserad infrastruktur eller ett annat Apache Spark-erbjudande för företag kräver de flesta arbetsbelastningar bara några ändringar för att komma in i produktion. Azure Databricks utökar, förenklar och förbättrar prestanda för Apache Spark genom att introducera anpassade optimeringar, konfigurera och distribuera infrastruktur och underhålla beroenden i Databricks Runtime.

Viktigt!

När du uppgraderar versioner av Apache Spark kan det finnas icke-bakåtkompatibla ändringar i syntaxen. Se Viktig information om versioner och kompatibilitet för Databricks Runtime och Spark-migreringsguiden.

Ändra parquet till delta

Databricks rekommenderar att du använder Delta Lake i stället för Parquet eller ORC när du skriver data. Azure Databricks har optimerat många funktioner för effektivitet när du interagerar med tabeller som backas upp av Delta Lake, och uppgradering av data och kodformulär Parquet till Delta Lake tar bara några steg. Se Migrera en Parquet-datasjö till Delta Lake.

Eftersom Delta Lake tillhandahåller ACID-transaktionsgarantierkan du kanske förenkla arbetsflöden för att avlägsna nödlösningar inriktade på att skapa pseudo-transaktionalitet i Apache Spark-åtgärder. Exempel:

• Skapa en katalogstruktur eller partitioneringsstrategi som gör att alla filer från en viss åtgärd kan identifieras samtidigt som en del av en partition.
• Konfigurera eller förlita sig på metaarkivet för att lägga till transaktionalitet för hur nya data identifieras.
• Använd MSCK repair för att registrera filer som skrivits till en tabell till metaarkivet.
• Använda alter table add partition för att manuellt lägga till partitioner i en tabell.

Se När man ska partitionera tabeller på Azure Databricks.

Kommentar

Du kan köra arbetsbelastningar utan att uppgradera de dataformat som används, men många av de största prestandavinsterna på Azure Databricks är direkt knutna till Delta Lake.

Kompilera om Apache Spark-kod med Databricks Runtime-kompatibla bibliotek

Varje version av Databricks Runtime är förkonfigurerad med många av de bibliotek som krävs i Apache Spark-program. Du kan installera ytterligare bibliotek i din beräkning efter behov, men när det är möjligt rekommenderar Databricks att du använder biblioteksversioner som paketerats i Databricks Runtime som testas för kompatibilitet. Varje Databricks Runtime-version innehåller en lista över alla installerade bibliotek. Se Viktig information om versioner och kompatibilitet för Databricks Runtime.

Ta bort SparkSession-skapandekommandon

Många äldre Apache Spark-arbetsbelastningar deklarerar uttryckligen en ny SparkSession för varje jobb. Azure Databricks skapar automatiskt en SparkContext för varje beräkningskluster och skapar en isolerad SparkSession för varje notebook-fil eller jobb som körs mot klustret. Du kan behålla möjligheten att kompilera och testa kod lokalt och sedan distribuera till Azure Databricks genom att uppgradera dessa kommandon för att använda SparkSession.builder().getOrCreate().

Ta bort terminalskriptkommandon

Apache Spark kräver att program uttryckligen deklarerar att de är slutförda med hjälp av kommandon som sys.exit() eller sc.stop(). Azure Databricks avslutar och rensar automatiskt jobb när de har slutförts, så dessa kommandon är inte nödvändiga och bör tas bort.

Azure Databricks avslutar och rensar också automatiskt arbetsbelastningar för strukturerad direktuppspelning vid körningsavslut, så att du kan ta bort awaitTermination() och liknande kommandon från strukturerade strömningsprogram.

Lita på att Azure Databricks konfigurerar klustret

Azure Databricks konfigurerar alla inställningar för drivrutinen och kören i beräkningsklustret automatiskt för att maximera återhämtning och resursanvändning. Om du tillhandahåller anpassade konfigurationer för körarna eller JVM kan det leda till lägre prestanda. Databricks rekommenderar att du endast anger Spark-konfigurationer som är nödvändiga för att kontrollera typhantering eller funktioner så att logiken förblir konsekvent.

Köra dina arbetsbelastningar

Nu när du har tagit bort mönster, kommandon och inställningar som kan störa Azure Databricks-körningen kan du köra dina arbetsbelastningar i en testmiljö och jämföra prestanda och resultat med din äldre infrastruktur. Även om många av de kunskaper som ditt team kan ha utvecklat för att felsöka och förbättra prestanda för Apache Spark-arbetsbelastningar fortfarande kan utnyttjas på Azure Databricks, kan du oftare se större vinster från att uppgradera steg för att använda nya funktioner i Apache Spark, Delta Lake eller anpassade Azure Databricks-produkter.