Storleksguide för Azure HDInsight Interaktiv fråga Cluster (Hive LLAP)

  • Artikel

Det här dokumentet beskriver storleken på HDInsight Interaktiv fråga-klustret (Hive LLAP-klustret) för en typisk arbetsbelastning för att uppnå rimlig prestanda. Observera att rekommendationerna i det här dokumentet är allmänna riktlinjer och att specifika arbetsbelastningar kan behöva justeras specifikt.

Azure Default VM Types for HDInsight Interaktiv fråga Cluster (LLAP)

Nodtyp Instans Storlek
Head D13 v2 8 vcpus, 56 GB RAM,400 GB SSD
Arbetare D14 v2 16 vcpus, 112 GB RAM, 800 GB SSD
ZooKeeper A4 v2 4 vcpus, 8 GB RAM, 40 GB SSD

Obs! Alla rekommenderade konfigurationsvärden baseras på arbetsnod av typen D14 v2

Konfiguration:

Konfigurationsnyckel Rekommenderat värde beskrivning
yarn.nodemanager.resource.memory-mb 102400 (MB) Totalt minne i MB för alla YARN-containrar på en nod
yarn.scheduler.maximum-allocation-mb 102400 (MB) Den maximala allokeringen för varje containerbegäran på RM, i MBs. Minnesbegäranden som är högre än det här värdet börjar inte gälla
yarn.scheduler.maximum-allocation-vcores 12 Det maximala antalet CPU-kärnor för varje containerbegäran i Resource Manager. Begäranden som är högre än det här värdet börjar inte gälla.
yarn.nodemanager.resource.cpu-vcores 12 Antal CPU-kärnor per NodeManager som kan allokeras för containrar.
yarn.scheduler.capacity.root.llap.capacity 85 (%) YARN-kapacitetsallokering för LLAP-kö
tez.am.resource.memory.mb 4 096 (MB) Mängden minne i MB som ska användas av tez AppMaster
hive.server2.tez.sessions.per.default.queue <number_of_worker_nodes> Antalet sessioner för varje kö med namnet i köerna hive.server2.tez.default.. Det här talet motsvarar antalet frågekoordinatorer (Tez AMs)
hive.tez.container.size 4 096 (MB) Angiven Tez-containerstorlek i MB
hive.llap.daemon.num.executors 19 Antal utförare per LLAP-daemon
hive.llap.io.threadpool.size 19 Storlek på trådpool för utförare
hive.llap.daemon.yarn.container.mb 81920 (MB) Totalt minne i MB som används av enskilda LLAP-daemoner (minne per daemon)
hive.llap.io.memory.size 242688 (MB) Cachestorlek i MB per LLAP-daemon angivet SSD-cache är aktiverat
hive.auto.convert.join.noconditionaltask.size 2048 (MB) minnesstorlek i MB för att göra kartkoppling

LLAP-arkitektur/komponenter:

`LLAP Architecture/Components`.

Storleksuppskattningar för LLAP-daemon:

1. Fastställa total YARN-minnesallokering för alla containrar på en nod

Konfiguration: yarn.nodemanager.resource.memory-mb

Det här värdet anger en maximal summa minne i MB som kan användas av YARN-containrarna på varje nod. Det angivna värdet bör vara mindre än den totala mängden fysiskt minne på noden.
Totalt minne för alla YARN-containrar på en nod = (Totalt fysiskt minne – minne för OS + andra tjänster)
Ange det här värdet till ~90 % av den tillgängliga RAM-storleken.
För D14 v2 är det rekommenderade värdet 102400 MB. 

2. Fastställa maximal mängd minne per YARN-containerbegäran

Konfiguration: yarn.scheduler.maximum-allocation-mb

