Dlaczego warto używać Presto do analiz ad hoc

Presto! To nie tylko zaklęcie, aby podekscytować publiczność magiczną sztuczką, ale także imię, które jest coraz częściej używane podczas dyskusji o tym, jak przejść przez duże zbiory danych. Chociaż istnieje wiele wdrożeń Presto w środowisku naturalnym, technologia - rozproszony silnik zapytań SQL, który obsługuje wszystkie rodzaje źródeł danych - pozostaje nieznana wielu programistom i analitykom danych, którzy mogliby skorzystać na jej użyciu.

W tym artykule omówię Presto: czym jest, skąd się wziął, czym różni się od innych rozwiązań do hurtowni danych i dlaczego warto wziąć go pod uwagę przy rozwiązaniach Big Data.

Presto kontra Hive

Presto powstało na Facebooku w 2012 roku. Oprogramowanie Open-sourcing w 2013 roku i zarządzane przez Presto Foundation (część Linux Foundation), przez lata cieszyło się stałym wzrostem popularności. Obecnie kilka firm, takich jak Ahana, zbudowało model biznesowy wokół Presto, korzystając z usług analitycznych ad hoc opartych na PrestoDB.

Presto zostało zbudowane jako środek zapewniający użytkownikom końcowym dostęp do ogromnych zbiorów danych w celu przeprowadzania analiz ad hoc. Przed Presto Facebook używał Hive (również zbudowanego przez Facebooka, a następnie przekazanego na rzecz Apache Software Foundation) w celu wykonania tego rodzaju analizy. Wraz ze wzrostem zbiorów danych Facebooka, Hive okazał się niewystarczająco interaktywny (czytaj: zbyt wolny). Było to w dużej mierze spowodowane tym, że podstawą Hive jest MapReduce, która w tamtym czasie wymagała utrwalenia pośrednich zestawów danych w HDFS. Oznaczało to wiele operacji wejścia / wyjścia na dysk w przypadku danych, które ostatecznie zostały wyrzucone. 

Presto stosuje inne podejście do wykonywania tych zapytań, aby zaoszczędzić czas. Zamiast przechowywać dane pośrednie w HDFS, Presto pozwala na ściągnięcie danych do pamięci i wykonywanie operacji na tych danych zamiast utrwalania wszystkich pośrednich zestawów danych na dysku. Jeśli brzmi to znajomo, być może słyszałeś o Apache Spark (lub dowolnej liczbie innych technologii), które mają tę samą podstawową koncepcję, aby skutecznie zastąpić technologie oparte na MapReduce. Korzystając z Presto, zatrzymam dane tam, gdzie się one znajdują (na Hadoop lub, jak zobaczymy, w dowolnym miejscu) i będę wykonywać operacje w pamięci w naszym systemie rozproszonym, tasując dane między serwerami w razie potrzeby. Unikam dotykania żadnego dysku, ostatecznie przyspieszając czas wykonywania zapytań.

Jak działa Presto

W odróżnieniu od tradycyjnej hurtowni danych, Presto jest określane jako mechanizm wykonywania zapytań SQL. Hurtownie danych kontrolują sposób zapisu danych, ich lokalizację i odczyt. Gdy dane trafią do magazynu, odzyskanie ich z powrotem może się okazać trudne. Presto stosuje inne podejście, oddzielając przechowywanie danych od przetwarzania, zapewniając jednocześnie obsługę tego samego języka zapytań ANSI SQL, do którego jesteś przyzwyczajony.

Zasadniczo Presto wykonuje zapytania dotyczące zestawów danych dostarczanych przez wtyczki, w szczególności łączniki. Złącze zapewnia Presto możliwość odczytu (a nawet zapisu) danych w zewnętrznym systemie danych. Łącznik Hive jest jednym ze standardowych łączników, używającym tych samych metadanych, których używałbyś do interakcji z HDFS lub Amazon S3. Ze względu na tę łączność Presto jest bezpośrednim zamiennikiem dla organizacji używających obecnie Hive. Jest w stanie odczytać dane z tych samych schematów i tabel przy użyciu tych samych formatów danych - ORC, Avro, Parquet, JSON i nie tylko. Oprócz łącznika Hive znajdziesz łączniki dla Cassandry, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL i wielu innych. Łączniki są dodawane do Presto przez cały czas, co daje Presto możliwość uzyskania dostępu do danych w dowolnym miejscu.

