Metodtips för prestandaeffektivitet

Den här artikeln beskriver metodtips för prestandaeffektivitet, ordnade efter arkitekturprinciper som anges i följande avsnitt.

1. Vertikal skalning, horisontell skalning och linjär skalbarhet

Innan vi går in på metodtipsen ska vi titta på några distribuerade beräkningsbegrepp: horisontell skalning, vertikal skalning och linjär skalbarhet.

• Lodrät skalning: Skala lodrätt genom att lägga till eller ta bort resurser från en enda dator, vanligtvis processorer, minne eller GPU:er. Det innebär vanligtvis att du stoppar arbetsbelastningen, flyttar den till en större dator och startar om den. Det finns gränser för vertikal skalning: Det kanske inte finns någon större dator, eller så kan priset på nästa större dator vara oöverkomligt.
• Horisontell skalning: Skala vågrätt genom att lägga till eller ta bort noder från ett distribuerat system. När gränserna för vertikal skalning uppnås är lösningen att skala horisontellt: Distribuerad databehandling använder system med flera datorer (kallas kluster) för att köra arbetsbelastningar. Det är viktigt att förstå att för att detta ska vara möjligt måste arbetsbelastningarna förberedas för parallell körning, vilket stöds av motorerna i Databricks Data Intelligence Platform, Apache Spark och Photon. På så sätt kan flera billiga datorer kombineras till ett större databehandlingssystem. När fler beräkningsresurser behövs lägger horisontell skalning till fler noder i klustret och tar bort dem när de inte längre behövs. Även om det tekniskt sett inte finns någon gräns (och Spark-motorn gör den komplexa delen av belastningsutjämningen), ökar ett stort antal noder hanteringskomplexiteten.
• Linjär skalbarhet, vilket innebär att relationen mellan dataflöde och resurser som används är linjär när du lägger till fler resurser i ett system. Detta är endast möjligt om de parallella uppgifterna är oberoende. Annars krävs mellanliggande resultat på en uppsättning noder på en annan uppsättning noder i klustret för ytterligare beräkning. Det här datautbytet mellan noder innebär att resultaten överförs via nätverket från en uppsättning noder till en annan uppsättning noder, vilket tar lång tid. I allmänhet har distribuerad databehandling vissa kostnader för att hantera distribution och utbyte av data. Därför kan små arbetsbelastningar för datauppsättningar som kan analyseras på en enskild nod vara ännu långsammare när de körs i ett distribuerat system. Databricks Data Intelligence Platform tillhandahåller flexibel databehandling (enskild nod och distribuerad) för att uppfylla de unika behoven för dina arbetsbelastningar.

2. Använd serverlösa arkitekturer

Använda serverlös beräkning

Med serverlös beräkning på Databricks Data Intelligence Platform körs beräkningslagret i kundens Azure Databricks-konto. Tjänsterna hanteras fullständigt och förbättras kontinuerligt av Databricks. Förutom att kunderna bara betalar för det de använder resulterar detta i förbättrad produktivitet:

• Molnadministratörer behöver inte längre hantera komplexa molnmiljöer, till exempel att justera kvoter, skapa och underhålla nätverksresurser och ansluta till faktureringskällor. De kan fokusera sin tid på projekt med högre värde i stället för att hantera molnkomponenter på låg nivå.
• Användare drar nytta av nästan noll svarstid för klusterstart och förbättrad samtidighet i frågor.

Databricks tillhandahåller hanterade tjänster för olika arbetsbelastningar:

• Serverlösa SQL-lager för SQL-arbetsbelastningar

  Arbetsyteadministratörer kan skapa serverlösa SQL-lager som möjliggör omedelbar beräkning och hanteras av Databricks. Använd dem med Databricks SQL-frågor precis som vanligt med de ursprungliga Databricks SQL-lageren. Serverlös beräkning levereras med en mycket snabb starttid för SQL-lager och infrastrukturen hanteras och optimeras av Databricks.