Det här värdet anger den maximala allokeringen för varje containerbegäran i Resource Manager i MB. Minnesbegäranden som är högre än det angivna värdet börjar inte gälla. Resource Manager kan ge minne till containrar i steg av yarn.scheduler.minimum-allocation-mb och får inte överskrida den storlek som anges av yarn.scheduler.maximum-allocation-mb. Det angivna värdet får inte vara mer än det totala angivna minnet för alla containrar på noden som anges av yarn.nodemanager.resource.memory-mb.
För D14 v2-arbetsnoder är det rekommenderade värdet 102400 MB

3. Fastställa maximal mängd vcores per YARN-containerbegäran

Konfiguration: yarn.scheduler.maximum-allocation-vcores

Det här värdet anger det maximala antalet virtuella CPU-kärnor för varje containerbegäran i Resource Manager. Om du begär ett högre antal vcores så börjar inte det här värdet gälla. Det är en global egenskap för YARN-schemaläggaren. För LLAP-daemoncontainern kan det här värdet anges till 75 % av det totala antalet tillgängliga vcores. Återstående 25 % bör reserveras för NodeManager, DataNode och andra tjänster som körs på arbetsnoderna.
Det finns 16 vcores virtuella D14 v2-datorer och 75 % av det totala antalet 16 vcores kan användas av LLAP-daemoncontainern.
För D14 v2 är det rekommenderade värdet 12.

4. Antal samtidiga frågor

Konfiguration: hive.server2.tez.sessions.per.default.queue

Det här konfigurationsvärdet bestämmer antalet Tez-sessioner som kan startas parallellt. Dessa Tez-sessioner startas för var och en av de köer som anges av "hive.server2.tez.default.queues". Det motsvarar antalet Tez-AMs (frågekoordinatorer). Vi rekommenderar att du är samma som antalet arbetsnoder. Antalet Tez-AMs kan vara högre än antalet LLAP-daemonnoder. Tez AM:s primära ansvar är att samordna frågekörningen och tilldela frågeplansfragment till motsvarande LLAP-daemoner för körning. Behåll det här värdet som flera av många LLAP-daemonnoder för att uppnå högre dataflöde.

Standard-HDInsight-kluster har fyra LLAP-daemoner som körs på fyra arbetsnoder, så det rekommenderade värdet är 4.

Ambari UI-skjutreglage för Hive-konfigurationsvariabel hive.server2.tez.sessions.per.default.queue:

`LLAP maximum concurrent queries`.

5. Tez Container och Tez Application Master storlek

Konfiguration: tez.am.resource.memory.mb, hive.tez.container.size

tez.am.resource.memory.mb – definierar Tez-programmets huvudstorlek.
Det rekommenderade värdet är 4 096 MB.

hive.tez.container.size – definierar mängden minne som ges för Tez-containern. Det här värdet måste anges mellan YARN minsta containerstorlek (yarn.scheduler.minimum-allocation-mb) och YARN maximum container size(yarn.scheduler.maximum-allocation-mb). LLAP-daemonkörningarna använder det här värdet för att begränsa minnesanvändningen per körning.
Det rekommenderade värdet är 4 096 MB.

6. LLAP-kökapacitetsallokering

Konfiguration: yarn.scheduler.capacity.root.llap.capacity

Det här värdet anger en procentandel av kapaciteten som ges till LLAP-kön. Kapacitetsallokeringarna kan ha olika värden för olika arbetsbelastningar beroende på hur YARN-köerna konfigureras. Om din arbetsbelastning är skrivskyddad bör det fungera att ange den så hög som 90 % av kapaciteten. Men om din arbetsbelastning är en blandning av åtgärder för uppdatering/borttagning/sammanslagning med hanterade tabeller rekommenderar vi att du ger 85 % av kapaciteten för LLAP-kön. Den återstående kapaciteten på 15 % kan användas av andra uppgifter, till exempel komprimering osv. för att allokera containrar från standardkön. På så sätt kommer uppgifter i standardkön inte att beröva YARN-resurser.

