Förstå metodtips för kluster

Slutförd

Slutligen är det dags att tänka på arbetshoran för dina Azure Databricks jobb; klustret. Som du kanske kommer ihåg har ingen i det här scenariot omvärderat typer och storlekar för kluster på arbetsytan under flera år. För att allokera rätt mängd och typ av klusterresurs för ett jobb behöver vi förstå hur olika typer av jobb kräver olika typer av klusterresurser.

  • Machine Learning – För att träna maskininlärningsmodeller cachelagras alla data i minnet. Överväg att använda minnesoptimerade virtuella datorer så att klustret kan dra nytta av RAM-cacheminnet. Du kan också använda lagringsoptimerade instanser för stora datamängder. Om du vill ändra storlek på klustret tar du en % av datauppsättningen → cache den → se hur mycket minne det använde → extrapolera det till resten av data.

  • Direktuppspelning – Du måste se till att bearbetningshastigheten ligger precis ovanför indatahastigheten vid hög belastning på dagen. Beroende på tider med hög indatahastighet bör du överväga att beräkna optimerade virtuella datorer för klustret för att se till att bearbetningstakten är högre än din indatahastighet.

  • Extrahering, transformering och inläsning (ETL) – I det här fallet är datastorleken och bestämma hur snabbt ett jobb måste vara en ledande indikator. Spark kräver inte alltid att data läses in i minnet för att kunna köra transformationer, men du behöver åtminstone se hur stora uppgiftsstorlekarna är på blandningar och jämföra det med det uppgiftsdataflöde du vill ha. För att analysera prestanda för dessa jobb börjar du med grunderna och kontrollerar om jobbet är av CPU, nätverk eller lokal I/O och går därifrån. Överväg att använda en virtuell dator för generell användning för dessa jobb.

  • Interaktiva arbetsbelastningar/utvecklingsarbetsbelastningar – Möjligheten för ett kluster att skala automatiskt är viktigast för dessa typer av jobb. I det här fallet är det bäst att använda funktionen Autoskalning för att hantera kostnaden för infrastrukturen.

När du bestämmer dig för rätt klusterkonfiguration bör du ha dessa viktiga designattribut för Azure Databricks (ADB)-tjänsten i åtanke:

  • Molnoptimerad: Azure Databricks är en produkt som skapats exklusivt för molnmiljöer som Azure. Det finns för närvarande inga distributioner på plats. Det förutsätter att vissa funktioner tillhandahålls av molnet, är utformade för att hålla molnpraxis och tillhandahåller molnbaserade funktioner.
  • Plattform/programvara som en tjänstabstrahion: ADB finns någonstans mellan PaaS- och SaaS-ändarna av spektrumet, beroende på hur du använder det. I båda fallen är ADB utformat för att dölja infrastrukturinformation så mycket som möjligt så att användaren kan fokusera på programutveckling. Det är till exempel inte ett IaaS-erbjudande som exponerar operativsystemets kernel för dig.
  • Hanterad tjänst: ADB garanterar ett serviceavtal med 99,95 % drifttid. Det finns ett stort team med dedikerad personal som övervakar olika aspekter av hälsotillståndet och får aviseringar när något går fel. Den körs som en webbplats som alltid är på och Microsofts och Databricks systemdriftsteam strävar efter att minimera eventuella driftstopp.

Dessa tre attribut gör att ADB skiljer sig från andra Spark-plattformar som HDP, CDH, Mesos osv. som är utformade för lokala datacenter och ger användaren fullständig kontroll över maskinvaran. Konceptet med ett kluster är därför unikt i Azure Databricks. Till skillnad från YARN- eller Mesos-kluster, som bara är en samling arbetsdatorer som väntar på att ett program ska schemaläggas på dem, har kluster i ADB ett förkonfigurerat Spark-program. ADB skickar alla efterföljande användarbegäranden som notebook-kommandon, SQL-frågor, Java JAR-jobb osv. till den här ursprungliga appen för körning.

Under omfattar Databricks-kluster den fristående Spark-resurstilldelningen.

När det gäller taxonomi delas ADB-kluster in längs begreppen "typ" och "läge". Det finns två typer _ av ADB-kluster, beroende på hur de skapas. Kluster som skapas med hjälp av användargränssnittet och kluster-API:et kallas interaktiva kluster, medan de som skapas med jobb-API kallas jobbkluster. Dessutom kan varje kluster ha två _lägen**: Standard och hög samtidighet. Oavsett typ eller läge kan alla kluster i Azure Databricks skalas automatiskt för att matcha arbetsbelastningen med hjälp av en funktion som kallas autoskalning.

Utöver autoskalningsfunktioner kan du använda automatisk avslutning där det är tillämpligt (t.ex. auto-avslutning är inte meningsfullt om du behöver ett kluster för dataanalys av flera användare nästan hela dagen osv.).

Välja typ av virtuell dator

Olika typer av Azure VM-instanser

Beräkningsoptimerad Minnesoptimerad Storage Optimerad Generell användning
FS
  • Haswell-processor (Skylake stöds inte ännu)
  • 1 kärna ~ 2 GB RAM-minne
  • SSD Storage: 1 kärna ~ 16 GB
DSv2
  • Haswell-processor
  • 1 kärna ~ 7 GB RAM
  • SSD Storage: 1 kärna ~ 14 GB