• Serverlösa jobb för effektiva och tillförlitliga arbetsflöden

  Med serverlös beräkning för jobb kan du köra ditt Databricks-jobb utan att konfigurera och distribuera infrastrukturen. Med serverlös beräkning fokuserar du på att implementera dina databearbetnings- och analyspipelines, och Databricks hanterar effektivt beräkningsresurser, inklusive optimering och skalning av beräkning för dina arbetsbelastningar. Automatisk skalning och foton aktiveras automatiskt för beräkningsresurserna som kör jobbet.

  Du kan övervaka kostnaden för jobb som använder serverlös beräkning för jobb genom att fråga den fakturerbara användningssystemtabellen.

• Serverlös beräkning för notebook-filer

  Om din arbetsyta är aktiverad för serverlös interaktiv beräkning har alla användare på arbetsytan åtkomst till serverlös beräkning för notebook-filer. Inga ytterligare behörigheter krävs.

Använda en tjänst i företagsklassmodell

Mosaic AI Model Serving tillhandahåller ett enhetligt gränssnitt för att distribuera, styra och fråga AI-modeller. Varje modell som du hanterar är tillgänglig som ett REST-API som du kan integrera i ditt webb- eller klientprogram.

Modellservering ger en tjänst med hög tillgänglighet och låg svarstid för distribution av modeller. Tjänsten skalas automatiskt upp eller ned för att möta ändringar i efterfrågan, vilket sparar infrastrukturkostnader samtidigt som svarstidsprestandan optimeras. Den här funktionen använder serverlös beräkning.

3. Utforma arbetsbelastningar för prestanda

Förstå dina datainmatnings- och åtkomstmönster

Ur ett prestandaperspektiv fungerar dataåtkomstmönster – till exempel "aggregeringar kontra punktåtkomst" eller "genomsökning kontra sökning" – på olika sätt beroende på datastorleken. Stora filer är mer effektiva för genomsökningsfrågor och mindre filer är bättre för sökningar eftersom du behöver läsa mindre data för att hitta de specifika raderna.

För inmatningsmönster är det vanligt att använda DML-instruktioner. DML-instruktioner är mest högpresterande när data klustras och du kan helt enkelt isolera dataavsnittet. Det är viktigt att hålla data klustrade och isolatbara under inmatningen: överväg att behålla en naturlig tidssorteringsordning och tillämpa så många filter som möjligt på inmatningsmåltabellen. För arbetsbelastningar med endast tillägg och överskrivning finns det inte mycket att tänka på eftersom det är en relativt billig åtgärd.

Inmatnings- och åtkomstmönster pekar ofta på en uppenbar datalayout och klustring. Om inte, bestäm vad som är viktigare för din verksamhet och fokusera på hur du bättre kan uppnå det målet.

Använd parallell beräkning där det är fördelaktigt

Tid till värde är en viktig dimension när du arbetar med data. Många användningsfall kan enkelt implementeras på en enda dator (små data, få och enkla beräkningssteg), men det finns ofta användningsfall som behöver bearbeta stora datamängder, har långa körningstider på grund av komplicerade algoritmer eller behöver upprepas 100- och 1000-talets gånger.

Klustermiljön på Databricks-plattformen är en bra miljö för att effektivt distribuera dessa arbetsbelastningar. Den parallelliserar automatiskt SQL-frågor över alla noder i ett kluster och tillhandahåller bibliotek som Python och Scala kan göra på samma sätt. Under huven analyserar motorerna Apache Spark- och Photon-motorerna frågorna, fastställer det optimala sättet för parallell körning och hanterar den distribuerade körningen på ett motståndskraftigt sätt.

På samma sätt som batchuppgifter distribuerar Structured Streaming strömmande jobb över klustret för bästa prestanda.

Ett av de enklaste sätten att använda parallell databehandling är med Delta Live Tables. Du deklarerar ett jobbs uppgifter och beroenden i SQL eller Python, och sedan hanterar Delta Live Tables körningsplanering, effektiv infrastrukturkonfiguration, jobbkörning och övervakning.

För dataforskare är Pandas ett Python-paket som tillhandahåller lätthanterade datastrukturer och dataanalysverktyg för programmeringsspråket Python. Pandas skalar dock inte ut till stordata. Pandas API på Spark fyller det här tomrummet genom att tillhandahålla pandas motsvarande API:er som fungerar på Apache Spark.

