आइसबर्ग और मिनिओ के साथ लेकहाउस आर्किटेक्चर के लिए आपकी निश्चित मार्गदर्शिका

ऐसा लगता है कि अपाचे आइसबर्ग ने डेटा जगत में तूफान ला दिया है। शुरुआत में रेयान ब्लू द्वारा नेटफ्लिक्स में इनक्यूबेट किया गया, अंततः इसे अपाचे सॉफ्टवेयर फाउंडेशन को प्रेषित किया गया जहां यह वर्तमान में स्थित है। इसके मूल में यह बड़े पैमाने पर विश्लेषणात्मक डेटा सेट के लिए एक खुला तालिका प्रारूप है (सैकड़ों टीबी से सैकड़ों पीबी के बारे में सोचें)।

यह एक बहु-इंजन संगत प्रारूप है। इसका मतलब यह है कि स्पार्क, ट्रिनो, फ्लिंक, प्रेस्टो, हाइव और इम्पाला सभी डेटा सेट पर स्वतंत्र रूप से और एक साथ काम कर सकते हैं। यह डेटा विश्लेषण, एसक्यूएल की भाषा के साथ-साथ पूर्ण स्कीमा विकास, छिपे हुए विभाजन, समय यात्रा और रोलबैक और डेटा संपीड़न जैसी प्रमुख विशेषताओं का समर्थन करता है।

यह पोस्ट इस बात पर केंद्रित है कि कैसे आइसबर्ग और मिनिओ एक दूसरे के पूरक हैं और कैसे विभिन्न विश्लेषणात्मक ढांचे (स्पार्क, फ्लिंक, ट्रिनो, ड्रेमियो और स्नोफ्लेक) दोनों का लाभ उठा सकते हैं।

पृष्ठभूमि

जबकि अपाचे हाइव अपने समय के लिए एक बड़ा कदम था, अंततः इसमें दरारें दिखाई देने लगीं क्योंकि एनालिटिक्स अनुप्रयोग अधिक असंख्य, विविध और परिष्कृत हो गए। प्रदर्शन प्राप्त करने के लिए, डेटा को निर्देशिकाओं में रहना आवश्यक था और उन निर्देशिकाओं को लगातार प्रबंधित करने की आवश्यकता थी। इससे निर्देशिकाओं का एक डेटाबेस तैयार हो गया। इससे यह समस्या हल हो गई कि डेटा कहाँ था, लेकिन इसने उस तालिका के लिए स्थिति क्या थी की समस्या पेश की - जो अब दो स्थानों (निर्देशिकाओं का डेटाबेस और फ़ाइल सिस्टम) में थी।

यह सीमित है कि आप क्या कर सकते हैं और कितना लचीलापन मौजूद है - विशेष रूप से परिवर्तनों के संबंध में, जिसकी गारंटी एक ही ऑपरेशन के साथ दोनों स्थानों पर नहीं दी जा सकती है।

कल्पना कीजिए कि बड़ी मात्रा में बहु-वर्षीय डेटा को तिथि के अनुसार विभाजित किया गया है। वर्षों को महीनों और सप्ताहों में विभाजित किया जाता है और, यदि सप्ताहों को दिनों में, और दिनों को घंटों में और इसी तरह विभाजित किया जाता है - तो निर्देशिका सूची फट जाती है। हाइव मेटास्टोर (एचएमएस) एक ट्रांजेक्शनल आरडीबीएमएस है। फ़ाइल सिस्टम (HDFS) गैर-लेन-देन वाला है। जब विभाजन की जानकारी बदली जाती है तो इसके लिए विभाजन भंडार और फ़ाइल सिस्टम दोनों के पुनर्निर्माण की आवश्यकता होती है।

समस्या टिकाऊ नहीं थी और किसी भी पैचिंग से अंतर्निहित समस्याओं का समाधान नहीं होने वाला था। वास्तव में, डेटा वृद्धि के साथ चुनौतियाँ बढ़ती ही जा रही थीं।

आधुनिक ओपन टेबल प्रारूप के लिए लक्ष्य

डेटा लेकहाउस आर्किटेक्चर के आसपास प्रमुख विक्रय बिंदुओं में से एक यह है कि यह कई विश्लेषणात्मक इंजनों और रूपरेखाओं का समर्थन करता है। उदाहरण के लिए, आपको ईएलटी (एक्सट्रैक्ट, लोड, ट्रांसफॉर्म) और ईटीएल (एक्सट्रैक्ट, ट्रांसफॉर्म, लोड) दोनों का समर्थन करना होगा। आपको बिजनेस इंटेलिजेंस, बिजनेस एनालिटिक्स और एआई/एमएल प्रकार के वर्कलोड का समर्थन करने की आवश्यकता है। आपको सुरक्षित और पूर्वानुमानित तरीके से तालिकाओं के समान सेट के साथ सफलतापूर्वक इंटरफ़ेस करने की आवश्यकता है। इसका मतलब है कि स्पार्क, फ्लिंक, ट्रिनो, एरो और डस्क जैसे कई इंजनों को किसी न किसी तरह से एक सामंजस्यपूर्ण वास्तुकला में बांधा जाना चाहिए।

एक बहु-इंजन प्लेटफ़ॉर्म जो प्रत्येक इंजन को सफल बनाने में सक्षम बनाते हुए डेटा को कुशलतापूर्वक संग्रहीत करता है, वह है जो विश्लेषणात्मक दुनिया के लिए तरस रहा है, और आइसबर्ग और डेटा लेकहाउस आर्किटेक्चर क्या प्रदान करते हैं।

यह आसान नहीं है और इसमें बहुत सारी चुनौतियाँ हैं; डेटा के विश्वसनीय अद्यतन के साथ एकाधिक इंजनों का उपयोग करने का कोई आसान तरीका नहीं है। लेकिन अब भी हमारे पास दो या तीन प्रारूप हैं जो विश्वसनीय अपडेट प्रदान करते हैं, फिर भी बहुत भ्रम है और इस क्षेत्र में समस्याएं हैं।

आधुनिक आवश्यकताएँ इस प्रकार दिखती हैं:

1. सेंट्रल टेबल स्टोरेज : डेटा को गणना से स्वतंत्र संग्रहीत करना एक महत्वपूर्ण वास्तुशिल्प निर्णय बन जाता है। इसका महत्व इसलिए है क्योंकि डेटा में गुरुत्वाकर्षण होता है और यह हमें डेटा के स्थान की ओर खींचता है। इसलिए, यदि हमारा डेटा पूरी तरह से एक विक्रेता या क्लाउड प्रदाता के पास है तो हम केवल उस विक्रेता या क्लाउड प्रदाता से बंधे हैं। यह स्वाभाविक रूप से समस्याग्रस्त है जब वे सिस्टम बंद हो जाते हैं या डिज़ाइन में विशिष्ट होते हैं। ओपन सॉफ्टवेयर आधुनिक आर्किटेक्चर के लिए आवश्यकता बन गया है।

   
   

