Storleks-, skalnings- och köbeteende för SQL-lager

I den här artikeln beskrivs hur SQL-informationslagrens storlek, köer och autoskalning fungerar.

Storleksöversikt

SQL-lager finns i serverlösa, proffs- och klassiska typer som har olika prestandafunktioner och optimeringar som kan påverka frågeprestanda i ditt lager. Se SQL-lagertyper. Databricks rekommenderar att du använder serverlösa SQL-lager när det är tillgängligt.

För alla lagertyper väljer du en klusterstorlek för dess beräkningsresurser. Att optimera din Databricks SQL-lagerstorlek innebär mer än att bara överväga datavolym eller användarantal. Frågekomplexitet och antalet samtidiga frågor är också viktiga faktorer för prestanda.

Databricks SQL-lager använder dynamisk samtidighet för att hantera dessa krav. Till skillnad från informationslager med statisk kapacitet justerar Databricks SQL beräkningsresurser i realtid för att hantera samtidiga belastningar och maximera dataflödet. Varje lagerstorlekskategori har en fast beräkningskapacitet per enhet, men systemet skalar antalet resurser för att hantera varierande krav.

Klusterstorlekar för SQL-lager

Tabellen i det här avsnittet mappar SQL-lagerklusterstorlekar till Azure Databricks-klusterdrivrutinsstorlek och antal arbetare. Drivrutinsstorleken gäller endast för pro- och klassiska SQL-lager.

Instansstorleken för alla arbetare är Standard_E8ds_v4.

Varje drivrutin och arbetare har åtta 128 GB Standard LRS-hanterade diskar anslutna. De anslutna diskarna debiteras varje timme.

Obligatorisk Azure vCPU-kvot för klassiska och pro SQL-lager

Om du vill starta ett klassiskt eller pro SQL-lager måste du ha tillräcklig Azure vCPU-kvot för Standard_E8ds_v4 instanser i ditt Azure-konto. Använd följande riktlinjer för att fastställa vilken vCPU-kvot som krävs:

Om du bara har ett eller två SQL-lager kontrollerar du att du har 8 Azure vCPU:er tillgängliga för varje kärna i klustret. Detta säkerställer att du har tillräckligt med Azure vCPU för att möjliggöra ometablering av ditt lager, vilket sker ungefär var 24:e timme. Du kan behöva öka multiplikatorn om dina SQL-lager använder automatisk skalning eller belastningsutjämning för flera kluster.

• När antalet SQL-lager ökar kan du tillåta mellan 4 och 8 Azure vCPU för varje kärna i klustret. Databricks rekommenderar att du börjar med ett större antal och övervakning för stabilitet.
• Azure vCPU:er som används av SQL-datamagasiner är utöver Azure vCPU:er som används för kluster i Data Science & Engineering eller av andra arbetsbelastningar än Databricks.

Information om hur du begär ytterligare Azure vCPU-kvot finns i Standardkvot: Öka gränserna per VM-serie i Azure-dokumentationen.

Köning och automatisk skalning för pro- och klassiska SQL-lager

Azure Databricks begränsar antalet frågor i ett kluster som tilldelats till ett SQL-lager baserat på kostnaden för att beräkna deras resultat. Uppskalningen av kluster per lager baseras på frågedataflöde, antalet inkommande frågor och köstorleken. Databricks rekommenderar ett kluster för varje 10 samtidiga frågor. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000.

Azure Databricks lägger till kluster baserat på den tid det tar att bearbeta alla frågor som körs, alla köade frågor och de inkommande frågor som förväntas under de kommande två minuterna.

• Om mindre än 2 minuter ska du inte skala upp.
• Om 2 till 6 minuter lägger du till ett kluster.
• Om 6 till 12 minuter lägger du till 2 kluster.
• Om 12 till 22 minuter lägger du till 3 kluster.

Annars lägger Azure Databricks till tre kluster plus ett kluster för varje ytterligare 15 minuter av förväntad frågebelastning.

Dessutom skalas ett lager alltid upp om en fråga väntar i 5 minuter i kön.

Om belastningen är låg i 15 minuter skalar Azure Databricks ned SQL-lagret. Det behåller tillräckligt med kluster för att hantera den högsta belastningen under de senaste 15 minuterna. Om den högsta belastningen till exempel var 25 samtidiga frågor behåller Azure Databricks tre kluster.

Serverlös autoskalning och frågeköer

Intelligent arbetsbelastningshantering (IWM) är en uppsättning funktioner som förbättrar möjligheten för serverlösa SQL-lager att bearbeta ett stort antal frågor snabbt och kostnadseffektivt. Den hanterar dynamiskt arbetsbelastningar med hjälp av maskininlärningsmodeller för att förutsäga resursbehoven för inkommande frågor samtidigt som informationslagrets tillgängliga beräkningskapacitet övervakas i realtid. Genom att spåra dessa och andra signaler i lagret kan IWM svara på ändringar i arbetsbelastningskrav.

Med den här dynamiska hanteringen kan IWM göra följande:

• Snabbt uppskalningsberäkning för att upprätthålla låg svarstid.
• Ange intagning av frågor till priser som ligger närmare maskinvarans begränsning.
• Snabbt nedskalning för att minimera kostnaderna när efterfrågan är låg.

När en fråga kommer till lagret förutsäger IWM kostnaden. Samtidigt övervakar IWM informationslagrets tillgängliga beräkningskapacitet i realtid. Med hjälp av maskininlärningsmodeller förutsäger IWM sedan om den inkommande frågan har den nödvändiga beräkningen tillgänglig för den befintliga beräkningen. Om den inte har den beräkning som behövs läggs frågan till i kön. Om den har den beräkning som behövs börjar frågan köras omedelbart.

IWM övervakar kön i realtid. Om kön inte minskar tillräckligt snabbt tilldelar autoskalning mer datorkraft automatiskt. När ny kapacitet har lagts till tas köade frågor upp till de nya beräkningsresurserna. Med serverlösa SQL-lager kan ny beräkning läggas till snabbt. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000.

Ändra storlek på ett serverlöst SQL-lager

Börja med en större storlek för ditt serverlösa SQL-lager än du tror att du behöver och ändra storlek när du testar. Börja inte med en liten storlek för ditt serverlösa SQL-lager och gå upp. I allmänhet börjar du med ett enda serverlöst SQL-lager och förlitar dig på att Azure Databricks har rätt storlek med serverlösa kluster, prioriterar arbetsbelastningar och snabba dataläsningar. Se Serverlös autoskalning och frågeköer.

• Så här minskar du frågefördröjningen för ett visst serverlöst SQL-lager:
  • Om frågor spills till disk ökar du t-shirtstorleken.
  • Om frågorna är mycket parallella ökar du t-shirtstorleken.
  • Om du kör flera frågor åt gången lägger du till fler kluster för automatisk skalning.
• Minska kostnaderna genom att försöka minska storleken utan att spilla på disken eller avsevärt öka svarstiden.

Verktyg för att övervaka och utvärdera prestanda

Använd följande verktyg för att få rätt storlek på ditt SQL-lager:

• Övervakningssida: Granska det högsta antalet frågor. Om den högsta köen vanligtvis är högre än en lägger du till kluster. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000. Se Övervaka ett SQL-lager.
• Frågehistorik. Se Frågehistorik.
• Frågeprofiler (leta efter byte som spillts till disken över 1). Se Frågeprofil.