Apache HBase-adviezen in Azure HDInsight

In dit artikel worden verschillende adviezen beschreven om u te helpen de Prestaties van Apache HBase in Azure HDInsight te optimaliseren.

HBase optimaliseren om laatst geschreven gegevens te lezen

Als uw use-case betrekking heeft op het lezen van de meest recent geschreven gegevens van HBase, kan dit advies u helpen. Voor hoge prestaties is het optimaal dat HBase-leesbewerkingen worden geleverd vanuit memstore, in plaats van de externe opslag.

Het queryadvies geeft aan dat voor een bepaalde kolomfamilie in een tabel > 75% leesbewerkingen worden uitgevoerd.memstore Deze indicator geeft aan dat zelfs als er een leegmaken op het memstore recente bestand moet worden geopend en dat dit in de cache moet zijn. De gegevens worden eerst naar het systeem geschreven om toegang te krijgen tot memstore de recente gegevens daar. Er is een kans dat de interne HBase-flusher-threads detecteren dat een bepaalde regio de grootte van 128M (standaard) heeft bereikt en een leegmaken kan activeren. Dit scenario gebeurt zelfs met de meest recente gegevens die zijn geschreven toen de memstore grootte ongeveer 128 miljoen was. Daarom kan een latere leesbewerking van deze recente records een bestand vereisen in plaats van van.memstore Daarom is het raadzaam om te optimaliseren dat zelfs recente gegevens die onlangs zijn leeggemaakt, zich in de cache kunnen bevinden.

Houd rekening met de volgende configuratie-instellingen om de recente gegevens in de cache te optimaliseren:

1. Stel hbase.rs.cacheblocksonwrite in op true. Deze standaardconfiguratie in HDInsight HBase is true, dus controleer of deze niet opnieuw is ingesteld falseop .

2. Verhoog de hbase.hstore.compactionThreshold waarde zodat u kunt voorkomen dat de compressie wordt geactiveerd. Standaard is deze waarde ingesteld op 3. U kunt deze verhogen naar een hogere waarde, zoals 10.

3. Als u stap 2 volgt en compactionThreshold instelt, gaat hbase.hstore.compaction.max u naar een hogere waarde, bijvoorbeeld 100en verhoogt u ook de waarde voor de configuratie hbase.hstore.blockingStoreFiles naar een hogere waarde, bijvoorbeeld 300.

4. Als u zeker weet dat u alleen de recente gegevens moet lezen, stelt u hbase.rs.cachecompactedblocksonwrite de configuratie in op AAN. Deze configuratie vertelt het systeem dat, zelfs als de compressie plaatsvindt, de gegevens in de cache blijven. De configuraties kunnen ook op gezinsniveau worden ingesteld.

   Voer in de HBase Shell de volgende opdracht uit om de configuratie in te stellen hbase.rs.cachecompactedblocksonwrite :

   alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
   

5. Blokcache kan worden uitgeschakeld voor een bepaalde familie in een tabel. Zorg ervoor dat deze functie is ingeschakeld voor gezinnen met de meest recente gegevensleesbewerkingen. Blokcache is standaard ingeschakeld voor alle families in een tabel. Als u de blokcache voor een gezin hebt uitgeschakeld en deze moet inschakelen, gebruikt u de opdracht Alter van de hbase-shell.

   Deze configuraties helpen ervoor te zorgen dat de gegevens beschikbaar zijn in de cache en dat de recente gegevens niet worden gecomprimeerd. Als een TTL mogelijk is in uw scenario, kunt u overwegen om datum-gelaagde compressie te gebruiken. Zie de Handleiding voor Apache HBase-naslaginformatie: Gelaagde compressie van datums voor meer informatie

De wachtrij leegmaken optimaliseren

Dit advies geeft aan dat HBase flushes mogelijk moeten worden afgestemd. De huidige configuratie voor flush-handlers is mogelijk niet hoog genoeg om te verwerken met schrijfverkeer dat kan leiden tot vertraging van leegmaken.

In de gebruikersinterface van de regioserver ziet u of de wachtrij leegmaken groter is dan 100. Deze drempelwaarde geeft aan dat de leegmaken traag zijn en dat u de hbase.hstore.flusher.count configuratie mogelijk moet afstemmen. De waarde is standaard 2. Zorg ervoor dat de maximale flusher-threads niet hoger zijn dan 6.