2. पोर्टेबल कंप्यूट : एक अन्य आधुनिक आवश्यकता आपके कंप्यूट इंजन को एक अलग विक्रेता/क्लाउड प्रदाता के पास ले जाने या विशेष कंप्यूट इंजन का लाभ उठाने की क्षमता है। जबकि कई लोग गुरुत्वाकर्षण के केंद्र (डेटा) पर ध्यान केंद्रित करते हैं, उद्यम को तर्क, कोड और एसक्यूएल के लिए पोर्टेबिलिटी की भी आवश्यकता होती है।

   
   

3. अभिगम नियंत्रण : अधिकांश उद्यमों के लिए सभी इंजनों के लिए एक सुसंगत प्राधिकरण नीति रखना एक बड़ी चुनौती है। हालाँकि, यह केवल वास्तुकला से कहीं अधिक है, क्योंकि कई इंजनों में इन नीतियों का सफल और दोहराव योग्य कार्यान्वयन एक परिचालन अनिवार्यता बन जाता है।

   
   

4. संरचना बनाए रखें : मानव कार्य के सबसे बड़े स्रोतों में से एक जो हमने पिछले कुछ वर्षों में देखा है वह डेटा संरचना को खोना है क्योंकि इसे कहीं और स्थानांतरित कर दिया गया है। इसका एक आदर्श उदाहरण स्नोफ्लेक हुआ करता था। स्नोफ्लेक में डेटा ले जाने की प्रक्रिया मैन्युअल थी और तृतीय-पक्ष डेटा सेट की शुरूआत के कारण विभिन्न फ़ाइल स्वरूपों और संचलन के दौरान स्वरूपों में परिवर्तन के कारण पुन: कार्य करना पड़ा।

बचाव के लिए अपाचे हिमखंड

अपाचे आइसबर्ग को ओपन टेबल प्रारूप को लागू करने के आधार के रूप में ऊपर उल्लिखित अधिकांश चुनौतियों और लक्ष्यों के साथ तैयार किया गया है। यह निम्नलिखित चुनौतियों का समाधान करता है:

1. लचीली गणना

   • डेटा स्थानांतरित न करें; एकाधिक इंजनों को निर्बाध रूप से काम करना चाहिए

   • बैच, स्ट्रीमिंग और तदर्थ नौकरियों का समर्थन करें

   • केवल जेवीएम फ्रेमवर्क ही नहीं, बल्कि कई भाषाओं के कोड का समर्थन करें

     
     

2. SQL वेयरहाउस व्यवहार

   • SQL तालिकाओं के साथ विश्वसनीय लेनदेन जहां हमारे पास CRUD संचालन को विश्वसनीय रूप से करने की क्षमता है

   • चिंताओं को वास्तविक तालिकाओं से अलग करने से अलगाव मिलता है

     
     

अपाचे आइसबर्ग अपने रिकॉर्ड को ऑब्जेक्ट स्टोरेज में रखता है - अपाचे हाइव के विपरीत। आइसबर्ग SQL व्यवहार को कई इंजनों द्वारा लाभ उठाने में सक्षम बनाता है और इसे विशाल तालिकाओं के लिए डिज़ाइन किया गया है। उत्पादन में, जहां एक ही तालिका में दसियों पेटाबाइट डेटा हो सकता है, यह बहुत मायने रखता है। यहां तक कि मल्टी-पेटाबाइट तालिकाओं को तालिका मेटाडेटा के माध्यम से छानने के लिए वितरित SQL इंजन की आवश्यकता के बिना, एक ही नोड से पढ़ा जा सकता है।

स्रोत: https://iceberg.apache.org/spec/

आइसबर्ग का एक अलिखित नियम है, बिग डेटा स्टैक में उपयोग किए जाने पर अदृश्य होना। यह दर्शन SQL टेबल स्पेस से आता है, जहाँ हम कभी नहीं सोचते कि SQL टेबल के नीचे क्या है। जैसा कि कोई भी व्यवसायी जानता है, Hadoop और Hive-जैसी तालिकाओं के साथ काम करते समय ऐसा बिल्कुल नहीं होता है।

आइसबर्ग इसे दो तरह से सरल रखता है। सबसे पहले, तालिकाओं में परिवर्तन किए जाने पर अप्रिय आश्चर्य से बचें। उदाहरण के लिए, किसी परिवर्तन से वह डेटा कभी वापस नहीं आना चाहिए जो हटा दिया गया था। दूसरा, आइसबर्ग संदर्भ स्विचिंग को कम कर देता है क्योंकि टेबल के नीचे क्या है इससे कोई फर्क नहीं पड़ता - जो काम किया जाना है वह मायने रखता है।

आइसबर्ग फाइलआईओ को समझना

FileIO कोर आइसबर्ग लाइब्रेरी और अंतर्निहित स्टोरेज के बीच का इंटरफ़ेस है। FileIO को आइसबर्ग के लिए एक ऐसी दुनिया में काम करने के तरीके के रूप में बनाया गया था जहां वितरित गणना और भंडारण अलग-अलग हैं। विरासत Hadoop पारिस्थितिकी तंत्र को पदानुक्रमित पथ और विभाजन संरचनाओं की आवश्यकता होती है जो व्यवहार में, ऑब्जेक्ट स्टोरेज दुनिया में गति और पैमाने को प्राप्त करने के लिए उपयोग की जाने वाली विधियों के बिल्कुल विपरीत हैं।

Hadoop और Hive उच्च-प्रदर्शन और स्केलेबल क्लाउड-नेटिव ऑब्जेक्ट स्टोरेज के लिए विरोधी पैटर्न हैं। डेटा लेक एप्लिकेशन जो मिनिओ के साथ इंटरैक्ट करने के लिए एस3 एपीआई पर निर्भर हैं, आसानी से लाखों या अरबों ऑब्जेक्ट पर प्रति सेकंड हजारों लेनदेन तक पहुंच सकते हैं। आप समानांतर में कई समवर्ती अनुरोधों को संसाधित करके पढ़ने और लिखने के प्रदर्शन को बढ़ा सकते हैं। आप उपसर्ग जोड़कर इसे पूरा करते हैं - वर्णों की एक स्ट्रिंग जो किसी ऑब्जेक्ट नाम का सबसेट है, पहले अक्षर से शुरू होती है - बकेट में और फिर समानांतर संचालन लिखकर, प्रत्येक उपसर्ग के अनुसार एक कनेक्शन खोलता है।

इसके अलावा, फ़ाइल सिस्टम निर्देशिकाओं पर Hadoop की निर्भरता ऑब्जेक्ट स्टोरेज में परिवर्तित नहीं होती है - डेटा सेट को अलग-अलग निर्देशिकाओं में भौतिक रूप से व्यवस्थित करना और पथ मौजूद नहीं होने पर उन्हें पथ द्वारा संबोधित करना कठिन है। Hadoop डेटा सेट को परिभाषित करने और समवर्ती और संघर्ष समाधान के लिए लॉकिंग तंत्र प्रदान करने के लिए एक फ़ाइल सिस्टम पर निर्भर करता है। इसके अलावा, Hadoop पारिस्थितिकी तंत्र में, नाम बदलने की प्रक्रिया वाली नौकरियां परमाणु होनी चाहिए। S3 API का उपयोग करना संभव नहीं है क्योंकि नाम बदलना वास्तव में दो ऑपरेशन हैं: कॉपी करना और हटाना। दुर्भाग्य से, इसका परिणाम यह है कि पढ़ने और लिखने के बीच कोई अलगाव नहीं है, जो संभवतः संघर्षों, टकरावों और विसंगतियों को जन्म देता है।

