Porady bazy danych Apache HBase w usłudze Azure HDInsight

Artykuł
09/22/2023

W tym artykule opisano kilka porad, które ułatwiają optymalizację wydajności bazy danych Apache HBase w usłudze Azure HDInsight.

Optymalizowanie bazy danych HBase pod kątem odczytywania ostatnio zapisanych danych

Jeśli twój przypadek użycia obejmuje odczytywanie ostatnio zapisanych danych z bazy danych HBase, ten poradnik może Ci pomóc. W przypadku wysokiej wydajności jest optymalne, że odczyty bazy HBase mają być obsługiwane z memstoreprogramu , a nie z magazynu zdalnego.

Porada dotycząca zapytań wskazuje, że dla danej rodziny kolumn w tabeli > 75% odczytów, które są obsługiwane z memstoreusługi . Ten wskaźnik sugeruje, że nawet jeśli na ostatnim pliku trzeba uzyskać dostęp do opróżnienia memstore , a to musi być w pamięci podręcznej. Dane są najpierw zapisywane w memstore systemie, aby uzyskać dostęp do najnowszych danych. Istnieje prawdopodobieństwo, że wewnętrzne wątki opróżniania HBase wykryją, że dany region osiągnął rozmiar 128M (domyślny) i może wyzwolić opróżnienie. Ten scenariusz dotyczy nawet najnowszych danych, które zostały zapisane, gdy memstore rozmiar wynosił około 128 mln. W związku z tym późniejsze odczytanie tych ostatnich rekordów może wymagać odczytu pliku, a nie z memstorepliku . Dlatego najlepiej jest zoptymalizować, że nawet ostatnie dane, które ostatnio opróżnione mogą znajdować się w pamięci podręcznej.

Aby zoptymalizować najnowsze dane w pamięci podręcznej, rozważ następujące ustawienia konfiguracji:

Ustaw wartość opcji hbase.rs.cacheblocksonwrite na true. Ta domyślna konfiguracja bazy danych HBase w usłudze HDInsight to true, dlatego sprawdź, czy nie jest resetowane do false.
hbase.hstore.compactionThreshold Zwiększ wartość, aby uniknąć zagęszczania przed kopnięciem. Domyślna wartość to 3. Możesz zwiększyć ją do wyższej wartości, takiej jak 10.
Jeśli wykonasz krok 2 i ustawisz wartość compactionThreshold, zmień hbase.hstore.compaction.max wartość na wyższą na przykład 100, a także zwiększ wartość konfiguracji hbase.hstore.blockingStoreFiles na wyższą wartość, na przykład 300.
Jeśli masz pewność, że musisz odczytywać tylko ostatnie dane, ustaw hbase.rs.cachecompactedblocksonwrite konfigurację na WŁ. Ta konfiguracja informuje system, że nawet w przypadku zagęszczania dane pozostają w pamięci podręcznej. Konfiguracje można również ustawić na poziomie rodziny.

W powłoce HBase uruchom następujące polecenie, aby ustawić hbase.rs.cachecompactedblocksonwrite konfigurację:
```
alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
```
Blokuj pamięć podręczną można wyłączyć dla danej rodziny w tabeli. Upewnij się, że jest włączona dla rodzin, które mają najnowsze odczyty danych. Domyślnie pamięć podręczna bloku jest włączona dla wszystkich rodzin w tabeli. W przypadku wyłączenia pamięci podręcznej bloku dla rodziny i konieczności jej włączenia użyj polecenia alter w powłoce hbase.

Te konfiguracje pomagają zapewnić dostępność danych w pamięci podręcznej i że ostatnie dane nie przechodzą kompaktowania. Jeśli czas wygaśnięcia jest możliwy w twoim scenariuszu, rozważ użycie kompaktowania warstwowego daty. Aby uzyskać więcej informacji, zobacz Apache HBase Reference Guide: Date Tiered Compaction (Przewodnik referencyjny bazy danych Apache HBase: Kompaktowanie warstwowe daty)

Optymalizowanie kolejki opróżniania

Ten poradnik wskazuje, że opróżnienia bazy danych HBase mogą wymagać dostrajania. Bieżąca konfiguracja procedur obsługi opróżniania może nie być wystarczająco duża, aby obsługiwać ruch zapisu, który może prowadzić do spowolnienia opróżnień.

W interfejsie użytkownika serwera regionu zwróć uwagę, że kolejka opróżniania przekroczy 100. Ten próg wskazuje, że opróżnienia są powolne i może być konieczne dostosowanie hbase.hstore.flusher.count konfiguracji. Domyślnie wartość to 2. Upewnij się, że maksymalna liczba wątków opróżniania nie przekracza 6.

