Ipinaliwanag ang Spark Accumulator: Apache Spark

Ibinigay ni Prithviraj Bose

Narito ang isang blog sa mga bagay na kailangan mong malaman tungkol sa Spark accumulator.Kasama si pagiging isang pangunahing kasanayan na hinahanap ng karamihan sa mga IT recruiters, ang paglago at demand nito sa industriya ay naging exponential mula pa nang magsimula ito.

Ano ang mga nagtitipon?

Ang mga accumulator ay mga variable na ginagamit para sa pagsasama-sama ng impormasyon sa mga tagapagpatupad. Halimbawa, ang impormasyong ito ay maaaring nauugnay sa data o diagnosis ng API tulad ng kung gaano karaming mga tala ang nasira o kung gaano karaming beses ang isang partikular na library API ay tinawag.

Upang maunawaan kung bakit kailangan namin ng mga nagtitipid, tingnan natin ang isang maliit na halimbawa.

Narito ang isang haka-haka na tala ng mga transaksyon ng isang kadena ng mga tindahan sa paligid ng rehiyon ng gitnang Kolkata.

Mayroong 4 na mga patlang,

Patlang 1 -> Lungsod

Patlang 2 -> Lokalidad

Field 3 -> Kategoryang item na nabili

Patlang 4 -> Halaga ng item na nabili

hindi nagpapakilalang klase sa java]

Gayunpaman, ang mga log ay maaaring masira. Halimbawa, ang pangalawang linya ay isang blangko na linya, ang pang-apat na linya ay nag-uulat ng ilang mga isyu sa network at sa wakas ang huling linya ay nagpapakita ng halaga ng benta na zero (na hindi maaaring mangyari!).

Maaari naming gamitin ang mga nagtitipon upang pag-aralan ang tala ng transaksyon upang malaman ang bilang ng mga blangko na tala (mga blangko na linya), bilang ng beses na nabigo ang network, ang anumang produkto na walang kategorya o kahit na bilang ng beses na naitala ang mga benta. Matatagpuan ang buong sample na log dito .
Ang mga accumulator ay nalalapat sa anumang operasyon na,
1. Commutative -> f (x, y) = f (y, x) , at
2. Associative -> f (f (x, y), z) = f (f (x, z), y) = f (f (y, z), x)
Halimbawa, kabuuan at max ang mga pagpapaandar ay nasiyahan ang mga kondisyon sa itaas samantalang average ay hindi.

Bakit gumagamit ng Spark Accumulator?

Ngayon bakit kailangan namin ng mga nagtitipid at bakit hindi lamang gumamit ng mga variable tulad ng ipinakita sa code sa ibaba.

Ginagarantiyahan nito ang nagtitipon mga blangko na linya ay na-update sa lahat ng tagapagpatupad at ang mga update ay nai-relay pabalik sa driver.

Maaari naming ipatupad ang iba pang mga counter para sa mga error sa network o zero na halaga ng pagbebenta, atbp. Ang buong code ng mapagkukunan kasama ang pagpapatupad ng iba pang mga counter ay maaaring matagpuan dito .

Mapapansin ng mga taong pamilyar sa Hadoop Map-Reduce na ang mga nagtitipon ng Spark ay pareho sa mga counter ng Map-Reduce ng Hadoop.

Caveats

Kapag gumagamit ng mga nagtitipid mayroong ilang mga pag-uusap na dapat nating magkaroon ng kamalayan ng mga programmer,

1. Mga pagkalkula sa loob mga pagbabago tinatasa nang tamad, kaya maliban kung ang isang aksyon nangyayari sa RDD ang mga pagbabago ay hindi naisakatuparan. Bilang isang resulta nito, ginagamit ng mga nagtitipon sa loob ng mga pagpapaandar tulad ng mapa () o filter () hindi naisakatuparan maliban kung ang ilan aksyon mangyari sa RDD.
2. Ginagarantiyahan ng spark na i-update ang mga nagtitipon sa loob kilos minsan lang . Kaya't kahit na ang isang gawain ay nai-restart at ang lineage ay na recompute, ang mga nagtitipon ay i-update nang isang beses lamang.
3. Hindi ginagarantiyahan ito ng Spark para sa mga pagbabago . Kaya't kung ang isang gawain ay nai-restart at ang lineage ay muling naipon, may mga pagkakataon na hindi kanais-nais na mga epekto kapag ang mga nagtitipid ay nai-update nang higit sa isang beses.

Upang maging ligtas, laging gamitin ang mga nagtitipid sa loob ng mga pagkilos LAMANG.
Ang code dito nagpapakita ng isang simple ngunit mabisang halimbawa sa kung paano ito makakamtan.
Para sa karagdagang impormasyon sa mga nagtitipid, basahin ito .

May tanong ba sa amin? Nabanggit ang mga ito sa seksyon ng komento at babalikan ka namin.

Mga Kaugnay na Post:

Apache Spark pagsamahinByKey Ipinaliwanag