L
  • 1 kärna ~ 8 GB RAM-minne
  • SSD Storage: 1 kärna ~ 170 GB
  • Pris: 0,156
DSv2 och DSv3
  • DSv2 – 1 kärna ~ 3,5 GB RAM
  • DSv3 – 1 kärna ~ 4 GB RAM
  • SSD-Storage:
    • DSv2 – 1 kärna ~ 7 GB
    • DSv3 – 1 kärna ~ 8 GB
H
  • Höga prestanda
  • 1 kärna ~ 7 GB RAM
  • SSD Storage: 1 kärna ~ 125 GB
ESv3
  • Höga prestanda (Broadwell-processor)
  • 1 kärna ~ 8 GB RAM-minne
  • SSD Storage: 1 kärna ~ 16 GB

Startpunkter för klusterändring

Få rätt klusterstorlek genom iterativ prestandatestning

Det går inte att förutsäga rätt klusterstorlek utan att utveckla programmet eftersom Spark och Azure Databricks använder flera tekniker för att förbättra klusteranvändningen. Den breda metod du bör följa för storleksändring är:

  1. Utveckla på ett medelstort kluster med 2–8 noder, med virtuella datorer som matchas mot arbetsbelastningsklassen enligt tidigare förklaring.
  2. När du uppfyller funktionskraven kör du ett test från början till slut på större representativa data vid mätning av processor, minne och I/O som används av klustret på aggregeringsnivå.
  3. Optimera klustret för att ta bort flaskhalsar som hittades i steg 2
    • CPU-bunden: lägg till fler kärnor genom att lägga till fler noder
    • Nätverksbunden: Använd färre, större SSD-datorer för att minska nätverksstorleken och förbättra fjärrläsningsprestanda
    • Disk-I/O-bunden: Om jobb spiller till disk använder du virtuella datorer med mer minne.

Upprepa steg 2 och 3 genom att lägga till noder och/eller utvärdera olika virtuella datorer tills alla uppenbara flaskhalsar har åtgärdats.

Genom att utföra de här stegen får du hjälp att komma fram till en baslinjeklusterstorlek som kan uppfylla serviceavtalet för en delmängd av data. I teorin har Spark-jobb, precis som jobb i andra dataintensiva ramverk (Hadoop) linjär skalning. Om det till exempel krävs 5 noder för att uppfylla serviceavtalet på en datauppsättning på 100 TB och produktionsdata är cirka 1PB kommer prod-klustret troligen att vara cirka 50 noder i storlek. Du kan använda den här delen av kuvertberäkningen som en första gissning för att göra kapacitetsplanering. Det finns dock scenarier där Spark-jobb inte skalas linjärt. I vissa fall beror detta på att stora mängder shuffle lägger till en exponentiell synkroniseringskostnad (förklaras härnäst), men det kan också finnas andra orsaker. För att förfina den första uppskattningen och få ett mer exakt antal noder rekommenderar vi att du upprepar den här processen 3–4 gånger med allt större datauppsättningsstorlekar, till exempel 5 %, 10 %, 15 %, 30 %, osv. Processens övergripande precision beror på hur nära testdata matchar den levande arbetsbelastningen både i typ och storlek.

Tumregler

  • Färre stora instanser > fler små instanser
    • Minska nätverksblandning; Databricks har 1 utförare/dator
    • Gäller främst batch-ETL (för strömning kan man börja med mindre instanser beroende på omvandlingens komplexitet)
    • Inte inställt i sten, och omvänd skulle vara meningsfullt i många fall – så storleksändring är viktigt
  • Storlek baserat på antalet uppgifter från början, justera senare
    • Kör jobbet med ett litet kluster för att få en uppfattning om antal uppgifter (använd 2–3 x aktiviteter per kärna för grundläggande storleksändring)
  • Välj baserat på arbetsbelastning (börja förmodligen med F-serien eller DSv2):
    • ETL med fullständiga filgenomsökningar och ingen återanvändning av data – F/DSv2
    • ML arbetsbelastning med cachelagring av data – DSv2/F
    • Dataanalys – L
    • Direktuppspelning – F

Arbetsbelastning kräver cachelagring (t.ex. maskininlärning)

  • Titta på Storage i Spark-användargränssnittet för att se om hela träningsdatauppsättningen cachelagras
    • Fullständigt cachelagrat med utrymme att spara > färre instanser
    • Delvis cachelagrad
      • Nästan cachelagrat? -> öka klusterstorleken
      • Inte ens nära cachelagrad -> Överväg L-serien eller DSv2-minnesoptimerad
    • Kontrollera om persist är MEMORY_ONLY eller MEMORY_AND_DISK
    • Spill till disk med SSD är inte så dåligt
  • Är det fortfarande inte tillräckligt bra? Följ stegen i nästa avsnitt

ETL- och analysarbetsbelastningar

  • Är vi beräkningsbundna?
    • Kontrollera CPU-användning (Ganglia-mått kommer till Azure Databricks snart)
    • Det enda sättet att göra snabbare är fler kärnor
  • Är vi nätverksbundna?
    • Sök efter höga toppar innan beräkningstunga steg
    • Använd större/färre datorer för att minska blandning
    • Använda en SSD-baserad instans för snabbare fjärrläsningar
  • Spiller vi massor?
    • Kontrollera SQL spark (föraggregering före blandningar är vanliga att spilla)
  • Använda L-serien
  • Eller använd mer minne

Ytterligare överväganden