Ponadto sprawdź, czy masz zalecenie dotyczące dostrajania liczby regionów. Jeśli tak, zalecamy wypróbowanie dostrajania regionu, aby sprawdzić, czy pomaga to w szybszym opróżnianiu. W przeciwnym razie dostrajanie wątków opróżniania może ci pomóc.

Dostrajanie liczby regionów

Porada dotycząca dostrajania liczby regionów wskazuje, że baza HBase zablokowała aktualizacje, a liczba regionów może być większa niż optymalnie obsługiwany rozmiar sterty. Rozmiar sterty, memstore rozmiar i liczba regionów można dostosować.

Jako przykładowy scenariusz:

Załóżmy, że rozmiar sterty dla serwera regionu wynosi 10 GB. Domyślnie jest to hbase.hregion.memstore.flush.size128M. Wartość domyślna to hbase.regionserver.global.memstore.size0.4. Oznacza to, że na 10 GB przydzielono memstore 4 GB (globalnie).
Załóżmy, że istnieje równomierny rozkład obciążenia zapisu we wszystkich regionach i zakładając, że każdy region rośnie do 128 MB tylko wtedy maksymalna liczba regionów w tej konfiguracji jest 32 regionami. Jeśli dany serwer regionów jest skonfigurowany do obsługi 32 regionów, system lepiej unika blokowania aktualizacji.
Po ustawieniu tych ustawień liczba regionów wynosi 100. Globalny memstore 4 GB jest teraz podzielony na 100 regionów. Tak skutecznie każdy region otrzymuje tylko 40 MB dla memstoreelementu . Gdy zapisy są jednolite, system często opróżnia i mniejszy rozmiar zamówienia < 40 MB. Posiadanie wielu wątków opróżniania może zwiększyć szybkość hbase.hstore.flusher.countopróżniania .

Porada oznacza, że warto rozważyć liczbę regionów na serwer, rozmiar sterty i konfigurację rozmiaru globalnego memstore wraz z dostrajaniem wątków opróżniania, aby uniknąć blokowania aktualizacji.

Dostrajanie kolejek kompaktowania

Jeśli kolejka kompaktowania HBase rośnie do ponad 2000 i jest okresowo wykonywana, możesz zwiększyć wątki kompaktowania do większej wartości.

Jeśli istnieje nadmierna liczba plików do kompaktowania, może to prowadzić do większego użycia sterty związanego z interakcją plików z systemem plików platformy Azure. Dlatego lepiej jest jak najszybciej ukończyć kompaktowanie. Czasami w starszych klastrach konfiguracje kompaktowania związane z ograniczaniem przepustowości mogą prowadzić do wolniejszego zagęszczania.

Sprawdź konfiguracje hbase.hstore.compaction.throughput.lower.bound i hbase.hstore.compaction.throughput.higher.bound. Jeśli są już ustawione na 50M i 100M, pozostaw je tak, jak to jest. Jeśli jednak te ustawienia zostały skonfigurowane na niższą wartość (w przypadku starszych klastrów), zmień odpowiednio limity na 50M i 100M.

Konfiguracje to hbase.regionserver.thread.compaction.small i hbase.regionserver.thread.compaction.large (wartości domyślne to 1). Zawęż maksymalną wartość tej konfiguracji, aby być mniejsza niż 3.

Pełne skanowanie tabeli

Porady dotyczące skanowania pełnej tabeli wskazują, że ponad 75% wystawionych skanów to pełne skanowanie tabel/regionów. Możesz ponownie zapoznać się ze sposobem, w jaki kod wywołuje skanowania w celu zwiększenia wydajności zapytań. Weź pod uwagę następujące rozwiązania:

Ustaw odpowiedni wiersz uruchamiania i zatrzymywania dla każdego skanowania.
Użyj interfejsu API MultiRowRangeFilter , aby można było wykonywać zapytania dotyczące różnych zakresów w jednym wywołaniu skanowania. Aby uzyskać więcej informacji, zobacz dokumentację interfejsu API MultiRowRangeFilter.
W przypadkach, gdy potrzebujesz pełnego skanowania tabeli lub regionu, sprawdź, czy istnieje możliwość uniknięcia użycia pamięci podręcznej dla tych zapytań, aby inne zapytania korzystające z pamięci podręcznej nie wykluczały bloków, które są gorące. Aby upewnić się, że skanowania nie używają pamięci podręcznej, użyj interfejsu API skanowania z opcją setCaching(false) w kodzie:
```
scan#setCaching(false)
```

Następne kroki

Optymalizowanie bazy danych Apache HBase przy użyciu narzędzia Ambari

Share via