Zaletą tego modelu oddzielonej pamięci masowej jest to, że Presto jest w stanie zapewnić pojedynczy federacyjny widok wszystkich danych - bez względu na to, gdzie się one znajdują. Zwiększa to możliwości zapytań ad hoc do poziomów, których nigdy wcześniej nie osiągnął, jednocześnie zapewniając interaktywne czasy zapytań w dużych zestawach danych (o ile masz infrastrukturę do tworzenia kopii zapasowych, lokalną lub w chmurze).

Przyjrzyjmy się, jak wdrażane jest Presto i jak wygląda wykonywanie zapytań. Presto jest napisane w Javie i dlatego wymaga JDK lub JRE, aby móc się uruchomić. Presto jest wdrażane jako dwie główne usługi, jeden koordynator i wielu pracowników . Usługa Koordynator jest w rzeczywistości mózgiem operacji, ponieważ odbiera zapytania od klientów, analizuje zapytanie, buduje plan wykonania, a następnie planuje pracę do wykonania w wielu usługach Worker. Każdy pracownik równolegle przetwarza część ogólnego zapytania, a do wdrożenia Presto można dodać usługi Worker, aby dostosować je do swoich potrzeb. Każde źródło danych jest skonfigurowane jako katalog i możesz wysyłać zapytania do dowolnej liczby katalogów w każdym zapytaniu.

Ahana

Dostęp do Presto uzyskuje się przez sterownik JDBC i integruje się z praktycznie każdym narzędziem, które może łączyć się z bazami danych za pomocą JDBC. Interfejs wiersza poleceń Presto lub CLI jest często punktem wyjścia do rozpoczęcia eksploracji Presto. Tak czy inaczej, klient łączy się z koordynatorem, aby wysłać zapytanie SQL. To zapytanie jest analizowane i sprawdzane przez koordynatora oraz wbudowane w plan wykonania zapytania. Ten plan zawiera szczegółowe informacje o sposobie wykonania zapytania przez pracowników Presto. Plan kwerend (zazwyczaj) zaczyna się od co najmniej jednego skanowania tabeli w celu pobrania danych z zewnętrznych magazynów danych. Następnie istnieje szereg operatorów wykonujących projekcje, filtry, łączenia, grupowanie, zamówienia i wszelkiego rodzaju inne operacje. Plan kończy się wraz z dostarczeniem klientowi końcowego zestawu wyników za pośrednictwem Koordynatora.Te plany zapytań są niezbędne do zrozumienia, w jaki sposób Presto wykonuje zapytania, a także do analizy wydajności zapytań i znalezienia potencjalnych wąskich gardeł.

Przykład zapytania Presto

Rzućmy okiem na zapytanie i odpowiadający mu plan zapytań. Użyję zapytania TPC-H, popularnego narzędzia testowego używanego w bazach danych SQL. Krótko mówiąc, TPC-H definiuje standardowy zestaw tabel i zapytań w celu przetestowania kompletności języka SQL, a także środek do testów porównawczych różnych baz danych. Dane są przeznaczone do zastosowań biznesowych, zawierających zamówienia sprzedaży towarów, które mogą być dostarczone przez dużą liczbę dostaw. Presto zapewnia złącze TPC-H, które generuje dane w locie - bardzo przydatne narzędzie podczas sprawdzania Presto.

WYBIERZ

  SUMA (l. Cena rozszerzona * l. Rabat) AS przychód

FROM lineitem l

GDZIE

  l.shipdate> = DATA '1994-01-01'

   AND l. Data wysyłki <DATA '1994-01-01' + INTERWAŁ '1' ROK

   ORAZ l. Rabat MIĘDZY 0,06 - 0,01 I 0,01 + 0,01

   AND l.quantity <24;

To jest kwerenda numer sześć, znana jako kwerenda dotycząca prognozowania zmiany przychodów. Cytując dokumentację TPC-H, „to zapytanie określa ilościowo wzrost przychodów, który wynikałby z wyeliminowania niektórych rabatów w całej firmie w danym przedziale procentowym w danym roku”.

