Model zhutňování se drasticky mění s CDH 5/HBase 0,96. Zde je to, co potřebujete vědět.
Apache HBase je distribuované úložiště dat založené na slučovacím stromu strukturovaném do protokolů, takže optimální výkon čtení by pocházel z jediného souboru na úložiště (rodina sloupců). Tento ideál však není možný během období silných příchozích zápisů. Místo toho se HBase pokusí zkombinovat HFiles, aby se snížil maximální počet hledání disku potřebných pro čtení. Tento proces se nazývá zhutnění .
Komprimace vyberou některé soubory z jednoho úložiště v oblasti a zkombinují je. Tento proces zahrnuje čtení hodnot KeyValues ve vstupních souborech a vypisování všech klíčových hodnot, které nejsou smazány, jsou v rámci doby životnosti (TTL) a neporušují počet verzí. Nově vytvořený kombinovaný soubor pak nahradí vstupní soubory v oblasti.
Nyní, kdykoli klient požádá o data, HBase ví, že data ze vstupních souborů jsou uložena v jednom souvislém souboru na disku – proto je potřeba pouze jedno vyhledávání, zatímco dříve mohlo být vyžadováno jedno pro každý soubor. Disk IO však není zdarma a bez pečlivé pozornosti může opakované přepisování dat vést k vážnému nadměrnému odběru sítě a disku. Jinými slovy, komprimace je o výměně některých IO disku nyní za méně hledání později.
V tomto příspěvku se dozvíte více o použití a důsledcích zhutňování v CDH 4, stejně jako o změnách modelu zhutňování v CDH 5 (který bude nově založen na HBase 0.96).
Zhutnění v CDH 4
Ideální komprimace by vybrala soubory, které sníží nejvíce hledání při nadcházejících čteních, a zároveň vybere soubory, které budou potřebovat nejmenší množství IO. Bohužel tento problém není řešitelný bez znalosti budoucnosti. Jako takový je to jen ideál, o který by se HBase měla snažit, a ne něco, co je někdy skutečně dosažitelné.
Namísto nemožného ideálu používá HBase heuristiku ke zkoušení a výběru souborů v obchodě, které jsou pravděpodobně vhodnými kandidáty. Soubory jsou vybírány na základě intuice, že podobné soubory by měly být kombinovány s podobnými soubory – to znamená, že by se měly kombinovat soubory, které jsou přibližně stejné velikosti.
Výchozí zásada v HBase 0.94 (dodává se v CDH 4) prohlíží seznam HFiles a snaží se najít první soubor, který má velikost menší než součet všech souborů vynásobený hbase.store.compaction.ratio. Jakmile je tento soubor nalezen, vybere se soubor HFfile a všechny soubory s menšími ID sekvence ke komprimaci.
Ve výchozím případě, kdy největší soubory jsou nejstarší, tento přístup funguje dobře:
Tento předpoklad o korelaci mezi stářím a velikostí souborů je však v některých případech chybný, což vede k tomu, že současný algoritmus není optimální. Hromadně načtené soubory mohou a někdy se také třídí velmi odlišně od běžněji vyčištěných souborů HFiles, takže jsou skvělými příklady:
Změny zhutnění v CDH 5
Zhutňování se v poslední době výrazně změnilo. U HBase 0.96 a CDH 5 byl algoritmus výběru souborů konfigurovatelný pomocí HBASE-7516 – takže je nyní možné mít uživatelem dodané zásady zhutňování. Tato změna umožňuje zkušenějším uživatelům testovat a opakovat, jak chtějí spouštět komprimace.
Výchozí algoritmus výběru komprimace byl také změněn na ExploringCompactionPolicy. Tato zásada se liší od staré výchozí hodnoty v tom, že zajišťuje, že každý jednotlivý soubor v navrhované komprimaci bude v daném poměru. Také nevybírá pouze první sadu souborů, které mají velikost v rámci komprimačního poměru; místo toho se podívá na všechny možné sady, které neporušují žádná pravidla, a pak vybere něco, co se zdá být nejpůsobivější při nejmenším očekávaném množství IO. Za tímto účelem zvolí ExploringCompactionPolicy zhutnění, které odstraní nejvíce souborů v rámci poměru, a pokud existuje shoda, dává se přednost sadě souborů, které jsou menší velikosti:
Pro budoucí vydání jsou plánovány další změny, včetně stupňovitého zhutňování, pruhovaného zhutňování a zhutňování na základě úrovní.
Závěr
V některých případech použití tato práce nebude mít vůbec žádný dopad. To je dobrá věc, protože zhutnění již bylo docela dobře prozkoumáno. Pro uživatele, kteří mají velké výkyvy provozu nebo kteří používají hromadné načítání, však tato práce může přinést velké zlepšení čekacích dob IO a latence požadavků. U konkrétního případu použití hromadného zatížení jsme zaznamenali 90% snížení I/O disku v důsledku zhutnění.
Zde jsou výsledky z testovacího případu v HBase PerfTestCompactionPolicies:
Podívejte se na tuto práci v CDH 5 (ve verzi beta v době psaní tohoto článku), pokud jde o cluster ve vaší blízkosti.
Další čtení:
- Prozkoumání zásad zhutňování
- 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/