Testování výkonu HBase pomocí YCSB

Při spouštění jakéhokoli nástroje pro srovnávání výkonu ve vašem clusteru je vždy kritickým rozhodnutím, jaká velikost datové sady by měla být použita pro test výkonu, a zde si ukážeme, proč je důležité vybrat „vhodnou“ velikost datové sady při spuštění výkonu HBase. otestujte na svém clusteru.

Konfigurace clusteru HBase a velikost datové sady mohou měnit výkon vaší pracovní zátěže a výsledky testů na stejném clusteru. Velikost této datové sady byste měli vybrat na základě toho, co se snažíte pochopit o výkonu vašeho clusteru. Abychom ukázali rozdíl mezi pracovní sadou, která se vejde do dostupné mezipaměti, a sadou, kterou je třeba načíst ze základního úložiště, provedli jsme 2 testy pracovní zátěže YCSB s vhodně zvolenými velikostmi sady dat na stejném clusteru operační databáze CDP Private Cloud Base 7.2.2. Použili jsme velikosti datových sad 40 GB vs 1 TB a propustnost pro různé pracovní zátěže YCSB je porovnána níže, v grafu čím vyšší pruh, tím lepší propustnost.

Poznámka:Propustnost =Operace za sekundu

Když se aplikace pokusí provést čtení z clusteru HBase, oblastní server zpracovávající požadavek nejprve zkontroluje, zda jsou potřebné výsledky v datovém bloku, který je již lokální pro její proces prostřednictvím mezipaměti bloků. Pokud je datový blok přítomen, požadavek klienta lze obsloužit přímo z mezipaměti a to se počítá jako zásah do mezipaměti. Pokud však blok není aktuálně lokální pro proces Region Server, pak se to počítá jako vynechání mezipaměti a musí být načteno ze souboru HF v úložišti HDFS. V závislosti na využití mezipaměti bude tento blok uložen do mezipaměti pro budoucí požadavky.

Jak se očekávalo a je vidět v souhrnném grafu, pracovní zátěž, kde se většina datových souborů vejde do mezipaměti, má nižší latence a propustnost je mnohem vyšší v porovnání s pracovní zátěží, kdy se k datům přistupuje z HFiles v úložišti HDFs.

Abychom vybrali velikosti souboru dat o pracovní zátěži tak, aby dobře splňovaly naše testovací cíle, je důležité zkontrolovat velikosti hald RegionServer, mezipaměti L1 a L2, mezipaměti vyrovnávací paměti operačního systému a poté nastavit vhodnou velikost datové sady. Po dokončení běhu zátěže YCSB je dobrým parametrem ke kontrole, jak ověřit, že věci proběhly podle očekávání, kolik dat bylo obsluhováno z mezipaměti (zásah do mezipaměti) a kolik bylo zpřístupněno z úložiště hdfs. Tento poměr mezipaměti serveru Region Server k celkovému počtu požadavků na čtení je poměr mezipaměti.

Tyto informace můžete najít v konfiguraci L1 cache hit ratio „l1CacheHitRatio“. Pokud máte v clusteru nastaveny mezipaměti L1 i L2, pak mezipaměť L1 obsluhuje indexové bloky a mezipaměť L2 obsluhuje datové bloky a pro referenci můžete zaznamenat konfigurace L1 „l1CacheHitRatio“ a L2 „l2CacheHitRatio“.

Zbytek tohoto příspěvku na blogu probere podrobnosti našeho testovacího nastavení, výběr velikosti datové sady a následné spuštění YCSB s těmito velikostmi datové sady.

Konfigurace clusteru HBase použitá pro tento test:

• Použitý cluster: 6 uzlový cluster (1 hlavní + 5 regionálních serverů)
• Popis: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2,2 GHz, 128 GB RAM, 4–2 TB disky
• Zabezpečení: Není nakonfigurováno (žádné Kerberos)
• Verze CDP: CDP Private Cloud Base 7.2.2 6 uzlový cluster HBase s 1 hlavním serverem + 5 servery regionu
• JDK používá jdk1.8_232
• Servery HBase Region byly nakonfigurovány s 32GB haldou 
• HBase master byl nakonfigurován s haldou 4 GB
• Cache L1 s LruBlockCache byla použita s velikostí mezipaměti 12,3 GB
• Celková mezipaměť L1 v clusteru je 61 GB (12,3 * 5 =61 GB)
• Vypnutá mezipaměť haldy L2 nebyla v clusteru nakonfigurována

Případ velikosti 1:Data se zcela vejdou do dostupné mezipaměti v clusteru

V našem clusteru HBase jsme nakonfigurovali celkem 61 GB (12,3 GB *5) na 5 serverech regionů přidělených pro mezipaměť bloku L1. Pro soubor dat, který se zcela vejde do mezipaměti, jsme vybrali soubor dat o velikosti 40 GB ve velikosti.

Případ velikosti 2:Soubor dat větší než dostupná mezipaměť v clusteru

