Tryl to rozproszony silnik zapytań SQL o otwartym kodzie źródłowym, przeznaczony do interaktywnych obciążeń analitycznych. W AWS możesz uruchomić Trino Amazon EMR, na którym możesz uruchomić preferowaną wersję Trino o otwartym kodzie źródłowym Elastyczna chmura obliczeniowa Amazon (Amazon EC2), którymi zarządzasz lub na których zarządzasz Amazonka Atena dla doświadczenia bezserwerowego. Kiedy używasz Trino na Amazon EMR lub Athena, otrzymujesz najnowsze innowacje społeczności open source wraz z zastrzeżonymi optymalizacjami opracowanymi przez AWS.

Począwszy od Amazon EMR 6.8.0 i silnika Athena w wersji 2, AWS opracowuje plan zapytań i optymalizacje zachowania silnika, które poprawiają wydajność zapytań w Trino. W tym poście porównujemy Amazon EMR 6.15.0 z open source Trino 426 i pokazujemy, że zapytania TPC-DS działały do ​​2.7 razy szybciej na Amazon EMR 6.15.0 Trino 426 w porównaniu do open source Trino 426. Później wyjaśnimy kilka optymalizacji wydajności opracowanych przez AWS, które przyczyniły się do tych wyników.

Konfiguracja testu porównawczego

W naszych testach wykorzystaliśmy zbiór danych o pojemności 3 TB przechowywany w Amazon S3 w skompresowanym formacie Parquet, a metadane baz danych i tabel są przechowywane w Klej AWS Katalog danych. Ten test porównawczy wykorzystuje niezmodyfikowany schemat danych TPC-DS i relacje między tabelami. Tabele faktów są podzielone według kolumny daty i zawierają 200-2100 partycji. Dla żadnej z tabel nie były dostępne statystyki tabelaryczne i kolumnowe. Użyliśmy zapytań TPC-DS z open source Trino Repozytorium Github bez modyfikacji. Zapytania porównawcze przeprowadzono sekwencyjnie w dwóch różnych klastrach Amazon EMR 6.15.0: jeden z Amazon EMR Trino 426, a drugi z open source Trino 426. Obydwa klastry korzystały z 1 instancji roboczej r5.4xlarge i 20 instancji roboczych r5.4xlarge.

Zaobserwowane wyniki

Nasze testy porównawcze pokazują niezmiennie lepszą wydajność z Trino na Amazon EMR 6.15.0 w porównaniu z Trino o otwartym kodzie źródłowym. Całkowity czas wykonywania zapytań Trino na Amazon EMR był 2.7 razy szybszy w porównaniu z oprogramowaniem open source. Poniższy wykres przedstawia poprawę wydajności mierzoną na podstawie całkowitego czasu wykonywania zapytań (w sekundach) dla zapytań porównawczych.

Wiele zapytań TPC-DS wykazało ponad pięciokrotnie szybszy wzrost wydajności w porównaniu z Trino o otwartym kodzie źródłowym. Niektóre zapytania wykazały jeszcze większą wydajność, jak zapytanie 72, które poprawiło się 160 razy. Poniższy wykres przedstawia 10 najpopularniejszych zapytań TPC-DS z największą poprawą czasu działania. Aby uzyskać zwięzłe przedstawienie i uniknąć nierównej poprawy wydajności na wykresie, wykluczyliśmy q72.

Udoskonalenia wydajności

Teraz, gdy rozumiemy wzrost wydajności dzięki Trino na Amazon EMR, przyjrzyjmy się bliżej niektórym kluczowym innowacjom opracowanym przez inżynierów AWS, które przyczyniają się do tych ulepszeń.

Wybór lepszej kolejności łączenia i typu łączenia ma kluczowe znaczenie dla lepszej wydajności zapytań, ponieważ może mieć wpływ na ilość danych odczytywanych z określonej tabeli, ilość danych przesyłanych przez sieć do etapów pośrednich oraz ilość pamięci potrzebnej do zbudowania tablica mieszająca ułatwiająca łączenie. Decyzje dotyczące kolejności łączenia i algorytmów łączenia to zazwyczaj funkcje wykonywane przez optymalizatory oparte na kosztach, które wykorzystują statystyki do ulepszania planów zapytań poprzez decydowanie o sposobie łączenia tabel i podzapytań.

