Programmering

Hvorfor du bør bruke Presto til ad hoc-analyse

Presto! Det er ikke bare en besvergelse for å begeistre publikum etter et magisk triks, men også et navn som blir brukt mer og mer når man diskuterer hvordan man kan kjempe gjennom store data. Mens det er mange distribusjoner av Presto i naturen, forblir teknologien - en distribuert SQL-søkemotor som støtter alle slags datakilder - ukjent for mange utviklere og dataanalytikere som kan ha nytte av å bruke den.

I denne artikkelen skal jeg diskutere Presto: hva det er, hvor det kom fra, hvordan det er forskjellig fra andre datalagringsløsninger, og hvorfor du bør vurdere det for dine store dataløsninger.

Presto vs Hive

Presto stammer fra Facebook tilbake i 2012. Åpen kilde i 2013 og administrert av Presto Foundation (en del av Linux Foundation), har Presto opplevd en jevn økning i popularitet gjennom årene. I dag har flere selskaper bygget en forretningsmodell rundt Presto, som Ahana, med PrestoDB-baserte ad hoc-analysetilbud.

Presto ble bygget som et middel for å gi sluttbrukere tilgang til enorme datasett for å utføre ad hoc-analyse. Før Presto ville Facebook bruke Hive (også bygget av Facebook og deretter donert til Apache Software Foundation) for å utføre denne typen analyser. Da Facebooks datasett vokste, ble Hive funnet å være utilstrekkelig interaktiv (les: for sakte). Dette var i stor grad fordi grunnlaget for Hive er MapReduce, som på den tiden krevde at mellomliggende datasett skulle vedvares til HDFS. Det betydde mye I / O til disk for data som til slutt ble kastet.

Presto tar en annen tilnærming til å utføre disse spørsmålene for å spare tid. I stedet for å beholde mellomdata på HDFS, lar Presto deg trekke dataene inn i minnet og utføre operasjoner på dataene der i stedet for å vedvare alle de mellomliggende datasettene til disken. Hvis det høres kjent ut, har du kanskje hørt om Apache Spark (eller et hvilket som helst antall andre teknologier der ute) som har det samme grunnleggende konseptet for effektivt å erstatte MapReduce-baserte teknologier. Ved å bruke Presto vil jeg lagre dataene der de bor (i Hadoop eller, som vi ser, hvor som helst) og utføre kjøringer i minnet på tvers av vårt distribuerte system, og blande data mellom serverne etter behov. Jeg unngår å berøre noen disk, og til slutt øke hastigheten på spørringens utførelse.

Hvordan Presto fungerer

I motsetning til et tradisjonelt datalager, blir Presto referert til som en SQL-spørringsutførelsesmotor. Datalager kontrollerer hvordan data skrives, hvor dataene ligger og hvordan de leses. Når du har fått data inn på lageret ditt, kan det være vanskelig å få dem ut igjen. Presto tar en annen tilnærming ved å frakoble datalagring fra behandling, samtidig som det gir støtte for det samme ANSI SQL-spørringsspråket du er vant til.

I sin kjerne utfører Presto spørsmål over datasett som er levert av plugin-moduler, spesielt Kontakter. En kontakt gir et middel for Presto å lese (og til og med skrive) data til et eksternt datasystem. Hive Connector er en av standardkontaktene, og bruker de samme metadataene du bruker for å samhandle med HDFS eller Amazon S3. På grunn av denne tilkoblingen er Presto en erstatning for organisasjoner som bruker Hive i dag. Den er i stand til å lese data fra de samme skjemaene og tabellene ved hjelp av de samme dataformatene - ORC, Avro, Parquet, JSON og mer. I tillegg til Hive-kontakten, finner du kontakter for Cassandra, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL og mange andre. Kontakter blir bidratt til Presto hele tiden, noe som gir Presto potensialet til å kunne få tilgang til data hvor som helst det lever.

