Udostępnij za pośrednictwem


Rozwiązywanie problemów z wydajnością oprogramowania Apache HBase w usłudze Azure HDInsight

W tym artykule opisano różne wytyczne dotyczące dostrajania wydajności i wskazówki dotyczące uzyskiwania optymalnej wydajności w usłudze Azure HDInsight. Wiele z tych wskazówek zależy od konkretnego obciążenia i wzorca odczytu/zapisu/skanowania. Przed zastosowaniem zmian konfiguracji w środowisku produkcyjnym przetestuj je dokładnie.

Szczegółowe informacje o wydajności bazy danych HBase

Najczęstszym wąskim gardłem w większości obciążeń bazy danych HBase jest dziennik zapisu z wyprzedzeniem (WAL, Write Ahead Log). Znacząco wpływa on na wydajność zapisu. Baza HBase usługi HDInsight ma oddzielny model obliczeniowy magazynu. Dane są przechowywane zdalnie w usłudze Azure Storage, mimo że maszyny wirtualne hostujące serwery regionów. Do niedawna wal został również napisany w usłudze Azure Storage. W usłudze HDInsight to zachowanie wzmacniało to wąskie gardło. Funkcja przyspieszonych zapisów została zaprojektowana w celu rozwiązania tego problemu. Zapisuje on plik WAL na dyskach zarządzanych ssd w warstwie Premium platformy Azure. To ogromne korzyści z wydajności zapisu i pomaga wiele problemów napotykanych przez niektóre obciążenia intensywnie korzystające z zapisu.

Aby uzyskać znaczną poprawę operacji odczytu, użyj konta usługi Premium Block Blob Storage jako magazynu zdalnego. Ta opcja jest możliwa tylko wtedy, gdy funkcja WAL jest włączona.

Zagęszczania

Kompaktowanie jest kolejnym potencjalnym wąskim gardłem, które jest zasadniczo uzgodnione w społeczności. W klastrach HBase usługi HDInsight główne kompaktowanie jest domyślnie wyłączone. Kompaktowanie jest wyłączone, ponieważ mimo że jest to proces intensywnie korzystający z zasobów, klienci mają pełną elastyczność planowania zgodnie ze swoimi obciążeniami. Mogą na przykład zaplanować go poza godzinami szczytu. Ponadto lokalność danych nie jest problemem, ponieważ magazyn jest zdalny (wspierany przez usługę Azure Storage) zamiast lokalnego rozproszonego systemu plików Hadoop (HDFS).

Klienci powinni zaplanować duże kompaktowanie w dogodnym miejscu. Jeśli nie zrobią tej konserwacji, kompaktowanie wpłynie negatywnie na wydajność odczytu w dłuższej perspektywie.

W przypadku operacji skanowania średnie opóźnienia, które są znacznie wyższe niż 100 milisekund, powinny być przyczyną problemu. Sprawdź, czy główne kompaktowanie zostało dokładnie zaplanowane.

Obciążenie apache Phoenix

Udzielenie odpowiedzi na następujące pytania pomoże Lepiej zrozumieć obciążenie apache Phoenix:

  • Czy wszystkie operacje "odczytu" są tłumaczane na skany?
    • Jeśli tak, jakie są cechy tych skanów?
    • Czy zoptymalizowano schemat tabeli Phoenix pod kątem tych skanowań, w tym odpowiednie indeksowanie?
  • Czy użyto instrukcji EXPLAIN do zrozumienia planów zapytań wygenerowanych przez "odczyty"?
  • Czy twoje zapisy są "upsert-selects"?
    • Jeśli tak, będą również wykonywać skanowania. Oczekiwane opóźnienie skanowania wynosi średnio około 100 milisekund, w porównaniu do 10 milisekund dla punktu w bazie danych HBase.

Metodologia testowania i monitorowanie metryk

Jeśli używasz testów porównawczych, takich jak Yahoo! Test porównawczy usługi w chmurze, JMeter lub Pherf w celu testowania i dostrajania wydajności, upewnij się, że:

  • Maszyny klienckie nie stają się wąskim gardłem. W tym celu sprawdź użycie procesora CPU na maszynach klienckich.

  • Konfiguracje po stronie klienta, takie jak liczba wątków, są odpowiednio dostosowane do saturacji przepustowości klienta.

  • Wyniki testów są rejestrowane dokładnie i systematycznie.

Jeśli zapytania nagle zaczęły robić znacznie gorzej niż wcześniej, sprawdź potencjalne błędy w kodzie aplikacji. Czy nagle generuje duże ilości nieprawidłowych danych? Jeśli tak jest, może zwiększyć opóźnienia odczytu.

Problemy z migracją

Jeśli przeprowadzasz migrację do usługi Azure HDInsight, upewnij się, że migracja odbywa się systematycznie i dokładnie, najlepiej za pośrednictwem automatyzacji. Unikaj ręcznej migracji. Upewnij się, że:

  • Atrybuty tabeli są dokładnie migrowane. Atrybuty mogą zawierać jako kompresję, filtry blooma itd.

  • Ustawienia soli w tabelach Phoenix są odpowiednio mapowane na nowy rozmiar klastra. Na przykład liczba zasobników soli powinna być wielokrotną liczbą węzłów roboczych w klastrze. Należy użyć wielokrotności, która jest czynnikiem ilości hot spotting.

Dostrajanie konfiguracji po stronie serwera

