મોટા પ્રમાણના ડેટાની પ્રક્રિયા કેવી રીતે શરૂ કરશો?

Question

IT Interview Practice · Accepted Answer

**Big-data tool પસંદ કરતાં પહેલાં પરિણામ, તેની deadline અને correctnessના નિયમોથી શરૂઆત કરો.** મોટો dataset એટલે distributed processing framework જરૂરી જ હોય એવું નથી.

માનો કે businessને દર સવાર ગઈકાલની merchant પ્રમાણે revenue જોઈએ. આ શંકાસ્પદ payment મંજૂર કરતાં પહેલાં શોધવાથી જુદું છે. બંનેમાં ઘણા records હોઈ શકે, પરંતુ પહેલામાં scheduled processing ચાલે અને બીજામાં સમયસર નિર્ણય જોઈએ.

## 1. શું process કરવું છે તે સ્પષ્ટ કરો

કેટલો data છે, નવો data કેટલી ઝડપે આવે છે, કયા fields જોઈએ અને કેટલો સમય સાચવવો છે તે જાણો. Revenue reportમાં refund મૂળ દિવસને બદલે કે refundના દિવસને તે નક્કી કરો. આ નિયમ વિના ઝડપી pipeline પણ ખોટો total આપી શકે.

Source of truth તથા late અથવા corrected records કેવી રીતે સંભાળવા તે પણ નક્કી કરો. તેનાથી જૂનું result final કરી શકાય કે પછી સુધારવું પડશે તે નક્કી થાય છે.

## 2. વહેંચતાં પહેલાં કામ ઘટાડો

સમય અને resources ક્યાં જાય છે તે માપો: files વાંચવામાં, database queries, computation, network transfer કે results લખવામાં. પછી બિનજરૂરી records વહેલા filter કરો અને જરૂરી columns જ વાંચો.

બધું memoryમાં લોડ કરવાને બદલે bounded chunks process કરો. એક worker deadlineમાં સ્વીકાર્ય ખર્ચે કામ પૂરું કરે તો તે સૌથી સરળ operational system હોઈ શકે. વધુ machines coordination અને data-transfer cost ઉમેરે છે, એટલે માપેલી મર્યાદા ઉકેલવા જ ઉમેરો.

## 3. Deadline પરથી batch અથવા streaming પસંદ કરો

| જરૂરિયાત | શરૂઆતની રીત | કારણ અને જવાબદારી |
|---|---|---|
| દર સવાર સંપૂર્ણ report | Scheduled batch | મર્યાદિત input reconcile અને rerun કરવું સરળ; deadline પહેલાં પૂરું થવું જોઈએ |
| દિવસ દરમિયાન updated dashboard | Incremental batches અથવા streaming | નવા dataને વધુ વાર process કરો; અગાઉના totalsમાં corrections કેવી રીતે લાગશે તે નક્કી કરો |
| દરેક event પછી ટૂંક સમયમાં નિર્ણય | Streaming | Duplicates, late events અને recovery સંભાળીને delay ઘટાડો |

Streaming એટલે આવતા dataનું સતત processing; દરેક event એક જ વાર અને ક્રમમાં આવશે એવી ધારણા નહીં. Daily report માટે businessને ખરેખર fresher results ન જોઈએ તો હું batchથી શરૂ કરું.

## 4. Partial failure સુરક્ષિત બનાવો

Worker revenue total લખીને progress નોંધતાં પહેલાં crash થાય એવું ધારો. Restart પછી તે સમાન records ફરી process કરી શકે. ફરી amounts ઉમેરે તો revenue વધારે ગણાય.

Stable record identifiers અને સુરક્ષિત રીતે ફરી કરી શકાય એવી writes વાપરો, અથવા support હોય ત્યાં output અને progress trackingને transactionથી જોડો. Checkpoint પૂરું થયેલું કામ નોંધે છે; output સુરક્ષિત સાચવતાં પહેલાં તેને save કરવાથી crash પછી કામ છૂટી શકે. પછી save કરો તો વચ્ચેનું કામ સુરક્ષિત replay કરી શકાય તે જરૂરી છે.