Pro druhý scénář chceme, aby data byla mnohem větší než dostupná mezipaměť. Abychom vybrali vhodnou velikost datové sady, podívali jsme se jak na nakonfigurovanou mezipaměť bloku HBase, tak na mezipaměť vyrovnávací paměti OS v clusteru. V našem daném clusteru HBase je konfigurovaná mezipaměť bloku L1 61G, když je agregována mezi servery RegionServers. Každý z uzlů serveru měl celkem 128 G RAM a libovolnou paměť, která nebyla vyhrazena pro serverový proces, může operační systém využít k efektivní mezipaměti základních bloků HDFS a ke zvýšení celkové propustnosti. V naší testovací konfiguraci je pro tento účel na každém uzlu regionálního serveru k dispozici přibližně 96G mezipaměť operačního systému (ignoruje se paměť používaná procesy DataNode nebo OS pro zjednodušení). Při agregaci mezi servery 5 regionů jsme měli potenciál téměř 500G pro vyrovnávací paměti (96G * servery 5 regionů). Zvolili jsme tedy velikost datové sady 1 TB, která překračuje nakonfigurovanou mezipaměť bloků i dostupnou vyrovnávací paměť operačního systému.

Přeměna cílových velikostí dat na parametry YCSB

V YCSB má řádek ve výchozím nastavení 1 kB, takže v závislosti na tom, kolik řádků načtete do YCSB ‚usertable‘, můžete snadno odhadnout velikost dat vaší ‚usertable‘ tabulky YCSB. Pokud tedy nahrajete 1 milion řádků, nahráli jste 1 000 000 * 1 kB =1 GB dat do YCSB  ‘usertable’.

Velikosti datových souborů použité pro naše dva testy byly:

• 40 GB dat se 40 miliony řádků
• 1 TB dat s 1 miliardou řádků 

Metodika testu

CDP Private Cloud Base 7.2.2 byl nainstalován na 6uzlovém clusteru a byla vygenerována data o pracovní zátěži se 40 miliony řádků (celková velikost sady dat => 40 GB ) a byly spuštěny úlohy YCSB. Po načtení jsme před zahájením testu zátěže čekali na dokončení všech operací zhutňování.

Úlohy YCSB, které byly spuštěny na HBase, byly

1. Úloha A:50 % čtení a 50 % aktualizace
2. Úloha C:100% čtení 
3. Pracovní zátěž F:50 % čtení a 50 % poměr aktualizace/čtení-upravování-zápis:50/50
4. Vytížení pouze pro vlastní aktualizaci:100% aktualizace
   

Každá pracovní zátěž YCSB (A, C, F a UpdateOnly) byla spuštěna každá po dobu 15 minut a celý běh byl opakován 5krát bez restartů mezi běhy, aby se změřila propustnost YCSB*. Zobrazené výsledky jsou průměry za poslední 3 běhy z 5 běhů. První 2 testovací běhy byly ignorovány, aby se předešlo penalizaci za první a druhý běh.

Po dokončení 40GB běhů jsme zrušili uživatelskou tabulku a znovu vygenerovali 1 miliardu řádků, abychom vytvořili datovou sadu o velikosti 1 TB, a znovu spustili testy se stejnou metodikou na stejném clusteru.

Výsledky testu

Výsledky YCSB s 40 GB

V případě 40GB se data zcela vejdou do 61GB L1 cache na clusteru. Poměr zásahů do mezipaměti L1 pozorovaný v clusteru během testu se blížil 99 %.

Tip: Pro menší datové sady, kde se data vejdou do mezipaměti, můžeme také použít možnost mezipaměti při načtení a předehřát mezipaměť, abychom získali 100% poměr mezipaměti pomocí možnosti tabulky PREFETCH_BLOCKS_ON_OPEN

Každou zátěž YCSB jsme provedli 5krát po 15 minutách a vzali jsme průměry z posledních 3 běhů, abychom se vyhnuli penalizaci za první běh.

Výsledky zaznamenané s poměrem zásahů mezipaměti 40G L1 99 % na regionálních serverech jsou uvedeny níže v tabulce: 

Výsledky YCSB s 1TB datovým souborem

V případě 1 TB se data nevejdou do mezipaměti 61 GB L1 v clusteru nebo 500 GB mezipaměti operačního systému. Poměr zásahů do mezipaměti L1 v clusteru pozorovaný během testu byl 82–84 %.

Každou zátěž jsme provedli 5krát po 15 minutách a vzali jsme průměry z posledních 3 běhů, abychom se vyhnuli penalizaci za první běh.

Výsledky zaznamenané s 1 TB Poměr požadavků na mezipaměť L1 82–84 % na regionálních serverech jsou uvedeny níže v tabulce: 

*Propustnost (ops/s) =počet operací za sekundu

Analýza:

Porovnáním výsledků testů pro dvě různé velikosti datových sad výše vidíme, jak se stejná propustnost pracovního zatížení může lišit od 3 000 operací za sekundu do 165 000 operací za sekundu když se k datům přistupuje rychleji z datové sady 40G s vyhřívanou mezipamětí než z úložiště HDF.