Dessutom levereras plattformen med parallelliserade maskininlärningsalgoritmer i standardbiblioteket för maskininlärning MLlib. Den stöder out-of-the-box multi-GPU-användning. Djupinlärning kan också parallelliseras med DeepSpeed Distributor eller TorchDistributor.

Analysera hela körningskedjan

De flesta pipelines eller förbrukningsmönster omfattar en kedja av system. Med BI-verktyg påverkas till exempel prestandan av flera faktorer:

• Själva BI-verktyget.
• Anslutningsappen som ansluter BI-verktyget och SQL-motorn.
• DEN SQL-motor som BI-verktyget skickar frågan till.

För bästa prestanda i klassen måste hela kedjan beaktas och väljas/finjusteras för bästa prestanda.

Föredrar större kluster

Planera för större kluster, särskilt om arbetsbelastningen skalar linjärt. I det här fallet är det inte dyrare att använda ett stort kluster för en arbetsbelastning än att använda ett mindre kluster. Det är bara snabbare. Nyckeln är att du hyr klustret under arbetsbelastningens varaktighet. Så om du startar två arbetskluster och det tar en timme betalar du för dessa arbetare under hela timmen. På samma sätt, om du startar ett fyra arbetskluster och det bara tar en halvtimme (det är här linjär skalbarhet kommer in), är kostnaderna desamma. Om kostnaderna är den primära drivrutinen med ett mycket flexibelt serviceavtal är ett autoskalningskluster vanligtvis det billigaste, men inte nödvändigtvis det snabbaste.

Kommentar

Att föredra stora kluster krävs inte för serverlös beräkning eftersom det automatiskt hanterar kluster.

Använda inbyggda Spark-åtgärder

Användardefinierade funktioner (UDF: er) är ett bra sätt att utöka funktionerna i Spark SQL. Använd dock inte Python- eller Scala-UDF:er om det finns en intern funktion:

• Spark SQL
• PySpark

Orsaker:

• Serialisering krävs för att överföra data mellan Python och Spark. Detta gör frågor betydligt långsammare.
• Ökade ansträngningar för att implementera och testa funktioner som redan finns på plattformen.

Om inbyggda funktioner saknas och bör implementeras som Python-UDF:er använder du Pandas UDF:er. Apache Arrow säkerställer att data flyttas effektivt fram och tillbaka mellan Spark och Python.

Använda inbyggda plattformsmotorer

Photon är motorn i Azure Databricks som ger snabba frågeprestanda till låg kostnad – från datainmatning, ETL, strömning, datavetenskap och interaktiva frågor – direkt på din datasjö. Photon är kompatibelt med Apache Spark-API:er, så det är lika enkelt att komma igång som att aktivera det – inga kodändringar och ingen inlåsning.

Photon är en del av en högpresterande körning som kör dina befintliga SQL- och DataFrame API-anrop snabbare, vilket minskar den totala kostnaden per arbetsbelastning. Foton används som standard i Databricks SQL-lager.

Förstå maskinvaru- och arbetsbelastningstypen

Alla virtuella molndatorer skapas inte lika. De olika maskinfamiljerna som erbjuds av molnleverantörer är alla tillräckligt olika för att spela roll. Det finns uppenbara skillnader – RAM-minne och kärnor – och mer subtila skillnader – processortyp och -generering, garantier för nätverksbandbredd och lokal höghastighetslagring jämfört med lokal disk jämfört med fjärrdisk. Det finns också skillnader på "spot"-marknaderna. Dessa bör förstås innan du bestämmer dig för den bästa VM-typen för din arbetsbelastning.

Kommentar

Detta krävs inte för serverlös beräkning eftersom serverlös beräkning automatiskt hanterar kluster.

Använda cachelagring