इसके विपरीत, आइसबर्ग को ऑब्जेक्ट स्टोरेज का उपयोग करके भौतिक भंडारण से पूरी तरह अलग होकर चलाने के लिए डिज़ाइन किया गया था। मेटाडेटा में परिभाषित अनुसार सभी स्थान "स्पष्ट, अपरिवर्तनीय और पूर्ण" हैं। आइसबर्ग संदर्भ निर्देशिकाओं के बोझ के बिना तालिका की पूर्ण स्थिति को ट्रैक करता है। S3 API का उपयोग करके संपूर्ण पदानुक्रम को सूचीबद्ध करने की तुलना में किसी तालिका को खोजने के लिए मेटाडेटा का उपयोग करना नाटकीय रूप से तेज़ है। कोई नाम नहीं है - एक कमिट बस मेटाडेटा तालिका में नई प्रविष्टियाँ जोड़ता है।

FileIO API योजना और प्रतिबद्ध चरणों के दौरान मेटाडेटा संचालन करता है। कार्य अंतर्निहित डेटा फ़ाइलों को पढ़ने और लिखने के लिए FileIO का उपयोग करते हैं, और इन फ़ाइलों के स्थानों को कमिट के दौरान तालिका मेटाडेटा में शामिल किया जाता है। इंजन वास्तव में यह कैसे करता है यह FileIO के कार्यान्वयन पर निर्भर करता है। विरासत परिवेशों के लिए, HadoopFileIO मौजूदा Hadoop FileSystem कार्यान्वयन और आइसबर्ग के भीतर FileIO API के बीच एक एडाप्टर परत के रूप में कार्य करता है।

हम इसके बजाय S3FileIO पर ध्यान केंद्रित करने जा रहे हैं क्योंकि यह एक मूल S3 कार्यान्वयन है। जब हम अपना क्लाउड-नेटिव लेकहाउस बनाते हैं तो हमें Hadoop क्राफ्ट को अपने साथ ले जाने की आवश्यकता नहीं होती है। आइसबर्ग फाइलआईओ: क्लाउड नेटिव टेबल्स के अनुसार, देशी एस3 कार्यान्वयन के फायदों में शामिल हैं:

• अनुबंध व्यवहार: Hadoop फ़ाइल सिस्टम कार्यान्वयन में सख्त अनुबंध व्यवहार होता है जिसके परिणामस्वरूप अतिरिक्त अनुरोध (अस्तित्व जांच, डीकंफ्लिक्ट निर्देशिकाएं और पथ) होते हैं जो ओवरहेड और जटिलता जोड़ते हैं। आइसबर्ग पूरी तरह से पता योग्य और अद्वितीय पथों का उपयोग करता है जो अतिरिक्त जटिलता से बचाता है।

• अनुकूलित अपलोड: S3FileIO बड़े कार्यों के लिए डिस्क खपत को कम करने के लिए उत्तरोत्तर डेटा अपलोड करके स्टोरेज/मेमोरी को अनुकूलित करता है और आउटपुट के लिए एकाधिक फ़ाइलें खुली होने पर कम मेमोरी खपत को संरक्षित करता है।

• S3 क्लाइंट अनुकूलन: क्लाइंट नवीनतम प्रमुख AWS SDK संस्करण (v2) का उपयोग करता है और उपयोगकर्ताओं को S3 (किसी भी S3 API संगत एंडपॉइंट सहित) के साथ उपयोग के लिए क्लाइंट को पूरी तरह से अनुकूलित करने की अनुमति देता है।

• क्रमांकन प्रदर्शन: HadoopFileIO के साथ कार्य प्रसंस्करण के लिए Hadoop कॉन्फ़िगरेशन के क्रमांकन की आवश्यकता होती है, जो काफी बड़ा है और विकृत मामलों में प्रसंस्करण धीमा हो सकता है और संसाधित डेटा की तुलना में अधिक ओवरहेड हो सकता है।

• कम निर्भरताएँ: Hadoop फ़ाइल सिस्टम कार्यान्वयन एक बड़े निर्भरता वृक्ष का परिचय देता है और एक सरलीकृत कार्यान्वयन समग्र पैकेजिंग जटिलता को कम करता है।

  
  

आइसबर्ग 0.11.0 से आगे के सभी संस्करणों के लिए स्पार्क और फ्लिंक रनटाइम के साथ बंडल किए गए आइसबर्ग-एडब्ल्यूएस मॉड्यूल के माध्यम से विभिन्न एडब्ल्यूएस सेवाओं के साथ एकीकरण प्रदान करता है। आइसबर्ग उपयोगकर्ताओं को S3FileIO के माध्यम से S3 पर डेटा लिखने की अनुमति देता है। S3FileIO का उपयोग करते समय, कैटलॉग को io-impl कैटलॉग प्रॉपर्टी का उपयोग करके S3 API का उपयोग करने के लिए कॉन्फ़िगर किया जाता है। S3FileIO अनुकूलित सुरक्षा (S3 एक्सेस कंट्रोल सूचियां, सभी तीन S3 सर्वर साइड एन्क्रिप्शन मोड) और प्रदर्शन (प्रगतिशील मल्टीपार्ट अपलोड) के लिए नवीनतम S3 सुविधाओं को अपनाता है और इसलिए ऑब्जेक्ट स्टोरेज उपयोग मामलों के लिए इसकी अनुशंसा की जाती है।

आइसबर्ग और मिनिओ ट्यूटोरियल

इस समय, आइसबर्ग के साथ काम करने के लिए स्पार्क सबसे अधिक सुविधा संपन्न कंप्यूट इंजन है, इसलिए यह ट्यूटोरियल आइसबर्ग अवधारणाओं और सुविधाओं को समझने के लिए स्पार्क और स्पार्क-एसक्यूएल का उपयोग करने पर केंद्रित है। उबंटू 20.04 पर, हम जावा, पोस्टग्रेएसक्यूएल को कैटलॉग या मेटाडेटा पॉइंटर, स्पार्क और मिनिओ के रूप में स्थापित और कॉन्फ़िगर करेंगे - जबकि जावा निर्भरता को सावधानीपूर्वक डाउनलोड और कॉन्फ़िगर करेंगे। फिर हम तालिका बनाने, पॉप्युलेट करने, क्वेरी करने और संशोधित करने के लिए स्पार्क-एसक्यूएल चलाएंगे। हम कुछ अद्भुत चीज़ों के बारे में भी जानेंगे जो आप आइसबर्ग के साथ कर सकते हैं, जैसे स्कीमा विकास, छिपे हुए विभाजन के साथ काम करना, समय यात्रा और रोलबैक। प्रत्येक चरण के बाद, हम मिनिओ में आइसबर्ग बकेट का एक स्क्रीनशॉट शामिल करते हैं ताकि आप देख सकें कि पर्दे के पीछे क्या चल रहा है।

