Meer informatie over de ontwerpbeslissingen achter de nieuwe ondersteuning van HBase voor MOB's.
Apache HBase is een gedistribueerde, schaalbare, performante, consistente sleutelwaardedatabase die een verscheidenheid aan binaire gegevenstypen kan opslaan. Het blinkt uit in het opslaan van veel relatief kleine waarden (<10K) en het bieden van lees- en schrijfbewerkingen met lage latentie.
Er is echter een groeiende vraag naar het opslaan van documenten, afbeeldingen en andere gematigde objecten (MOB's) in HBase met behoud van een lage latentie voor lezen en schrijven. Een voorbeeld van zo'n use-case is een bank die ondertekende en gescande klantdocumenten opslaat. Een ander voorbeeld is dat vervoersbureaus momentopnamen van verkeer en rijdende auto's willen opslaan. Deze MOB's zijn over het algemeen eenmalig te schrijven.
Helaas kunnen de prestaties afnemen in situaties waarin veel waarden van gemiddelde grootte (100K tot 10 MB) worden opgeslagen vanwege de steeds toenemende I/O-druk die wordt veroorzaakt door verdichtingen. Denk aan het geval waarin 1 TB aan foto's van verkeerscamera's, elk 1 MB groot, dagelijks in HBase wordt opgeslagen. Delen van de opgeslagen bestanden worden meerdere keren gecomprimeerd via kleine compressies en uiteindelijk worden gegevens herschreven door grote compressies. Samen met de accumulatie van deze MOB's, zal I/O gecreëerd door verdichtingen de verdichtingen vertragen, het opschonen van de geheugenopslag verder blokkeren en uiteindelijk updates blokkeren. Een grote MOB-winkel zal frequente regio-splitsingen veroorzaken, waardoor de beschikbaarheid van de getroffen regio's wordt verminderd.
Om deze nadelen aan te pakken, hebben Cloudera- en Intel-ingenieurs MOB-ondersteuning geïmplementeerd in een HBase-tak (hbase-11339:HBase MOB). Deze branch wordt samengevoegd met de master in HBase 1.1 of 1.2 en is al aanwezig en wordt ook ondersteund in CDH 5.4.x.
Bewerkingen op MOB's zijn meestal schrijfintensief, met zeldzame updates of verwijderingen en relatief zeldzame leesbewerkingen. MOB's worden meestal samen met hun metadata opgeslagen. Metadata met betrekking tot MOB's kunnen bijvoorbeeld autonummer, snelheid en kleur zijn. Metadata zijn erg klein in verhouding tot de MOB's. Metadata worden meestal geopend voor analyse, terwijl MOB's meestal alleen willekeurig worden geopend als ze expliciet worden aangevraagd met rijsleutels.
Gebruikers willen de MOB's in HBase lezen en schrijven met lage latentie in dezelfde API's, en willen sterke consistentie, beveiliging, snapshot en HBase-replicatie tussen clusters, enzovoort. Om deze doelen te bereiken, werden MOB's verplaatst van het hoofd-I/O-pad van HBase naar een nieuw I/O-pad.
In dit bericht leer je over deze ontwerpbenadering en waarom deze is gekozen.
Mogelijke benaderingen
Er waren een paar mogelijke benaderingen van dit probleem. De eerste benadering die we overwogen was om MOB's op te slaan in HBase met een afgestemd splitsings- en verdichtingsbeleid - een grotere gewenste MaxFileSize verlaagt de frequentie van regiosplitsing en minder of geen verdichtingen kunnen de straf voor schrijfversterking vermijden. Die aanpak zou de schrijflatentie en doorvoer aanzienlijk verbeteren. Echter, samen met het toenemende aantal opgeslagen bestanden, zouden er te veel geopende lezers in een enkele winkel zijn, zelfs meer dan wat door het besturingssysteem is toegestaan. Als gevolg hiervan zou er veel geheugen worden verbruikt en zouden de leesprestaties afnemen.
Een andere benadering was om een HBase + HDFS-model te gebruiken om de metadata en MOB's afzonderlijk op te slaan. In dit model wordt een enkel bestand gekoppeld door een item in HBase. Dit is een clientoplossing en de transactie wordt beheerd door de client - er worden geen HBase-side-geheugens gebruikt door MOB's. Deze aanpak zou werken voor objecten die groter zijn dan 50 MB, maar voor MOB's leiden veel kleine bestanden tot inefficiënt HDFS-gebruik, aangezien de standaardblokgrootte in HDFS 128 MB is.
Laten we bijvoorbeeld zeggen dat een NameNode 48 GB geheugen heeft en dat elk bestand 100 KB is met drie replica's. Elk bestand neemt meer dan 300 bytes in geheugen in beslag, dus een NameNode met 48 GB geheugen kan ongeveer 160 miljoen bestanden bevatten, wat ons zou beperken tot het opslaan van in totaal 16 TB MOB-bestanden.
Als verbetering hadden we de kleine MOB-bestanden kunnen samenvoegen tot grotere bestanden - dat wil zeggen, een bestand zou meerdere MOB-items kunnen hebben - en de offset en lengte in de HBase-tabel kunnen opslaan om ze snel te kunnen lezen. Het is echter moeilijk om gegevensconsistentie te behouden en verwijderde MOB's en kleine MOB-bestanden in compacties te beheren.
Als we deze aanpak zouden gebruiken, zouden we bovendien een nieuw beveiligingsbeleid moeten overwegen, de atomiciteitseigenschappen van schrijfbewerkingen verliezen en mogelijk de back-up en noodherstel verliezen die worden geboden door replicatie en snapshots.
HBase MOB-ontwerp
Omdat de meeste zorgen over het opslaan van MOB's in HBase betrekking hebben op de I/O die wordt gecreëerd door verdichtingen, was de sleutel uiteindelijk om MOB's uit het beheer te halen door normale regio's om regiosplitsingen en verdichtingen daar te voorkomen.
Het HBase MOB-ontwerp is vergelijkbaar met de HBase + HDFS-aanpak omdat we de metadata en MOB's afzonderlijk opslaan. Het verschil ligt echter in een ontwerp aan de serverzijde:memstore cachet de MOB's voordat ze naar de schijf worden leeggemaakt, de MOB's worden bij elke flush in een HFile met de naam "MOB-bestand" geschreven en elk MOB-bestand heeft meerdere vermeldingen in plaats van een enkel bestand in HDFS voor elke MOB. Dit MOB-bestand wordt opgeslagen in een speciale regio. Al het lezen en schrijven kan worden gebruikt door de huidige HBase API's.
Schrijf en lees
Elke MOB heeft een drempel:als de waardelengte van een cel groter is dan deze drempel, wordt deze cel beschouwd als een MOB-cel.
Wanneer de MOB-cellen in de regio's worden bijgewerkt, worden ze, net als de normale cellen, naar de WAL en memstore geschreven. Bij het opschonen worden de MOB's naar MOB-bestanden verwijderd en worden de metadata en paden van MOB-bestanden gewist om bestanden op te slaan. De gegevensconsistentie en HBase-replicatiefuncties zijn eigen aan dit ontwerp.
De MOB-bewerkingen zijn groter dan normaal. Bij de synchronisatie is de bijbehorende I/O ook groter, wat de synchronisatiebewerkingen van WAL kan vertragen. Als er andere regio's zijn die dezelfde WAL delen, kan de schrijflatentie van deze regio's worden beïnvloed. Als de gegevensconsistentie en niet-volatiliteit echter nodig zijn, is WAL een must.
De cellen mogen tussen opgeslagen bestanden en MOB-bestanden in de verdichtingen bewegen door de drempel te wijzigen. De standaarddrempel is 100 KB.
Zoals hieronder geïllustreerd, worden de cellen die de paden van MOB-bestanden bevatten, referentiecellen genoemd . De tags blijven in de cellen, zodat we kunnen blijven vertrouwen op het HBase-beveiligingsmechanisme.
De referentiecellen hebben referentietags die ze onderscheiden van normale cellen. Een referentietag impliceert een MOB-cel in een MOB-bestand, en dus is verdere oplossing nodig bij het lezen.
Tijdens het lezen opent de winkelscanner scanners om bestanden op te slaan en op te slaan. Als aan een referentiecel wordt voldaan, leest de scanner het bestandspad van de celwaarde en zoekt dezelfde rijsleutel uit dat bestand. De blokcache kan worden ingeschakeld voor de MOB-bestanden in de scan, wat het zoeken kan versnellen.
Het is niet nodig om readers voor alle MOB-bestanden te openen; er is er maar één nodig wanneer dat nodig is. Deze willekeurige lezing wordt niet beïnvloed door het aantal MOB-bestanden. We hoeven de MOB-bestanden dus niet steeds opnieuw te comprimeren als ze groot genoeg zijn.
De MOB-bestandsnaam is leesbaar en bestaat uit drie delen:de MD5 van de startsleutel, de laatste datum van cellen in dit MOB-bestand en een UUID. Het eerste deel is de startsleutel van de regio van waaruit dit MOB-bestand wordt leeggemaakt. Gewoonlijk hebben de MOB's een door de gebruiker gedefinieerde TTL, zodat u verlopen MOB-bestanden kunt vinden en verwijderen door het tweede deel te vergelijken met de TTL.
Momentopname
Om de snapshot vriendelijker te maken, worden de MOB-bestanden opgeslagen in een speciale dummy-regio, waarbij de snapshot, de tabelexport/-kloon en het archief werken zoals verwacht.
Bij het opslaan van een momentopname naar een tabel, maakt men de MOB-regio in de momentopname en voegt de bestaande MOB-bestanden toe aan het manifest. Maak bij het herstellen van de snapshot bestandskoppelingen in de MOB-regio.
Schoon en verdichtingen
Er zijn twee situaties waarin MOB-bestanden moeten worden verwijderd:wanneer het MOB-bestand is verlopen en wanneer het MOB-bestand te klein is en moet worden samengevoegd tot grotere bestanden om de HDFS-efficiëntie te verbeteren.
HBase MOB heeft een taak in de master:het scant de MOB-bestanden, vindt de verlopen die zijn bepaald door de datum in de bestandsnaam en verwijdert ze. Zo wordt schijfruimte periodiek teruggewonnen door verlopen MOB-bestanden te verouderen.
MOB-bestanden kunnen relatief klein zijn in vergelijking met een HDFS-blok als u rijen schrijft waarin slechts een paar items in aanmerking komen als MOB's; er kunnen ook verwijderde cellen zijn. U moet de verwijderde cellen verwijderen en de kleine bestanden samenvoegen tot grotere om het HDFS-gebruik te verbeteren. De MOB-verdichtingen comprimeren alleen de kleine bestanden en de grote bestanden worden niet aangeraakt, waardoor herhaalde verdichting tot grote bestanden wordt voorkomen.
Enkele andere dingen om in gedachten te houden:
- Weet welke cellen zijn verwijderd. Bij elke grote verdichting van HBase worden de verwijdermarkeringen naar een del-bestand geschreven voordat ze worden verwijderd.
- In de eerste stap van MOB-verdichtingen worden deze del-bestanden samengevoegd tot grotere.
- Alle kleine MOB-bestanden zijn geselecteerd. Als het aantal kleine bestanden gelijk is aan het aantal bestaande MOB-bestanden, wordt deze verdichting als een grote beschouwd en een ALL_FILES-verdichting genoemd.
- Deze geselecteerde bestanden zijn gepartitioneerd op de startsleutel en datum in de bestandsnaam. De kleine bestanden in elke partitie worden gecomprimeerd met del-bestanden zodat verwijderde cellen kunnen worden verwijderd; ondertussen wordt een nieuwe HFile met nieuwe referentiecellen gegenereerd, de compactor legt het nieuwe MOB-bestand vast en laadt deze HFile vervolgens in bulk in HBase.
- Nadat het comprimeren in alle partities is voltooid, worden de del-bestanden gearchiveerd als het om een ALL_FILES-comprimering gaat.
De levenscyclus van MOB-bestanden wordt hieronder geïllustreerd. In principe worden ze gemaakt wanneer de memstore wordt leeggemaakt en door HFileCleaner uit het bestandssysteem verwijderd als er niet naar wordt verwezen door de snapshot of als ze in het archief zijn verlopen.
Conclusie
Samenvattend:het nieuwe HBase MOB-ontwerp haalt MOB's uit het hoofd-I/O-pad van HBase, terwijl de meeste beveiligings-, verdichtings- en snapshotfuncties behouden blijven. Het komt tegemoet aan de kenmerken van bewerkingen in MOB, maakt de schrijfversterking van MOB's voorspelbaarder en houdt lage latenties bij zowel lezen als schrijven.
Jincheng Du is een Software Engineer bij Intel en een HBase-bijdrager.
Jon Hsieh is een Software Engineer bij Cloudera en een HBase-committer/PMC-lid. Hij is ook de oprichter van Apache Flume en een committer op Apache Sqoop.