Jednak statystyki dotyczące tabel są często niedostępne, nieaktualne lub zbyt drogie, aby gromadzić je na dużych tabelach. Gdy statystyki nie są dostępne, Amazon EMR i Athena korzystają z metadanych pliku S3 w celu optymalizacji planów zapytań. Metadane pliku S3 służą do wnioskowania o małych podzapytaniach i tabelach w zapytaniu podczas określania kolejności łączenia lub typu łączenia. Rozważmy na przykład następujące zapytanie:

SELECT ss_promo_sk FROM store_sales ss, store_returns sr, call_center cc WHERE 
ss.ss_cdemo_sk = sr.sr_cdemo_sk AND ss.ss_customer_sk = cc.cc_call_center_sk 
AND cc_sq_ft > 0

Składniowy porządek łączenia to store_sales łączy store_returns łączy call_center. Dzięki regułom optymalizacji typu łączenia i wyboru zamówienia Amazon EMR ustalana jest optymalna kolejność łączenia, nawet jeśli te tabele nie zawierają statystyk. W przypadku poprzedniego zapytania if call_center jest uważany za mały stół po oszacowaniu przybliżonego rozmiaru na podstawie metadanych pliku S3, reguły optymalizacji łączenia EMR zostaną połączone store_sales w call_center najpierw i przekonwertuj złączenie na złączenie rozgłoszeniowe, przyspieszając wykonywanie zapytań i zmniejszając zużycie pamięci. Zmiana kolejności łączenia minimalizuje rozmiar wyniku pośredniego, co pomaga jeszcze bardziej skrócić ogólny czas wykonywania zapytania.

W przypadku Amazon EMR 6.10.0 i nowszych wersji optymalizacje łączenia oparte na metadanych plików S3 są domyślnie włączone. Jeśli używasz Amazon EMR 6.8.0 lub 6.9.0, możesz włączyć te optymalizacje, ustawiając właściwości sesji z klientów Trino lub dodając następujące właściwości do klasyfikacji trino-config podczas tworzenia klastra. Odnosić się do Skonfiguruj aplikacje aby uzyskać szczegółowe informacje na temat zastępowania domyślnych konfiguracji aplikacji.

Konfiguracja wyboru typu łączenia:

session property: rule_based_join_type_selection=true
config property: rule-based-join-type-selection=true

Konfiguracja zmiany kolejności dołączenia:

session property: rule_based_join_reorder=true
config property: rule-based-join-reorder=true

Wnioski

Dzięki Amazon EMR 6.8.0 i nowszym możesz uruchamiać zapytania w Trino znacznie szybciej niż Trino o otwartym kodzie źródłowym. Jak pokazano w tym poście na blogu, nasz test porównawczy TPC-DS wykazał 2.7-krotną poprawę całkowitego czasu wykonywania zapytań z Trino na Amazon EMR 6.15.0. Optymalizacje omówione w tym poście i wiele innych są również dostępne podczas uruchamiania zapytań Trino na platformie Athena, gdzie obserwuje się podobną poprawę wydajności. Aby dowiedzieć się więcej, zapoznaj się z Uruchamiaj zapytania 3 razy szybciej, oszczędzając nawet 70% kosztów dzięki najnowszemu silnikowi Amazon Athena.

W ramach naszej misji wprowadzania innowacji na rzecz klientów firmy Amazon EMR i Athena często udostępniają ulepszenia wydajności i niezawodności w swoich najnowszych wersjach. Sprawdź Amazon EMR i Amazonka Atena strony wersji, aby dowiedzieć się o nowych funkcjach i ulepszeniach.

O autorach

Bhargawi Sagi jest inżynierem ds. rozwoju oprogramowania w Amazon Athena. Dołączyła do AWS w 2020 roku i pracowała nad różnymi obszarami Amazon EMR i silnikiem Athena V3, w tym nad modernizacją silnika, niezawodnością silnika i wydajnością silnika.

Sushila Kumara Shivashankara jest kierownikiem technicznym w zespole EMR Trino i Athena Query Engine. Od 2014 roku koncentruje się na obszarze analityki Big Data.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/big-data/run-trino-queries-2-7-times-faster-with-amazon-emr-6-15-0/