How did we make our Impala run faster?
Więc masz swojego Hadoop’a, terabajty danych trafiają do niego dziennie, ETL’e są wykonywane 24/7 za pomocą Spark’a, Hive’a lub broń Boże – Pig’a. A potem, gdy dane są już w dokładnie takim kształcie, w jakim chcesz (lub nawet wcześniej) i wszystko jest po prostu idealne – analitycy chcą zadać im pytania. Jeśli wybrałeś Impalę do tej misji, ten artykuł jest dla Ciebie.
Używamy Impali do kilku celów:
- Umożliwiamy analitykom odpytywanie nowych typów danych, dla których inżynierowie danych nie stworzyli jeszcze ETL.
- Niech analitycy zapytają o dane, których ostatecznym miejscem przeznaczenia (po procesie ETL) jest HDFS.
- Generowanie raportów (za pomocą naszych własnych narzędzi).
- Monitorowanie & systemów alarmowych (na nowych danych, które napływają co godzinę).
Mamy dziesiątki tysięcy zapytań dziennie, każde zapytanie skanuje średnio kilka gigabajtów danych i zajmuje 10 sekund. Nasz klaster nie jest ogromny pod względem sprzętowym i ilości węzłów, które posiadamy. Nie wspominając o tym, że mamy setki innych przepływów pracy (Spark, Pig, Hive) uruchamianych każdego dnia na tym samym klastrze.
W tym artykule podzielę się wiedzą i wnioskami, jakie wyciągnęliśmy z naszego projektu optymalizacji Impali.
Co to jest Impala?
Jeśli nie wiesz, co to jest – przeczytaj o tym w przewodniku Cloudera Impala Guide, a potem wróć tutaj po interesujące rzeczy.
Impala Vs. Other SQL-on-Hadoop Solutions
Nie ma tu czego porównywać. W dzisiejszych czasach, Hive jest tylko dla ETL i przetwarzania wsadowego. Twoi analitycy otrzymają odpowiedź o wiele szybciej używając Impali, chociaż w przeciwieństwie do Hive, Impala nie jest fault-tolerance. Ale to jest w porządku dla silnika MPP (Massive Parallel Processing).
Impala jest szybsza niż Hive, ponieważ jest to zupełnie inny silnik, a Hive jest ponad MapReduce (który jest bardzo wolny ze względu na zbyt wiele operacji I/O na dysku).
Impala Vs. SparkSQL
Tak, SparkSQL jest znacznie szybszy niż Hive, zwłaszcza jeśli wykonuje tylko obliczenia w pamięci, ale Impala jest nadal szybsza niż SparkSQL.
Jest szybsza, ponieważ Impala jest silnikiem zaprojektowanym specjalnie do misji interaktywnego SQL nad HDFS i ma koncepcje architektury, które pomagają mu to osiągnąć. Na przykład demony Impali „always-on” są włączone i czekają na zapytania 24/7 – coś, co nie jest częścią SparkSQL. I jeszcze kilka innych powodów, takich jak mechanizm codegen Impali, optymalizacja formatu Parquet, statystyki, cache metadanych, itp.
JDBC/ODBC Thrift Server w SparkSQL może być porównywalnym konkurentem dla Impali, ale ponieważ nie znalazłem zbyt wiele na jego temat w sieci – po prostu powiem o tym tutaj, a jeśli masz jakąś wiedzę i doświadczenie w tym temacie, proszę napisz o tym średni post. Być może napiszę go w niedalekiej przyszłości.
Impala Vs. Presto
Presto jest bardzo podobną technologią o podobnej architekturze. Według prawie każdego benchmarku w sieci – Impala jest szybsza niż Presto, ale Presto jest znacznie bardziej pluggable niż Impala. Impala przypuszczalnie jest szybsza, gdy potrzebujesz SQL nad Hadoop, ale jeśli potrzebujesz odpytywać wiele źródeł danych za pomocą tego samego silnika zapytań – Presto jest lepsze niż Impala. Wystarczy zobaczyć tę listę łączników Presto. Impala może również wykonywać zapytania do Amazon S3, Kudu, HBase i to w zasadzie wszystko.
Do dalszego czytania o Presto- to jest pełna recenzja PrestoDB, którą zrobiłem.
Najlepsze praktyki Impali
Impala działa najlepiej, gdy zapytuje pliki przechowywane w formacie Parquet. Cała technologia, na której opiera się Cloudera Impala pochodzi z Google Dremel Whitepaper i w tym dokumencie można znaleźć koncepcję, na której opiera się Parquet. Pamiętaj więc, aby nie wykonywać zapytań do plików json, csv lub sekwencji – parkietuj swoje pliki, zanim pozwolisz analitykom na wykonywanie zapytań do nich.
Work With Partitions
Partycjonuj swoje dane zgodnie z zapytaniami analityków. Impala nie posiada żadnych indeksów, więc jest to jedyny sposób na zmniejszenie ilości danych przetwarzanych w każdym zapytaniu. Używamy DT (data time) jako głównej metody partycjonowania dla większości naszych tabel. Nadmierne partycjonowanie może być niebezpieczne (czytaj dalej po więcej szczegółów).
Oświadczenie REFRESH
Oświadczenie REFRESH może być kosztowną operacją, szczególnie jeśli masz tysiące tabel z danymi dodawanymi do nich co godzinę. Wykonujemy ponad 10,000 odświeżeń dziennie. Oto moje najlepsze praktyki dotyczące odświeżania:
- Odkąd Impala 2.7 możesz wykonać odświeżenie na określonej partycji, użyj tego, aby oświadczenie REFRESH było znacznie lżejsze.
- Architektura gorących & zarchiwizowanych tabel – każda tabela będzie miała wersję gorącą i wersję zarchiwizowaną. Gorąca wersja będzie zawierała dane z ostatnich 24 godzin, a odświeżanie tej tabeli będzie następowało co godzinę i będzie znacznie lżejsze. Każdego dnia tabela gorąca będzie łączona z tabelą zarchiwizowaną, a odświeżanie tej tabeli będzie następowało co godzinę i będzie znacznie lżejsze. I oczywiście VIEW nad tymi dwoma, które je łączą, więc użytkownicy nie będą nawet tego świadomi.
- Nie miej zbyt dużo metadanych (plików i partycji) na tabelę (zobacz sekcję 'Optymalny rozmiar pliku’).
Oblicz statystyki
Statystyki sprawią, że twoje zapytania będą o wiele bardziej wydajne, szczególnie te, które obejmują więcej niż jedną tabelę (złączenia). Dlatego powinieneś obliczać statystyki dla wszystkich swoich tabel i utrzymywać przepływ pracy, który utrzymuje je na bieżąco z przyrostowymi statystykami. Aby uzyskać więcej szczegółów technicznych, przeczytaj o Cloudera Impala Table and Column Statistics.
Optimal File Size – 256MB/File
TL;DR: Upewnij się, że nie masz zbyt wielu małych plików – to zaszkodzi serwerowi katalogów, odświeżaniu i wydajności zapytań naprawdę źle.
Zauważyliśmy, że nasz serwer katalogów Impala zawiesza się 4 razy w tygodniu i że nasze zapytania zajmują zbyt dużo czasu. Wtedy zdaliśmy sobie sprawę, że mamy o wiele za dużo plików i partycji. Pracowaliśmy z partycjami DT co godzinę, bez względu na rozmiar partycji.
W ten sposób po 2 latach mieliśmy tabele z 17 GB danych i 17 000 partycji – co oznacza, że każda partycja ma około 1mb. Mieliśmy tabele z partycjami o wielkości 50KB. A jakby tego było mało, niektóre z tych małych partycji miały w sobie wiele plików.
Na początku myśleliśmy, że ta nieracjonalna ilość plików powoduje tylko, że nasze metadane są zbyt duże i dlatego odświeżanie jest tak ciężkie i serwer katalogów się zawiesza. Ale potem zdaliśmy sobie sprawę, że ilość plików również bardzo źle wpływa na wydajność naszych zapytań (ponieważ liczba wątków skanera wymaganych do odczytania tak wielu plików parkietu).
Jak źle? Przeprowadziliśmy test na rzeczywistej 500MB tabeli, którą posiadamy, z 17,280(!) partycjami i plikami. Stworzyliśmy nową połączoną wersję tej tabeli z tylko 2 plikami, 1 na rok. Część SCAN HDFS w podsumowaniu wykonania zapytania była 2,000 razy szybsza. To była część, w której zrozumieliśmy jak bardzo nasze małe pliki nam szkodzą.
Zaczęliśmy więc zarządzać naszymi partycjami i łączyć je w optymalny rozmiar pliku, który wynosi około 256mb.
Tabele z partycjonowaniem godzinowym stały się partycjonowane dzienne, miesięczne lub roczne. Każda partycja ma tylko 1 plik (chyba że jego rozmiar wynosi > 256mb)
Configure Coordinators & Executors Per Daemon
Od wersji Impala 2.9 można określić, które demony impali są koordynatorami, a które wykonawcami. To ogromna zmiana, ponieważ wcześniej wszystkie demony były koordynatorami i wykonawcami, a narzut bycia koordynatorem jest bardzo zasobożerny dla dużych klastrów.
Oznacza to na przykład, że każdy węzeł przechowuje całą pamięć podręczną metadanych w swojej pamięci RAM. A jeśli masz na przykład 20GB metadanych i 50 węzłów – oznacza to marnowanie 1TB pamięci RAM tylko dlatego, że wszystkie węzły są również koordynatorami!
Sprawdź, jaki jest najlepszy wskaźnik koordynatorów/wykonawców dla Ciebie i użyj go. Wskazówka: zacznij od 2 koordynatorów na klaster.
Typy danych kolumn
Na początku używaliśmy STRING dla wszystkich naszych kolumn we wszystkich tabelach. Jest to naprawdę zła praktyka, która bardzo szkodzi wydajności. Należy spróbować wybrać typ najbardziej pasujący do kolumny spośród wszystkich typów danych obsługiwanych przez Impalę.
Impala Query Limits
Należy używać funkcji Impala Admission Control, aby ustawić różne pule dla różnych grup użytkowników w celu ograniczenia korzystania z niektórych użytkowników do X jednoczesnych zapytań lub Y pamięci. Ale nawet więcej niż to – zbudowaliśmy nasz własny system do obsługi problematycznych użytkowników i zapytań.
Nasz system próbkuje aktualnie uruchomione zapytania co 10 sekund i jeśli zapytanie działa dłużej niż 30 minut – zostaje zabite. Jeśli ten sam szablon zapytania został zabity 90% razy w zeszłym miesiącu, ponieważ trwał dłużej niż 30 minut – nasz system zabije go natychmiast, gdy rozpozna ten szablon, aby chronić naszą infrastrukturę.
Zabijanie zapytań nie jest nową koncepcją – Amazon Athena zrobiła to przed nami, ale zabijanie zapytań tylko według problematycznego wzorca – to coś, czego nie robi nikt inny i jest to jedyny sposób, aby obsłużyć tysiące głodnych analityków.
Podsumowanie
Jeśli musisz pozwolić swoim analitykom wykonywać ad-hoc, interaktywne zapytania SQL w Hadoop – Impala jest świetnym rozwiązaniem. Powinieneś przeczytać Cloudera Impala Guide, aby stać się naprawdę dobrym administratorem Impali i pamiętać, aby pracować według najlepszych praktyk, które tutaj wyjaśniłem.