Apache HBase-rekommendationer i Azure HDInsight

Artikel
10/16/2024

Den här artikeln beskriver flera rekommendationer som hjälper dig att optimera Apache HBase-prestanda i Azure HDInsight.

Optimera HBase för att läsa senast skrivna data

Om ditt användningsfall innebär att läsa de senast skrivna data från HBase kan den här rådgivningen hjälpa dig. För höga prestanda är det optimalt att HBase-läsningar hanteras från memstore, i stället för fjärrlagringen.

Frågerådgivningen anger att för en viss kolumnfamilj i en tabell > läser 75 % som hanteras från memstore. Den här indikatorn tyder på att även om en tömning sker på den memstore senaste filen måste du komma åt och som måste finnas i cacheminnet. Data skrivs först till systemet och får åtkomst till memstore de senaste data där. Det finns en chans att de interna HBase-tömningstrådarna upptäcker att en viss region har nått en storlek på 128 M (standard) och kan utlösa en tömning. Det här scenariot händer även de senaste data som skrevs när var memstore cirka 128 M stora. Därför kan en senare läsning av de senaste posterna kräva en filläsning i stället för från memstore. Därför är det bäst att optimera att även nyligen rensade data kan finnas i cacheminnet.

Tänk på följande konfigurationsinställningar för att optimera de senaste data i cacheminnet:

Ställ in hbase.rs.cacheblocksonwrite på true. Den här standardkonfigurationen i HDInsight HBase är true, så kontrollera att den inte återställs till false.
hbase.hstore.compactionThreshold Öka värdet så att du kan undvika komprimering från att sparka in. Det här värdet är som standard 3. Du kan öka det till ett högre värde som 10.
Om du följer steg 2 och anger compactionThreshold ändrar hbase.hstore.compaction.max du till exempel 100ett högre värde och ökar även värdet för konfigurationen hbase.hstore.blockingStoreFiles till ett högre värde, till exempel 300.
Om du är säker på att du bara behöver läsa de senaste data anger du hbase.rs.cachecompactedblocksonwrite konfigurationen till PÅ. Den här konfigurationen talar om för systemet att även om komprimering sker förblir data i cacheminnet. Konfigurationerna kan också anges på familjenivå.

I HBase Shell kör du följande kommando för att ange hbase.rs.cachecompactedblocksonwrite konfiguration:
```
alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
```
Blockcache kan stängas av för en viss familj i en tabell. Se till att den är aktiverad för familjer som har de senaste dataläsningarna. Som standard är blockcache aktiverat för alla familjer i en tabell. Om du har inaktiverat blockcacheminnet för en familj och behöver aktivera det använder du alter-kommandot från hbase-gränssnittet.

Dessa konfigurationer hjälper till att säkerställa att data är tillgängliga i cacheminnet och att de senaste data inte komprimeras. Om en TTL är möjlig i ditt scenario bör du överväga att använda komprimering på datumnivå. Mer information finns i Referensguide för Apache HBase: Date Tiered Compaction

Optimera tömningskö

Den här rekommendationen anger att HBase-tömningar kan behöva justeras. Den aktuella konfigurationen för tömningshanterare kanske inte är tillräckligt hög för att hantera skrivtrafik som kan leda till långsamma tömningar.

I regionserverns användargränssnitt ser du om tömningskön växer över 100. Det här tröskelvärdet anger att tömningen är långsam och att du kan behöva justera konfigurationen hbase.hstore.flusher.count . Som standard är värdet 2. Se till att de maximala tömningstrådarna inte ökar längre än 6.

Dessutom kan du se om du har en rekommendation för justering av antal regioner. Om ja föreslår vi att du provar regionjusteringen för att se om det hjälper till med snabbare tömningar. Annars kan det hjälpa dig att justera tömningstrådarna.

Justera antal regioner

Justeringsrekommendationer för regionantal anger att HBase har blockerat uppdateringar och att regionantalet kan vara mer än den optimalt stödda heapstorleken. Du kan justera heapstorleken, memstore storleken och antalet regioner.

Som ett exempelscenario:

Anta att heapstorleken för regionservern är 10 GB. Som standard är .hbase.hregion.memstore.flush.size 128M Standardvärdet för hbase.regionserver.global.memstore.size är 0.4. Vilket innebär att av 10 GB allokeras 4 GB för memstore (globalt).
Anta att det finns en jämn fördelning av skrivbelastningen i alla regioner och förutsatt att varje region växer upp till 128 MB är det maximala antalet regioner i den här konfigurationen 32 regioner. Om en viss regionserver har konfigurerats för att ha 32 regioner undviker systemet bättre blockering av uppdateringar.
Med de här inställningarna på plats är antalet regioner 100. Nu är 4 GB globalt memstore uppdelat i 100 regioner. Så effektivt får varje region bara 40 MB för memstore. När skrivningar är enhetliga, gör systemet frekventa tömningar och mindre storlek på ordningen < 40 MB. Om du har många spolartrådar kan du öka tömningshastigheten hbase.hstore.flusher.count.

Rekommendationen innebär att det vore bra att ompröva antalet regioner per server, heapstorleken och den globala memstore storlekskonfigurationen tillsammans med justeringen av tömningstrådar för att undvika att uppdateringar blockeras.

Komprimeringsköjustering

Om HBase-komprimeringskön växer till mer än 2000 och inträffar regelbundet kan du öka komprimeringstrådarna till ett större värde.

När det finns ett stort antal filer för komprimering kan det leda till mer heapanvändning relaterad till hur filerna interagerar med Azure-filsystemet. Så det är bättre att slutföra komprimering så snabbt som möjligt. Vissa gånger i äldre kluster kan komprimeringskonfigurationer relaterade till begränsning leda till långsammare komprimeringshastighet.

Kontrollera konfigurationerna hbase.hstore.compaction.throughput.lower.bound och hbase.hstore.compaction.throughput.higher.bound. Om de redan är inställda på 50M och 100M lämnar du dem som de är. Men om du har konfigurerat dessa inställningar till ett lägre värde (vilket var fallet med äldre kluster) ändrar du gränserna till 50M respektive 100 M.

Konfigurationerna är hbase.regionserver.thread.compaction.small och hbase.regionserver.thread.compaction.large (standardvärdena är 1 vardera). Begränsa maxvärdet för den här konfigurationen till mindre än 3.

Fullständig tabellgenomsökning

Den fullständiga tabellgenomsökningsrådgivningen anger att över 75 % av de utgivna genomsökningarna är fullständiga genomsökningar av tabeller/regioner. Du kan gå tillbaka till hur koden anropar genomsökningarna för att förbättra frågeprestandan. Överväg följande metoder:

Ange rätt start- och stopprad för varje genomsökning.
Använd MultiRowRangeFilter-API:et så att du kan köra frågor mot olika intervall i ett genomsökningsanrop. Mer information finns i Dokumentation om MultiRowRangeFilter API.
I de fall där du behöver en fullständig tabell- eller regiongenomsökning kontrollerar du om det finns en möjlighet att undvika cacheanvändning för dessa frågor, så att andra frågor som använder cacheminnet kanske inte tar bort blocken som är heta. För att säkerställa att genomsökningarna inte använder cacheminnet använder du genomsöknings-API:et med alternativet setCaching(false) i koden:
```
scan#setCaching(false)
```

Nästa steg

Optimera Apache HBase med Ambari

Dela via