DStreams vs. DataFrames: Two Flavors of Spark Streaming

aug. 5, 2021
admin

Acest articol este o publicație invitată scrisă de Yaroslav Tkachenko, arhitect software la Activision.

Apache Spark este unul dintre cele mai populare și mai puternice cadre de procesare a datelor pe scară largă. A fost creat ca o alternativă la cadrul MapReduce de la Hadoop pentru sarcini de lucru pe loturi, dar acum suportă, de asemenea, SQL, învățare automată și procesare în flux. Astăzi vreau să mă concentrez pe Spark Streaming și să prezint câteva opțiuni disponibile pentru procesarea în flux.

Prelucrarea datelor în flux este utilizată atunci când datele dinamice sunt generate în mod continuu și este adesea întâlnită în cazurile de utilizare a datelor mari. În cele mai multe cazuri, datele sunt procesate în timp aproape real, câte o înregistrare la un moment dat, iar informațiile derivate din date sunt, de asemenea, utilizate pentru a furniza alerte, pentru a reda tablouri de bord și pentru a alimenta modele de învățare automată care pot reacționa rapid la noile tendințe din cadrul datelor.

DStreams vs. DataFrames

Spark Streaming a devenit alfa cu Spark 0.7.0. Se bazează pe ideea de fluxuri discretizate sau DStreams. Fiecare DStream este reprezentat ca o secvență de RDD-uri, astfel încât este ușor de utilizat dacă veniți de la sarcini de lucru de nivel scăzut pe loturi susținute de RDD-uri. DStreams a suferit o mulțime de îmbunătățiri în această perioadă de timp, dar au existat încă diverse provocări, în primul rând pentru că este un API de nivel foarte scăzut.

Ca soluție la aceste provocări, Spark Structured Streaming a fost introdus în Spark 2.0 (și a devenit stabil în 2.2) ca o extensie construită pe Spark SQL. Din acest motiv, aceasta profită de optimizările de cod și de memorie Spark SQL. Structured Streaming oferă, de asemenea, abstracțiuni foarte puternice, cum ar fi API-urile Dataset/DataFrame, precum și SQL. Nu mai aveți de-a face direct cu RDD!

Atât Structured Streaming cât și Streaming with DStreams utilizează micro-batching. Cea mai mare diferență este latența și garanțiile de livrare a mesajelor: Structured Streaming oferă livrare exact o singură dată cu o latență de peste 100 de milisecunde, în timp ce abordarea Streaming with DStreams garantează doar livrarea cel puțin o dată, dar poate oferi latențe de milisecunde.

Personal prefer Spark Structured Streaming pentru cazuri de utilizare simple, dar Spark Streaming with DStreams este foarte bun pentru topologii mai complicate datorită flexibilității sale. De aceea, mai jos vreau să vă arăt cum să folosiți Streaming with DStreams și Streaming with DataFrames (care este utilizat de obicei cu Spark Structured Streaming) pentru a consuma și procesa date din Apache Kafka. Voi folosi Scala, Apache Spark 2.3 și Apache Kafka 2.0.

De asemenea, de dragul exemplului, voi rula lucrările mele folosind notebook-urile Apache Zeppelin furnizate de Qubole. Qubole este o platformă de date pe care o folosesc zilnic. Aceasta gestionează clusterele Hadoop și Spark, facilitează rularea ad-hoc a interogărilor Hive și Presto și, de asemenea, oferă notebook-uri Zeppelin gestionate pe care le folosesc cu plăcere. Cu Qubole nu trebuie să mă gândesc prea mult la configurarea și reglarea Spark și Zeppelin, totul este pur și simplu gestionat pentru mine.

Cazul real de utilizare pe care îl am este foarte simplu:

  • Un anumit tip de telemetrie este scris în Kafka: mesaje JSON mici cu metadate și perechi arbitrare de chei/valori
  • Vreau să mă conectez la Kafka, să consum și să deserializez aceste mesaje
  • Apoi să aplic transformări dacă este necesar
  • Colectez unele agregări
  • În cele din urmă, sunt interesat de anomalii și, în general, de date proaste – deoarece nu controlez producătorul, vreau să surprind lucruri precum NULL-uri, șiruri goale, poate date incorecte și alte valori cu formate specifice, etc.
  • Lucrarea ar trebui să ruleze un timp, apoi să se încheie automat. În mod obișnuit, joburile Spark Streaming rulează continuu, dar uneori ar putea fi util să fie rulate ad-hoc pentru analiză/depanare (sau ca exemplu în cazul meu, deoarece este atât de ușor să rulezi un job Spark într-un notebook).

Streaming cu DStreams

În această abordare folosim DStreams, care este pur și simplu o colecție de RDD-uri.

Streaming cu DataFrames

Acum putem încerca să combinăm Streaming cu DataFrames API pentru a obține ce e mai bun din ambele lumi!

Concluzie

Ce abordare este mai bună? Deoarece DStream este doar o colecție de RDD-uri, este utilizat de obicei pentru transformări și procesări de nivel scăzut. Adăugarea unei API DataFrames peste aceasta oferă abstracțiuni foarte puternice precum SQL, dar necesită un pic mai multă configurare. Iar dacă aveți un caz de utilizare simplu, Spark Structured Streaming ar putea fi o soluție mai bună în general!

.

Lasă un răspuns

Adresa ta de email nu va fi publicată.