Cachelagring lagrar data som används ofta i ett snabbare medium, vilket minskar den tid som krävs för att hämta dem jämfört med att komma åt den ursprungliga datakällan. Detta resulterar i kortare svarstider och snabbare svarstider, vilket avsevärt kan förbättra programmets övergripande prestanda och användarupplevelse. Genom att minimera antalet begäranden till den ursprungliga datakällan kan cachelagring minska kostnaderna för nätverkstrafik och dataöverföring. Den här effektivitetsvinsten kan vara särskilt fördelaktig för program som förlitar sig på externa API:er eller betala per användning-databaser. Det kan hjälpa till att sprida belastningen jämnare över systemet, vilket förhindrar flaskhalsar och potentiell stilleståndstid.

Det finns flera typer av cachelagring i Azure Databricks. Här är egenskaperna för varje typ:

• Använda diskcache

  Diskcachen (kallades tidigare "Delta cache") lagrar kopior av fjärrdata på de lokala diskarna (till exempel SSD) för de virtuella datorerna. Det kan förbättra prestandan för ett brett spektrum av frågor men kan inte användas för att lagra resultatet av godtyckliga underfrågor. Diskcacheminnet identifierar automatiskt när datafiler skapas eller tas bort och uppdaterar dess innehåll i enlighet med detta. Det rekommenderade (och enklaste) sättet att använda diskcachelagring är att välja en arbetstyp med SSD-volymer när du konfigurerar klustret. Sådana arbetare är aktiverade och konfigurerade för diskcachelagring.

• Undvik Spark-cachelagring

  Spark-cachen (med hjälp .persist() av och .unpersist()) kan lagra resultatet av underfrågor och data som lagras i andra format än Parquet (till exempel CSV, JSON och ORC). Men om den används på fel platser i en fråga kan den förbruka allt minne och kan till och med sakta ned frågor avsevärt. Som tumregel bör du undvika Spark-cachelagring om du inte vet exakt vad effekten blir.

• Cacheminne för frågeresultat

  Per klustercachelagring av frågeresultat för alla frågor via SQL-lager. Om du vill dra nytta av cachelagring av frågeresultat fokuserar du på deterministiska frågor som till exempel inte använder predikat som = NOW(). När en fråga är deterministisk och underliggande data är i Delta-format och oförändrade returnerar SQL Warehouses resultatet direkt från frågeresultatcachen.

• Cachelagring av Databricks SQL-gränssnitt

  Cachelagring per användare av alla frågor och äldre instrumentpanelsresultat resulterar i Databricks SQL-användargränssnittet.

Använd komprimering

Delta Lake på Azure Databricks kan förbättra hastigheten för att läsa frågor från en tabell. Ett sätt är att slå samman små filer i större filer. Du utlöser komprimering genom att köra kommandot OPTIMIZE. Se Optimera datafillayout.

Delta Lake innehåller alternativ för att automatiskt konfigurera målfilstorleken för skrivningar och för OPTIMIZE åtgärder. Databricks justerar automatiskt många av de här inställningarna och aktiverar funktioner som automatiskt förbättrar tabellprestanda genom att söka efter filer med rätt storlek:

• Auto compact kombinerar små filer i Delta-tabellpartitioner för att automatiskt minska små filproblem. Automatisk komprimering sker efter att en skrivning till en tabell har slutförts och körs synkront på klustret som har utfört skrivning. Automatisk komprimering komprimerar endast filer som inte har komprimerats tidigare.
• Optimerade skrivningar förbättrar filstorleken eftersom data skrivs och drar nytta av efterföljande läsningar i tabellen. Optimerade skrivningar är mest effektiva för partitionerade tabeller, eftersom de minskar antalet små filer som skrivs till varje partition.

Mer information finns i Konfigurera Delta Lake för att kontrollera datafilstorleken .

Använda data som hoppar över

Datahoppning kan avsevärt förbättra frågeprestanda genom att hoppa över data som inte uppfyller frågevillkoren. Detta minskar mängden data som behöver läsas och bearbetas, vilket leder till snabbare frågekörningstider.

För att uppnå detta samlas datahoppningsinformation automatiskt in när du skriver data till en Delta-tabell (som standard samlar Delta Lake på Azure Databricks in statistik över de första 32 kolumnerna som definierats i tabellschemat). Delta Lake på Azure Databricks använder den här informationen (lägsta och högsta värden) vid frågetillfället för att tillhandahålla snabbare frågor. Se Hoppa över data för Delta Lake.