För D14v2-arbetsnoder är det rekommenderade värdet för LLAP-kön 85.
(För skrivskyddade arbetsbelastningar kan den ökas upp till 90 som lämpliga.)

7. LLAP-daemoncontainerstorlek

Konfiguration: hive.llap.daemon.yarn.container.mb

LLAP-daemon körs som en YARN-container på varje arbetsnod. Den totala minnesstorleken för LLAP-daemoncontainern beror på följande faktorer:

  • Konfigurationer av YARN-containerstorlek (yarn.scheduler.minimum-allocation-mb, yarn.scheduler.maximum-allocation-mb, yarn.nodemanager.resource.memory-mb)
  • Antal Tez-datorer på en nod
  • Totalt minne som konfigurerats för alla containrar på en nod och LLAP-kökapacitet

Minne som behövs av Tez Application Masters (Tez AM) kan beräknas på följande sätt.
Tez AM fungerar som frågekoordinator och antalet Tez AMs ska konfigureras baserat på många samtidiga frågor som ska hanteras. Teoretiskt sett kan vi överväga en Tez AM per arbetsnod. Det är dock möjligt att du kan se mer än en Tez AM på en arbetsnod. I beräkningssyfte förutsätter vi en enhetlig fördelning av Tez-AMs över alla LLAP-daemonnoder/arbetsnoder. Vi rekommenderar att du har 4 GB minne per Tez AM.

Antal Tez Ams = värde som anges av Hive config hive.server2.tez.sessions.per.default.queue.
Antal LLAP-daemonnoder = som anges av env-variabeln num_llap_nodes_for_llap_daemons i Ambari-användargränssnittet.
Tez AM container size = value specified by Tez config tez.am.resource.memory.mb.

Tez AM-minne per nod = (ceil(Antal Tez AMs / Antal LLAP-daemonnoder)x Tez AM-containerstorlek**)**
För D14 v2 har standardkonfigurationen fyra Tez-AMs och fyra LLAP-daemonnoder.
Tez AM-minne per nod = (ceil(4/4) x 4 GB) = 4 GB

Totalt tillgängligt minne för LLAP-kö per arbetsnod kan beräknas på följande sätt:
Det här värdet beror på den totala mängden minne som är tillgängligt för alla YARN-containrar på en nod (yarn.nodemanager.resource.memory-mb) och den procentandel kapacitet som konfigurerats för LLAP-kön (yarn.scheduler.capacity.root.llap.capacity).
Totalt minne för LLAP-kön på arbetsnoden = Totalt tillgängligt minne för alla YARN-containrar på en nod x Procentandel kapacitet för LLAP-kön.
För D14 v2 är det här värdet (100 GB x 0,85) = 85 GB.

LLAP-daemoncontainerns storlek beräknas på följande sätt.

LLAP-daemoncontainerstorlek = (Totalt minne för LLAP-kö på en arbetsnod) – (Tez AM-minne per nod) – (Containerstorlek för Tjänsthanteraren)
Det finns bara en tjänsthanterare (programhanterare för LLAP-tjänsten) i klustret som skapas på en av arbetsnoderna. I beräkningssyfte överväger vi en tjänsthanterare per arbetsnod.
För arbetsnoden D14 v2 är HDI 4.0 – det rekommenderade värdet (85 GB – 4 GB – 1 GB)) = 80 GB

8. Fastställa antalet utförare per LLAP-daemon

Konfiguration: hive.llap.daemon.num.executors, hive.llap.io.threadpool.size

hive.llap.daemon.num.executors:
Den här konfigurationen styr antalet exekverare som kan köra uppgifter parallellt per LLAP-daemon. Det här värdet beror på antalet virtuella kärnor, mängden minne som används per exekveringar och mängden tillgängligt minne för LLAP-daemon-containern. Antalet utförare kan överprenumereras till 120 % av tillgängliga virtuella kärnor per arbetsnod. Den bör dock justeras om den inte uppfyller minneskraven baserat på minne som behövs per köre och LLAP-daemoncontainerns storlek.

