Perché dovresti usare Presto per analisi ad hoc

Presto! Non è solo un incantesimo per eccitare il tuo pubblico dopo un trucco magico, ma anche un nome usato sempre di più quando si discute di come sfornare i big data. Sebbene esistano molte distribuzioni di Presto in circolazione, la tecnologia, un motore di query SQL distribuito che supporta tutti i tipi di origini dati, rimane sconosciuta a molti sviluppatori e analisti di dati che potrebbero trarne vantaggio.

In questo articolo, parlerò di Presto: cos'è, da dove proviene, in che modo è diverso da altre soluzioni di data warehousing e perché dovresti considerarlo per le tue soluzioni per big data.

Presto contro Hive

Presto è nato su Facebook nel 2012. Creato come open source nel 2013 e gestito dalla Presto Foundation (parte della Linux Foundation), Presto ha registrato un costante aumento di popolarità nel corso degli anni. Oggi, diverse aziende hanno costruito un modello di business attorno a Presto, come Ahana, con offerte di analisi ad hoc basate su PrestoDB.

Presto è stato creato come mezzo per fornire agli utenti finali l'accesso a enormi set di dati per eseguire analisi ad hoc. Prima di Presto, Facebook utilizzava Hive (anch'esso costruito da Facebook e poi donato alla Apache Software Foundation) per eseguire questo tipo di analisi. Man mano che i set di dati di Facebook crescevano, Hive è risultato insufficientemente interattivo (leggi: troppo lento). Ciò è dovuto principalmente al fatto che la base di Hive è MapReduce, che all'epoca richiedeva la persistenza di set di dati intermedi in HDFS. Ciò significava un sacco di I / O su disco per i dati che alla fine venivano gettati via. 

Presto adotta un approccio diverso all'esecuzione di tali query per risparmiare tempo. Invece di mantenere i dati intermedi su HDFS, Presto consente di estrarre i dati in memoria ed eseguire operazioni sui dati invece di conservare tutti i set di dati intermedi su disco. Se suona familiare, potresti aver sentito parlare di Apache Spark (o di qualsiasi altra tecnologia disponibile) che ha lo stesso concetto di base per sostituire efficacemente le tecnologie basate su MapReduce. Usando Presto, manterrò i dati dove risiedono (in Hadoop o, come vedremo, ovunque) ed eseguirò le esecuzioni in memoria attraverso il nostro sistema distribuito, mescolando i dati tra i server secondo necessità. Evito di toccare qualsiasi disco, accelerando in definitiva i tempi di esecuzione delle query.

Come funziona Presto

Diversamente da un data warehouse tradizionale, Presto viene definito motore di esecuzione di query SQL. I data warehouse controllano il modo in cui i dati vengono scritti, dove risiedono e come vengono letti. Una volta inseriti i dati nel tuo magazzino, può essere difficile recuperarli. Presto adotta un altro approccio separando l'archiviazione dei dati dall'elaborazione, fornendo al contempo il supporto per lo stesso linguaggio di query SQL ANSI a cui sei abituato.

Fondamentalmente, Presto esegue query sui set di dati forniti dai plug-in, in particolare dai connettori. Un connettore fornisce a Presto un mezzo per leggere (e persino scrivere) i dati su un sistema di dati esterno. Il connettore Hive è uno dei connettori standard, che utilizza gli stessi metadati che useresti per interagire con HDFS o Amazon S3. A causa di questa connettività, Presto è un sostituto immediato per le organizzazioni che utilizzano Hive oggi. È in grado di leggere i dati dagli stessi schemi e tabelle utilizzando gli stessi formati di dati: ORC, Avro, Parquet, JSON e altri. Oltre al connettore Hive, troverai connettori per Cassandra, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL e molti altri. I connettori vengono forniti costantemente a Presto, offrendo a Presto il potenziale per poter accedere ai dati ovunque si trovi.

Il vantaggio di questo modello di archiviazione disaccoppiato è che Presto è in grado di fornire un'unica visualizzazione federata di tutti i dati, indipendentemente da dove risiedono. Ciò aumenta le capacità di query ad hoc a livelli che non ha mai raggiunto prima, fornendo allo stesso tempo tempi di query interattivi su set di dati di grandi dimensioni (purché si disponga dell'infrastruttura per eseguirne il backup, in locale o nel cloud).