आवश्यक शर्तें

मिनियो सर्वर डाउनलोड करें और प्रारंभ करें । आईपी एड्रेस, टीसीपी पोर्ट, एक्सेस कुंजी और गुप्त कुंजी रिकॉर्ड करें।
मिनियो क्लाइंट डाउनलोड और इंस्टॉल करें ।

उपनाम सेट करने और आइसबर्ग के लिए बकेट बनाने के लिए मिनियो क्लाइंट का उपयोग करें

 mc alias set minio http://<your-MinIO-IP:port> <your-MinIO-access-key> <your-MinIO-secret-key> mc mb minio/iceberg Bucket created successfully `myminio/iceberg`.

आपको Hadoop, AWS S3 और JDBC जैसी विभिन्न कार्यक्षमताओं को सक्षम करने के लिए आवश्यक जावा आर्काइव्स (JARs) का उपयोग करने के लिए स्पार्क को डाउनलोड और कॉन्फ़िगर करना होगा। आपको PATH और CLASSPATH में प्रत्येक आवश्यक JAR और कॉन्फ़िगरेशन फ़ाइल का सही संस्करण भी रखना होगा। दुर्भाग्य से, JAR के विभिन्न संस्करणों को लागू करना और आप कौन सा JAR चला रहे हैं इसका ट्रैक खो देना बहुत आसान है और इसलिए शो-स्टॉपिंग असंगतताओं का सामना करना पड़ता है।

यदि आपने पहले से ऐसा नहीं किया है तो जावा रनटाइम इंस्टॉल करें। Ubuntu 20.04 के लिए, कमांड है

 sudo apt install curl mlocate default-jdk -y

सिस्टम सेवा के रूप में चलाने के लिए PostgreSQL को डाउनलोड और कॉन्फ़िगर करें

 sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - sudo apt-get update sudo apt-get -y install postgresql sudo systemctl start postgresql.service

हम एक सुपरयूजर के रूप में icebergcat भूमिका बनाएंगे, पासवर्ड सेट करेंगे और एक डेटाबेस icebergcat बनाएंगे

 sudo -u postgres createuser --interactive ALTER ROLE icebergcat PASSWORD 'minio'; sudo -u postgres createdb icebergcat

डेटाबेस की कार्यप्रणाली को सत्यापित करने के लिए उसमें लॉग इन करें, आपसे पासवर्ड के लिए कहा जाएगा:

 psql -U icebergcat -d icebergcat -W -h 127.0.0.1

अपाचे स्पार्क को डाउनलोड करें, निकालें और स्थानांतरित करें

 $ wget https://dlcdn.apache.org/spark/spark-3.2.1/spark-3.2.1-bin-hadoop3.2.tgz $ tar zxvf spark-3.2.1-bin-hadoop3.2.tgz $ sudo mv spark-3.2.1-bin-hadoop3.2/ /opt/spark

निम्नलिखित को ~/.bashrc में जोड़कर स्पार्क वातावरण सेट करें और फिर परिवर्तनों को लागू करने के लिए शेल को पुनरारंभ करें।

 export SPARK_HOME=/opt/spark export PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin bash -l

निम्नलिखित .jar फ़ाइलें आवश्यक हैं. स्पार्क मशीन पर किसी भी आवश्यक स्थान पर .jar फ़ाइलों को डाउनलोड करें और कॉपी करें, उदाहरण के लिए /opt/spark/jars ।

S3 प्रोटोकॉल का समर्थन करने के लिए aws-java-sdk-bundle/1.11.901.jar (या उच्चतर) की आवश्यकता है।

 $ wget https://repo1.maven.org/maven2/software/amazon/awssdk/bundle/2.17.230/bundle-2.17.230.jar

आइसबर्ग-स्पार्क-रनटाइम-3.2_2.12.jar आवश्यक है।

 $ wget https://repo.maven.apache.org/maven2/org/apache/iceberg/iceberg-spark-runtime-3.1_2.12/0.13.2/iceberg-spark-runtime-3.1_2.12-0.13.2.jar

स्पार्क प्रारंभ करें

स्पार्क स्टैंडअलोन मास्टर सर्वर प्रारंभ करें

 $ start-master.sh starting org.apache.spark.deploy.master.Master, logging to /opt/spark/logs/spark-msarrel-org.apache.spark.deploy.master.Master-1-<Your-Machine-Name>.out

ब्राउज़र खोलें और http: // Your-IPaddress:7077 पर जाएं

स्पार्क://<आपका-मशीन-नाम>:7077 पर स्पार्क जीवित है

स्पार्क वर्कर प्रक्रिया प्रारंभ करें

 $ /opt/spark/sbin/start-worker.sh spark://<Your-Machine-Name>:7077 starting org.apache.spark.deploy.worker.Worker, logging to /opt/spark/logs/spark-msarrel-org.apache.spark.deploy.worker.Worker-1-<Your-Machine-Name>.out

स्पार्क-एसक्यूएल और आइसबर्ग

स्पार्क-एसक्यूएल लॉन्च करने से पहले पर्यावरण को आरंभ करें।

 export AWS_ACCESS_KEY_ID=minioadmin export AWS_SECRET_ACCESS_KEY=minioadmin export AWS_S3_ENDPOINT=10.0.0.10:9000 export AWS_REGION=us-east-1 export MINIO_REGION=us-east-1 export DEPENDENCIES="org.apache.iceberg:iceberg-spark-runtime-3.2_2.12:0.13.2" export AWS_SDK_VERSION=2.17.230 export AWS_MAVEN_GROUP=software.amazon.awssdk export AWS_PACKAGES=( "bundle" "url-connection-client" ) for pkg in "${AWS_PACKAGES[@]}"; do export DEPENDENCIES+=",$AWS_MAVEN_GROUP:$pkg:$AWS_SDK_VERSION" done

मेटाडेटा के लिए PostgreSQL और MiniIO के लिए आवश्यक S3 API के समर्थन का उपयोग करके आइसबर्ग के साथ स्पार्क-एसक्यूएल लॉन्च करने के लिए निम्नलिखित कमांड चलाएँ। वैकल्पिक रूप से, आप अपनी स्थानीय spark-defaults.conf फ़ाइल का उपयोग करके कॉन्फ़िगरेशन सेट कर सकते हैं

 $ spark-sql --packages $DEPENDENCIES \ --conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \ --conf spark.sql.catalog.demo=org.apache.iceberg.spark.SparkCatalog --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.jdbc.JdbcCatalog \ --conf spark.sql.catalog.my_catalog.uri=jdbc:postgresql://127.0.0.1:5432/icebergcat \ --conf spark.sql.catalog.my_catalog.jdbc.user=icebergcat \ --conf spark.sql.catalog.my_catalog.jdbc.password=minio \ --conf spark.sql.catalog.my_catalog.warehouse=s3://iceberg \ --conf spark.sql.catalog.my_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO \ --conf spark.sql.catalog.my_catalog.s3.endpoint=http://10.0.0.10:9000 \ --conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog \ --conf spark.sql.defaultCatalog=my_catalog \ --conf spark.eventLog.enabled=true \ --conf spark.eventLog.dir=/home/iceicedata/spark-events \ --conf spark.history.fs.logDirectory= /home/iceicedata/spark-events \ --conf spark.sql.catalogImplementation=in-memory

