Inleiding
De Apache HBase Medium Object Storage (MOB)-functie is geïntroduceerd door HBASE-11339. Deze functie verbetert de lees- en schrijftoegang met lage latentie voor waarden van gemiddelde grootte (idealiter van 100K tot 10 MB op basis van onze testresultaten), waardoor het zeer geschikt is voor het opslaan van documenten, afbeeldingen en andere objecten van gemiddelde grootte [1]. De Apache HBase MOB-functie bereikt deze verbetering door IO-paden voor bestandsverwijzingen en MOB-objecten te scheiden, verschillende verdichtingsbeleidsregels toe te passen op MOB's en zo de schrijfversterking te verminderen die wordt gecreëerd door de verdichtingen van HBase. De MOB-objecten worden opgeslagen in een speciale regio, de MOB-regio genoemd. MOB-objecten voor één tabel worden in de MOB-regio opgeslagen als MOB-bestanden, wat betekent dat er veel MOB-bestanden in deze regio zullen zijn. Zie afbeelding 1 van [1] voor Apache HBase MOB-architectuur.
Afbeelding 1 Apache HBase MOB-architectuur
Aanvankelijk zijn MOB-bestanden relatief klein (minder dan 1 of 2 HDFS-blokken). Om de efficiëntie van Apache HDFS te verbeteren, worden MOB-bestanden periodiek samengevoegd tot grotere bestanden via een bewerking genaamd MOB-comprimering , die onafhankelijk is van het normale verdichtingsproces. De eerste versie van MOB-compressie herschrijft de meerdere MOB-bestanden van een bepaalde dag in grotere MOB-bestanden voor die dag. Laten we de voorbeeldbestandslijst hieronder gebruiken om dit duidelijker te maken. Tabel t1 heeft twee regio's (r1, r2), één kolomfamilie (f1) en MOB ingeschakeld. Je kunt zien dat er twee voorvoegsels zijn; D279186428a75016b17e4df5ea43d080 komt overeen met de hash-waarde van de startsleutel voor regio r1 en D41d8cd98f00b204e9800998ecf8427e met de hash-waarde van de startsleutel voor regio r2. Voor regio r1 zijn er twee MOB-bestanden elk op 1/1/2016 en 1/2/2016 en voor regio r2 zijn er 3 MOB-bestanden op 1/1/2016 onder MOB-regio, namelijk /hbase/data/ mobdir/data/default/t1/78e317a6e78a0fceb27b9fa0cb9dcf5b/f1.
>ls /hbase/data/mobdir/data/default/t1/78e317a6e78a0fceb27b9fa0cb9dcf5b/f1
D279186428a75016b17e4df5ea43d08020160101 f9d9713ab2fb4a8b825485f6a8acfcd5
D279186428a75016b17e4df5ea43d08020160101 af7713ab2fbf4a8abc5135f6a8467ca8
D279186428a75016b17e4df5ea43d08020160102 9013ab2fceda8b825485f6a8acfcd515
D279186428a75016b17e4df5ea43d08020160102 9a7978013ab2fceda8b825485f6a8acf
D41d8cd98f00b204e9800998ecf8427e20160101 fc94af623c2345f1b241887721e32a48
D41d8cd98f00b204e9800998ecf8427e20160101 d0954af623c2345f1b241887721e3259
D41d8cd98f00b204e9800998ecf8427e20160101 439adf4af623c2345f1b241887721e32
Na MOB-comprimering worden twee MOB-bestanden op 1/1/2016 en 1/2/2016 voor regio r1 gecomprimeerd tot één bestand voor elke dag. Drie MOB-bestanden op 1/1/2016 voor regio r2 zijn gecomprimeerd tot één bestand.
D279186428a75016b17e4df5ea43d08020160101 f49a9d9713ab2fb4a8b825485f6a8acf
D279186428a75016b17e4df5ea43d08020160102 bc9176d09424e49a9d9065caf9713ab2
D41d8cd98f00b204e9800998ecf8427e20160101 d9cb0954af623c2345f1b241887721e3
Aangezien alleen MOB-bestanden van dezelfde dag voor een regio samen kunnen worden gecomprimeerd, is de minimumgrens van MOB-bestanden onder de enkele MOB-regiodirectory voor één specifieke familie in één jaar 365 x het aantal regio's. Met 1000 regio's zullen er in 10 jaar 365 x 1000 x 10, 3,65 miljoen bestanden zijn na MOB-verdichting, en het blijft groeien! Helaas heeft Apache HDFS een geheugenbeperkte limiet voor het aantal bestanden onder één map [2]. Nadat het aantal MOB-bestanden deze HDFS-limiet overschrijdt, is de MOB-tabel niet meer beschrijfbaar. Het standaard maximum aantal bestanden onder één map voor Apache HDFS is 1 miljoen. Voor 1000 regio's zal deze limiet over ongeveer drie jaar worden bereikt. Met meer regio's zal het de limiet sneller bereiken.
HBASE-16981 introduceert wekelijks en maandelijks MOB-verdichtingspartitie-aggregatiebeleid om dit probleem met het schalen van MOB-bestanden te verbeteren met respectievelijk een factor 7 of ~30.
Ontwerp van wekelijks en maandelijks MOB-verdichtingspartitiebeleid (HBASE-16981)
Het basisidee van HBASE-16981 is om MOB-bestanden in één kalenderweek of één kalendermaand te comprimeren tot minder, grotere bestanden. De kalenderweek wordt gedefinieerd door ISO 8601, deze begint op maandag en eindigt op zondag. Normaal gesproken is er bij weekbeleid na MOB-verdichting één bestand per week per regio; met maandelijks beleid is er na MOB-verdichting één bestand per maand per regio. Het aantal MOB-bestanden in de MOB-regiomap voor één specifieke familie in één jaar wordt teruggebracht tot 52 x aantal regio's met wekelijks beleid en 12 x aantal regio's met maandelijks beleid. Dit vermindert het aantal MOB-bestanden aanzienlijk na verdichting.
De aanvankelijk voorgestelde aanpak
Wanneer MOB-verdichting plaatsvindt, selecteert en aggregeert HBase-master MOB-bestanden binnen één kalendermaand of één kalenderweek in minder, grotere bestanden. Afhankelijk van hoe vaak MOB-verdichting plaatsvindt, is het mogelijk dat bestanden meerdere keren worden gecomprimeerd. Laten we als voorbeeld zeggen dat de MOB-verdichtingsbewerking dagelijks plaatsvindt met een maandelijks aggregatiebeleid. Op dag 1 comprimeert MOB compaction alle bestanden voor dag 1 tot één bestand. Op dag 2 comprimeert MOB compaction het bestand vanaf dag 1 en bestanden vanaf dag 2 tot een nieuw bestand; op dag 3 comprimeert MOB-verdichting het bestand vanaf dag 2 en bestanden vanaf dag 3 tot een nieuw bestand, het gaat door tot de laatste dag van de maand. In dit geval worden bestanden vanaf dag 1 meer dan 30 keer gecomprimeerd, waardoor de hoeveelheid schrijf-IO met meer dan 30x wordt vergroot.
Het ontwerpdoel van Apache HBase MOB is het verminderen van de schrijfversterking die wordt veroorzaakt door MOB-verdichting. Deze naïeve benadering verslaat het ontwerpdoel.
De uiteindelijk geïmplementeerde aanpak
Om de tekortkoming van de aanvankelijk voorgestelde aanpak te verhelpen, wordt in HBASE-16981 gefaseerde MOB-verdichting toegepast voor nieuwe wekelijkse en maandelijkse polissen. Figuur 2 laat zien hoe het werkt met maandelijks beleid, het werkt op dezelfde manier voor wekelijks beleid.
Figuur 2 Staging MOB-verdichting met maandelijks beleid
Zoals figuur 2 laat zien, vindt MOB-verdichting plaats op 15-11-2016. Bestanden in de huidige kalenderweek worden gecomprimeerd op basis van dagelijkse partitie met geconfigureerde MOB-drempel. In figuur 2 zijn bestanden voor 14-11-2016 samen gecomprimeerd en bestanden voor 15-11-2016 samen. Bestanden in de afgelopen kalenderweken van de huidige maand worden gecomprimeerd op basis van wekelijkse partitie met wekelijkse drempel (geconfigureerde MOB-drempel x 7). In figuur 2 zijn bestanden van 1-11-2016 tot 11-6-2016 samen gecomprimeerd en bestanden van 7-11-2016 tot 13-11-2016 samen gecomprimeerd. Bestanden in de afgelopen maanden worden gecomprimeerd op basis van maandelijkse partitie met maandelijkse drempel (geconfigureerde MOB-drempel x 28). In figuur 2 zijn de bestanden van 1-10-2016 tot 31-10-2016 gecomprimeerd. Zoals u wellicht opmerkt, loopt de eerste kalenderweek van november 2016 van 31-10-2016 tot 06-11-2016. Aangezien 31-10-2016 in de afgelopen maand is, worden de bestanden voor die dag gecomprimeerd op basis van de maandelijkse partitie, dit laat slechts 6 dagen over voor de wekelijkse partitie (11/1/2016 ~ 11/6/2016). Na verdichting zijn er 5 bestanden als de MOB-verdichtingsdrempel en de MOB-verdichtingsbatchgrootte correct zijn geconfigureerd.
Met dit ontwerp gaan MOB-bestanden door 2-traps of 3-traps verdichtingen. In elke fase wordt een dagelijkse partitie, wekelijkse partitie of maandelijkse partitie toegepast met toenemende MOB-verdichtingsdrempel. MOB-bestanden worden normaal gesproken maximaal 3 keer gecomprimeerd met maandelijks beleid en maximaal 2 keer normaal met wekelijks beleid tijdens hun levensduur.
Voor meer details over het ontwerp, zie [3].
Gebruik
Standaard is het MOB-compressiepartitiebeleid dagelijks. Om wekelijks of maandelijks beleid toe te passen, is er een nieuw kenmerk MOB_COMPACT_PARTITION_POLICY toegevoegd voor MOB-kolomfamilie. De gebruiker kan dit kenmerk instellen bij het maken van een tabel vanuit de HBase-shell.
>create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 1000000, MOB_COMPACT_PARTITION_POLICY => 'weekly’} De gebruiker kan ook de MOB_COMPACT_PARTITION_POLICY van de bestaande tabel wijzigen vanuit de HBase-shell.
>alter 't1', {NAME => 'f1', MOB_COMPACT_PARTITION_POLICY => 'monthly'} Als het beleid verandert van dagelijks naar wekelijks of maandelijks, of van wekelijks naar maandelijks, zal de volgende MOB-verdichting MOB-bestanden opnieuw comprimeren die zijn gecomprimeerd met het vorige beleid. Als het beleid verandert van maandelijks of wekelijks naar dagelijks, of van maandelijks naar wekelijks, worden de reeds gecomprimeerde MOB-bestanden met het vorige beleid niet opnieuw gecompacteerd met het nieuwe beleid.
Conclusie
HBASE-16981 lost het schalingsprobleem van het bestandsnummer op met Apache HBase MOB. Het zal beschikbaar zijn in de release van Apache HBase 2.0.0. CDH ondersteunt Apache HBase MOB in CDH 5.4.0+. HBASE-16981 is gebackporteerd en zal beschikbaar zijn in CDH 5.11.0.
Erkenningen
Speciale dank aan Jingcheng Du en Anoop Sam John voor hulp bij het ontwerpen en beoordelen van HBASE-16981, Jonathan Hsieh en Sean Busbey voor het beoordelen van de blog.
Referenties
[1] https://clouderatemp.wpengine.com/blog/2015/06/inside-apache-hbases-new-support-for-mobs/
[2] https://clouderatemp.wpengine.com/blog/2009/02/the-small-files-problem/
[3] https://issues.apache.org/jira/browse/HBASE-16981