मोठ्या डेटामध्ये फाइल स्वरूप: एक संक्षिप्त शैक्षणिक कार्यक्रम

Remarin द्वारे हवामान देवता

संघ Mail.ru क्लाउड सोल्यूशन्स ऑफर लेखाचे भाषांतर बिग डेटामध्ये कोणते फाइल फॉरमॅट्स आहेत, हडूप फॉरमॅट्सची सर्वात सामान्य वैशिष्ट्ये कोणती आहेत आणि कोणते फॉरमॅट वापरणे चांगले आहे याबद्दल Clairvoyant मधील अभियंता राहुल भाटिया.

वेगवेगळ्या फाईल फॉरमॅट्सची गरज का आहे?

MapReduce आणि Spark सारख्या HDFS-सक्षम ऍप्लिकेशन्ससाठी एक प्रमुख कार्यप्रदर्शन अडथळे म्हणजे डेटा शोधण्यासाठी, वाचण्यासाठी आणि लिहिण्यासाठी लागणारा वेळ. जर आमच्याकडे निश्चित केलेल्या ऐवजी विकसित होणारी स्कीमा असेल किंवा काही स्टोरेज मर्यादा असतील तर मोठ्या डेटा संच व्यवस्थापित करण्यात अडचणीमुळे या समस्या वाढतात.

मोठ्या डेटावर प्रक्रिया केल्याने स्टोरेज उपप्रणालीवरील भार वाढतो - दोष सहिष्णुता प्राप्त करण्यासाठी Hadoop अनावश्यकपणे डेटा संचयित करते. डिस्क्स व्यतिरिक्त, प्रोसेसर, नेटवर्क, इनपुट/आउटपुट सिस्टम आणि असेच लोड केले जातात. डेटाचे प्रमाण जसजसे वाढत जाते, तसतसा तो प्रक्रिया आणि साठवण्याचा खर्चही वाढतो.

मध्ये विविध फाइल स्वरूप हडोप या समस्यांचे अचूक निराकरण करण्यासाठी शोध लावला. योग्य फाइल स्वरूप निवडल्याने काही महत्त्वपूर्ण फायदे मिळू शकतात:

1. जलद वाचन वेळ.
2. जलद रेकॉर्डिंग वेळ.
3. शेअर केलेल्या फायली.
4. स्कीमा उत्क्रांतीसाठी समर्थन.
5. विस्तारित कॉम्प्रेशन समर्थन.

काही फाईल फॉरमॅट सामान्य वापरासाठी असतात, तर काही अधिक विशिष्ट वापरासाठी असतात आणि काही विशिष्ट डेटा वैशिष्ट्यांची पूर्तता करण्यासाठी डिझाइन केलेले असतात. त्यामुळे निवड खरोखर खूप मोठी आहे.

Avro फाइल स्वरूप

करण्यासाठी डेटा अनुक्रमणिका Avro मोठ्या प्रमाणावर वापरले जाते - ते स्ट्रिंग आधारित, म्हणजे, Hadoop मधील स्ट्रिंग डेटा स्टोरेज फॉरमॅट. हे JSON फॉरमॅटमध्ये स्कीमा संचयित करते, कोणत्याही प्रोग्रामद्वारे वाचणे आणि त्याचा अर्थ लावणे सोपे करते. डेटा स्वतः बायनरी स्वरूपात, संक्षिप्त आणि कार्यक्षम आहे.

Avro ची अनुक्रमांक प्रणाली भाषा तटस्थ आहे. फाइल्सवर विविध भाषांमध्ये प्रक्रिया केली जाऊ शकते, सध्या C, C++, C#, Java, Python आणि Ruby.

वेळोवेळी बदलणाऱ्या, म्हणजेच विकसित होणाऱ्या डेटा स्कीमासाठी त्याचा मजबूत सपोर्ट हे Avro चे मुख्य वैशिष्ट्य आहे. Avro स्कीमा बदल समजून घेते — हटवणे, जोडणे किंवा फील्ड बदलणे.

Avro विविध डेटा स्ट्रक्चर्सला सपोर्ट करते. उदाहरणार्थ, तुम्ही एक रेकॉर्ड तयार करू शकता ज्यामध्ये अॅरे, एक प्रगणित प्रकार आणि सबरेकॉर्ड आहे.