Diamo un'occhiata a come viene distribuito Presto e come esegue le query. Presto è scritto in Java e quindi richiede un JDK o JRE per essere avviato. Presto è distribuito come due servizi principali, un unico coordinatore e molti lavoratori . Il servizio Coordinator è effettivamente il cervello dell'operazione, riceve richieste di query dai client, analizza la query, crea un piano di esecuzione e quindi pianifica il lavoro da svolgere su molti servizi Worker. Ogni Worker elabora una parte della query complessiva in parallelo ed è possibile aggiungere servizi Worker alla distribuzione di Presto per soddisfare le proprie esigenze. Ogni origine dati è configurata come un catalogo ed è possibile eseguire query su tutti i cataloghi desiderati in ciascuna query.

Ahana

Si accede a Presto tramite un driver JDBC e si integra praticamente con qualsiasi strumento in grado di connettersi ai database utilizzando JDBC. L'interfaccia della riga di comando di Presto, o CLI, è spesso il punto di partenza quando si inizia a esplorare Presto. In ogni caso, il client si connette al coordinatore per inviare una query SQL. Quella query viene analizzata e convalidata dal coordinatore e incorporata in un piano di esecuzione della query. Questo piano descrive in dettaglio come verrà eseguita una query dai lavoratori di Presto. Il piano di query (in genere) inizia con una o più scansioni di tabelle per estrarre i dati dagli archivi dati esterni. Ci sono poi una serie di operatori per eseguire proiezioni, filtri, join, raggruppamenti, ordini e tutti i tipi di altre operazioni. Il piano si conclude con la consegna del set di risultati finali al cliente tramite il coordinatore.Questi piani di query sono fondamentali per comprendere come Presto esegue le query, oltre ad essere in grado di analizzare le prestazioni delle query e trovare potenziali colli di bottiglia.

Esempio di query Presto

Diamo un'occhiata a una query e al relativo piano di query. Userò una query TPC-H, uno strumento di benchmarking comune utilizzato per i database SQL. In breve, TPC-H definisce un set standard di tabelle e query per testare la completezza del linguaggio SQL e un mezzo per confrontare vari database. I dati sono progettati per casi d'uso aziendali, contenenti ordini di vendita di articoli che possono essere forniti da un numero elevato di forniture. Presto fornisce un connettore TPC-H che genera dati al volo, uno strumento molto utile durante il check out di Presto.

SELEZIONARE

  SUM (l. Prezzo esteso * l. Sconto) AS entrate

FROM lineitem l

DOVE

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

   E l. Data di spedizione <DATA '1994-01-01' + INTERVALLO '1' ANNO

   E l. Sconto TRA .06 - 0,01 E .06 + 0,01

   E l. Quantità <24;

Questa è la query numero sei, nota come query di modifica dei ricavi di previsione. Citando la documentazione di TPC-H, "questa query quantifica l'ammontare dell'aumento delle entrate che sarebbe stato il risultato dell'eliminazione di alcuni sconti a livello aziendale in un determinato intervallo percentuale in un determinato anno".

Presto suddivide una query in una o più fasi, chiamate anche frammenti , e ciascuna fase contiene più operatori . Un operatore è una particolare funzione del piano che viene eseguito, una scansione, un filtro, un join o uno scambio. Gli scambi spesso interrompono le fasi. Uno scambio è la parte del piano in cui i dati vengono inviati attraverso la rete ad altri lavoratori nel cluster Presto. In questo modo Presto riesce a fornire la propria scalabilità e prestazioni, suddividendo una query in più operazioni più piccole che possono essere eseguite in parallelo e consentono la ridistribuzione dei dati nel cluster per eseguire join, raggruppamenti e ordinamento di set di dati. Diamo un'occhiata al piano di query distribuito per questa query. Tieni presente che i piani di query vengono letti dal basso verso l'alto.

 Frammento 0 [SINGLE]

     - Risultato [entrate] => [somma: doppia]       

             entrate: = somma   

         - Aggregato (FINAL) => [sum: double]         

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

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

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

 Frammento 1 

     - Aggregato (PARZIALE) => [sum_4: double]  

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

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

                 expr: = (prezzo esteso) * (sconto)   

                 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.

Il New Tech Forum offre un luogo per esplorare e discutere la tecnologia aziendale emergente in profondità e ampiezza senza precedenti. La selezione è soggettiva, in base alla nostra scelta delle tecnologie che riteniamo importanti e di maggiore interesse per i lettori. non accetta materiale di marketing per la pubblicazione e si riserva il diritto di modificare tutti i contenuti forniti. Invia tutte le richieste a [email protected]