इस कॉन्फ़िगरेशन के बारे में कुछ महत्वपूर्ण नोट्स

• हम एक कैटलॉग my_catalog घोषित करते हैं जो आंतरिक आईपी पते पर PostgreSQL से कनेक्ट करने के लिए JDBC का उपयोग करता है और मेटाडेटा के लिए icebergcat तालिका का उपयोग करता है।
• फिर हमने अपने गोदाम स्थान को पहले बनाए गए मिनिओ बकेट पर सेट किया और इसे एक्सेस करने के लिए S3FileIO उपयोग करने के लिए आइसबर्ग को कॉन्फ़िगर किया।

एक तालिका बनाना

इसके बाद, हम एक साधारण तालिका बनाएंगे।

 CREATE TABLE my_catalog.my_table ( id bigint, data string, category string) USING iceberg LOCATION 's3://iceberg' PARTITIONED BY (category);

यहां एक व्यापक प्रदर्शन सुधार है जो आइसबर्ग S3FileIO के साथ पेश करता है। यह हममें से उन लोगों के लिए एक बड़ी राहत है, जो ऑब्जेक्ट प्रीफ़िक्स के आधार पर थ्रॉटलिंग अनुरोधों के परिणामस्वरूप S3 के साथ पारंपरिक हाइव स्टोरेज लेआउट का उपयोग करते समय धीमे प्रदर्शन से पीड़ित हैं। यह कोई रहस्य नहीं है कि AWS S3 पर एक विभाजित एथेना/हाइव तालिका बनाने में 30-60 मिनट लग सकते हैं। आइसबर्ग डिफ़ॉल्ट रूप से हाइव स्टोरेज लेआउट का उपयोग करता है, लेकिन इसे ObjectStoreLocationProvider उपयोग करने के लिए स्विच किया जा सकता है।

ObjectStoreLocationProvider के साथ, प्रत्येक संग्रहीत फ़ाइल के लिए एक नियतात्मक हैश उत्पन्न होता है, हैश को सीधे write.data.path के बाद जोड़ा जाता है। यह सुनिश्चित करता है कि S3-संगत ऑब्जेक्ट स्टोरेज में लिखी गई फ़ाइलें S3 बकेट में कई उपसर्गों में समान रूप से वितरित की जाती हैं, जिसके परिणामस्वरूप S3-संबंधित IO संचालन के लिए न्यूनतम थ्रॉटलिंग और अधिकतम थ्रूपुट होता है। ObjectStoreLocationProvider उपयोग करते समय, आपके आइसबर्ग तालिकाओं में एक साझा और संक्षिप्त write.data.path होने से प्रदर्शन में सुधार होगा। हाइव की तुलना में प्रदर्शन और विश्वसनीयता को बेहतर बनाने के लिए आइसबर्ग में बहुत कुछ किया गया है।

 CREATE TABLE my_catalog.my_table ( id bigint, data string, category string) USING iceberg OPTIONS ( 'write.object-storage.enabled'=true, 'write.data.path'='s3://iceberg') PARTITIONED BY (category);

मिनिओ कंसोल को देखने पर, हम देखते हैं कि हमारे iceberg बकेट के नीचे my_table के लिए एक पथ बनाया गया था

बकेट में एक metadata पथ होता है

इस बिंदु पर, तालिका में कोई डेटा नहीं है, केवल तालिका का वर्णन करने वाला मेटाडेटा है। PostgreSQL में आइसबर्ग कैटलॉग तालिका में संग्रहीत इस मेटाडेटा के लिए एक संकेतक भी है। स्पार्क-एसक्यूएल (क्वेरी इंजन) टेबल नाम ( my_table ) द्वारा आइसबर्ग कैटलॉग ( my_catalog ) को खोजता है, और यूआरआई को वर्तमान मेटाडेटा फ़ाइल में पुनर्प्राप्त करता है।

आइए पहली मेटाडेटा फ़ाइल पर एक नज़र डालें, जहां तालिका के स्कीमा, विभाजन और स्नैपशॉट के बारे में जानकारी संग्रहीत है। जबकि सभी स्नैपशॉट परिभाषित हैं, current-snapshot-id क्वेरी इंजन को बताता है कि किस स्नैपशॉट का उपयोग करना है, फिर क्वेरी इंजन snapshots सरणी में उस मान की खोज करता है, उस स्नैपशॉट की manifest-list का मान प्राप्त करता है और उसमें मेनिफेस्ट फ़ाइलें खोलता है सूची, क्रम में. ध्यान दें कि हमारे उदाहरण में केवल एक स्नैपशॉट है क्योंकि तालिका अभी बनाई गई है, और कोई मैनिफ़ेस्ट नहीं है क्योंकि हमने अभी तक डेटा सम्मिलित नहीं किया है।

 { "format-version" : 1, "table-uuid" : "b72c46d1-0648-4e02-aab3-0d2853c97363", "location" : "s3://iceberg/my_table", "last-updated-ms" : 1658795119167, "last-column-id" : 3, "schema" : { "type" : "struct", "schema-id" : 0, "fields" : [ { "id" : 1, "name" : "id", "required" : false, "type" : "long" }, { "id" : 2, "name" : "data", "required" : false, "type" : "string" }, { "id" : 3, "name" : "category", "required" : false, "type" : "string" } ] }, "current-schema-id" : 0, "schemas" : [ { "type" : "struct", "schema-id" : 0, "fields" : [ { "id" : 1, "name" : "id", "required" : false, "type" : "long" }, { "id" : 2, "name" : "data", "required" : false, "type" : "string" }, { "id" : 3, "name" : "category", "required" : false, "type" : "string" } ] } ], "partition-spec" : [ { "name" : "category", "transform" : "identity", "source-id" : 3, "field-id" : 1000 } ], "default-spec-id" : 0, "partition-specs" : [ { "spec-id" : 0, "fields" : [ { "name" : "category", "transform" : "identity", "source-id" : 3, "field-id" : 1000 } ] } ], "last-partition-id" : 1000, "default-sort-order-id" : 0, "sort-orders" : [ { "order-id" : 0, "fields" : [ ] } ], "properties" : { "option.write.data.path" : "s3://iceberg/my_table", "owner" : "msarrel", "option.write.object-storage.enabled" : "true", "write.data.path" : "s3://iceberg/my_table", "write.object-storage.enabled" : "true" }, "current-snapshot-id" : -1, "snapshots" : [ ], "snapshot-log" : [ ], "metadata-log" : [ ] }