Fordelen med denne frakoblede lagringsmodellen er at Presto er i stand til å gi et enkelt samlet bilde av alle dataene dine - uansett hvor de ligger. Dette forbedrer mulighetene for ad hoc-spørring til nivåer det aldri har nådd før, samtidig som det gir interaktive spørretider over dine store datasett (så lenge du har infrastrukturen til å sikkerhetskopiere det, lokalt eller i skyen).

La oss ta en titt på hvordan Presto blir distribuert, og hvordan det går ut på å utføre spørsmålene dine. Presto er skrevet på Java, og krever derfor en JDK eller JRE for å kunne starte. Presto er distribuert som to hovedtjenester, en enkelt Koordinator og mange Arbeidere. Koordinator-tjenesten er effektivt hjernen til operasjonen, mottar spørringsforespørsler fra klienter, analyserer spørringen, bygger en utførelsesplan og planlegger deretter arbeidet som skal utføres på tvers av mange arbeidstjenester. Hver arbeider behandler en del av det samlede spørsmålet parallelt, og du kan legge til arbeidstjenester i Presto-distribusjonen din for å dekke dine behov. Hver datakilde er konfigurert som en katalog, og du kan spørre så mange kataloger som du vil i hvert søk.

Ahana

Presto er tilgjengelig via en JDBC-driver og integreres med praktisk talt ethvert verktøy som kan koble til databaser ved hjelp av JDBC. Presto kommandolinjegrensesnitt, eller CLI, er ofte utgangspunktet når du begynner å utforske Presto. Uansett kobler klienten seg til koordinatoren for å utstede et SQL-spørsmål. Det spørsmålet blir analysert og validert av koordinatoren, og innebygd i en plan for utførelse av spørringer. Denne planen beskriver hvordan et spørsmål skal utføres av Presto-arbeiderne. Spørringsplanen begynner (vanligvis) med en eller flere tabellskanninger for å trekke data ut av de eksterne datalagrene. Det er da en serie operatører for å utføre projeksjoner, filtre, sammenføyninger, gruppebyer, ordrer og alle slags andre operasjoner. Planen slutter med at det endelige resultatsettet blir levert til klienten via koordinatoren. Disse spørringsplanene er avgjørende for å forstå hvordan Presto utfører spørsmålene dine, samt å kunne dissekere søkeytelsen og finne eventuelle flaskehalser.

Eksempel på Presto-spørring

La oss ta en titt på en spørring og tilsvarende søkeplan. Jeg bruker et TPC-H-spørsmål, et vanlig referanseverktøy som brukes til SQL-databaser. Kort sagt definerer TPC-H et standard sett med tabeller og spørsmål for å teste SQL-språkets fullstendighet, samt et middel til å måle ulike databaser. Dataene er designet for forretningsbruk, og inneholder salgsordrer på varer som kan leveres av et stort antall forsyninger. Presto tilbyr en TPC-H-kontakt som genererer data på farten - et veldig nyttig verktøy når du sjekker ut Presto.

Å VELGE

SUM (l. Utvidet pris * l. Rabatt) AS inntekt

FRA lineitem l

HVOR

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

OG l.skipsdato <DATO '1994-01-01' + INTERVALL '1' ÅR

OG l.rabatt MELLOM 0,06 - 0,01 OG 0,06 + 0,01

OG l.mengde <24;

Dette er spørring nummer seks, kjent som Forecasting Revenue Change Query. Sitat i TPC-H-dokumentasjonen, "kvantifiserer dette spørsmålet mengden inntektsøkning som ville ha blitt resultatet av å eliminere visse rabatter over hele selskapet i et gitt prosentområde i et gitt år."