डेटा लेकच्या लँडिंग (संक्रमण) झोनमध्ये लिहिण्यासाठी हे स्वरूप आदर्श आहे (डेटा तलाव, किंवा डेटा लेक - थेट डेटा स्त्रोतांव्यतिरिक्त विविध प्रकारचे डेटा संचयित करण्यासाठी उदाहरणांचा संग्रह).

तर, खालील कारणांसाठी डेटा लेकच्या लँडिंग झोनमध्ये लिहिण्यासाठी हे स्वरूप सर्वात योग्य आहे:

1. या झोनमधील डेटा सामान्यतः डाउनस्ट्रीम सिस्टमद्वारे पुढील प्रक्रियेसाठी संपूर्णपणे वाचला जातो - आणि या प्रकरणात पंक्ती-आधारित स्वरूप अधिक कार्यक्षम आहे.
2. डाउनस्ट्रीम सिस्टीम फाइल्समधून स्कीमा टेबल्स सहजपणे पुनर्प्राप्त करू शकतात-बाह्य मेटा स्टोरेजमध्ये स्कीमा स्वतंत्रपणे संग्रहित करण्याची आवश्यकता नाही.
3. मूळ स्कीमामधील कोणताही बदल सहजपणे प्रक्रिया केला जातो (स्कीमा उत्क्रांती).

Parquet फाइल स्वरूप

Parquet हे Hadoop साठी एक ओपन सोर्स फाइल फॉरमॅट आहे जे स्टोअर करते नेस्टेड डेटा स्ट्रक्चर्स फ्लॅट कॉलम फॉरमॅटमध्ये.

पारंपारिक पंक्तीच्या दृष्टिकोनाच्या तुलनेत, पर्केट स्टोरेज आणि कार्यक्षमतेच्या बाबतीत अधिक कार्यक्षम आहे.

हे विशेषतः विस्तृत (अनेक स्तंभ) सारणीमधील विशिष्ट स्तंभ वाचणाऱ्या क्वेरींसाठी उपयुक्त आहे. फाइल फॉरमॅटबद्दल धन्यवाद, फक्त आवश्यक स्तंभ वाचले जातात, त्यामुळे I/O कमीत कमी ठेवला जातो.

एक लहान विषयांतर आणि स्पष्टीकरण: Hadoop मधील Parquet फाइल फॉरमॅट अधिक चांगल्या प्रकारे समजून घेण्यासाठी, स्तंभ-आधारित - म्हणजे स्तंभ - स्वरूप काय आहे ते पाहू. हे स्वरूप प्रत्येक स्तंभासाठी समान मूल्ये एकत्रितपणे संग्रहित करते.

उदाहरणार्थ, रेकॉर्डमध्ये आयडी, नाव आणि विभाग फील्ड समाविष्ट आहेत. या प्रकरणात, सर्व आयडी स्तंभ मूल्ये एकत्र संग्रहित केली जातील, जसे की नाव स्तंभ मूल्ये इत्यादी. टेबल असे काहीतरी दिसेल:

ID
नाव
विभाग

1
emp1
d1

2
emp2
d2

3
emp3
d3

स्ट्रिंग फॉरमॅटमध्ये, डेटा खालीलप्रमाणे सेव्ह केला जाईल:

1
emp1
d1
2
emp2
d2
3
emp3
d3

स्तंभीय फाइल स्वरूपनात, समान डेटा याप्रमाणे जतन केला जाईल:

1
2
3
emp1
emp2
emp3
d1
d2
d3

जेव्हा तुम्हाला टेबलमधून अनेक स्तंभांची क्वेरी करायची असते तेव्हा स्तंभ स्वरूप अधिक कार्यक्षम असते. हे फक्त आवश्यक स्तंभ वाचेल कारण ते समीप आहेत. अशा प्रकारे, I/O ऑपरेशन्स कमीत कमी ठेवल्या जातात.

उदाहरणार्थ, तुम्हाला फक्त NAME स्तंभाची आवश्यकता आहे. IN स्ट्रिंग स्वरूप डेटासेटमधील प्रत्येक रेकॉर्ड लोड करणे, फील्डद्वारे विश्लेषित करणे आणि नंतर NAME डेटा काढणे आवश्यक आहे. कॉलम फॉरमॅट तुम्हाला थेट नेम कॉलमवर ड्रिल डाउन करण्याची परवानगी देतो कारण त्या कॉलमची सर्व व्हॅल्यू एकत्र साठवलेली असतात. तुम्हाला संपूर्ण रेकॉर्डिंग स्कॅन करण्याची गरज नाही.

