DStreams vs. DataFrames: Two Flavors of Spark Streaming

This post is a guest publication written by Jaroslav Tkachenko, a Software Architect at Activision.

Apache Spark on yksi suosituimmista ja voimakkaimmista laajamittaisista tietojenkäsittelyjärjestelmistä. Se luotiin vaihtoehtona Hadoopin MapReduce-kehykselle erätyökuormille, mutta nyt se tukee myös SQL: ää, koneoppimista ja stream-prosessointia. Tänään haluan keskittyä Spark Streaming ja näyttää muutamia vaihtoehtoja stream käsittely.

Streamitietojen käsittelyä käytetään, kun dynaamista dataa syntyy jatkuvasti, ja sitä esiintyy usein big datan käyttötapauksissa. Useimmissa tapauksissa tietoja käsitellään lähes reaaliajassa, yksi tallenne kerrallaan, ja tiedoista saatuja oivalluksia käytetään myös hälytysten antamiseen, näyttötaulujen tekemiseen ja koneoppimismallien syöttämiseen, jotka voivat reagoida nopeasti uusiin trendeihin datan sisällä.

DStreams vs. DataFrames

Spark Streaming went alpha with Spark 0.7.0. Se perustuu ajatukseen diskretoiduista puroista tai Dstreameista. Jokainen DStream on edustettuna sekvenssi RDDs, joten se on helppo käyttää, jos olet tulossa matalan tason RDD-tukena erän työkuormia. DStreams koki paljon parannuksia tuona aikana, mutta oli vielä erilaisia haasteita, pääasiassa koska se on hyvin matalan tason API.

ratkaisuna näihin haasteisiin Spark Structured Streaming otettiin käyttöön Spark 2.0: ssa (ja vakiintui 2.2: ssa) Spark SQL: n päälle rakennettuna laajennuksena. Siksi se hyödyntää Spark SQL-koodia ja muistin optimointeja. Strukturoitu Streaming antaa myös erittäin tehokkaita abstraktioita, kuten Dataset/DataFrame API sekä SQL. Ei enää RDD: tä suoraan!

sekä strukturoitu striimaus että striimaus Dstreameilla käyttävät mikroerottelua. Suurin ero on latenssi ja viestin toimitus takuut: jäsennelty Streaming tarjoaa täsmälleen-kerran toimitus 100+ millisekunnin latenssi, kun taas Streaming DStreams lähestymistapa takaa vain-vähintään-kerran toimitus, mutta voi tarjota millisekunnin latenssi.

itse suosin Spark strukturoitua striimausta yksinkertaisiin käyttötapauksiin, mutta Spark striimaus Dstreameilla on joustavuutensa vuoksi todella hyvä asia monimutkaisempiin topologioihin. Siksi alla haluan näyttää, miten käyttää Streaming dstreams ja Streaming DataFrames (jota käytetään tyypillisesti Spark Structured Streaming) kuluttamiseen ja tietojen käsittelyyn Apache Kafka. Käytän Scalaa, Apache Spark 2.3: A ja Apache Kafka 2.0: aa.

myös esimerkkitapausten vuoksi aion hoitaa keikkani Qubolen toimittamilla Apache Zeppelin-muistikirjoilla. Qubole on data-alusta, jota käytän päivittäin. Se hallinnoi Hadoop-ja kipinä-klustereita, helpottaa ad hoc-Hive-ja Presto-kyselyjen suorittamista ja tarjoaa myös hallittuja Zeppelin-muistikirjoja, joita käytän mielelläni. Qubole minun ei tarvitse ajatella paljon konfigurointi ja viritys kipinä ja Zeppelin, se on vain hoitaa minulle.

todellinen käyttötapaukseni on hyvin yksinkertainen:

  • Kafkalle on kirjoitettu jonkinlainen telemetria: pienet JSON — viestit metatiedoilla ja mielivaltaisilla avain/arvopareilla
  • haluan muodostaa yhteyden Kafkaan, kuluttaa ja deserialisoida nuo viestit
  • käytä tarvittaessa muunnoksia
  • kerää joitakin aggregaatioita
  • lopuksi olen kiinnostunut anomalioista ja yleensä huonoista tiedoista-koska en hallitse tuottajaa, Haluan napata sellaisia asioita kuin Nullit, tyhjät merkkijonot, ehkä väärät päivämäärät ja muut arvot erityiset muodot jne.
  • työn pitäisi kestää jonkin aikaa, minkä jälkeen se päättyisi automaattisesti. Tyypillisesti Spark Streaming työt toimivat jatkuvasti, mutta joskus se voi olla hyödyllistä suorittaa ad hoc analyysi/virheenkorjaus (tai esimerkkinä minun tapauksessani, koska se on niin helppo ajaa Kipinätyö kannettavan).

striimaus dstreameilla

tässä lähestymistavassa käytämme Dstreameja, jotka ovat yksinkertaisesti kokoelma RDD: tä.

Streaming with DataFrames

Now we can try to combine Streaming with DataFrames API to get the best of both worlds!

johtopäätös

kumpi lähestymistapa on parempi? Koska DStream on vain kokoelma RDDs, sitä käytetään tyypillisesti matalan tason muutoksia ja käsittely. DataFrames API: n lisääminen sen päälle tarjoaa erittäin tehokkaita abstraktioita, kuten SQL, mutta vaatii hieman enemmän konfigurointia. Ja jos sinulla on yksinkertainen käyttötapaus, Spark Structured Streaming voisi olla parempi ratkaisu yleisesti!

Vastaa

Sähköpostiosoitettasi ei julkaista.

Previous post 10-tuumainen vs 12-tuumainen Mitalisaha: onko isompi aina parempi?
Next post Fatal Motor Vehicle Crash On US Route 1 North At Harrison Street in West Windsor