इसके बाद, आइए कुछ नकली डेटा डालें और उन फ़ाइलों को देखें जिन्हें आइसबर्ग मिनिओ में संग्रहीत करता है। iceberg बकेट के अंदर, अब my_table/metadata और my_table/data उपसर्ग हैं।

 INSERT INTO my_catalog.my_table VALUES (1, 'a', "music"), (2, 'b', "music"), (3, 'c', "video"); 

मेटाडेटा उपसर्ग में मूल मेटाडेटा फ़ाइल, एक मेनिफेस्ट सूची और मेनिफेस्ट फ़ाइलें शामिल हैं। मेनिफेस्ट सूची - आपने अनुमान लगाया - मेनिफेस्ट फ़ाइलों की एक सूची है। मेनिफेस्ट सूची में प्रत्येक मेनिफेस्ट फ़ाइल के बारे में जानकारी होती है जो प्रत्येक स्नैपशॉट में शामिल होती है: मेनिफेस्ट फ़ाइल का स्थान, वह स्नैपशॉट जिसके परिणामस्वरूप इसे जोड़ा गया था, विभाजन के बारे में जानकारी और संबंधित डेटा फ़ाइलों के विभाजन कॉलम के लिए निचली और ऊपरी सीमाएं। क्वेरी के दौरान, क्वेरी इंजन मेनिफेस्ट सूची से मेनिफेस्ट फ़ाइल स्थानों का मान पढ़ता है और उपयुक्त मेनिफेस्ट फ़ाइलें खोलता है। मेनिफेस्ट सूची AVRO प्रारूप में है.

मेनिफेस्ट फ़ाइलें डेटा फ़ाइलों को ट्रैक करती हैं और प्रत्येक फ़ाइल के बारे में विवरण और पूर्व-गणना किए गए आँकड़े शामिल करती हैं। ट्रैक की जाने वाली पहली चीज़ फ़ाइल स्वरूप और स्थान है। मेनिफेस्ट फ़ाइलें वे हैं जिनसे आइसबर्ग फ़ाइल सिस्टम स्थान के आधार पर हाइव-शैली ट्रैकिंग डेटा को हटा देता है। मेनिफेस्ट फ़ाइलें विभाजन सदस्यता, रिकॉर्ड गणना और प्रत्येक कॉलम की निचली और ऊपरी सीमाओं जैसे विवरणों को शामिल करके डेटा फ़ाइलों को पढ़ने की दक्षता और प्रदर्शन में सुधार करती हैं। आँकड़े लेखन कार्यों के दौरान लिखे जाते हैं और हाइव आँकड़ों की तुलना में उनके समय पर, सटीक और अद्यतित होने की अधिक संभावना होती है।

जब एक SELECT क्वेरी सबमिट की जाती है, तो क्वेरी इंजन मेटाडेटा डेटाबेस से मेनिफेस्ट सूची का स्थान प्राप्त करता है। फिर क्वेरी इंजन प्रत्येक data-file ऑब्जेक्ट के लिए file-path प्रविष्टियों का मान पढ़ता है और फिर क्वेरी को निष्पादित करने के लिए डेटा फ़ाइलों को खोलता है।

विभाजन द्वारा व्यवस्थित data उपसर्ग की सामग्री नीचे दिखाई गई है।

विभाजन के अंदर, प्रत्येक तालिका पंक्ति में एक डेटा फ़ाइल होती है।

आइए एक उदाहरण क्वेरी चलाएँ:

 spark-sql> SELECT count(1) as count, data FROM my_catalog.my_table GROUP BY data; 1 a 1 b 1 c Time taken: 9.715 seconds, Fetched 3 row(s) spark-sql>

अब जब हम आइसबर्ग तालिका के विभिन्न घटकों को समझ गए हैं और क्वेरी इंजन उनके साथ कैसे काम करता है, तो आइए आइसबर्ग की सर्वोत्तम विशेषताओं के बारे में जानें और अपने डेटा लेक में उनका लाभ कैसे उठाएं।

टेबल इवोल्यूशन

ऐड, ड्रॉप, नाम बदलें और अपडेट जैसे स्कीमा विकास परिवर्तन मेटाडेटा परिवर्तन हैं, जिसका अर्थ है कि अपडेट करने के लिए किसी डेटा फ़ाइल को बदलने/फिर से लिखने की आवश्यकता नहीं है। आइसबर्ग यह भी गारंटी देता है कि ये स्कीमा विकास परिवर्तन स्वतंत्र और दुष्प्रभावों से मुक्त हैं। आइसबर्ग तालिका में प्रत्येक कॉलम को ट्रैक करने के लिए अद्वितीय आईडी का उपयोग करता है, यदि कोई नया कॉलम जोड़ा जाता है तो यह कभी भी गलती से मौजूदा आईडी का लाभ नहीं उठाएगा।

आइसबर्ग तालिका विभाजन को मौजूदा तालिका में अद्यतन किया जा सकता है क्योंकि क्वेरीज़ विभाजन मानों को सीधे संदर्भित नहीं करती हैं। जब नया डेटा लिखा जाता है तो यह एक नए लेआउट में एक नई विशिष्टता का उपयोग करता है, एक अलग विशिष्टता के साथ पहले लिखा गया डेटा अपरिवर्तित रहता है। जब आप नई क्वेरीज़ लिखते हैं तो यह विभाजित योजना का कारण बनता है। प्रदर्शन को बेहतर बनाने के लिए, आइसबर्ग छिपे हुए विभाजन का उपयोग करता है ताकि उपयोगकर्ताओं को तेज़ होने के लिए किसी विशिष्ट विभाजन लेआउट के लिए प्रश्न लिखने की आवश्यकता न हो। उपयोगकर्ता अपनी ज़रूरत के डेटा के लिए प्रश्न लिखने पर ध्यान केंद्रित करते हैं और आइसबर्ग को उन फ़ाइलों को छाँटने देते हैं जिनमें मेल खाने वाला डेटा नहीं होता है।

एक और विकास जो बहुत उपयोगी है वह यह है कि आइसबर्ग सॉर्ट ऑर्डर को विभाजन विनिर्देश की तरह मौजूदा तालिका में भी अपडेट किया जा सकता है। जब सॉर्टिंग अत्यधिक महंगी होती है, तो अलग-अलग इंजन अनसॉर्टेड ऑर्डर पर नवीनतम सॉर्ट ऑर्डर में डेटा लिखना चुन सकते हैं, पिछले सॉर्ट ऑर्डर के साथ लिखा गया पुराना डेटा अपरिवर्तित रहता है।

 spark-sql> ALTER TABLE my_catalog.my_table > RENAME my_catalog.my_table_2;