Följande tekniker kan användas för att hoppa över data:

• Z-ordering, en teknik för att organisera relaterad information i samma filuppsättning. Den här samlokaliteten används automatiskt på Azure Databricks av Delta Lake-datahoppande algoritmer. Det här beteendet minskar avsevärt mängden data som Delta Lake måste läsa.

• Liquid-klustring förenklar beslut om datalayout och optimerar frågeprestanda. Den ersätter partitionering och z-beställning över tid. Databricks rekommenderar flytande klustring för alla nya deltatabeller. Flytande klustring ger flexibiliteten att omdefiniera klustringsnycklar utan att skriva om befintliga data, vilket gör att datalayouter kan utvecklas med analytiska behov över tid. Databricks rekommenderar flytande klustring för alla nya deltatabeller.

  Tabeller med följande egenskaper drar nytta av flytande klustring:

  • Filtreras efter kolumner med hög kardinalitet.
  • Med betydligt skev datadistribution.
  • Det växer snabbt och kräver underhåll och justering.
  • Med samtidiga skrivbegäranden.
  • Med åtkomstmönster som ändras över tid.
  • Där en typisk partitionsnyckel kan lämna tabellen med för många eller för få partitioner.

Mer information och tekniker finns i Den omfattande guiden för att optimera Databricks, Spark och Delta Lake-arbetsbelastningar.

Aktivera förutsägelseoptimering för Delta Lake

Förutsägande optimering tar bort behovet av att manuellt hantera underhållsåtgärder för Delta-tabeller i Databricks. Med förutsägande optimering aktiverat identifierar Databricks automatiskt tabeller som skulle dra nytta av underhållsåtgärder och kör dem för användaren. Underhållsåtgärder körs bara efter behov, vilket eliminerar både onödiga körningar för underhållsåtgärder och den börda som är kopplad till spårnings- och felsökningsprestanda.

Undvik överpartitionering

Tidigare var partitionering det vanligaste sättet att hoppa över data. Partitioneringen är dock statisk och visar sig som en filsystemhierarki. Det finns inget enkelt sätt att ändra partitioner när åtkomstmönstren ändras över tid. Ofta leder partitionering till överpartitionering – med andra ord för många partitioner med för små filer, vilket resulterar i dåliga frågeprestanda.

Databricks rekommenderar att du inte partitionera tabeller under 1 TB i storlek och att du bara partitioneras efter en kolumn om du förväntar dig att data i varje partition ska vara minst 1 GB.

Under tiden är ett bättre val än partitionering Z-beställning eller nyare Liquid Clustering (se ovan).

Optimera kopplingsprestanda

• Överväg optimering av intervallkoppling.

  En intervallkoppling inträffar när två relationer kopplas med hjälp av en punkt i intervall- eller intervall överlappningsvillkor. Stöd för range join-optimering i Databricks Runtime kan ge bättre frågeprestanda, men kräver noggrann manuell justering.

• Använd anpassningsbar frågekörning.

  Adaptiv frågekörning (AQE) är en omoptimering av frågor som sker under frågekörningen. Den har 4 huvudfunktioner:

  • Ändrar sorteringskoppling dynamiskt till sändningshashkoppling.
  • Sammansejsar partitioner dynamiskt efter shuffle-utbyte.
  • Hanterar skevhet dynamiskt i sorteringskoppling och shuffle-hashkoppling.
  • Identifierar och sprider tomma relationer dynamiskt.

  Vi rekommenderar att du behåller AQE aktiverat. Olika funktioner kan konfigureras separat.

Mer information finns i den omfattande guiden för att optimera arbetsbelastningar i Databricks, Spark och Delta Lake.

Kör analysera tabell för att samla in tabellstatistik

Instruktionen ANALYZE TABLE samlar in statistik om tabeller i ett angivet schema. Den här statistiken används av frågeoptimeraren för att generera en optimal frågeplan, välja rätt kopplingstyp, välja rätt byggsida i en hash-koppling eller kalibrera kopplingsordningen i en flervägskoppling.

