Poradce Pro Apache HBase ve službě Azure HDInsight

  • Článek

Tento článek popisuje několik rad, které vám pomůžou optimalizovat výkon Apache HBase ve službě Azure HDInsight.

Optimalizace HBase pro čtení naposledy zapsaných dat

Pokud váš případ použití zahrnuje čtení naposledy zapsaných dat z HBase, může vám pomoct tento poradce. Pro vysoký výkon je optimální, aby čtení HBase bylo obsluhované ze memstorevzdáleného úložiště místo ze vzdáleného úložiště.

Poradce pro dotazy označuje, že pro danou řadu sloupců v tabulce > 75 % přečte, která se obsluhují z memstore. Tento indikátor naznačuje, že i v případě, že dojde k vyprázdnění nedávného memstore souboru, musí být přístupný a musí být v mezipaměti. Data se nejprve zapíšou do memstore systému, který přistupuje k nedávným datům tam. Je možné, že vlákna interního vyprázdnění HBase zjistí, že daná oblast dosáhla velikosti 128 min (výchozí) a můžou aktivovat vyprázdnění. Tento scénář se stává i u nejnovějších dat, která byla zapsána, když memstore byla velikost přibližně 128 min. Proto pozdější čtení těchto nedávných záznamů může vyžadovat čtení souboru, nikoli z memstore. Proto je nejlepší optimalizovat, aby se v mezipaměti mohla nacházet i nedávno vyprázdněná data.

Pokud chcete optimalizovat nedávná data v mezipaměti, zvažte následující nastavení konfigurace:

  1. Nastavte hbase.rs.cacheblocksonwrite na hodnotu true. Tato výchozí konfigurace v HDInsight HBase je true, takže zkontrolujte, jestli není resetovaná na false.

  2. hbase.hstore.compactionThreshold Zvyšte hodnotu, abyste se vyhnuli komprimování. Ve výchozím nastavení touto hodnotou je 3. Můžete ho zvýšit na vyšší hodnotu, například 10.

  3. Pokud budete postupovat podle kroku 2 a nastavíte compactionThreshold, změňte hbase.hstore.compaction.max na vyšší hodnotu, například 100, a také zvyšte hodnotu konfigurace hbase.hstore.blockingStoreFiles na vyšší hodnotu, například 300.

  4. Pokud jste si jistí, že potřebujete číst jenom nedávná data, nastavte hbase.rs.cachecompactedblocksonwrite konfiguraci na ZAPNUTO. Tato konfigurace říká systému, že i v případě komprimace zůstanou data v mezipaměti. Konfigurace je možné nastavit také na úrovni rodiny.

    Spuštěním následujícího příkazu v prostředí HBase nastavte hbase.rs.cachecompactedblocksonwrite konfiguraci:

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

  5. Mezipaměť bloku je možné vypnout pro danou rodinu v tabulce. Ujistěte se, že je zapnutá pro rodiny, které mají nejnovější čtení dat. Ve výchozím nastavení je mezipaměť bloku zapnutá pro všechny rodiny v tabulce. Pokud jste zakázali mezipaměť bloků pro řadu a potřebujete ji zapnout, použijte příkaz alter z prostředí hbase.

    Tyto konfigurace pomáhají zajistit, aby data byla k dispozici v mezipaměti a aby nedávná data neprošla komprimací. Pokud je hodnota TTL ve vašem scénáři možná, zvažte použití komprimace s datovou vrstvou. Další informace najdete v referenční příručce k Apache HBase: Komprimace vrstveného data.

Optimalizace fronty vyprázdnění

Tento poradce označuje, že vyprázdnění HBase může vyžadovat ladění. Aktuální konfigurace obslužných rutin vyprázdnění nemusí být dostatečně vysoká pro zpracování provozu zápisu, což může vést ke zpomalení vyprázdnění.

V uživatelském rozhraní serveru oblastí si všimněte, že fronta vyprázdnění překročí 100. Tato prahová hodnota označuje, že vyprázdnění je pomalé a možná budete muset vyladit hbase.hstore.flusher.count konfiguraci. Ve výchozím nastavení je hodnota 2. Ujistěte se, že maximální počet vláken vyprázdnění se nezvětší nad 6.