- જરૂરી period replay થાય તેટલો સમય source data રાખો.
- Invalid records ચૂપચાપ કાઢવાને બદલે તપાસ માટે અલગ રાખો.
- ધીમા destinationને workers કેટલી ઝડપે data મોકલે તે મર્યાદિત કરો. આ backpressure સતત વધતા memory buffer અથવા queueને અટકાવે છે.

Recovery વર્તન designનો ભાગ છે, પ્રથમ failure પછીનું સફાઈનું કામ નહીં.

## 5. જરૂરી કામ જ distribute કરો

એક worker અપૂરતો હોય ત્યારે inputને independent રીતે ચાલે એવા ભાગમાં વહેંચો. ખરેખર data distribution તપાસો: એક ખૂબ મોટો merchant એક workerને વ્યસ્ત રાખે અને બીજા વહેલા પૂરા થઈ જાય એવું બની શકે.

Grouping અને joiningમાં workers વચ્ચે records ખસેડવા પડે, જેને shuffle કહે છે. શક્ય હોય તો એ પહેલાં data ઘટાડો અને destination combined output લઈ શકે તે જુઓ. Sparkમાં સંબંધિત રીતો છે, પણ ઉપયોગ query અને version પર આધારિત છે; તેનું [performance tuning guide](https://spark.apache.org/docs/3.5.6/sql-performance-tuning.html) જુઓ.

Storage પણ access patterns પ્રમાણે હોવું જોઈએ. Parquet જેવી column-oriented files પસંદ કરેલા fieldsના analytical scans માટે યોગ્ય હોઈ શકે; individual operational lookups માટે indexed database વધુ યોગ્ય હોઈ શકે. માત્ર file size નહીં, માપેલી access જરૂરિયાત પરથી પસંદ કરો.

## 6. ઝડપ અને સાચાપણું સાથે સાબિત કરો

વિશ્વસનીય નાના dataset સામે result સરખાવો અને record counts તથા business totals બંને જુઓ. Duplicate events, refunds, late records અને output લખવા તથા progress સાચવવા વચ્ચે crashનો સમાવેશ કરો.

પછી વાસ્તવિક volume અને skew સાથે runtime, peak memory, backlog અને cost માપો. Revenue reportમાં સફળતા એટલે સહમત deadline પહેલાં સાચો અને ફરી મેળવી શકાય એવો total. **આ શરતો પૂરી કરતી અને data ગુમાવ્યા કે બે વાર ગણ્યા વિના recover થતી સૌથી સરળ pipeline પસંદ કરો.**

જરૂરિયાત	શરૂઆતની રીત	કારણ અને જવાબદારી
દર સવાર સંપૂર્ણ report	Scheduled batch	મર્યાદિત input reconcile અને rerun કરવું સરળ; deadline પહેલાં પૂરું થવું જોઈએ
દિવસ દરમિયાન updated dashboard	Incremental batches અથવા streaming	નવા dataને વધુ વાર process કરો; અગાઉના totalsમાં corrections કેવી રીતે લાગશે તે નક્કી કરો
દરેક event પછી ટૂંક સમયમાં નિર્ણય	Streaming	Duplicates, late events અને recovery સંભાળીને delay ઘટાડો

1. શું process કરવું છે તે સ્પષ્ટ કરો

2. વહેંચતાં પહેલાં કામ ઘટાડો

3. Deadline પરથી batch અથવા streaming પસંદ કરો

4. Partial failure સુરક્ષિત બનાવો

5. જરૂરી કામ જ distribute કરો

6. ઝડપ અને સાચાપણું સાથે સાબિત કરો

સંબંધિત પ્રશ્નો