Varje exekverare motsvarar en Tez-container och kan förbruka 4 GB (Tez-containerstorlek) minne. Alla utförare i LLAP-daemon delar samma heapminne. Med antagandet att inte alla exekverare kör minnesintensiva åtgärder samtidigt kan du överväga 75 % av Tez-containerstorleken (4 GB) per exekverare. På så sätt kan du öka antalet exekverare genom att ge varje exekverare mindre minne (till exempel 3 GB) för ökad parallellitet. Vi rekommenderar dock att du justerar den här inställningen för målarbetsbelastningen.

Det finns 16 virtuella kärnor på virtuella D14 v2-datorer. För D14 v2 är det rekommenderade värdet för antalet utförare (16 virtuella kärnor x 120 %) ~= 19 på varje arbetsnod med 3 GB per köre.

hive.llap.io.threadpool.size:
Det här värdet anger storleken på trådpoolen för utförare. Eftersom exekverare har åtgärdats enligt angivet är det samma som antalet exekverare per LLAP-daemon.
För D14 v2 är det rekommenderade värdet 19.

9. Fastställa llap-daemoncachestorlek

Konfiguration: hive.llap.io.memory.size

LLAP-daemoncontainerns minne består av följande komponenter;

  • Huvudrum
  • Heapminne som används av utförare (Xmx)
  • Minnesintern cache per daemon (dess minnesstorlek utanför heap, inte tillämpligt när SSD-cache är aktiverat)
  • Cachemetadatastorlek i minnet (gäller endast när SSD-cachen är aktiverad)

Utrymmesstorlek: Den här storleken anger en del av minnet utanför heapen som används för omkostnader för virtuella Java-datorer (metaområde, trådstacken, gc datastrukturer osv.). I allmänhet är den här kostnaden cirka 6 % av heapstorleken (Xmx). För att vara på den säkrare sidan kan det här värdet beräknas som 6 % av den totala LLAP-daemonminnesstorleken.
För D14 v2 är det rekommenderade värdet ceil(80 GB x 0,06) ~= 4 GB.

Heap size(Xmx): Det är mängden heapminne som är tillgängligt för alla utförare. Total heapstorlek = Antal exekverare x 3 GB
För D14 v2 är det här värdet 19 x 3 GB = 57 GB

Ambari environment variable for LLAP heap size:

`LLAP heap size`.

När SSD-cachen är inaktiverad är minnesintern cache mängden minne som finns kvar när du har tagit ut utrymmesstorlek och Heap-storlek från LLAP-daemoncontainerns storlek.

Cachestorleksberäkningen skiljer sig åt när SSD-cachen är aktiverad. Om du anger hive.llap.io.allocator.mmap = true aktiveras SSD-cachelagring. När SSD-cachen är aktiverad används en del av minnet för att lagra metadata för SSD-cachen. Metadata lagras i minnet och förväntas vara ~8 % av SSD-cachestorleken.
SSD Cache in-memory metadata size = LLAP daemon container size - (Head room + Heap size)
För D14 v2, med HDI 4.0, SSD cacheminne metadatastorlek = 80 GB - (4 GB + 57 GB) = 19 GB

Med tanke på storleken på tillgängligt minne för lagring av SSD-cachemetadata kan vi beräkna storleken på SSD-cachen som kan stödjas.
Storleken på minnesinterna metadata för SSD-cache = LLAP-daemoncontainerstorlek – (Huvudrum + Heap-storlek) = 19 GB
Storleken på SSD-cache = storleken på minnesinterna metadata för SSD-cache (19 GB) /0,08 (8 procent)

För D14 v2 och HDI 4.0 rekommenderas SSD-cachestorlek = 19 GB/0,08 ~= 237 GB

10. Justera kartkopplingsminne

Konfiguration: hive.auto.convert.join.noconditionaltask.size

