Podczas uruchamiania dowolnego narzędzia do analizy porównawczej wydajności w klastrze, krytyczną decyzją jest zawsze, jaki rozmiar zestawu danych powinien zostać użyty do testu wydajności, a tutaj pokazujemy, dlaczego ważne jest, aby wybrać rozmiar zestawu danych „dobrze dopasowany” podczas uruchamiania wydajności HBase przetestuj na swoim klastrze.
Konfiguracje klastra HBase i rozmiar zestawu danych mogą zmieniać wydajność obciążenia i wyniki testów w tym samym klastrze. Powinieneś wybrać ten rozmiar zestawu danych na podstawie tego, co próbujesz zrozumieć na temat wydajności klastra. Aby pokazać różnicę między zestawem roboczym, który mieści się w dostępnej pamięci podręcznej, a tym, który należy odczytać z bazowej pamięci, przeprowadziliśmy 2 testy obciążenia YCSB z odpowiednio dobranymi rozmiarami zestawów danych na tym samym klastrze CDP Private Cloud Base 7.2.2 Operation Database. Użyliśmy zestawów danych o rozmiarach 40 GB w porównaniu z 1 TB, a przepustowość dla różnych obciążeń YCSB została porównana poniżej, na wykresie wyższy słupek, tym lepsza przepustowość.
Uwaga:przepustowość =liczba operacji na sekundę
Gdy aplikacja próbuje wykonać odczyt z klastra HBase, serwer regionu obsługujący żądanie najpierw sprawdza, czy potrzebne wyniki znajdują się w bloku danych, który jest już lokalny dla jej procesu za pośrednictwem pamięci podręcznej bloków. Jeśli blok danych jest obecny, żądanie klienta może być obsługiwane bezpośrednio z pamięci podręcznej i liczy się to jako trafienie w pamięci podręcznej. Jeśli jednak blok nie jest obecnie lokalny w procesie serwera regionu, jest to liczone jako brak pamięci podręcznej i musi zostać odczytany z pliku HFile w pamięci HDFS. W zależności od wykorzystania pamięci podręcznej ten blok zostanie zapisany w pamięci podręcznej dla przyszłych żądań.
Zgodnie z oczekiwaniami i wynikami przedstawionymi na wykresie podsumowującym, obciążenie, w którym większość zestawów danych mieści się w pamięci podręcznej, ma mniejsze opóźnienia, a przepustowość jest znacznie wyższa w porównaniu z uruchomieniem obciążenia, w którym dostęp do danych jest uzyskiwany z HFiles w pamięci masowej hdfs.
Aby dobrze dobrać rozmiary zestawów danych obciążenia, aby dobrze spełniały nasze cele testowe, ważne jest, aby sprawdzić rozmiary stert serwera RegionServer, pamięci podręczne L1 i L2, pamięci podręczne buforów systemu operacyjnego, a następnie ustawić odpowiedni rozmiar zestawu danych. Po zakończeniu obciążenia YCSB dobrym parametrem do sprawdzenia jako sposobu sprawdzenia, czy wszystko działało zgodnie z oczekiwaniami, jest to, jaka część danych została obsłużona z pamięci podręcznej (trafienie w pamięci podręcznej) i do jakiej części uzyskano dostęp z pamięci hdfs. Ten stosunek trafień w pamięć podręczną serwera regionalnego do łącznej liczby żądań odczytu jest współczynnikiem trafień w pamięci podręcznej.
Te informacje można znaleźć w konfiguracji współczynnika trafień w pamięci podręcznej L1 „l1CacheHitRatio”. Jeśli w klastrze ustawiono zarówno pamięci podręczne L1, jak i L2, pamięć podręczna L1 obsługuje bloki indeksów, a pamięć podręczna L2 obsługuje bloki danych, a w celach informacyjnych można zarejestrować zarówno konfiguracje L1 „l1CacheHitRatio” i L2 „l2CacheHitRatio”.
W dalszej części tego wpisu na blogu omówimy szczegóły konfiguracji testowej, wybierając rozmiar zestawu danych, a następnie uruchamiając YCSB z tymi rozmiarami zestawu danych.
Konfiguracja klastra HBase użyta w tym teście:
- Użyty klaster: Klaster z 6 węzłami (1 master + 5 serwerów regionalnych)
- Opis: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2,2 Ghz, 128 GB pamięci RAM, dyski 4-2 TB
- Zabezpieczenia: Brak skonfigurowanych (bez protokołu Kerberos)
- Wersja CDP: CDP Private Cloud Base 7.2.2 6-węzłowy klaster HBase z 1 serwerem głównym + 5 serwerami regionu
- JDK używany jdk1.8_232
- Serwery regionu HBase zostały skonfigurowane ze stertą 32 GB
- HBase master został skonfigurowany ze stertą 4 GB
- Pamięć podręczna L1 z LruBlockCache była używana z rozmiarem pamięci podręcznej 12,3 GB
- Łączna pamięć podręczna L1 w klastrze wynosi 61 GB (12,3 * 5 =61 GB)
- Pamięć podręczna L2 wyłączonej sterty nie została skonfigurowana w klastrze
Rozmiar Przypadek 1:Dane całkowicie mieszczą się w dostępnej pamięci podręcznej w klastrze
W naszym klastrze HBase skonfigurowaliśmy łącznie 61 GB (12,3 GB *5) na 5 serwerach regionu przydzielonych na pamięć podręczną bloków L1. W przypadku zestawu danych, który całkowicie mieści się w pamięci podręcznej, wybraliśmy zestaw danych o pojemności 40 GB W rozmiarze.
Rozmiar przypadku 2:zestaw danych większy niż dostępna pamięć podręczna w klastrze
W drugim scenariuszu chcemy, aby dane były znacznie większe niż dostępna pamięć podręczna. Aby wybrać odpowiedni rozmiar zestawu danych, przyjrzeliśmy się zarówno skonfigurowanej pamięci podręcznej bloków HBase, jak i pamięci podręcznej bufora systemu operacyjnego w klastrze. W naszym danym klastrze HBase skonfigurowana pamięć podręczna bloków L1 to 61G po agregacji na serwerach RegionServers. Węzły serwera miały łącznie 128 GB pamięci RAM, a każda pamięć nie przeznaczona dla procesu serwera może być wykorzystana przez system operacyjny do efektywnego buforowania bazowych bloków HDFS i zwiększenia ogólnej przepustowości. W naszej konfiguracji testowej jest około 96G pamięci podręcznej OS dostępnej na każdym węźle serwera regionu w tym celu (ignorując pamięć używaną przez procesy DataNode lub OS, aby uprościć sprawę). Łącząc to na 5 serwerach regionalnych, uzyskaliśmy potencjał prawie 500G dla buforów (96G * 5 serwerów regionalnych). Dlatego wybraliśmy rozmiar zestawu danych wynoszący 1 TB, przekraczający zarówno skonfigurowaną pamięć podręczną bloków, jak i dostępną pamięć podręczną bufora systemu operacyjnego.
Przekształcanie docelowych rozmiarów danych w parametry YCSB
W YCSB wiersz ma domyślnie 1 KB, więc w zależności od tego, ile wierszy załadujesz do „tabeli użytkownika” YCSB, możesz łatwo oszacować rozmiar danych tabeli „tabela użytkownika” YCSB. Więc jeśli prześlesz 1 milion wierszy, przesłałeś 1 000 000 * 1 KB =1 GB danych do „tabeli użytkownika” YCSB.
Rozmiary zestawów danych użyte w naszych dwóch testach to:
- 40 GB danych z 40 milionami wierszy
- 1 TB danych z 1 miliardem wierszy
Metodologia testów
Na klastrze z 6 węzłami zainstalowano CDP Private Cloud Base 7.2.2 i wygenerowano dane obciążenia z 40 milionami wierszy (całkowity rozmiar zestawu danych => 40 GB ) i uruchomiono obciążenia YCSB. Po załadowaniu czekaliśmy na zakończenie wszystkich operacji kompaktowania przed rozpoczęciem testu obciążenia.
Obciążenia YCSB uruchomione w HBase były
- Zadanie A:50% odczyt i 50% aktualizacja
- Zadanie C:odczyt w 100%
- Obciążenie F:50% odczyt i 50% aktualizacja/odczyt-modyfikacja-zapis:50/50
- Obciążenie Tylko aktualizacja niestandardowa:aktualizacja 100%
Każde obciążenie YCSB (A, C, F i UpdateOnly) było uruchamiane przez 15 minut każde, a pełne uruchomienie zostało powtórzone 5 razy bez ponownych uruchomień między uruchomieniami, aby zmierzyć przepustowość YCSB*. Przedstawione wyniki są średnimi z ostatnich 3 przebiegów z 5 przebiegów. Pierwsze 2 przejazdy testowe zostały zignorowane, aby uniknąć kary za pierwszy i drugi przejazd.
Po ukończeniu 40 GB przebiegów porzuciliśmy tabelę użytkownika i ponownie wygenerowaliśmy 1 miliard wierszy, aby utworzyć zestaw danych o rozmiarze 1 TB i ponownie przeprowadziliśmy testy przy użyciu tej samej metodologii w tym samym klastrze.
Wyniki testu
Wyniki YCSB z 40 GB
W przypadku 40 GB dane mogą całkowicie zmieścić się w 61 GB pamięci podręcznej L1 w klastrze. Współczynnik trafień w pamięci podręcznej L1 zaobserwowany w klastrze podczas testu był bliski 99%.
Wskazówka: W przypadku mniejszych zestawów danych, w których dane mieszczą się w pamięci podręcznej, możemy również użyć opcji pamięci podręcznej przy ładowaniu i wstępnie podgrzać pamięć podręczną, aby uzyskać 100% współczynnik trafień w pamięci podręcznej, korzystając z opcji tabeli PREFETCH_BLOCKS_ON_OPEN
Uruchomiliśmy każde obciążenie YCSB przez 15 minut co 5 razy i obliczyliśmy średnie z ostatnich 3 przebiegów, aby uniknąć kary za pierwszy przebieg.
Wyniki widoczne przy współczynniku trafień w pamięci podręcznej L1 40G L1 99% na serwerach regionu pokazano poniżej w tabeli:
| Operacja | Liczba operacji | Przepustowość | Średnie opóźnienie | 95 lat oczekiwania | 99 lat oczekiwania |
| (Liczba operacji/s) | (ms) | (ms) | (ms) | ||
| Zadanie C | 148558364 | 165063 | 0,24 | 0,30 | 0,48 |
| Tylko aktualizacja | 56727908 | 63030 | 0,63 | 0,78 | 1,57 |
| Zadanie A | 35745710 | 79439 | 0,40 | 0,54 | 0,66 |
| Obciążenie F | 24823285 | 55157 | 0,58 | 0,70 | 0.96 |
Wyniki YCSB z zestawem danych 1 TB
W przypadku 1 TB dane nie mieszczą się w pamięci podręcznej L1 o pojemności 61 GB w klastrze lub w buforze bufora systemu operacyjnego 500 GB. Zaobserwowany podczas testu współczynnik trafień w pamięci podręcznej L1 w klastrze wyniósł 82-84%.
Przeprowadzaliśmy każde obciążenie przez 15 minut co 5 razy i obliczyliśmy średnie z ostatnich 3 przebiegów, aby uniknąć kary za pierwszy przebieg.
Wyniki widoczne przy 1 TB Współczynnik trafień w pamięci podręcznej L1 82-84% na serwerach regionu pokazano poniżej w tabeli:
| Operacja | Liczba operacji | Przepustowość | Średnie opóźnienie | 95 lat oczekiwania | 99 lat oczekiwania |
| (Liczba operacji/s) | (ms) | (ms) | (ms) | ||
| Zadanie C | 2727037 | 3030 | 13.19 | 55,50 | 110,85 |
| Tylko aktualizacja | 56345498 | 62605 | 0,64 | 0,78 | 1,58 |
| Zadanie A | 3085135 | 6855 | 10,88 | 48,34 | 97,70 |
| Obciążenie F | 3333982 | 3704 | 10,45 | 47,78 | 98,62 |
*Przepustowość (operacje/s) =liczba operacji na sekundę
Analiza:
Porównując wyniki testu dla dwóch różnych rozmiarów zestawów danych powyżej, możemy zobaczyć, jak ta sama przepustowość obciążenia może się różnić od 3K operacji na sekundę do 165K operacji na sekundę gdy dostęp do danych jest szybszy z zestawu danych 40G z rozgrzaną pamięcią podręczną w porównaniu z pamięcią hdfs.
Poniższy wykres przedstawia przepływność i porównuje, jak przepływność zmieniła się dla różnych obciążeń podczas uruchamiania z 2 zestawami danych o różnych rozmiarach. Na wykresie wyższy słupek, tym lepsza przepustowość.
Uwaga:przepustowość =liczba operacji na sekundę
Jak widać na wykresie, obciążenia YCSB, które czytają dane, takie jak Obciążenie A, Obciążenie C i Obciążenie F, miały znacznie lepszą przepustowość w przypadku 40G, w którym dane łatwo mieszczą się w pamięci podręcznej w porównaniu z przypadkiem o rozmiarze 1 TB, w którym dane HFile musiały być dostęp z HDFS
Patrząc na współczynniki trafień w pamięci podręcznej, zestaw danych 40G miał współczynnik trafień w pamięci podręcznej bliski 99%, a zestaw danych 1 TB miał współczynnik trafień w pamięci podręcznej około 85%, więc 15% danych w przypadku 1 TB było dostępnych z pamięci hdfs .
Niestandardowe obciążenie YCSB tylko do aktualizacji, które uruchomiliśmy, miało taką samą przepustowość w obu przypadkach, ponieważ wykonywało tylko aktualizacje i nie dokonywało odczytów.
Podczas wydajności HBase uważnie przyglądamy się opóźnieniom 95. i 99. percentyla. Średnie opóźnienie to po prostu całkowita przepustowość podzielona przez całkowity czas, jednak 95. i 99. percentyl pokazują rzeczywiste wartości odstające, które wpływają na całkowitą przepustowość obciążenia. W przypadku 1 TB wartości odstające o wysokim opóźnieniu w 95. i 99. percentylu powodują spowolnienie przepustowości, a w przypadku 40 GB trafienia w pamięć podręczną o niskim opóźnieniu w 99. percentylu prowadzą do zwiększenia całkowitej przepustowości.
Poniższy wykres przedstawia porównanie opóźnień dla średniego czasu oczekiwania, 95. percentyla i 99. percentyla oraz różnice między różnymi obciążeniami, gdy są uruchamiane z zestawami danych o różnych rozmiarach.
Na powyższym wykresie trudno jest zobaczyć słupki reprezentujące opóźnienie dla zestawu danych 40 GB, ponieważ są one wyjątkowo niskie w porównaniu z opóźnieniem obserwowanym dla zestawu danych 1 TB uzyskującego dostęp do danych z hdfs.
Sporządziliśmy wykres opóźnień, korzystając z logu wartości opóźnień, aby pokazać różnicę na poniższym wykresie
Jak widać powyżej, opóźnienia są znacznie niższe w przypadku 40 GB, gdzie współczynnik trafień w pamięci podręcznej jest bliski 99%, a większość danych dotyczących obciążenia jest dostępna w pamięci podręcznej. W porównaniu do zestawu danych 1 TB, współczynnik trafień w pamięci podręcznej wyniósł około 85%, ponieważ dane HFile musiały być dostępne z pamięci HDFS.
Średnie opóźnienie i 99 dla Workload C w przypadku 40G, w którym 99% danych jest zwracanych z rozgrzanej pamięci podręcznej, wynosiło około 2 – 4 ms. Opóźnienie 99. percentyla dla tego samego obciążenia C w przypadku 1 TB wynosiło około 100 ms dla obciążenia C (obciążenie tylko do odczytu).
To pokazuje, że trafienie w pamięć podręczną z blokowej pamięci podręcznej na stercie zwraca odczyt w około 2 ms, a brak pamięci podręcznej i uzyskanie rekordu z HDFS może zająć w tym klastrze około 100 ms.
Zalecenie:
Podczas przeprowadzania testu porównawczego YCSB rozmiar zestawu danych ma znaczną różnicę w wynikach wydajności, dlatego bardzo ważne jest odpowiednie określenie rozmiaru testu. Jednocześnie przyjrzenie się współczynnikowi trafień w pamięci podręcznej i różnicom opóźnień między minimalnym a 99. opóźnieniem pomoże Ci znaleźć opóźnienie trafienia w pamięci podręcznej w porównaniu z dostępem do danych z bazowej pamięci w klastrze.
Wskazówka:
Aby sprawdzić współczynniki trafień w pamięci podręcznej obciążenia na serwerze regionu, możesz użyć poniższego polecenia
curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio
Możesz również wyświetlić współczynnik trafień w pamięci podręcznej z HBase Web UI, wykonując poniższe czynności:
- W interfejsie internetowym HBase kliknij serwer regionu
- W sekcji Blokuj pamięć podręczną wybierz L1 (i L2, jeśli skonfigurowano L2), aby przejrzeć współczynniki trafień w pamięci podręcznej.
Zrzut ekranu pokazujący współczynnik trafień w pamięci podręcznej z pamięci podręcznej bloku L1 jest pokazany poniżej:
Oto link do dodatkowych informacji na temat zrzutu ekranu HBase pokazanego powyżej i pamięci podręcznej bloku https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
O YCSB
YCSB to specyfikacja i pakiet programów typu open source do oceny możliwości pobierania i konserwacji programów komputerowych. Jest to bardzo popularne narzędzie używane do porównywania względnej wydajności systemów zarządzania bazami danych NoSQL.
Aby użyć YCSB do testowania wydajności operacyjnej bazy danych, zapoznaj się z blogiem Jak uruchomić YCSB dla HBase
