Тестване на производителността на HBase с помощта на YCSB

Когато изпълнявате какъвто и да е инструмент за сравнителен анализ на производителността във вашия клъстер, критично решение винаги е какъв размер на набора от данни трябва да се използва за тест за производителност и тук ние демонстрираме защо е важно да изберете размер на набора от данни за „добро съответствие“, когато изпълнявате HBase производителност тествайте на вашия клъстер.

Конфигурациите на клъстер HBase и размерът на набора от данни могат да променят производителността на вашето работно натоварване и резултатите от теста на един и същ клъстер. Трябва да изберете този размер на набора от данни въз основа на това, което се опитвате да разберете за производителността на вашия клъстер. За да покажем разликата между работен набор, който се вписва в наличния кеш памет, и този, който трябва да бъде прочетен от основното хранилище, проведохме 2 теста за натоварване на YCSB с подходящо избрани размери на набора от данни в един и същ клъстер CDP Private Cloud Base 7.2.2 Operation Database. Използвахме набори от данни с размери от 40GB срещу 1TB и пропускателната способност за различните YCSB работни натоварвания е сравнена по-долу, в диаграмата по-висока лентата, толкова по-добра е пропускателната способност.

Забележка:Пропускателна способност =Операции в секунда

Когато приложение се опита да извърши четене от HBase клъстер, регионалният сървър, обработващ заявката, първо проверява дали необходимите резултати са в блок данни, който вече е локален за неговия процес чрез неговия блоков кеш. Ако блокът от данни е налице, клиентската заявка може да бъде обслужена директно от кеша и това се брои като удар в кеша. Въпреки това, ако блокът в момента не е локален за процеса на регионалния сървър, тогава това се брои като пропуск в кеша и трябва да бъде прочетен от HFile в HDFS съхранение. В зависимост от използването на кеша, този блок ще бъде запазен в кеша за бъдещи заявки.

Както се очаква и се вижда в обобщената диаграма, работно натоварване, при което повечето набори от данни се вписват в кеша, има латентности, които са по-ниски, а пропускателната способност е много по-висока в сравнение с изпълнение на натоварване, при което се осъществява достъп до данни от HFiles в hdfs съхранение.

За да изберете размерите на набора от данни за работното ни натоварване, за да покрием добре нашите тестови цели, важно е да проверите размерите на купчини на RegionServer,  L1 и L2 кешове, кешове на буфера на операционната система и след това да зададете подходящ размер на набора от данни. След като изпълнение на работното натоварване на YCSB завърши, добър параметър за проверка като начин да се провери дали нещата се изпълняват според очакванията е колко от данните са били обслужвани от кеша (попадане в кеш) и колко е било достъпно от hdfs хранилище. Това съотношение на посещенията в кеша на регионалния сървър към общия брой заявки за четене е съотношението на посещения в кеша.

Можете да намерите тази информация от конфигурацията за съотношение на попадане в кеша L1 „l1CacheHitRatio“. Ако имате и двата кеша L1 и L2, зададени във вашия клъстер, тогава кешът L1 обслужва индексните блокове, а L2 кешът обслужва блоковете данни и можете да записвате и двете конфигурации L1 „l1CacheHitRatio“ и L2 „l2CacheHitRatio“ за справка.

Останалата част от тази публикация в блога ще разгледа подробности за нашата тестова настройка, като изберете размера на набора от данни и след това ще стартирате YCSB с тези размери на набора от данни.

Клъстерна конфигурация на HBase, използвана за този тест:

• Използван клъстер : Клъстер с 6 възли (1 главен + 5 регионални сървъра)
• Описание: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2.2Ghz, 128GB RAM, 4-2TB дискове
• Сигурност: Няма конфигуриран (без Kerberos)
• CDP версия: CDP Private Cloud Base 7.2.2 6  възел HBase клъстер с 1 главен + 5 регионални сървъра
• JDK използва jdk1.8_232
• Сървърите на регион HBase бяха конфигурирани с 32GB купчина 
• Главният HBase е конфигуриран с 4GB купчина
• L1 кеш с LruBlockCache беше използван с размер на кеша от 12,3 GB
• Общият кеш L1 в клъстера е 61 GB (12,3 * 5 =61 GB)
• L2 изключен кеш паметник не е конфигуриран в клъстера

Оразмеряване Случай 1:Данните напълно се вписват в наличния кеш на клъстера

В нашия HBase клъстер ние конфигурирахме общо 61GB (12.3GB *5) в 5-те регионални сървъра, разпределени за L1 блоков кеш. За набор от данни, който напълно се вписва в кеша, избрахме набор от данни, който беше 40GB в размер.

Оразмеряване Случай 2:Набор от данни е по-голям от наличния кеш в клъстера