Prediktiv optimering kör automatiskt kommandot ANALYZE (offentlig förhandsversion) för att samla in statistik i Unity Catalog-hanterade tabeller. Databricks rekommenderar att du aktiverar förutsägande optimering för alla hanterade Unity Catalog-tabeller för att förenkla dataunderhållet och minska lagringskostnaderna. Se Förutsägelseoptimering för hanterade Unity Catalog-tabeller.

4. Kör prestandatestning i utvecklingsomfånget

Testa data som är representativa för produktionsdata

Kör prestandatestning på produktionsdata (skrivskyddade) eller liknande data. När du använder liknande data bör egenskaper som volym, fillayout och datasnedvridning likna produktionsdata, eftersom detta har en betydande inverkan på prestandan.

Överväg att förvärma resurser

Oavsett fråge- och dataformat är den första frågan i ett kluster alltid långsammare än efterföljande frågor. Det beror på att alla olika undersystem startar och läser alla data de behöver. Förvarning har en betydande inverkan på prestandatestresultat:

• Förkrigskluster: Klusterresurser måste initieras på flera lager. Det går att förbereda kluster: Databricks-pooler är en uppsättning inaktiva instanser som är redo att användas. När klusternoder skapas med hjälp av dessa inaktiva instanser minskas tiden för klusterstart och automatisk skalning.
• Förvärmda cacheminnen: När cachelagring är en del av installationen säkerställer den första körningen att data finns i cacheminnet, vilket påskyndar efterföljande jobb. Cacheminnen kan vara förvärmade genom att köra specifika frågor för att initiera cacheminnen (till exempel efter en omstart av klustret). Detta kan avsevärt förbättra prestandan för de första frågorna.

Så för att förstå beteendet för de olika scenarierna testar du prestandan för den första körningen med och utan förvarning och efterföljande körningar.

Identifiera flaskhalsar

Flaskhalsar är områden i din arbetsbelastning som kan försämra den övergripande prestandan när belastningen ökar i produktionen. Genom att identifiera dessa vid design och testning mot högre arbetsbelastningar kan du hålla arbetsbelastningarna stabila i produktionen.

5. Övervaka prestanda

Övervaka frågeprestanda

Genom att övervaka frågeprestanda kan du förstå hur resurser används av olika frågor. Du kan identifiera frågor som körs långsamt, så att du kan hitta prestandaflaskhalsar i systemet. Du kan också identifiera frågor som förbrukar betydande systemresurser, vilket kan leda till instabilitet eller stilleståndstid. Den här informationen hjälper dig att optimera resursallokering, minska avfallet och se till att resurserna används effektivt.

Databricks Data Intelligence Platform har olika övervakningsfunktioner (se Operational Excellence – Konfigurera övervakning, aviseringar och loggning), varav några kan användas för prestandaövervakning:

• Frågeprofil: Använd frågeprofilfunktionen för att felsöka prestandaflaskhalsar under frågekörningen. Det ger visualisering av varje frågeuppgift och relaterade mått, till exempel tid som spenderas, antal rader som bearbetas och minne som används.
• SQL Warehouse-övervakning: Övervaka SQL-lager genom att visa livestatistik, diagram med maximalt antal frågor, klusterdiagram som körs och tabell med frågehistorik

Övervaka strömningsarbetsbelastningar

Med strömningsövervakning kan du analysera data och identifiera problem när de uppstår, vilket ger insikter i realtid om systemets prestanda och beteende. Genom att analysera strömmande data kan du identifiera trender, mönster och möjligheter till optimering. Detta kan hjälpa dig att finjustera systemet, förbättra resursanvändningen och minska kostnaderna.

För strömningsfrågor använder du den inbyggda övervakningen av strukturerad direktuppspelning i Spark-användargränssnittet eller push-överför mått till externa tjänster med hjälp av Apache Spark Streaming Query Listener-gränssnittet.

Övervaka jobbprestanda

Jobbövervakning hjälper dig att identifiera och åtgärda problem i dina Databricks-jobb, till exempel fel, fördröjningar eller flaskhalsar i prestanda. Jobbövervakning ger insikter om jobbprestanda, så att du kan optimera resursanvändningen, minska mängden och förbättra den övergripande effektiviteten.