पहले कुछ बार जब आप ऐसा करेंगे तो आप यह देखकर दंग रह जाएंगे कि यह कितनी तेजी से होता है। ऐसा इसलिए है क्योंकि आप किसी तालिका को दोबारा नहीं लिख रहे हैं, आप बस मेटाडेटा पर काम कर रहे हैं। इस मामले में हमने केवल table_name बदला है और आइसबर्ग ने हमारे लिए यह काम लगभग एक सेकंड के दसवें हिस्से में किया है।

अन्य स्कीमा परिवर्तन समान रूप से दर्द रहित हैं:

 spark-sql> ALTER TABLE my_catalog.my_table RENAME COLUMN data TO quantity; spark-sql> ALTER TABLE my_catalog.my_table ADD COLUMN buyer string AFTER quantity; spark-sql> ALTER TABLE my_catalog.my_table ALTER COLUMN quantity AFTER buyer;

विभाजन

जैसा कि हमने पहले उल्लेख किया है, विभाजन अन्य हाइव प्रारूपों द्वारा समर्थित हैं, हालांकि आइसबर्ग छिपे हुए विभाजन का समर्थन करता है जो तालिका में पंक्तियों के लिए विभाजन मान उत्पन्न करने के कठिन और त्रुटि-प्रवण कार्यों को संभाल सकता है। उपयोगकर्ता प्रश्नों में फ़िल्टर जोड़ने पर ध्यान केंद्रित करते हैं जो व्यावसायिक समस्याओं को हल करते हैं और इस बात की चिंता नहीं करते कि तालिका को कैसे विभाजित किया गया है। आइसबर्ग अनावश्यक विभाजनों से स्वचालित रूप से पढ़ने से बचने का ख्याल रखता है।

आइसबर्ग आपके लिए विभाजन की जटिलताओं को संभालता है और तालिका की विभाजन योजना को बदलता है, जिससे अंतिम उपयोगकर्ताओं के लिए प्रक्रिया बहुत सरल हो जाती है। आप विभाजन को परिभाषित कर सकते हैं या आइसबर्ग को इसकी देखभाल करने दे सकते हैं। आइसबर्ग को टाइमस्टैम्प पर विभाजन करना पसंद है, जैसे कि घटना का समय। विभाजनों को मेनिफ़ेस्ट में स्नैपशॉट द्वारा ट्रैक किया जाता है। क्वेरीज़ अब तालिका के भौतिक लेआउट पर निर्भर नहीं करतीं। भौतिक और तार्किक तालिकाओं के बीच इस अलगाव के कारण, अधिक डेटा जोड़े जाने पर आइसबर्ग तालिकाएँ समय के साथ विभाजन विकसित कर सकती हैं। उदाहरण के लिए, हाइव तालिका को पुनः विभाजित करने के लिए एक नई तालिका बनाने और उसमें पुराना डेटा पढ़ने की आवश्यकता होगी। आपको पहले से लिखी गई प्रत्येक क्वेरी में PARTITION मान भी बदलना होगा - मज़ेदार नहीं।

 spark-sql> ALTER TABLE my_catalog.my_table ADD COLUMN month int AFTER category; ALTER TABLE my_catalog.my_table ADD PARTITION FIELD month;

अब हमारे पास एक ही तालिका के लिए दो विभाजन योजनाएँ हैं। हाइव में जो असंभव था वह आइसबर्ग में पारदर्शी तरीके से हो गया है। अब से, क्वेरी योजनाओं को विभाजित किया जाता है, पुराने डेटा को क्वेरी करने के लिए पुरानी विभाजन योजना का उपयोग किया जाता है, और नए डेटा को क्वेरी करने के लिए नई विभाजन योजना का उपयोग किया जाता है। आइसबर्ग आपके लिए इसका ख्याल रखता है - तालिका में पूछताछ करने वाले लोगों को यह जानने की आवश्यकता नहीं है कि डेटा दो विभाजन योजनाओं का उपयोग करके संग्रहीत किया जाता है। आइसबर्ग पर्दे के पीछे के दृश्यों के संयोजन के माध्यम से ऐसा करता है जहां क्लॉज और विभाजन फ़िल्टर होते हैं जो बिना मिलान के डेटा फ़ाइलों को छांटते हैं।

समय यात्रा और रोलबैक

आइसबर्ग टेबल पर प्रत्येक लेखन नए स्नैपशॉट बनाता है। स्नैपशॉट संस्करणों की तरह होते हैं और उनका उपयोग समय यात्रा और रोलबैक के लिए किया जा सकता है जैसे हम मिनिओ संस्करण क्षमताओं के साथ करते हैं। जिस तरह से स्नैपशॉट को प्रबंधित किया जाता है वह expireSnapshot सेट करके होता है ताकि सिस्टम अच्छी तरह से बनाए रखा जा सके। समय यात्रा पुनरुत्पादित क्वेरी को सक्षम करती है जो बिल्कुल उसी तालिका स्नैपशॉट का उपयोग करती है, या उपयोगकर्ताओं को आसानी से परिवर्तनों की जांच करने देती है। संस्करण रोलबैक उपयोगकर्ताओं को तालिकाओं को अच्छी स्थिति में रीसेट करके समस्याओं को तुरंत ठीक करने की अनुमति देता है।

जैसे ही तालिकाएँ बदली जाती हैं, आइसबर्ग प्रत्येक संस्करण को स्नैपशॉट के रूप में ट्रैक करता है और फिर तालिका को क्वेरी करते समय किसी भी स्नैपशॉट पर समय यात्रा करने की क्षमता प्रदान करता है। यह बहुत उपयोगी हो सकता है यदि आप ऐतिहासिक क्वेरी चलाना चाहते हैं या पिछली क्वेरी के परिणामों को पुन: प्रस्तुत करना चाहते हैं, शायद रिपोर्टिंग के लिए। नए कोड परिवर्तनों का परीक्षण करते समय समय यात्रा भी सहायक हो सकती है क्योंकि आप ज्ञात परिणामों की क्वेरी के साथ नए कोड का परीक्षण कर सकते हैं।

तालिका के लिए सहेजे गए स्नैपशॉट देखने के लिए:

 spark-sql> SELECT * FROM my_catalog.my_table.snapshots; 2022-07-25 17:26:47.53 527713811620162549 NULL append s3://iceberg/my_table/metadata/snap-527713811620162549-1-c16452b4-b384-42bc-af07-b2731299e2b8.avro {"added-data-files":"3","added-files-size":"2706","added-records":"3","changed-partition-count":"2","spark.app.id":"local-1658795082601","total-data-files":"3","total-delete-files":"0","total-equality-deletes":"0","total-files-size":"2706","total-position-deletes":"0","total-records":"3"} Time taken: 7.236 seconds, Fetched 1 row(s)

कुछ उदाहरण:

 -- time travel to October 26, 1986 at 01:21:00 spark-sql> SELECT * FROM my_catalog.my_table TIMESTAMP AS OF '1986-10-26 01:21:00'; -- time travel to snapshot with id 10963874102873 spark-sql> SELECT * FROM prod.db.table VERSION AS OF 10963874102873;