За втория сценарий искаме данните да са много по-големи от наличния кеш. За да изберем подходящ размер на набора от данни, разгледахме както конфигурирания блоков кеш на HBase, така и кеша на буфера на операционната система в клъстера. В нашия даден HBase клъстер конфигурираният L1 блок кеш е 61G, когато се агрегира в регионалните сървъри. Сървърните възли имаха общо 128G RAM всеки и всяка памет, която не е предназначена за сървърен процес, може да се използва от ОС за ефективно кеширане на основните HDFS блокове и увеличаване на общата пропускателна способност. В нашата тестова конфигурация има около 96G кеш на ОС, наличен на всеки възел на сървъра на региона за тази цел (като се игнорира паметта, използвана от DataNode или процесите на OS, за да се опростят нещата). Обединявайки това в 5-те регионални сървъра, имахме потенциал от почти 500G за буфери (96G * 5 регионални сървъри). По този начин избрахме размер на набора от данни от 1TB, надхвърлящ както конфигурирания блок кеш, така и наличния буферен кеш на ОС.

Превръщане на размерите на целевите данни в параметри на YCSB

В YCSB редът е 1KB по подразбиране, така че в зависимост от това колко реда зареждате в YCSB „usertable“ можете лесно да прецените размера на данните на вашата YCSB „usertable“ таблица. Така че, ако качите 1 милион реда, вие сте качили 1 000 000 * 1 KB =1 GB данни в YCSB „userable“.

Размерите на набора от данни, използвани за нашите два теста, бяха:

• 40 GB данни с 40 милиона реда
• 1 TB данни с 1 милиард реда 

Методология на изпитване

CDP Private Cloud Base 7.2.2 беше инсталиран на клъстер с 6 възли и бяха генерирани данни за работното натоварване с 40 милиона реда (общ размер на набора от данни => 40 GB) и бяха стартирани YCSB работни натоварвания. След зареждането изчакахме да приключат всички операции по уплътняване, преди да започнем теста на работното натоварване.

YCSB работните натоварвания, които се изпълняваха на HBase, бяха

1. Работно натоварване A:50% четене и 50% актуализиране
2. Работно натоварване C:100% четене 
3. Работно натоварване F:50% четене и 50% съотношение актуализиране/четене-промяна-запис:50/50
4. Натоварване само за персонализирана актуализация:100% актуализация
   

Всяко YCSB работно натоварване (A,C,F и UpdateOnly) се изпълняваше в продължение на 15 минути всяко и пълното изпълнение се повтаря 5 пъти без рестартиране между циклите за измерване на пропускателната способност на YCSB*. Показаните резултати са средни стойности, взети за последните 3 цикъла от 5-те цикъла. Първите 2 пробни проби бяха игнорирани, за да се избегне наказанието за първи и втори цикъл.

След като бяха завършени 40GB тестове, изхвърлихме потребителската таблица и отново генерирахме 1 милиард реда, за да създадем размер на набора от данни от 1TB и изпълнихме отново тестовете със същата методология в същия клъстер.

Резултати от теста

YCSB резултати с 40GB

В случая от 40 GB данните могат напълно да се поберат в 61 GB L1 кеш памет на клъстера. Съотношението на попадане в кеша L1, наблюдавано в клъстера по време на теста, беше близо до 99%.

Съвет: За по-малки набори от данни, където данните могат да се поберат в кеша, можем също да използваме опцията за кеш при зареждане и предварително да загреем кеша, за да получим 100% съотношение на попадане в кеша, като използваме опцията за таблица PREFETCH_BLOCKS_ON_OPEN

Изпълнихме всяко работно натоварване на YCSB за 15 минути всеки 5 пъти и взехме средни стойности от последните 3 цикъла, за да избегнем наказанието за първо изпълнение.

Резултати, наблюдавани при 40G L1 съотношение на попадане в кеша 99% на сървърите в региона са показани по-долу в таблица: 

YCSB резултати с набор от 1TB данни

В случая от 1TB данните не се вписват в 61GB L1 кеш памет на клъстера или 500GB кеш на буфера на операционната система. Коефициентът на попадане в кеша L1 в клъстера, наблюдаван по време на теста, е 82-84%.

Изпълнихме всяко работно натоварване за 15 минути всеки 5 пъти и взехме средни стойности от последните 3 бягания, за да избегнем наказанието за първото изпълнение.

Резултати се виждат с 1TB Съотношение на попадане в кеша L1 82-84% на сървърите в региона са показани по-долу в таблица: 

*Пропускателна способност (операции/сек) =брой операции в секунда

Анализ:

Сравнявайки резултатите от теста за двата различни размера на набора от данни по-горе, можем да видим как една и съща производителност на натоварване може да варира от 3K операции в секунда до 165K операции в секунда когато данните се осъществяват по-бързо от набора от 40G данни със загрят кеш в сравнение с hdfs съхранение.

Диаграмата по-долу показва пропускателната способност и сравнява как се е променила пропускателната способност за различни работни натоварвания при изпълнение с 2 различни набора от данни. В диаграмата по-висока лента, толкова по-добра е пропускателната способност.

Забележка:Пропускателна способност =Операции в секунда

Както се вижда на диаграмата, работните натоварвания на YCSB, които четат данни като работно натоварване A, работно натоварване C и работно натоварване F, имаха много по-добра пропускателна способност в случая 40G, където данните лесно се вписват в кеша, спрямо случая с размер на данни от 1TB, където данните от HFile трябваше да бъдат достъпен от HDFS

Гледайки коефициентите на попадане в кеш паметта, наборът от данни 40G имаше коефициент на попадане в кеша от близо 99%, а наборът от 1TB имаше коефициент на попадане в кеша от около 85%, така че 15% от данните в случай 1TB бяха достъпни от hdfs съхранение .

Работното натоварване на YCSB само за актуализация, което изпълнихме, имаше една и съща пропускателна способност и в двата случая, тъй като правеше само актуализации и не четеше.

По време на представянето на HBase разглеждаме отблизо латентностите от 95-ия и 99-ия процентил. Средната латентност е само общата пропускателна способност, разделена на общото време, но 95-ия персентил и 99-ия персентил показват реалните отклонения, които влияят върху общата пропускателна способност на работното натоварване. В случая с 1 TB, големите отклонения на латентност в 95-ия и 99-ия персентил водят до забавяне на пропускателната способност, а в случая с 40 GB ударите в кеша с ниска латентност в 99-ия персентил водят до повишена обща пропускателна способност.

Графиката по-долу показва сравнението на латентността за средна латентност, 95-та персентилна латентност и 99-та персентилна латентност и как се различава за различните натоварвания, когато се изпълнява с различни набори от данни.

В диаграмата по-горе е трудно да се видят лентите, представляващи латентност за 40GB набор от данни, тъй като те са изключително ниски в сравнение с наблюдаваното забавяне за набор от 1TB данни за достъп до данни от hdfs.

Начертахме графиката на латентността, използвайки дневник на стойностите на латентността, за да покажем разликата в диаграмата по-долу

Както се вижда по-горе, латентностите са много по-ниски в случая с 40 GB, където съотношението на попадане в кеша е близо до 99% и повечето данни за работното натоварване са налични в кеша. В сравнение с набора от данни от 1TB, съотношението на попадане в кеша е около 85%, тъй като HFile данните трябваше да бъдат достъпни от HDFS хранилище.

Средната и 99 латентност за работно натоварване C в случая 40G, където 99% данни се връщат от загрятия кеш е около 2 – 4 ms. Закъснението от 99-ти персентил за същото работно натоварване C в случая с 1TB беше около 100 мс за работно натоварване C (натоварване само за четене).

Това показва, че при попадане в кеша от кеша на блока в хранилището се връща четене за около 2 ms, а пропускането на кеша и получаването на запис от HDFS може да отнеме около 100 ms в този клъстер.

Препоръка: 

Когато провеждате тест за сравнителен анализ на YCSB, размерът на набора от данни прави съществена разлика в резултатите от производителността и следователно правилното оразмеряване на теста е много важно. В същото време разглеждането на съотношението на попадане в кеша и разликите в латентността между минималната и 99-та латентност ще ви помогне да намерите латентността на удара в кеша в сравнение с момента, когато се осъществява достъп до данни от основното хранилище в клъстера.

Съвет:

За да проверите коефициента на попадане в кеша на вашето работно натоварване на сървър в региона, можете да използвате командата по-долу

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

Можете също да видите съотношението на попадане в кеша от уеб интерфейса на HBase, като следвате стъпките по-долу:

1. От HBase Web UI щракнете върху сървъра на региона 
2. Под секцията Блоков кеш изберете L1 (и L2, ако L2 е конфигуриран), за да прегледате съотношенията на попадане в кеша.

Екранна снимка, показваща съотношението на попадане в кеша от L1 блок кеша, е показана по-долу:

Ето връзка към повече информация около екранната снимка на HBase, показана по-горе, и блокиране на кеша https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

Относно YCSB

YCSB е спецификация и програмен пакет с отворен код за оценка на възможностите за извличане и поддръжка на компютърни програми. Това е много популярен инструмент, използван за сравняване на относителната производителност на системите за управление на бази данни NoSQL.

За да използвате YCSB за тестване на производителността на оперативна база данни, вижте блога Как да стартирате YCSB за HBase