Het verdichtingsmodel verandert drastisch met CDH 5/HBase 0.96. Dit is wat je moet weten.
Apache HBase is een gedistribueerde datastore gebaseerd op een log-gestructureerde merge tree, dus optimale leesprestaties zouden komen van het hebben van slechts één bestand per store (Column Family). Dat ideaal is echter niet mogelijk tijdens perioden van zware inkomende schrijfacties. In plaats daarvan probeert HBase HFiles te combineren om het maximale aantal schijfzoekopdrachten dat nodig is voor een leesbewerking te verminderen. Dit proces wordt verdichting genoemd .
Compactions kiezen enkele bestanden uit een enkele winkel in een regio en combineren ze. Dit proces omvat het lezen van KeyValues in de invoerbestanden en het wegschrijven van KeyValues die niet zijn verwijderd, binnen de time to live (TTL) vallen en het aantal versies niet schenden. Het nieuw aangemaakte gecombineerde bestand vervangt dan de invoerbestanden in de regio.
Wanneer een client nu om gegevens vraagt, weet HBase dat de gegevens van de invoerbestanden in één aaneengesloten bestand op schijf worden bewaard - vandaar dat er maar één zoekactie nodig is, terwijl voorheen één voor elk bestand nodig kon zijn. Maar schijf-IO is niet gratis, en zonder zorgvuldige aandacht kan het steeds opnieuw herschrijven van gegevens leiden tot een serieus netwerk- en schijfoverabonnement. Met andere woorden, verdichting gaat over het verruilen van een schijf-IO nu voor minder zoekacties later.
In dit bericht leert u meer over het gebruik en de implicaties van verdichtingen in CDH 4, evenals wijzigingen in het verdichtingsmodel in CDH 5 (dat opnieuw zal worden gebaseerd op HBase 0.96).
Verdichting in CDH 4
De ideale verdichting zou de bestanden kiezen die de meeste zoekacties bij komende reads zullen verminderen, terwijl ze ook bestanden kiezen die de minste hoeveelheid IO nodig hebben. Helaas is dat probleem niet oplosbaar zonder kennis van de toekomst. Als zodanig is het gewoon een ideaal waar HBase naar moet streven en niet iets dat ooit echt haalbaar is.
In plaats van het onmogelijke ideaal, gebruikt HBase een heuristiek om te proberen te kiezen welke bestanden in een winkel waarschijnlijk goede kandidaten zijn. De bestanden zijn gekozen op basis van de intuïtie dat soortgelijke bestanden moeten worden gecombineerd met soortgelijke bestanden - wat betekent dat bestanden die ongeveer even groot zijn, moeten worden gecombineerd.
Het standaardbeleid in HBase 0.94 (verzending in CDH 4) kijkt door de lijst met HFiles en probeert het eerste bestand te vinden dat kleiner is dan het totaal van alle bestanden vermenigvuldigd met hbase.store.compaction.ratio. Zodra dat bestand is gevonden, worden het HF-bestand en alle bestanden met kleinere sequentie-ID's gekozen om te worden gecomprimeerd.
Voor het standaardgeval dat de grootste bestanden de oudste zijn, werkt deze aanpak goed:
Deze veronderstelling over de correlatie tussen leeftijd en grootte van bestanden is in sommige gevallen echter onjuist, waardoor het huidige algoritme suboptimaal kiest. In plaats daarvan kunnen in bulk geladen bestanden heel anders worden gesorteerd en soms heel anders dan de meer normaal weggespoelde HFiles, dus het zijn geweldige voorbeelden:
Verdichtingsveranderingen in CDH 5
Verdichtingen zijn de laatste tijd aanzienlijk veranderd. Voor HBase 0.96 en CDH 5 is het algoritme voor bestandsselectie configureerbaar gemaakt via HBASE-7516, dus het is nu mogelijk om door de gebruiker aangeleverd verdichtingsbeleid te gebruiken. Met deze wijziging kunnen meer ervaren gebruikers testen en herhalen hoe ze verdichtingen willen uitvoeren.
Het standaard selectiealgoritme voor verdichting is ook gewijzigd in ExploringCompactionPolicy. Dit beleid verschilt van de oude standaard omdat het ervoor zorgt dat elk afzonderlijk bestand in een voorgestelde verdichting binnen de gegeven verhouding valt. Het kiest ook niet alleen de eerste set bestanden met een grootte binnen de verdichtingsratio; in plaats daarvan kijkt het naar alle mogelijke sets die geen regels overtreden, en kiest vervolgens iets dat het meest impactvol lijkt te zijn voor de minste hoeveelheid IO die wordt verwacht. Om dat te doen, kiest het ExploringCompactionPolicy een verdichting die de meeste bestanden binnen de verhouding zal verwijderen, en als er een gelijkspel is, wordt de voorkeur gegeven aan de reeks bestanden die kleiner zijn:
Er zijn meer wijzigingen gepland voor toekomstige releases, waaronder gelaagde verdichting, gestreepte verdichting en op niveau gebaseerde verdichting.
Conclusie
Voor sommige use-cases heeft dit werk helemaal geen impact. Dat is maar goed ook, want verdichtingen waren al behoorlijk goed bestudeerd. Voor gebruikers met grote verkeerspieken of die bulkladingen gebruiken, kan dit werk echter grote verbeteringen opleveren in de IO-wachttijden en de latentie van verzoeken. Voor een specifiek geval van bulklading hebben we een reductie van 90% in schijf-IO gezien als gevolg van verdichtingen.
Hier zijn resultaten van een testcase in PerfTestCompactionPolicies van HBase:
Bekijk dit werk in CDH 5 (in bèta op het moment van schrijven) als het gaat om een cluster bij jou in de buurt.
Verder lezen:
- Verdichtingsbeleid onderzoeken
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/