Presto dzieli zapytanie na jeden lub więcej etapów, zwanych także fragmentami , a każdy etap zawiera wiele operatorów . Operator to określona funkcja planu, która jest wykonywana, albo skanowanie, filtr, łączenie, albo wymiana. Wymiany często przerywają etapy. Wymiana to część planu, w której dane są przesyłane przez sieć do innych pracowników w klastrze Presto. W ten sposób Presto udaje się zapewnić swoją skalowalność i wydajność - dzieląc zapytanie na wiele mniejszych operacji, które mogą być wykonywane równolegle i zezwalając na redystrybucję danych w klastrze w celu wykonywania połączeń, grupowania i porządkowania zbiorów danych. Przyjrzyjmy się rozproszonemu planowi zapytań dla tego zapytania. Zwróć uwagę, że plany zapytań są odczytywane od dołu do góry.

 Fragment 0 [SINGLE]

     - Realizacja [przychody] => [suma: double]       

             przychody: = suma   

         - Agregat (FINAL) => [suma: double]         

                 sum: = "presto.default.sum" ((sum_4))          

             - LocalExchange [SINGLE] () => [sum_4: double]  

                 - RemoteSource [1] => [sum_4: double]      

 Fragment 1 

     - Agregat (PARTIAL) => [sum_4: double]  

             sum_4: = "presto.default.sum" ((wyr))  

         - ScanFilterProject [table = TableHandle {connectorId = 'tpch', connectorHandle = "lineitem: sf1.0", layout = "Optional [lineitem: sf1.0]"}, grouped = false, filterPredicate = ((rabat BETWEEN (DOUBLE 0,05 ) AND (DOUBLE 0.07)) AND ((quantity) = (DATE 1994-01-01)) AND ((shipdate) [expr: double]

                 wyrażenie: = (cena rozszerzona) * (rabat)   

                 extendedprice := tpch:extendedprice

                 discount := tpch:discount         

                 shipdate := tpch:shipdate 

                 quantity := tpch:quantity  

This plan has two fragments containing several operators. Fragment 1 contains two operators. The ScanFilterProject scans data, selects the necessary columns (called projecting) needed to satisfy the predicates, and calculates the revenue lost due to the discount for each line item. Then a partial Aggregate operator calculates the partial sum. Fragment 0 contains a LocalExchange operator that receives the partial sums from Fragment 1, and then the final aggregate to calculate the final sum. The sum is then output to the client.

When executing the query, Presto scans data from the external data source in parallel, calculates the partial sum for each split, and then ships the result of that partial sum to a single worker so it can perform the final aggregation. Running this query, I get about $123,141,078.23 in lost revenue due to the discounts.

      revenue       

----------------------

 1.2314107822830005E8

As queries grow more complex, such as joins and group-by operators, the query plans can get very long and complicated. With that said, queries break down into a series of operators that can be executed in parallel against data that is held in memory for the lifetime of the query.

As your data set grows, you can grow your Presto cluster in order to maintain the same expected runtimes. This performance, combined with the flexibility to query virtually any data source, can help empower your business to get more value from your data than ever before — all while keeping the data where it is and avoiding expensive transfers and engineering time to consolidate your data into one place for analysis. Presto!

Ashish Tadose is co-founder and principal software engineer at Ahana. Passionate about distributed systems, Ashish joined Ahana from WalmartLabs, where as principal engineer he built a multicloud data acceleration service powered by Presto while leading and architecting other products related to data discovery, federated query engines, and data governance. Previously, Ashish was a senior data architect at PubMatic where he designed and delivered a large-scale adtech data platform for reporting, analytics, and machine learning. Earlier in his career, he was a data engineer at VeriSign. Ashish is also an Apache committer and contributor to open source projects.

New Tech Forum to miejsce, w którym można badać i omawiać pojawiające się technologie dla przedsiębiorstw na niespotykaną dotąd skalę i dogłębnie. Wybór jest subiektywny, oparty na naszym wyborze technologii, które uważamy za ważne i najbardziej interesujące dla czytelników. nie przyjmuje marketingowych materiałów reklamowych do publikacji i zastrzega sobie prawo do edycji wszystkich przesłanych treści. Wszelkie zapytania należy kierować na adres [email protected]