अशा प्रकारे, स्तंभीय स्वरूप क्वेरी कार्यप्रदर्शन सुधारते कारण आवश्यक स्तंभांपर्यंत पोहोचण्यासाठी कमी लुकअप वेळ लागतो आणि I/O ऑपरेशन्सची संख्या कमी करते कारण फक्त इच्छित स्तंभ वाचले जातात.

अद्वितीय वैशिष्ट्यांपैकी एक छप्पर या स्वरूपात ते शक्य आहे नेस्टेड स्ट्रक्चर्ससह डेटा संग्रहित करा. याचा अर्थ असा की Parquet फाइलमध्ये, नेस्टेड स्ट्रक्चरमधील सर्व फील्ड न वाचता नेस्टेड फील्ड देखील स्वतंत्रपणे वाचता येतात. नेस्टेड स्ट्रक्चर्स साठवण्यासाठी पर्केट श्रेडिंग आणि असेंबली अल्गोरिदम वापरते.

Hadoop मधील Parquet फाइल स्वरूप समजून घेण्यासाठी, तुम्हाला खालील अटी माहित असणे आवश्यक आहे:

1. पंक्ती गट (पंक्ती गट): पंक्तींमध्ये डेटाचे तार्किक क्षैतिज विभाजन. पंक्ती गटामध्ये डेटा सेटमधील प्रत्येक स्तंभाचा एक तुकडा असतो.
2. स्तंभ खंड (स्तंभ भाग): विशिष्ट स्तंभाचा तुकडा. हे स्तंभाचे तुकडे पंक्तींच्या विशिष्ट गटामध्ये राहतात आणि फाइलमध्ये संलग्न असण्याची हमी दिली जाते.
3. पृष्ठ (पृष्ठ): स्तंभाचे तुकडे एकामागून एक लिहिलेल्या पृष्ठांमध्ये विभागलेले आहेत. पृष्ठांना एक सामान्य शीर्षक आहे, त्यामुळे वाचताना तुम्ही अनावश्यक गोष्टी वगळू शकता.

येथे शीर्षकात फक्त जादूचा क्रमांक आहे PAR1 (4 बाइट्स) जे फाइलला Parquet फाइल म्हणून ओळखते.

तळटीप खालील म्हणते:

1. फाइल मेटाडेटा ज्यामध्ये प्रत्येक स्तंभाच्या मेटाडेटाचे प्रारंभिक निर्देशांक असतात. वाचताना, स्वारस्य असलेले सर्व स्तंभ खंड शोधण्यासाठी तुम्ही प्रथम फाइलचा मेटाडेटा वाचला पाहिजे. स्तंभाचे भाग नंतर क्रमाने वाचले पाहिजेत. इतर मेटाडेटामध्ये फॉरमॅट आवृत्ती, स्कीमा आणि कोणत्याही अतिरिक्त की-व्हॅल्यू जोड्या समाविष्ट असतात.
2. मेटाडेटा लांबी (4 बाइट).
3. जादूची संख्या PAR1 (4 बाइट्स).

ORC फाइल स्वरूप

ऑप्टिमाइझ पंक्ती-स्तंभ फाइल स्वरूप (अनुकूलित पंक्ती स्तंभ, ओआरसी) डेटा संचयित करण्याचा एक अतिशय कार्यक्षम मार्ग ऑफर करतो आणि इतर स्वरूपांच्या मर्यादांवर मात करण्यासाठी डिझाइन केले होते. मोठ्या, गुंतागुंतीच्या किंवा मॅन्युअली देखरेख केलेल्या अनुक्रमणिका तयार न करता - तुम्हाला अनावश्यक तपशील वगळण्याची परवानगी देऊन उत्तम प्रकारे कॉम्पॅक्ट स्वरूपात डेटा संग्रहित करते.

ORC स्वरूपाचे फायदे:

1. एक फाईल प्रत्येक टास्कचे आउटपुट असते, जे NameNode (नाव नोड) वरील भार कमी करते.
2. Hive डेटा प्रकारांसाठी समर्थन, तारीख वेळ, दशांश आणि जटिल डेटा प्रकार (स्ट्रक्चर, सूची, नकाशा आणि युनियन).
3. वेगवेगळ्या RecordReader प्रक्रियांद्वारे एकाच फाईलचे एकाचवेळी वाचन.
4. मार्करसाठी स्कॅन न करता फायली विभाजित करण्याची क्षमता.
5. फाईल तळटीपमधील माहितीवर आधारित वाचन/लेखन प्रक्रियेसाठी जास्तीत जास्त संभाव्य हीप मेमरी वाटपाचा अंदाज.
6. मेटाडेटा प्रोटोकॉल बफर्स ​​बायनरी सीरियलायझेशन फॉरमॅटमध्ये संग्रहित केला जातो, जो फील्ड जोडण्याची आणि काढण्याची परवानगी देतो.

