Řešení potíží s výkonem Apache HBase ve službě Azure HDInsight
Tento článek popisuje různé pokyny a tipy pro ladění výkonu Apache HBase pro zajištění optimálního výkonu ve službě Azure HDInsight. Mnoho z těchto tipů závisí na konkrétní úloze a vzoru čtení/zápisu/skenování. Před použitím změn konfigurace v produkčním prostředí je důkladně otestujte.
Přehledy výkonu HBase
Hlavním kritickým bodem většiny úloh HBase je protokol WAL (Write Ahead Log). Má závažný dopad na výkon zápisu. HDInsight HBase má oddělený model výpočetních prostředků úložiště. Data se ukládají vzdáleně ve službě Azure Storage, i když virtuální počítače hostují servery oblastí. Donedávna se wal také zapsal do Azure Storage. V HDInsight toto chování zmocnilo toto kritické body. Funkce Akcelerované zápisy je navržená k vyřešení tohoto problému. Zapisuje WAL na disky spravované disky SSD úrovně Azure Premium. To výrazně přináší výhody výkonu zápisu a pomáhá mnoha problémům způsobeným některými úlohami náročnými na zápis.
Pokud chcete zlepšit operace čtení, použijte jako vzdálené úložiště účet služby Blob Storage úrovně Premium. Tato možnost je možná jenom v případě, že je povolená funkce WAL.
Stlačení
Komprimace je dalším potenciálním kritickým bodem, na kterém se v komunitě v zásadě dohodne. Ve výchozím nastavení je velké komprimování v clusterech HDInsight HBase zakázané. Komprimace je zakázaná, protože i když jde o proces náročný na prostředky, mají zákazníci plnou flexibilitu při plánování podle svých úloh. Například ho můžou naplánovat mimo špičku. Umístění dat také není problém, protože naše úložiště je vzdálené (zálohované službou Azure Storage) místo místního systému souborů HDFS (Hadoop Distributed File System).
Zákazníci by měli naplánovat velké komprimace na své pohodlí. Pokud tuto údržbu neprovedou, komprimace bude mít nepříznivý vliv na výkon čtení v dlouhodobém horizontu.
U operací prohledávání by měla být příčinou obav latence, které jsou mnohem vyšší než 100 milisekund. Zkontrolujte, jestli je správně naplánováno hlavní komprimace.
Apache Phoenix – úloha
Odpovědi na následující otázky vám pomůžou lépe porozumět úlohě Apache Phoenix:
- Překládají se všechny vaše "čtení" na kontroly?
- Pokud ano, jaké jsou charakteristiky těchto kontrol?
- Optimalizovali jste schéma tabulky Phoenix pro tyto kontroly, včetně odpovídajícího indexování?
- Použili jste tento
EXPLAIN
příkaz k pochopení plánů dotazů, které generuje vaše "čtení"? - Píšete "upsert-selects"?
- Pokud ano, budou také provádět kontroly. Očekávaná latence prohledávání průměrně přibližně 100 milisekund ve srovnání s 10 milisekundami pro bod se v HBase dostane.
Metodologie testů a monitorování metrik
Pokud používáte srovnávací testy, jako je Yahoo! Cloud Serving Benchmark, JMeter nebo Pherf pro testování a ladění výkonu se ujistěte, že:
Klientské počítače se nestaly kritickým bodem. Provedete to tak, že zkontrolujete využití procesoru na klientských počítačích.
Konfigurace na straně klienta, jako je počet vláken, jsou správně vyladěny tak, aby saturovaly šířku pásma klienta.
Výsledky testů se zaznamenávají přesně a systematicky.
Pokud se vaše dotazy náhle začaly výrazně zhoršit než dřív, zkontrolujte potenciální chyby v kódu aplikace. Generuje se náhle velké objemy neplatných dat? Pokud ano, může zvýšit latenci čtení.
problémy s migrací
Pokud migrujete do Služby Azure HDInsight, ujistěte se, že se migrace provádí systematicky a přesně, nejlépe prostřednictvím automatizace. Vyhněte se ruční migraci. Ujistěte se, že:
Atributy tabulky se migrují přesně. Atributy mohou být zahrnuty jako komprese, bloom filtry a tak dále.
Nastavení solení v tabulkách Phoenix se správně mapuje na novou velikost clusteru. Například počet solných kbelíků by měl být násobkem počtu pracovních uzlů v clusteru. A měli byste použít násobek, který je faktorem množství horkého spotování.
Ladění konfigurace na straně serveru
V HDInsight HBase jsou HFiles uložené ve vzdáleném úložišti. Když dojde k chybě mezipaměti, náklady na čtení jsou vyšší než místní systémy, protože data v místních systémech jsou založená na místním HDFS. Pro většinu scénářů je inteligentní použití mezipamětí HBase (mezipaměť bloků a mezipaměti kontejnerů) navržené tak, aby tento problém obcházel. V případech, kdy problém nejde obejít, může tento problém pomoct použití účtu objektů blob bloku úrovně Premium. Ovladač objektů blob služby Windows Azure Storage spoléhá na určité vlastnosti, jako fs.azure.read.request.size
je načtení dat v blocích na základě toho, co určuje, že se má režim čtení (sekvenční a náhodné), takže může docházet k instancím vyšší latence při čtení. Pomocí empirických experimentů jsme zjistili, že nastavení velikosti bloku požadavku pro čtení (fs.azure.read.request.size
) na 512 kB a porovnávání velikosti bloku tabulek HBase tak, aby byla stejná velikost, vede k dosažení nejlepšího výsledku v praxi.
Pro většinu clusterů s velkými uzly poskytuje bucketcache
HDInsight HBase jako soubor na místním disku SSD úrovně Premium, který je připojený k virtuálnímu počítači, který běží regionservers
. Použití mezipaměti mimo haldu může místo toho přinést určité vylepšení. Toto alternativní řešení má omezení použití dostupné paměti a potenciálně menší než mezipaměť založená na souborech, takže nemusí být vždy nejlepší volbou.
Následuje několik dalších specifických parametrů, které jsme naladili, a které se zdají pomoci různým stupňům:
Zvětšete
memstore
velikost z výchozích 128 MB na 256 MB. Obvykle se toto nastavení doporučuje pro scénáře náročného zápisu.Zvětšete počet vláken vyhrazených pro komprimace z výchozího nastavení 1 na 4. Toto nastavení je relevantní, pokud pozorujeme časté menší komprimace.
Vyhněte se blokování
memstore
vyprázdnění kvůli limitu úložiště. Pokud chcete tuto vyrovnávací paměť poskytnout, zvyšteHbase.hstore.blockingStoreFiles
nastavení na 100.K řízení vyprázdnění použijte následující nastavení:
Hbase.regionserver.maxlogs
: 140 (vyhne se vyprázdnění kvůli limitům WAL)Hbase.regionserver.global.memstore.lowerLimit
: 0,55Hbase.regionserver.global.memstore.upperLimit
: 0.60
Konfigurace specifické pro Phoenix pro ladění fondu vláken:
Phoenix.query.queuesize
: 10000Phoenix.query.threadpoolsize
: 512
Další konfigurace specifické pro Phoenix:
Phoenix.rpc.index.handler.count
: 50 (pokud existuje velké nebo mnoho vyhledávání indexů)Phoenix.stats.updateFrequency
: 1 hodinaPhoenix.coprocessor.maxmetadatacachetimetolivems
: 1 hodinaPhoenix.coprocessor.maxmetadatacachesize
: 50 MB
Časové limity RPC: 3 minuty
- K vypršení časových limitů rpc rpc patří vypršení časového limitu HBase, vypršení časového limitu klientského skeneru HBase a vypršení časového limitu dotazu Phoenix.
- Ujistěte se, že
hbase.client.scanner.caching
je parametr nastavený na stejnou hodnotu na straně serveru i na straně klienta. Pokud nejsou stejné, toto nastavení vede k chybám na straně klienta, které souvisejí sOutOfOrderScannerException
. Toto nastavení by mělo být nastaveno na nízkou hodnotu pro velké kontroly. Tuto hodnotu nastavíme na 100.
Ostatní úvahy
Další parametry, které je potřeba zvážit při ladění:
Hbase.rs.cacheblocksonwrite
– ve výchozím nastavení v HDI je toto nastavení nastaveno na true.Nastavení, která umožňují odložit menší komprimace pro pozdější použití.
Experimentální nastavení, například úprava procent front, které jsou vyhrazené pro požadavky na čtení a zápis.
Další kroky
Pokud váš problém zůstane nevyřešený, navštivte jeden z následujících kanálů, kde získáte další podporu:
Získejte odpovědi od odborníků na Azure prostřednictvím podpory komunity Azure.
Připojte se pomocí @AzureSupport. Toto je oficiální účet Microsoft Azure pro zlepšení zákaznického prostředí. Propojuje komunitu Azure se správnými prostředky: odpověďmi, podporou a odborníky.
Pokud potřebujete další pomoc, můžete odeslat žádost o podporu z webu Azure Portal. V řádku nabídek vyberte možnost Podpora nebo otevřete centrum nápovědy a podpory . Podrobnější informace najdete v tématu Vytvoření žádosti o podpora Azure. Vaše předplatné Microsoft Azure zahrnuje přístup ke správě předplatného a podpoře fakturace a technická podpora je poskytována prostřednictvím jednoho z plánů podpora Azure.