Níže uvedený graf ukazuje propustnost a porovnává, jak se propustnost změnila pro různé pracovní zátěže při spuštění se 2 různými velikostmi datových sad. Čím vyšší sloupec v grafu, tím lepší propustnost.

Poznámka:Propustnost =Operace za sekundu

Jak je vidět v grafu, pracovní zátěže YCSB, které čtou data jako pracovní zátěž A, pracovní zátěž C a pracovní zátěž F, měly mnohem lepší propustnost v případě 40G, kdy se data snadno vešla do mezipaměti, než v případě o velikosti dat 1 TB, kde musela být data HFfile. přístupné z HDFS

Podíváme-li se na poměry přístupů do mezipaměti, datová sada 40G měla poměr mezipaměti téměř 99 % a datová sada 1 TB měla poměr mezipaměti asi 85 %, takže 15 % dat v případě 1TB bylo zpřístupněno z úložiště HDF. .

Vlastní pracovní zátěž pouze aktualizace YCSB, kterou jsme spustili, měla v obou případech stejnou propustnost, protože prováděla pouze aktualizace a žádná čtení.

Během výkonu HBase pozorně sledujeme latence 95. a 99. percentilu. Průměrná latence je pouze celková propustnost dělená celkovým časem, avšak 95. percentil a 99. percentil ukazují skutečné odlehlé hodnoty, které ovlivňují celkovou propustnost pracovní zátěže. V případě 1 TB odlehlé hodnoty vysoké latence v 95. a 99. percentilu způsobují zpomalení propustnosti a v případě 40 GB vedou zásahy do mezipaměti s nízkou latencí v 99. percentilu ke zvýšení celkové propustnosti.

Níže uvedený graf ukazuje srovnání latence pro průměrnou latenci, 95. percentilovou latenci a 99. percentilovou latenci a jak se liší pro různé pracovní zátěže při spuštění s různými velikostmi datových souborů.

Ve výše uvedeném grafu je těžké vidět pruhy představující latenci pro 40GB datovou sadu, protože jsou extrémně nízké ve srovnání s latencí pozorovanou pro 1TB datovou sadu pro přístup k datům z HDF.

Graf latence jsme vynesli pomocí logu hodnot latence, abychom ukázali rozdíl v grafu níže

Jak je vidět výše, latence jsou mnohem nižší v případě 40 GB, kde se poměr zásahů do mezipaměti blíží 99 % a většina dat o pracovní zátěži je k dispozici v mezipaměti. Ve srovnání s datovou sadou o velikosti 1 TB byl poměr přístupů do mezipaměti přibližně 85 %, protože k datům HFile bylo nutné přistupovat z úložiště HDFS.

Průměrná a 99 latence pro pracovní zátěž C v případě 40G, kdy se 99 % dat vrací ze zahřáté mezipaměti, byla kolem 2 – 4 ms. Latence 99. percentilu pro stejnou pracovní zátěž C v případě 1 TB byla kolem 100 ms pro pracovní zátěž C (pracovní zátěž pouze pro čtení).

To ukazuje, že přístup do mezipaměti z mezipaměti bloků na haldě vrátí čtení za přibližně 2 ms a vynechání mezipaměti a získání záznamu z HDFS může v tomto clusteru trvat přibližně 100 ms.

Doporučení: 

Když spouštíte srovnávací test YCSB, velikost datové sady má podstatný rozdíl ve výsledcích výkonu, a proto je vhodná velikost testu velmi důležitá. Pohled na poměr mezipaměti a rozdíly v latenci mezi minimální a 99. latencí vám zároveň pomůže najít latenci přístupu do mezipaměti ve srovnání s přístupem k datům ze základního úložiště v clusteru.

Tip:

Pro kontrolu poměrů přístupů do mezipaměti vaší pracovní zátěže na regionálním serveru můžete použít níže uvedený příkaz

curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio

Poměr přístupů do mezipaměti můžete také zobrazit z webového uživatelského rozhraní HBase podle následujících kroků:

1. Ve webovém uživatelském rozhraní HBase klikněte na server regionu 
2. V části Blokovat mezipaměť vyberte L1 (a L2, pokud je nakonfigurována L2), abyste zkontrolovali poměry přístupů do mezipaměti.

Snímek obrazovky ukazující poměr zásahů do mezipaměti z mezipaměti bloku L1 je uveden níže:

Zde je odkaz na další informace o snímku obrazovky HBase zobrazeném výše a blokovací mezipaměti https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

O YCSB

YCSB je open-source specifikace a sada programů pro vyhodnocování možností vyhledávání a údržby počítačových programů. Jedná se o velmi oblíbený nástroj používaný k porovnání relativního výkonu systémů správy databází NoSQL.

Chcete-li použít YCSB k testování výkonu provozní databáze, podívejte se na blog Jak spustit YCSB pro HBase