ORC एकाच फाईलमध्ये स्ट्रिंगचे संग्रह संग्रहित करते आणि संग्रहामध्ये, स्ट्रिंग डेटा स्तंभाच्या स्वरूपात संग्रहित केला जातो.

ओआरसी फाइल फाईलच्या तळटीपमध्ये पट्टे नावाच्या ओळींचे गट आणि सहाय्यक माहिती संग्रहित करते. फाईलच्या शेवटी पोस्टस्क्रिप्टमध्ये कॉम्प्रेशन पॅरामीटर्स आणि कॉम्प्रेस केलेल्या फूटरचा आकार असतो.

डीफॉल्ट पट्टी आकार 250 MB आहे. अशा मोठ्या पट्ट्यांमुळे, HDFS वरून वाचन अधिक कार्यक्षमतेने केले जाते: मोठ्या संलग्न ब्लॉक्समध्ये.

फाइल फूटर फाइलमधील लेनची सूची, प्रति लेनच्या पंक्तींची संख्या आणि प्रत्येक स्तंभाचा डेटा प्रकार रेकॉर्ड करतो. प्रत्येक स्तंभासाठी गणना, किमान, कमाल आणि बेरीजचे परिणामी मूल्य देखील तेथे लिहिलेले आहे.

स्ट्रिपच्या फूटरमध्ये प्रवाह स्थानांची निर्देशिका असते.

टेबल स्कॅन करताना पंक्ती डेटा वापरला जातो.

अनुक्रमणिका डेटामध्ये प्रत्येक स्तंभासाठी किमान आणि कमाल मूल्ये आणि प्रत्येक स्तंभातील पंक्तींची स्थिती समाविष्ट असते. ORC इंडेक्स फक्त पट्टे आणि पंक्ती गट निवडण्यासाठी वापरले जातात, प्रश्नांची उत्तरे देण्यासाठी नाही.

भिन्न फाइल स्वरूपांची तुलना

Parquet च्या तुलनेत Avro

1. Avro एक पंक्ती संचयन स्वरूप आहे, तर Parquet कॉलममध्ये डेटा संग्रहित करते.
2. विश्लेषणात्मक प्रश्नांसाठी Parquet अधिक योग्य आहे, म्हणजे वाचन ऑपरेशन्स आणि क्वेरी डेटा लेखनापेक्षा अधिक कार्यक्षम आहेत.
3. Avro मध्ये लेखन ऑपरेशन्स Parquet पेक्षा अधिक कार्यक्षमतेने केले जातात.
4. Avro सर्किट उत्क्रांती अधिक परिपक्वपणे हाताळते. Parquet फक्त स्कीमा जोडण्यास समर्थन देते, तर Avro बहु-कार्यात्मक उत्क्रांती, म्हणजेच स्तंभ जोडणे किंवा बदलणे समर्थन करते.
5. मल्टी-कॉलम टेबलमधील कॉलम्सच्या उपसंच क्वेरीसाठी Parquet आदर्श आहे. Avro ETL ऑपरेशन्ससाठी योग्य आहे जिथे आम्ही सर्व कॉलम्सची चौकशी करतो.

ORC विरुद्ध Parquet

1. Parquet नेस्टेड डेटा अधिक चांगल्या प्रकारे साठवतो.
2. ओआरसी पुशडाउनचा अंदाज घेण्यासाठी अधिक योग्य आहे.
3. ORC ACID गुणधर्मांना समर्थन देते.
4. ORC डेटा अधिक चांगल्या प्रकारे संकुचित करते.

विषयावर अजून काय वाचायचे:

1. क्लाउडमध्ये मोठे डेटा विश्लेषण: कंपनी डेटा-केंद्रित कशी होऊ शकते.
2. डेटाबेस स्कीमासाठी एक नम्र मार्गदर्शक.
3. डिजिटल परिवर्तनाबद्दल आमचे टेलिग्राम चॅनेल.

स्त्रोत: www.habr.com