Presto deler et spørsmål i ett eller flere trinn, også kalt fragmenter, og hvert trinn inneholder flere operatører. En operatør er en bestemt funksjon av planen som utføres, enten en skanning, et filter, en sammenkobling eller en sentral. Utveksling bryter ofte opp etappene. En utveksling er den delen av planen der data sendes over nettverket til andre arbeidere i Presto-klyngen. Slik klarer Presto å tilby skalerbarhet og ytelse - ved å dele et spørsmål i flere mindre operasjoner som kan utføres parallelt og tillate at data blir distribuert over klyngen for å utføre sammenkoblinger, gruppeby og bestilling av datasett. La oss se på den distribuerte spørreplanen for denne spørringen. Merk at spørringsplaner leses nedenfra og opp.

 Fragment 0 [SINGLE]

- Output [income] => [sum: double]

inntekt: = sum

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

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

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

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

Fragment 1

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

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

- ScanFilterProject [table = TableHandle {connectorId = 'tpch', connectorHandle = "lineitem: sf1.0", layout = "Valgfritt [lineitem: sf1.0]"}, gruppert = false, filterPredicate = ((rabatt MELLAN (DOBBEL 0,05) ) OG (DOBBELT 0,07)) OG ((mengde) = (DATO 1994-01-01)) OG ((skipsdato) [eks.: Dobbel]

ekspr: = (utvidet pris) * (rabatt)

utvidet pris: = tpch: utvidet pris

rabatt: = tpch: rabatt

skipsdato: = tpch: skipsdato

mengde: = tpch: mengde

Denne planen har to fragmenter som inneholder flere operatører. Fragment 1 inneholder to operatorer. ScanFilterProject skanner data, velger de nødvendige kolonnene (kalt projiserende) som trengs for å tilfredsstille predikatene, og beregner inntektene som er tapt på grunn av rabatten for hver artikkel. Deretter beregner en delvis aggregatoperatør delsummen. Fragment 0 inneholder en LocalExchange-operatør som mottar delsummene fra fragment 1, og deretter det endelige aggregatet for å beregne den endelige summen. Summen sendes deretter ut til klienten.

Når spørringen kjøres, skanner Presto data fra den eksterne datakilden parallelt, beregner delsummen for hver deling, og sender deretter resultatet av den delsummen til en enkelt arbeider slik at den kan utføre den endelige aggregeringen. Når jeg kjører dette spørsmålet, får jeg rundt 123.141.078,23 dollar i tapte inntekter på grunn av rabattene.

  inntekter

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

1.2314107822830005E8

Etter hvert som spørringene blir mer komplekse, som for eksempel tilknytning og gruppevirksomhet, kan spørringsplanene bli veldig lange og kompliserte. Når det er sagt, fordeler spørringer seg i en rekke operatører som kan utføres parallelt mot data som holdes i minnet i løpet av spørringen.

Når datasettet ditt vokser, kan du utvide Presto-klyngen din for å opprettholde de samme forventede kjøretidene. Denne ytelsen, kombinert med fleksibiliteten til å søke i praktisk talt alle datakilder, kan hjelpe virksomheten din til å få mer verdi av dataene enn noensinne - alt mens du holder dataene der de er og unngår dyre overføringer og teknisk tid til å konsolidere dataene dine ett sted for analyse. Presto!

Ashish Tadose er medstifter og hovedprogramvareingeniør i Ahana. Ashish ble lidenskapelig opptatt av distribuerte systemer og kom til Ahana fra WalmartLabs, hvor han som hovedingeniør bygde en multicloud data-akselerasjonstjeneste drevet av Presto mens han ledet og arkitekturerte andre produkter relatert til dataoppdagelse, fødererte spørsmotorer og datastyring. Tidligere var Ashish senior dataarkitekt hos PubMatic hvor han designet og leverte en storstilt adtech-dataplattform for rapportering, analyse og maskinlæring. Tidligere i karrieren var han dataingeniør i VeriSign. Ashish er også en Apache-kommittør og bidragsyter til open source-prosjekter.

New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til [email protected].

$config[zx-auto] not found$config[zx-overlay] not found