W bazie HBase usługi HDInsight pliki HFile są przechowywane w magazynie zdalnym. W przypadku braku pamięci podręcznej koszt odczytu jest wyższy niż w systemach lokalnych, ponieważ dane w systemach lokalnych są wspierane przez lokalny system plików HDFS. W większości scenariuszy inteligentne użycie pamięci podręcznych HBase (blokowej pamięci podręcznej i pamięci podręcznej zasobnika) zostało zaprojektowane w celu obejścia tego problemu. W przypadkach, gdy problem nie jest pomijany, użycie konta blokowych obiektów blob w warstwie Premium może pomóc w tym problemie. Sterownik obiektów blob usługi Windows Azure Storage opiera się na niektórych właściwościach, takich jak fs.azure.read.request.size pobieranie danych w blokach na podstawie tego, co określa tryb odczytu (sekwencyjny i losowy), więc nadal mogą istnieć wystąpienia wyższych opóźnień z odczytami. W eksperymentach empirycznych okazało się, że ustawienie rozmiaru bloku żądania odczytu (fs.azure.read.request.size) na 512 KB i dopasowanie rozmiaru bloku tabel HBase do tego samego rozmiaru daje najlepszy wynik w praktyce.

W przypadku większości klastrów węzłów o dużym rozmiarze baza HBase usługi HDInsight udostępnia bucketcache jako plik na lokalnym dysku SSD w warstwie Premium dołączonym do maszyny wirtualnej z systemem regionservers. Zamiast tego użycie pamięci podręcznej poza stertą może zapewnić pewne ulepszenia. To obejście ma ograniczenie dotyczące używania dostępnej pamięci i potencjalnie mniejszej niż pamięć podręczna oparta na plikach, więc może nie zawsze być najlepszym wyborem.

Poniżej przedstawiono niektóre z innych określonych parametrów, które zostały dostrojone i które wydawały się pomóc w różnym stopniu:

  • Zwiększ memstore rozmiar z domyślnego 128 MB do 256 MB. Zazwyczaj to ustawienie jest zalecane w przypadku scenariuszy dużego zapisu.

  • Zwiększ liczbę wątków przeznaczonych do kompaktowania, od domyślnego ustawienia od 1 do 4. To ustawienie jest istotne, jeśli obserwujemy częste niewielkie kompaktowanie.

  • Unikaj blokowania opróżniania memstore ze względu na limit sklepu. Aby zapewnić ten bufor, zwiększ Hbase.hstore.blockingStoreFiles ustawienie do 100.

  • Aby kontrolować opróżnienia, użyj następujących ustawień:

    • Hbase.regionserver.maxlogs: 140 (unika opróżniania z powodu limitów WAL)

    • Hbase.regionserver.global.memstore.lowerLimit: 0,55

    • Hbase.regionserver.global.memstore.upperLimit: 0,60

  • Konfiguracje specyficzne dla rozwiązania Phoenix na potrzeby dostrajania puli wątków:

    • Phoenix.query.queuesize: 10000

    • Phoenix.query.threadpoolsize: 512

  • Inne konfiguracje specyficzne dla rozwiązania Phoenix:

    • Phoenix.rpc.index.handler.count: 50 (jeśli istnieje duże lub wiele odnośników indeksu)

    • Phoenix.stats.updateFrequency: 1 godzina

    • Phoenix.coprocessor.maxmetadatacachetimetolivems: 1 godzina

    • Phoenix.coprocessor.maxmetadatacachesize: 50 MB

  • Przekroczenia limitu czasu RPC: 3 minuty

    • Limity czasu wywołań RPC obejmują limit czasu protokołu RPC bazy danych HBase, limit czasu skanera klienta HBase i limit czasu zapytania Phoenix.
    • Upewnij się, że hbase.client.scanner.caching parametr jest ustawiony na tę samą wartość zarówno na końcu serwera, jak i na końcu klienta. Jeśli nie są one takie same, to ustawienie prowadzi do błędów klienta, które są związane z OutOfOrderScannerException. To ustawienie powinno być ustawione na niską wartość dla dużych skanowań. Ustawiliśmy tę wartość na 100.

Inne uwagi

Poniżej przedstawiono dodatkowe parametry do rozważenia dostrajania:

  • Hbase.rs.cacheblocksonwrite — domyślnie w usłudze HDI to ustawienie ma wartość true.

  • Ustawienia, które umożliwiają odroczenie drobnych zagęszczania na później.

  • Ustawienia eksperymentalne, takie jak dostosowywanie wartości procentowych kolejek zarezerwowanych dla żądań odczytu i zapisu.

Następne kroki

Jeśli problem pozostanie nierozwiązany, odwiedź jeden z następujących kanałów, aby uzyskać więcej pomocy technicznej:

  • Uzyskaj odpowiedzi od ekspertów platformy Azure za pośrednictwem pomocy technicznej społeczności platformy Azure.

  • Nawiąż połączenie z @AzureSupport. Jest to oficjalne konto platformy Microsoft Azure w celu poprawy jakości obsługi klienta. Łączy społeczność platformy Azure z odpowiednimi zasobami: odpowiedziami, pomocą techniczną i ekspertami.

  • Jeśli potrzebujesz dodatkowej pomocy, możesz przesłać wniosek o pomoc techniczną w witrynie Azure Portal. Wybierz pozycję Pomoc techniczna na pasku menu lub otwórz centrum Pomoc i obsługa techniczna . Aby uzyskać bardziej szczegółowe informacje, zobacz How to create an pomoc techniczna platformy Azure request (Jak utworzyć żądanie pomoc techniczna platformy Azure). Subskrypcja platformy Microsoft Azure obejmuje dostęp do zarządzania subskrypcjami i obsługi rozliczeń, a pomoc techniczna jest zapewniana za pośrednictwem jednego z planów pomoc techniczna platformy Azure.