Kijk ook of u een aanbeveling hebt voor het afstemmen van het aantal regio's. Zo ja, dan raden we u aan om het afstemmen van de regio uit te voeren om te zien of dat helpt bij het sneller leegmaken. Anders kan het afstemmen van de flusher-threads u helpen.

Afstemming aantal regio's

Het afstemmingsadvies voor regioaantal geeft aan dat HBase updates heeft geblokkeerd en het aantal regio's kan groter zijn dan de optimaal ondersteunde heapgrootte. U kunt de heapgrootte, memstore grootte en het aantal regio's afstemmen.

Als voorbeeldscenario:

• Stel dat de heap-grootte voor de regioserver 10 GB is. hbase.hregion.memstore.flush.size De standaardwaarde is 128M. De standaardwaarde is hbase.regionserver.global.memstore.size 0.4. Dit betekent dat uit de 10 GB 4 GB wordt toegewezen memstore (wereldwijd).

• Stel dat er een gelijkmatige verdeling is van de schrijfbelasting voor alle regio's en ervan uitgaande dat elke regio alleen 128 MB groter wordt 32 dan is het maximum aantal regio's in deze installatie regio's. Als een bepaalde regioserver is geconfigureerd voor 32 regio's, voorkomt het systeem dat updates worden geblokkeerd.

• Met deze instellingen is het aantal regio's 100. De globale memstore 4 GB is nu verdeeld over 100 regio's. Dus in feite krijgt elke regio slechts 40 MB voor memstore. Wanneer de schrijfbewerkingen uniform zijn, wordt het systeem regelmatig leeggemaakt en wordt de order < 40 MB kleiner. Het hebben van veel flusher threads kan de spoelsnelheid hbase.hstore.flusher.countverhogen.

Het advies betekent dat het verstandig is om het aantal regio's per server, de heapgrootte en de configuratie van de globale memstore grootte te herzien, samen met het afstemmen van flush threads om te voorkomen dat updates worden geblokkeerd.

Afstemmen van compressiewachtrij

Als de HBase-compressiewachtrij groter wordt dan 2000 en periodiek plaatsvindt, kunt u de compressiethreads verhogen naar een grotere waarde.

Wanneer er een overmatig aantal bestanden is voor compressie, kan dit leiden tot meer heapgebruik met betrekking tot de interactie van de bestanden met het Azure-bestandssysteem. Het is dus beter om de compressie zo snel mogelijk af te ronden. Sommige keren in oudere clusters kunnen de compressieconfiguraties met betrekking tot beperking leiden tot een tragere compressiesnelheid.

Controleer de configuraties hbase.hstore.compaction.throughput.lower.bound en hbase.hstore.compaction.throughput.higher.bound. Als ze al zijn ingesteld op 50 M en 100M, laat u ze staan zoals het is. Als u deze instellingen echter hebt geconfigureerd voor een lagere waarde (wat het geval was bij oudere clusters), wijzigt u de limieten respectievelijk in 50M en 100M.

De configuraties zijn hbase.regionserver.thread.compaction.small en hbase.regionserver.thread.compaction.large (de standaardwaarden zijn elk 1). De maximumwaarde voor deze configuratie moet kleiner zijn dan 3.

Volledige tabelscan

Het advies voor een volledige tabelscan geeft aan dat meer dan 75% van de uitgegeven scans volledige tabel-/regioscans zijn. U kunt teruggaan naar de manier waarop uw code de scans aanroept om de queryprestaties te verbeteren. Houd rekening met de volgende procedures:

• Stel de juiste begin- en eindrij in voor elke scan.

• Gebruik de MultiRowRangeFilter-API , zodat u in één scanoproep verschillende bereiken kunt opvragen. Zie de documentatie voor MultiRowRangeFilter-API voor meer informatie.

• In gevallen waarin u een volledige tabel- of regioscan nodig hebt, controleert u of er een mogelijkheid is om cachegebruik voor deze query's te voorkomen, zodat andere query's die gebruikmaken van de cache de blokken die hot zijn, mogelijk niet verwijderen. Gebruik de scan-API met de optie setCaching(false) in uw code om ervoor te zorgen dat de scans geen cache gebruiken:

  scan#setCaching(false)
  

Volgende stappen

Apache HBase optimaliseren met Ambari