Kontrollera att hive.auto.convert.join.noconditionaltask har aktiverats för att den här parametern ska börja gälla. Den här konfigurationen avgör tröskelvärdet för MapJoin-val av Hive-optimerare som anser att överprenumerering av minne från andra utförare har mer utrymme för minnesinterna hash-tabeller för att tillåta fler konverteringar av kartkopplingar. Med tanke på 3 GB per köre kan den här storleken överprenumereras till 3 GB, men en del heapminne kan också användas för sorteringsbuffertar, shuffle-buffertar osv. av de andra åtgärderna.
Så för D14 v2, med 3 GB minne per köre, rekommenderar vi att du anger det här värdet till 2 048 MB.

(Obs! Det här värdet kan behöva justeringar som är lämpliga för din arbetsbelastning. Om du ställer in det här värdet för lågt kanske du inte använder funktionen autokonvertera. Och om du ställer in den för högt kan det leda till minnesfel eller GC-pauser som kan leda till sämre prestanda.)

11. Antal LLAP-daemoner

Miljövariabler i Ambari: num_llap_nodes, num_llap_nodes_for_llap_daemons

num_llap_nodes – anger antalet noder som används av Hive LLAP-tjänsten, omfattar detta noder som kör LLAP-daemon, LLAP Service Master och Tez Application Master (Tez AM).

`Number of Nodes for LLAP service`.
num_llap_nodes_for_llap_daemons – angivet antal noder som endast används för LLAP-daemoner. LLAP-daemoncontainerstorlekar är inställda på maximalt anpassa nod, så det resulterar i en llap daemon på varje nod.

`Number of Nodes for LLAP daemons`.

Vi rekommenderar att du behåller båda värdena på samma sätt som antalet arbetsnoder i Interaktiv fråga kluster.

Överväganden för arbetsbelastningshantering

Om du vill aktivera arbetsbelastningshantering för LLAP kontrollerar du att du reserverar tillräckligt med kapacitet för att arbetsbelastningshanteringen ska fungera som förväntat. Arbetsbelastningshanteringen kräver konfiguration av en anpassad YARN-kö, som är utöver llap kön. Se till att du delar upp den totala klusterresurskapaciteten mellan llap kön och arbetsbelastningshanteringskön i enlighet med dina arbetsbelastningskrav. Arbetsbelastningshantering skapar Tez Application Masters (Tez AMs) när en resursplan aktiveras.

Obs!

  • Tez AMs som skapas genom att aktivera en resursplan förbrukar resurser från arbetsbelastningshanteringskön enligt vad som anges av hive.server2.tez.interactive.queue.
  • Antalet virtuella Tez-datorer beror på värdet QUERY_PARALLELISM för det som anges i resursplanen.
  • När arbetsbelastningshanteringen är aktiv används inte Tez AMs i LLAP-kön. Endast Tez AMs från arbetsbelastningshanteringskön används för frågesamordning. Virtuella datorer i llap kön används när arbetsbelastningshantering inaktiveras.

Till exempel: Total klusterkapacitet = 100 GB minne, uppdelat mellan LLAP, arbetsbelastningshantering och standardköer enligt följande:

  • LLAP-kökapacitet = 70 GB
  • Kökapacitet för arbetsbelastningshantering = 20 GB
  • Standardkökapacitet = 10 GB

Med 20 GB i kökapacitet för arbetsbelastningshantering kan en resursplan ange QUERY_PARALLELISM värdet som fem, vilket innebär att arbetsbelastningshantering kan starta fem Tez-AMs med 4 GB containerstorlek vardera. Om QUERY_PARALLELISM är högre än kapaciteten kan vissa Tez AMs sluta svara i ACCEPTED tillståndet. Hive server 2 Interactive kan inte skicka frågefragment till de Tez AMs som inte är i RUNNING tillstånd.

Nästa steg

Om det inte gick att lösa problemet genom att ange dessa värden kan du gå till något av följande...