Dále se podívejte, jestli máte doporučení pro ladění počtu oblastí. Pokud ano, doporučujeme vyzkoušet ladění oblastí a zjistit, jestli to pomůže při rychlejším vyprázdnění. V opačném případě vám může pomoct ladění vláken vyprázdnění.

Ladění počtu oblastí

Poradce pro ladění počtu oblastí indikuje, že HBase zablokoval aktualizace a počet oblastí může být větší než optimálně podporovaná velikost haldy. Můžete vyladit velikost haldy, memstore velikost a počet oblastí.

Příklad scénáře:

  • Předpokládejme, že velikost haldy pro oblastní server je 10 GB. Ve výchozím nastavení hbase.hregion.memstore.flush.size je 128M. Výchozí hodnota pro hbase.regionserver.global.memstore.size je 0.4. To znamená, že z 10 GB jsou 4 GB přiděleny ( memstore globálně).

  • Předpokládejme, že ve všech oblastech existuje rovnoměrné rozdělení zatížení zápisu a za předpokladu, že každá oblast naroste až na 128 MB, ale maximální počet oblastí v tomto nastavení je 32 oblast. Pokud je server dané oblasti nakonfigurovaný tak, aby měl 32 oblastí, systém se lépe vyhne blokování aktualizací.

  • S těmito nastaveními je počet oblastí 100. Globální velikost 4 GB memstore je teď rozdělená do 100 oblastí. Takže v podstatě každá oblast získá pouze 40 MB pro memstore. Pokud jsou zápisy jednotné, systém provede časté vyprázdnění a menší velikost objednávky < 40 MB. S mnoha vlákny proplachování může zvýšit rychlost hbase.hstore.flusher.countsplachování .

Doporučení znamená, že by bylo dobré zvážit počet oblastí na server, velikost haldy a konfiguraci globální memstore velikosti spolu s laděním vyprázdnění vláken, aby se zabránilo zablokování aktualizací.

Ladění fronty komprimace

Pokud fronta komprimace HBase naroste na více než 2000 a dochází k tomu pravidelně, můžete zvýšit počet vláken komprimace na větší hodnotu.

Pokud existuje nadměrný počet souborů pro komprimování, může to vést k většímu využití haldy v souvislosti s tím, jak soubory interagují se systémem souborů Azure. Proto je lepší komprimovat co nejrychleji. Někdy ve starších clusterech můžou konfigurace komprimace související s omezováním vést k nižší míře komprimace.

Zkontrolujte konfigurace hbase.hstore.compaction.throughput.lower.bound a hbase.hstore.compaction.throughput.higher.bound. Pokud už jsou nastavené na 50M a 100M, nechte je tak, jak jsou. Pokud jste ale tato nastavení nakonfigurovali na nižší hodnotu (což byl případ starších clusterů), změňte limity na 50M a 100M.

Konfigurace jsou hbase.regionserver.thread.compaction.small a hbase.regionserver.thread.compaction.large (výchozí hodnoty jsou 1 každý). Maximální hodnota této konfigurace je menší než 3.

Kontrola celé tabulky

Poradce pro kontrolu celé tabulky označuje, že více než 75 % vydaných kontrol představují úplné kontroly tabulky nebo oblasti. Pokud chcete zlepšit výkon dotazů, můžete se znovu vrátit k tomu, jak kód volá skeny. Zvažte následující postupy:

  • Nastavte správný počáteční a zastavovací řádek pro každou kontrolu.

  • Pomocí rozhraní API MultiRowRangeFilter můžete dotazovat různé rozsahy v jednom volání kontroly. Další informace najdete v dokumentaci k rozhraní API MultiRowRangeFilter.

  • V případech, kdy potřebujete prohledat celou tabulku nebo oblast, zkontrolujte, jestli existuje možnost vyhnout se používání mezipaměti pro tyto dotazy, aby ostatní dotazy, které používají mezipaměť, nemusely vyřadit bloky, které jsou horké. Pokud chcete zajistit, aby kontroly nepoužívala mezipaměť, použijte rozhraní API pro kontrolu s možností setCaching(false) v kódu:

    scan#setCaching(false)

Další kroky

Optimalizace Apache HBase pomocí Ambari