Presto! Det er ikke kun en tilskyndelse til at begejstre dit publikum efter et magisk trick, men også et navn, der bruges mere og mere, når man diskuterer, hvordan man churn gennem big data. Mens der er mange implementeringer af Presto i naturen, forbliver teknologien - en distribueret SQL-forespørgselsmotor, der understøtter alle slags datakilder - ukendt for mange udviklere og dataanalytikere, der kan have gavn af at bruge den.
I denne artikel vil jeg diskutere Presto: hvad det er, hvor det kom fra, hvordan det adskiller sig fra andre datalagerløsninger, og hvorfor du skal overveje det til dine store dataløsninger.
Presto vs Hive
Presto stammer fra Facebook tilbage i 2012. Open-sourced i 2013 og ledes af Presto Foundation (en del af Linux Foundation), Presto har oplevet en støt stigning i popularitet gennem årene. I dag har flere virksomheder bygget en forretningsmodel omkring Presto, såsom Ahana, med PrestoDB-baserede ad hoc-analysetilbud.
Presto blev bygget som et middel til at give slutbrugerne adgang til enorme datasæt for at udføre ad hoc-analyse. Før Presto ville Facebook bruge Hive (også bygget af Facebook og derefter doneret til Apache Software Foundation) for at udføre denne form for analyse. Da Facebooks datasæt voksede, viste Hive sig at være utilstrækkelig interaktiv (læs: for langsom). Dette skyldtes hovedsageligt grundlaget for Hive er MapReduce, som på det tidspunkt krævede, at mellemliggende datasæt skulle opretholdes til HDFS. Det betød en masse I / O til disk for data, der i sidste ende blev smidt væk.
Presto tager en anden tilgang til at udføre disse forespørgsler for at spare tid. I stedet for at beholde mellemliggende data på HDFS giver Presto dig mulighed for at trække dataene ind i hukommelsen og udføre operationer på dataene der i stedet for at fastholde alle de mellemliggende datasæt til disken. Hvis det lyder velkendt, har du måske hørt om Apache Spark (eller et hvilket som helst antal andre teknologier derude), der har det samme grundlæggende koncept til effektivt at erstatte MapReduce-baserede teknologier. Ved hjælp af Presto opbevarer jeg dataene, hvor de bor (i Hadoop eller, som vi ser, hvor som helst) og udfører eksekveringerne i hukommelsen på tværs af vores distribuerede system og blander data mellem servere efter behov. Jeg undgår at røre ved enhver disk og i sidste ende fremskynde udførelsestiden for forespørgsler.
Sådan fungerer Presto
Forskellig fra et traditionelt datalager kaldes Presto som en SQL-forespørgselsudførelsesmotor. Datavarehuse styrer, hvordan data skrives, hvor disse data ligger, og hvordan de læses. Når du har fået data ind på dit lager, kan det vise sig vanskeligt at få det ud igen. Presto tager en anden tilgang ved at afkoble datalagring fra behandling, samtidig med at den understøtter det samme ANSI SQL-forespørgselssprog, som du er vant til.
I sin kerne udfører Presto forespørgsler over datasæt, der specifikt leveres af plug-ins Stik. En konnektor giver Presto et middel til at læse (og endda skrive) data til et eksternt datasystem. Hive Connector er et af standardstikkene, der bruger de samme metadata, som du ville bruge til at interagere med HDFS eller Amazon S3. På grund af denne forbindelse er Presto en drop-in erstatning for organisationer, der bruger Hive i dag. Det er i stand til at læse data fra de samme skemaer og tabeller ved hjælp af de samme dataformater - ORC, Avro, Parquet, JSON og mere. Ud over Hive-stikket finder du stik til Cassandra, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL og mange andre. Forbindelser bidrager hele tiden til Presto, hvilket giver Presto potentialet til at være i stand til at få adgang til data overalt, hvor det lever.
Fordelen ved denne afkoblede lagermodel er, at Presto er i stand til at give en samlet sammensat visning af alle dine data - uanset hvor de ligger. Dette forstærker mulighederne for ad hoc-forespørgsel til niveauer, som det aldrig har nået før, samtidig med at det giver interaktive forespørgselstider over dine store datasæt (så længe du har infrastrukturen til at sikkerhedskopiere det, lokalt eller i skyen).
Lad os se på, hvordan Presto implementeres, og hvordan det handler om at udføre dine forespørgsler. Presto er skrevet på Java og kræver derfor en JDK eller JRE for at kunne starte. Presto er implementeret som to hovedtjenester, en enkelt Koordinator og mange Arbejdere. Koordinator-tjenesten er faktisk hjernen i operationen, modtager forespørgsler fra klienter, parser forespørgslen, bygger en eksekveringsplan og planlægger derefter arbejde, der skal udføres på tværs af mange Worker-tjenester. Hver Worker behandler en del af den samlede forespørgsel parallelt, og du kan føje Worker-tjenester til din Presto-implementering, så de passer til dine behov. Hver datakilde er konfigureret som en katalog, og du kan forespørge så mange kataloger, som du vil i hver forespørgsel.
AhanaDer er adgang til Presto via en JDBC-driver og integreres med praktisk talt ethvert værktøj, der kan oprette forbindelse til databaser ved hjælp af JDBC. Presto-kommandolinjegrænsefladen eller CLI er ofte udgangspunktet, når man begynder at udforske Presto. Uanset hvad, klienten opretter forbindelse til koordinatoren for at udstede en SQL-forespørgsel. Denne forespørgsel analyseres og valideres af koordinatoren og indbygges i en plan for udførelse af forespørgsler. Denne plan beskriver, hvordan en forespørgsel skal udføres af Presto-medarbejderne. Forespørgselsplanen (typisk) begynder med en eller flere skanninger i en tabel for at trække data ud af dine eksterne datalagre. Der er derefter en række operatører til at udføre fremskrivninger, filtre, sammenføjninger, gruppeby, ordrer og alle former for andre operationer. Planen slutter med, at det endelige resultatsæt leveres til klienten via koordinatoren. Disse forespørgselsplaner er vigtige for at forstå, hvordan Presto udfører dine forespørgsler, samt for at kunne dissekere forespørgselsydeevne og finde eventuelle flaskehalse.
Eksempel på Presto-forespørgsel
Lad os se på en forespørgsel og en tilsvarende forespørgselsplan. Jeg bruger en TPC-H-forespørgsel, et almindeligt benchmarkingværktøj, der bruges til SQL-databaser. Kort sagt definerer TPC-H et standardsæt af tabeller og forespørgsler for at teste SQL-sprogets fuldstændighed samt et middel til at benchmarkere forskellige databaser. Dataene er designet til forretningsbrug, der indeholder salgsordrer på varer, der kan leveres af et stort antal forsyninger. Presto leverer en TPC-H-forbindelse, der genererer data i farten - et meget nyttigt værktøj, når du tjekker Presto.
VÆLGSUM (l.extendedprice * l.discount) AS indtægter
FRA lineitem l
HVOR
l.shipdate> = DATO '1994-01-01'
OG l.skibsdato <DATO '1994-01-01' + INTERVAL '1' ÅR
OG l. Rabat MELLEM 0,06 - 0,01 OG 0,06 + 0,01
OG l.mængde <24;
Dette er forespørgsel nummer seks, kendt som Forecasting Revenue Change Query. Citerer TPC-H-dokumentationen, "denne forespørgsel kvantificerer mængden af indtægtsforøgelse, der ville være resultatet af eliminering af visse virksomhedsdækkende rabatter i et givet procentinterval i et givet år."
Presto opdeler en forespørgsel i et eller flere trin, også kaldet fragmenter, og hvert trin indeholder flere operatører. En operatør er en bestemt funktion af planen, der udføres, enten en scanning, et filter, en sammenføjning eller en udveksling. Udvekslinger opdeler ofte etaperne. En udveksling er den del af planen, hvor data sendes over hele netværket til andre arbejdere i Presto-klyngen. Det er sådan Presto formår at levere sin skalerbarhed og ydeevne - ved at opdele en forespørgsel i flere mindre operationer, der kan udføres parallelt og tillade, at data omfordeles over klyngen for at udføre sammenføjninger, gruppeby og bestilling af datasæt. Lad os se på den distribuerede forespørgselsplan for denne forespørgsel. Bemærk, at forespørgselsplaner læses nedenfra og op.
Fragment 0 [SINGLE]- Output [indtægter] => [sum: dobbelt]
indtægter: = sum
- Samlet (FINAL) => [sum: dobbelt]
sum: = "presto.default.sum" ((sum_4))
- LocalExchange [SINGLE] () => [sum_4: dobbelt]
- RemoteSource [1] => [sum_4: dobbelt]
Fragment 1
- Samlet (PARTIAL) => [sum_4: dobbelt]
sum_4: = "presto.default.sum" ((expr))
- ScanFilterProject [tabel = TableHandle {connectorId = 'tpch', connectorHandle = "lineitem: sf1.0", layout = "Valgfri [lineitem: sf1.0]"}, grupperet = false, filterPredicate = ((rabat MELLEM (DOUBLE 0,05) ) OG (DOBBELT 0,07)) OG ((mængde) = (DATO 1994-01-01)) OG ((skibsdato) [expr: dobbelt]
ekspr: = (udvidet pris) * (rabat)
udvidet pris: = tpch: udvidet pris
rabat: = tpch: rabat
skibsdato: = tpch: skibsdato
mængde: = tpch: mængde
Denne plan har to fragmenter, der indeholder flere operatører. Fragment 1 indeholder to operatorer. ScanFilterProject scanner data, vælger de nødvendige kolonner (kaldet projicering) nødvendigt for at tilfredsstille prædikaterne og beregner den tabte omsætning på grund af rabatten for hver linjepost. Derefter beregner en delvis samlet operator den delvise sum. Fragment 0 indeholder en LocalExchange-operatør, der modtager delsummen fra fragment 1 og derefter det endelige aggregat til beregning af den endelige sum. Summen sendes derefter til klienten.
Når forespørgslen udføres, scanner Presto data fra den eksterne datakilde parallelt, beregner delsummen for hver opdeling og sender derefter resultatet af den delvise sum til en enkelt medarbejder, så den kan udføre den endelige sammenlægning. Når jeg kører denne forespørgsel, får jeg omkring $ 123.141.078,23 i tabt omsætning på grund af rabatterne.
indtægter----------------------
1.2314107822830005E8
Efterhånden som forespørgsler vokser mere komplekse, som f.eks. Sammenkædning og gruppe-by-operatører, kan forespørgselsplanerne blive meget lange og komplicerede. Når det er sagt, opdeles forespørgsler i en række operatører, der kan udføres parallelt mod data, der opbevares i hukommelsen i hele forespørgslens levetid.
Når dit datasæt vokser, kan du dyrke din Presto-klynge for at opretholde de samme forventede driftstider. Denne ydeevne kombineret med fleksibiliteten til at forespørge stort set enhver datakilde kan hjælpe din virksomhed med at få mere værdi af dine data end nogensinde før - alt sammen mens du holder dataene, hvor de er, og undgår dyre overførsler og teknisk tid til at konsolidere dine data i et sted til analyse. Presto!
Ashish Tadose er medstifter og hovedsoftwareingeniør i Ahana. Lidenskabelig med distribuerede systemer sluttede Ashish sig til Ahana fra WalmartLabs, hvor han som hovedingeniør byggede en multicloud dataaccelerationstjeneste drevet af Presto, mens han førte og arkitekturerede andre produkter relateret til dataopdagelse, forenede forespørgselsmotorer og datastyring. Tidligere var Ashish senior dataarkitekt hos PubMatic, hvor han designede og leverede en storstilet adtech-dataplatform til rapportering, analyse og maskinindlæring. Tidligere i sin karriere var han dataingeniør hos VeriSign. Ashish er også en Apache-kommitter og bidragyder til open source-projekter.
—
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