आप स्नैपशॉट का उपयोग करके वृद्धिशील रीडिंग कर सकते हैं, लेकिन आपको स्पार्क का उपयोग करना होगा, स्पार्क-एसक्यूएल का नहीं। उदाहरण के लिए:

 scala> spark.read() .format(“iceberg”) .option(“start-snapshot-id”, “10963874102873”) .option(“end-snapshot-id”, “10963874102994”) .load(“s3://iceberg/my_table”)

आप तालिका को किसी समय बिंदु या किसी विशिष्ट स्नैपशॉट पर वापस भी ला सकते हैं, जैसा कि इन दो उदाहरणों में है:

 spark-sql> CALL my_catalog.system.rollback_to_timestamp('my_table', TIMESTAMP '2022-07-25 12:15:00.000'); spark-sql> CALL my_catalog.system.rollback_to_snapshot('my_table', 527713811620162549);

अभिव्यंजक एसक्यूएल

आइसबर्ग पंक्ति स्तर डिलीट, मर्ज और अपडेट जैसे सभी अभिव्यंजक एसक्यूएल कमांड का समर्थन करता है, और हाइलाइट करने वाली सबसे बड़ी बात यह है कि आइसबर्ग ईगर और आलसी दोनों रणनीतियों का समर्थन करता है। हम उन सभी चीजों को एनकोड कर सकते हैं जिन्हें हमें हटाना है (उदाहरण के लिए, जीडीपीआर या सीसीपीए), लेकिन उन सभी डेटा फ़ाइलों को तुरंत दोबारा नहीं लिखना है, हम आवश्यकतानुसार कचरा इकट्ठा कर सकते हैं और यह वास्तव में आइसबर्ग द्वारा समर्थित विशाल तालिकाओं पर दक्षता में मदद करता है।

उदाहरण के लिए, आप किसी तालिका में किसी विशिष्ट विधेय से मेल खाने वाले सभी रिकॉर्ड हटा सकते हैं। निम्नलिखित वीडियो श्रेणी से सभी पंक्तियाँ हटा देगा:

 spark-sql> DELETE FROM my_catalog.my_table WHERE category = 'video';

वैकल्पिक रूप से, आप इसे पूरा करने के लिए CREATE TABLE AS SELECT या REPLACE TABLE AS SELECT का उपयोग कर सकते हैं:

 spark-sql> CREATE TABLE my_catalog.my_table_music AS SELECT * FROM my_catalog.my_table WHERE category = 'music';

आप दो तालिकाओं को बहुत आसानी से मर्ज कर सकते हैं:

 spark-sql> MERGE INTO my_catalog.my_data pt USING (SELECT * FROM my_catalog.my_data_new) st ON pt.id = st.id WHEN NOT MATCHED THEN INSERT *;

डेटा इंजीनियरिंग

आइसबर्ग ओपन एनालिटिक टेबल मानक की नींव है और अन्य हाइव टेबल प्रारूपों के विपरीत एसक्यूएल व्यवहार और वास्तविक टेबल एब्स्ट्रैक्शन का उपयोग करता है और समस्याओं को जानने से पहले उन्हें ठीक करने के लिए डेटा वेयरहाउस बुनियादी सिद्धांतों को लागू करता है। घोषणात्मक डेटा इंजीनियरिंग के साथ हम तालिकाओं को कॉन्फ़िगर कर सकते हैं और डेटा की जरूरतों को पूरा करने के लिए प्रत्येक इंजन को बदलने की चिंता नहीं कर सकते हैं। यह स्वचालित अनुकूलन और अनुशंसाओं को अनलॉक करता है। सुरक्षित प्रतिबद्धताओं के साथ, डेटा सेवाएँ संभव हैं जो मनुष्यों को बेबीसिटिंग डेटा कार्यभार से बचने में मदद करती हैं।

किसी तालिका के इतिहास, स्नैपशॉट और अन्य मेटाडेटा का निरीक्षण करने के लिए, आइसबर्ग मेटाडेटा को क्वेरी करने का समर्थन करता है। आपकी क्वेरी में मूल तालिका नाम के बाद मेटाडेटा तालिका नाम (उदाहरण के लिए, इतिहास) जोड़कर मेटाडेटा तालिकाओं की पहचान की जाती है।

किसी तालिका की डेटा फ़ाइलें प्रदर्शित करने के लिए:

 spark-sql> SELECT * FROM my_catalog.my_table.files;

मैनिफ़ेस्ट प्रदर्शित करने के लिए:

 spark-sql> SELECT * FROM my_catalog.my_table.manifests;

तालिका इतिहास प्रदर्शित करने के लिए:

 spark-sql> SELECT * FROM my_catalog.my_table.history;

स्नैपशॉट प्रदर्शित करने के लिए:

 spark-sql> SELECT * FROM my_catalog.my_table.snapshots;

आप प्रत्येक स्नैपशॉट को लिखने वाले एप्लिकेशन को देखने के लिए स्नैपशॉट और तालिका इतिहास से भी जुड़ सकते हैं:

 spark-sql> select h.made_current_at, s.operation, h.snapshot_id, h.is_current_ancestor, s.summary['spark.app.id'] from my_catalog.my_table.history h join my_catalog.my_table.snapshots s on h.snapshot_id = s.snapshot_id order by made_current_at;

अब जब आपने मूल बातें सीख ली हैं, तो अपना कुछ डेटा आइसबर्ग में लोड करें, फिर स्पार्क और आइसबर्ग क्विकस्टार्ट और आइसबर्ग डॉक्यूमेंटेशन से और जानें।

एकीकरण

अपाचे आइसबर्ग में विभिन्न क्वेरी और निष्पादन इंजनों के साथ एकीकरण है, जहां इन कनेक्टर्स द्वारा अपाचे आइसबर्ग टेबल बनाए और प्रबंधित किए जा सकते हैं। आइसबर्ग को सपोर्ट करने वाले इंजन हैं स्पार्क , फ्लिंक , हाइव , प्रेस्टो , ट्रिनो , ड्रेमियो , स्नोफ्लेक ।

आइसबर्ग और मिनिओ के साथ डेटा झील बनाना अच्छा है

अपाचे आइसबर्ग को डेटा लेक के लिए तालिका प्रारूप के रूप में बहुत अधिक ध्यान दिया जाता है। बढ़ते ओपन सोर्स समुदाय और कई क्लाउड प्रदाताओं और एप्लिकेशन फ्रेमवर्क से एकीकरण की बढ़ती संख्या का मतलब है कि अब आइसबर्ग को गंभीरता से लेने, प्रयोग शुरू करने, सीखने और मौजूदा डेटा लेक आर्किटेक्चर में इसे एकीकृत करने की योजना बनाने का समय है। मल्टी-क्लाउड डेटा लेक और एनालिटिक्स के लिए आइसबर्ग को मिनिओ के साथ जोड़ें।

जैसे ही आप आइसबर्ग और मिनिओ के साथ शुरुआत करते हैं, कृपया हमारे स्लैक चैनल के माध्यम से संपर्क करें और अपने अनुभव साझा करें या प्रश्न पूछें।