Porady bazy danych Apache HBase w usłudze Azure HDInsight

Artykuł
10/16/2024

W tym artykule opisano kilka porad, które ułatwiają optymalizowanie 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 celu zapewnienia wysokiej wydajności optymalne jest obsługiwanie odczytów bazy danych HBase z memstoreusługi , a nie z magazynu zdalnego.

Porady dotyczące zapytań wskazują, że dla danej rodziny kolumn w tabeli > 75% odczytów, które są obsługiwane z memstore. Ten wskaźnik sugeruje, że nawet w przypadku opróżnienia ostatniego memstore pliku musi być uzyskiwany dostęp do pliku, który musi znajdować się w pamięci podręcznej. Dane są najpierw zapisywane w memstore systemie, które uzyskują 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 M. W związku z tym późniejsze odczytanie tych ostatnich rekordów może wymagać odczytu pliku, a nie z pliku memstore. W związku z tym najlepiej zoptymalizować, że nawet ostatnie dane, które zostały niedawno opróżnione, mogą znajdować się w pamięci podręcznej.

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

Ustaw wartość opcji hbase.rs.cacheblocksonwrite na true. Ta domyślna konfiguracja w bazie HBase w usłudze HDInsight to true, dlatego sprawdź, czy nie jest resetowany do false.
hbase.hstore.compactionThreshold Zwiększ wartość, aby uniknąć zagęszczania przed rozpoczę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 kompaktowania 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 ona włączona dla rodzin, które mają najnowsze odczyty danych. Domyślnie pamięć podręczna bloków jest włączona dla wszystkich rodzin w tabeli. Jeśli pamięć podręczna bloków dla rodziny została wyłączona i trzeba ją włączyć, 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 są poddawane kompaktowaniu. Jeśli w twoim scenariuszu jest możliwy czas wygaśnięcia, rozważ użycie kompaktowania warstwy daty. Aby uzyskać więcej informacji, zobacz Apache HBase Reference Guide: Date Tiered Compaction (Przewodnik referencyjny dotyczący 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 wysoka, 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 zwiększa się poza 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 szybciej opróżniać. 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ć.

Przykładowy scenariusz:

Załóżmy, że rozmiar sterty dla serwera regionu wynosi 10 GB. Domyślnie wartość to hbase.hregion.memstore.flush.size 128M. Wartość domyślna parametru hbase.regionserver.global.memstore.size to 0.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 tak, aby miał 32 regiony, system lepiej unika blokowania aktualizacji.
W przypadku tych ustawień liczba regionów wynosi 100. Globalna memstore 4 GB jest teraz podzielona na 100 regionów. Dzięki temu każdy region otrzymuje tylko 40 MB dla programu memstore. 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 kolejki kompaktowania

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

W przypadku nadmiernej liczby plików w przypadku kompaktowania może to prowadzić do większego użycia sterty związanego z interakcją plików z systemem plików platformy Azure. Więc lepiej jest wykonać kompaktowanie tak szybko, jak to możliwe. Czasami w starszych klastrach konfiguracje kompaktowania związane z ograniczaniem mogą prowadzić do wolniejszego kompaktowania.

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). Ujmij maksymalną wartość dla tej konfiguracji, aby być mniejsza niż 3.

Pełne skanowanie tabeli

Porady dotyczące skanowania pełnej tabeli wskazują, że ponad 75% wystawionych skanowań to pełne skanowanie tabeli/regionu. Możesz wrócić do sposobu, w jaki kod wywołuje skanowania, aby zwiększyć wydajność zapytań. Rozważ następujące rozwiązania:

Ustaw odpowiedni wiersz uruchamiania i zatrzymywania dla każdego skanowania.
Użyj interfejsu API MultiRowRangeFilter , aby umożliwić wykonywanie zapytań o różne zakresy 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

Udostępnij za pośrednictwem