Informační zpravodaje Apache HBase ve službě Azure HDInsight

Tento článek popisuje několik doporučení, 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 tento poradce pomoct. Pro zajištění vysokého výkonu je optimální, aby čtení HBase bylo možné obsluhovat z memstorevzdáleného úložiště místo 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 když dojde memstore k vyprázdnění v nedávném souboru, musí být přístupný a musí být v mezipaměti. Data se nejprve zapíšou do memstore systému, kde se k posledním datům přistupuje. Je možné, že interní vlákna vyprázdnění HBase zjistí, že daná oblast dosáhla 128M (výchozí) velikosti a může aktivovat vyprázdnění. Tento scénář se stává dokonce i nejnovějšími daty, která byla zapsána, když memstore byla velikost přibližně 128 M. Proto pozdější čtení těchto posledních záznamů může vyžadovat čtení souboru, nikoli z memstore. Proto je nejlepší optimalizovat, aby se v mezipaměti mohly nacházet i nedávná data, která se nedávno vyprázdnila.

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, zda není resetová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 provedete krok 2 a nastavíte komprimaceThreshold, změňte hbase.hstore.compaction.max například 100na vyšší hodnotu 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. Blokovou mezipaměť je možné vypnout pro danou rodinu v tabulce. Ujistěte se, že je zapnutá pro rodiny s nejnovějšími čteními dat. Ve výchozím nastavení je bloková mezipaměť 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 že nedávná data neprocházejí komprimací. Pokud je ve vašem scénáři možný hodnota TTL, zvažte použití komprimace vrstvené podle data. Další informace najdete v referenční příručce k Apache HBase: Komprimace vrstveného data

Optimalizace fronty vyprázdnění

Tento poradce značí, ž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í s provozem zápisu, který může vést ke zpomalení vyprázdnění.

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

Kromě toho se podívejte, jestli máte doporučení pro ladění počtu oblastí. Pokud ano, doporučujeme vyzkoušet ladění oblastí, abyste zjistili, jestli vám to pomůže rychleji vyprázdnit. 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í oblastí označuje, ž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í.

Jako ukázkový scénář:

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

• Předpokládejme, že existuje rovnoměrná distribuce zatížení zápisu pro všechny oblasti a za předpokladu, že každá oblast roste až na 128 MB, pouze pak maximální počet oblastí v tomto nastavení je 32 oblast. Pokud je daný server oblasti nakonfigurovaný tak, aby měl 32 oblastí, systém lépe zabrání blokování aktualizací.

• S těmito nastaveními je počet oblastí 100. Globální memstore 4 GB je teď rozdělený mezi 100 oblastí. Každá oblast tak efektivně získá pouze 40 MB pro memstore. Pokud jsou zápisy jednotné, systém často vyprázdní a menší velikost objednávky < 40 MB. S mnoha nitěmi vyprázdnění může zvýšit rychlost hbase.hstore.flusher.countvyprázdnění .

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

Ladění fronty komprimace

Pokud fronta komprimace HBase roste na více než 2000 a probíhá pravidelně, můžete zkomprimovat vlákna na větší hodnotu.

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

Zkontrolujte konfigurace hbase.hstore.compaction.throughput.lower.bound a hbase.hstore.compaction.throughput.higher.bound. Pokud už jsou nastavené na 50 M a 100 M, nechte je tak, jak jsou. Pokud jste ale tato nastavení nakonfigurovali na nižší hodnotu (což byl případ u 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í hodnotu této konfigurace můžete nastavit tak, aby byla menší než 3.

Úplná kontrola tabulky

Poradce pro prohledávání celé tabulky označuje, že více než 75 % vydaných kontrol je úplné prohledávání tabulek a oblastí. Můžete se znovu vrátit ke způsobu, jakým váš kód volá kontroly, aby se zlepšil výkon dotazů. Zvažte následující postupy:

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

• Použijte rozhraní API MultiRowRangeFilter, abyste mohli dotazovat různé rozsahy v jednom volání kontroly. Další informace najdete v dokumentaci k rozhraní API MultiRowRangeFilter.

• V případech, kdy potřebujete úplnou tabulku nebo prohledávání oblastí, zkontrolujte, jestli není možné zabránit využití 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) ve vašem kódu:

  scan#setCaching(false)
  

Další kroky

Optimalizace Apache HBase pomocí Ambari