मोठ्या प्रमाणातील डेटा प्रक्रियेकडे कसे पाहता?

Question

IT Interview Practice · Accepted Answer

**Big-data साधन निवडण्याआधी निकाल, अंतिम वेळ आणि अचूकतेचे नियम ठरवा.** मोठा dataset म्हणजे distributed processing framework आवश्यकच असे नाही.

दर सकाळी व्यापाऱ्यानुसार कालचे उत्पन्न हवे असे समजा. हे पेमेंट मंजूर करण्याआधी संशयास्पद व्यवहार शोधण्यापेक्षा वेगळे आहे. दोन्हींत अनेक रेकॉर्ड असतील, पण एक नियोजित चालते तर दुसऱ्याला वेळेत निर्णय हवा.

## 1. काय प्रक्रिया करायचे ते ठरवा

सध्याचा डेटा, नवीन येण्याचा वेग, आवश्यक field आणि साठवण कालावधी स्पष्ट करा. उत्पन्नात refund मूळ दिवस बदलतो की refund चा दिवस, हे ठरवा. नियमाशिवाय जलद pipeline ही चुकीची बेरीज देईल.

अधिकृत स्रोत आणि उशिराचे किंवा दुरुस्त record कसे हाताळायचे तेही ठरवा. याने जुना निकाल अंतिम करता येईल की नंतर बदलावा लागेल हे ठरते.

## 2. वितरित करण्याआधी काम कमी करा

File वाचन, database query, गणना, network transfer किंवा output लेखन यात वेळ व संसाधने कुठे जातात ते मोजा. मग अनावश्यक record लवकर गाळा आणि आवश्यक स्तंभच वाचा.

सर्व memory मध्ये न आणता मर्यादित chunk प्रक्रिया करा. एक worker स्वीकार्य खर्चात वेळेत पूर्ण करत असेल तर ती सर्वात सोपी प्रणाली असू शकते. अधिक machine समन्वय व data transfer खर्च आणतात, म्हणून दिसलेली मर्यादा सोडवण्यासाठी वाढवा.

## 3. वेळेवरून batch की streaming ठरवा

| गरज | सुरुवातीचा मार्ग | कारण आणि जबाबदारी |
|---|---|---|
| दर सकाळी पूर्ण अहवाल | नियोजित batch | मर्यादित input जुळवणे व पुन्हा चालवणे सोपे; वेळेत पूर्ण हवा |
| दिवसभर बदलणारा dashboard | Incremental batch किंवा streaming | नवीन डेटा वारंवार प्रक्रिया करा; जुने total दुरुस्त करण्याचा नियम द्या |
| प्रत्येक event नंतर लगेच निर्णय | Streaming | विलंब कमी करत duplicate, late event आणि recovery हाताळा |

Streaming म्हणजे येणारा डेटा सतत प्रक्रिया करणे, प्रत्येक event एकदाच क्रमाने येईल असे मानणे नाही. दैनिक अहवालासाठी अधिक ताजे निकाल खरोखर हवे नसतील तर batch ने सुरू करेन.

## 4. अंशतः failure सुरक्षित करा

Worker ने revenue total लिहिला आणि progress नोंदण्याआधी crash झाला असे समजा. Restart नंतर तेच record पुन्हा येऊ शकतात. रक्कम पुन्हा जोडल्यास उत्पन्न जास्त दिसते.

स्थिर record ID आणि सुरक्षित पुनर्लेखन वापरा किंवा शक्य असल्यास output व progress transaction मध्ये जोडा. Checkpoint पूर्ण प्रगती नोंदतो; output सुरक्षित होण्याआधी तो लिहिल्यास crash नंतर काम सुटेल. नंतर लिहिल्यास मधल्या पोकळीचा सुरक्षित replay हवा.

- आवश्यक कालावधी पुन्हा चालवण्यासाठी स्रोत डेटा पुरेसा काळ ठेवा.
- चुकीचे record शांतपणे टाकून न देता तपासासाठी वेगळे करा.
- संथ गंतव्याकडे worker किती वेगाने पाठवतो ते मर्यादित करा. हे backpressure memory buffer किंवा queue अमर्याद वाढू देत नाही.

Recovery design चाच भाग आहे; पहिल्या failure नंतरची साफसफाई नाही.

## 5. आवश्यक कामच वितरित करा

एक worker अपुरा असेल तर input स्वतंत्र चालू शकणाऱ्या भागात विभागा. प्रत्यक्ष वाटप तपासा: एक मोठा व्यापारी एक worker व्यस्त ठेवेल आणि बाकी लवकर संपतील.

Grouping आणि join साठी worker मध्ये record हलवणे, म्हणजे shuffle, लागू शकते. शक्य असल्यास त्याआधी डेटा कमी करा आणि गंतव्य एकत्रित output स्वीकारते का पाहा. Spark तंत्र देतो, पण उपयोग query व version वर ठरतो; [performance tuning guide](https://spark.apache.org/docs/3.5.6/sql-performance-tuning.html) पाहा.

Storage देखील access pattern नुसार असावी. Parquet सारखी column-oriented file निवडक field च्या analytical scan ला योग्य, तर indexed database एकेक operational lookup ला चांगला असू शकतो. फक्त file size नव्हे, मोजलेल्या वापरावर निवडा.

## 6. वेग आणि अचूकता दोन्ही सिद्ध करा

विश्वासार्ह छोट्या dataset शी निकाल तुलना करून count आणि business total तपासा. Duplicate event, refund, late record आणि output व progress मधील crash घ्या.

मग वास्तविक volume आणि skew मध्ये runtime, peak memory, backlog आणि खर्च मोजा. अहवालाचे यश म्हणजे योग्य व पुन्हा बनवता येणारा total ठरलेल्या वेळेपूर्वी मिळणे. **अटी पूर्ण करणारी आणि डेटा न गमावता किंवा दोनदा न मोजता सावरणारी सर्वात सोपी pipeline निवडा.**

गरज	सुरुवातीचा मार्ग	कारण आणि जबाबदारी
दर सकाळी पूर्ण अहवाल	नियोजित batch	मर्यादित input जुळवणे व पुन्हा चालवणे सोपे; वेळेत पूर्ण हवा
दिवसभर बदलणारा dashboard	Incremental batch किंवा streaming	नवीन डेटा वारंवार प्रक्रिया करा; जुने total दुरुस्त करण्याचा नियम द्या
प्रत्येक event नंतर लगेच निर्णय	Streaming	विलंब कमी करत duplicate, late event आणि recovery हाताळा

1. काय प्रक्रिया करायचे ते ठरवा

2. वितरित करण्याआधी काम कमी करा

3. वेळेवरून batch की streaming ठरवा

4. अंशतः failure सुरक्षित करा

5. आवश्यक कामच वितरित करा

6. वेग आणि अचूकता दोन्ही सिद्ध करा

संबंधित प्रश्न