Komunikaty Apache HBase w usłudze Azure HDInsight

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 HBase z memstore, a nie z magazynu zdalnego.

Poradnik dotyczący zapytań wskazuje, że dla danej rodziny kolumn w tabeli > 75% odczytów jest realizowanych z memstore. Ten wskaźnik sugeruje, że nawet jeśli dojdzie do opróżnienia, ostatni plik memstore musi być dostępny i znajdować się w pamięci podręcznej. Dane są najpierw zapisywane w memstore, a system uzyskuje tam dostęp do najnowszych danych. Istnieje prawdopodobieństwo, że wewnętrzne wątki opróżniania HBase wykryją, że dany region osiągnął domyślny rozmiar 128M i mogą 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 z pliku, a nie z 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:

  1. Ustaw wartość opcji hbase.rs.cacheblocksonwrite na true. Ta domyślna konfiguracja w HBase w usłudze HDInsight to true, dlatego upewnij się, że nie została przywrócona do false.

  2. Zwiększ wartość hbase.hstore.compactionThreshold, aby uniknąć rozpoczęcia zagęszczania. Domyślna wartość to 3. Możesz zwiększyć ją do wyższej wartości, takiej jak 10.

  3. Jeśli wykonasz krok 2 i ustawisz wartość compactionThreshold, zmień hbase.hstore.compaction.max na wyższą wartość, na przykład 100, a także zwiększ wartość konfiguracji hbase.hstore.blockingStoreFiles do wyższej wartości, na przykład 300.

  4. 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ć konfigurację hbase.rs.cachecompactedblocksonwrite.

    alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}

  5. Pamięć podręczną bloku da się wyłączyć dla danej rodziny w tabeli. Upewnij się, że jest to włączone ON dla rodzin, które mają najnowsze odczyty danych. Domyślnie pamięć podręczna bloków jest włączona dla wszystkich grup kolumn 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 możliwe jest TTL, rozważ użycie kompaktowania z podziałem na warstwy według dat. Aby uzyskać więcej informacji, zobacz Apache HBase Reference Guide: Date Tiered Compaction (Przewodnik referencyjny dotyczący bazy danych Apache HBase: kompaktowanie warstwowe daty)

Optymalizuj kolejkę opróżniania

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

W interfejsie użytkownika serwera regionu zwróć uwagę, czy kolejka opróżniania rośnie powyżej 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 czyszczących nie zwiększa się poza 6.

Ponadto sprawdź, czy masz zalecenie dotyczące dostrajania liczby regionów. Jeśli tak, zalecamy wypróbowanie dostrajania obszaru, aby sprawdzić, czy pomaga to przyspieszyć proces spłukiwania. 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. Można dostosować rozmiar sterty, rozmiar memstore i liczbę regionów.

Przykładowy scenariusz:

  • Załóżmy, że rozmiar sterty dla serwera regionu wynosi 10 GB. Domyślnie wartość to hbase.hregion.memstore.flush.size128M. Wartość domyślna parametru hbase.regionserver.global.memstore.size to 0.4. Oznacza to, że z 10 GB, 4 GB przydzielono na memstore (globalnie).

  • Załóżmy, że istnieje równomierny rozkład obciążenia zapisu we wszystkich regionach. Jeśli przyjmiemy również, że każdy region rośnie maksymalnie do 128 MB, to maksymalna liczba regionów w tej konfiguracji wynosi 32. 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 o pojemności 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ą równomierne, system często wykonuje opróżnianie, a rozmiar jest mniejszy rzędu < 40 MB. Posiadanie wielu wątków opróżniania może zwiększyć szybkość hbase.hstore.flusher.countopróżniania .

Porada oznacza, że warto ponownie rozważyć liczbę regionów na serwer, rozmiar sterty i konfigurację rozmiaru globalnego memstore, a także dostroić wątki opróżniania, aby aktualizacje nie były blokowane.

Dostrajanie kolejki kompaktowania

Jeśli kolejka kompaktowania w HBase regularnie wzrasta do ponad 2000, można zwiększyć liczbę wątków kompaktowania na większą wartość.

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 przepustowością mogą prowadzić do niższego wskaźnika 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, tak aby była 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 początkowy i końcowy dla każdego skanowania.

  • Użyj API MultiRowRangeFilter, aby wykonać zapytania o różne zakresy w jednym skanowaniu. 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

  • Last updated on