अपाचे HBase लिखें पथ

अपाचे HBase Hadoop डेटाबेस है, और Hadoop डिस्ट्रिब्यूटेड फाइल सिस्टम (HDFS) पर आधारित है ) HBase HDFS में संग्रहीत डेटा को बेतरतीब ढंग से एक्सेस और अपडेट करना संभव बनाता है, लेकिन HDFS में फ़ाइलें केवल बनाई जा सकती हैं और बनाए जाने के बाद अपरिवर्तनीय हैं। तो आप पूछ सकते हैं, HBase कम-विलंबता पढ़ने और लिखने की सुविधा कैसे प्रदान करता है? इस ब्लॉग पोस्ट में, हम HBase के लेखन पथ का वर्णन करते हुए इसकी व्याख्या करते हैं - HBase में डेटा कैसे अपडेट किया जाता है।

लेखन पथ एक HBase पुट या डिलीट ऑपरेशंस को कैसे पूरा करता है। यह पथ एक क्लाइंट से शुरू होता है, एक क्षेत्र सर्वर पर जाता है, और तब समाप्त होता है जब डेटा अंततः एक HBase डेटा फ़ाइल को लिखा जाता है जिसे HFile कहा जाता है . राइट पाथ के डिज़ाइन में ऐसी सुविधाएँ शामिल हैं जिनका उपयोग HBase क्षेत्र सर्वर विफलता की स्थिति में डेटा हानि को रोकने के लिए करता है। इसलिए लेखन पथ को समझना HBase के मूल डेटा हानि निवारण तंत्र में अंतर्दृष्टि प्रदान कर सकता है।

प्रत्येक HBase तालिका को सर्वरों के सेट द्वारा होस्ट और प्रबंधित किया जाता है जो तीन श्रेणियों में आते हैं:

1. एक सक्रिय मास्टर सर्वर
2. एक या अधिक बैकअप मास्टर सर्वर
3. कई क्षेत्र सर्वर

क्षेत्र सर्वर HBase तालिकाओं को संभालने में योगदान करते हैं। क्योंकि HBase तालिकाएँ बड़ी हो सकती हैं, उन्हें क्षेत्रों में विभाजित किया जाता है जिन्हें क्षेत्र कहा जाता है। प्रत्येक क्षेत्र सर्वर इनमें से एक या अधिक क्षेत्रों को संभालता है। ध्यान दें कि क्योंकि क्षेत्र सर्वर ही एकमात्र सर्वर हैं जो HBase तालिका डेटा की सेवा करते हैं, एक मास्टर सर्वर क्रैश डेटा हानि का कारण नहीं बन सकता है।

HBase डेटा को सॉर्ट किए गए मैप के समान व्यवस्थित किया जाता है, सॉर्ट किए गए कुंजी स्थान को अलग-अलग शार्प या क्षेत्रों में विभाजित किया जाता है। एक HBase क्लाइंट पुट या डिलीट कमांड को लागू करके एक टेबल को अपडेट करता है। जब कोई क्लाइंट किसी बदलाव का अनुरोध करता है, तो वह अनुरोध डिफ़ॉल्ट रूप से तुरंत एक क्षेत्र सर्वर पर भेज दिया जाता है। हालाँकि, प्रोग्रामेटिक रूप से, क्लाइंट क्लाइंट साइड में परिवर्तनों को कैश कर सकता है, और ऑटोफ्लश को बंद करके, इन परिवर्तनों को एक बैच में क्षेत्र सर्वर पर फ़्लश कर सकता है। यदि ऑटोफ्लश को बंद कर दिया जाता है, तो परिवर्तन तब तक कैश किए जाते हैं जब तक कि फ्लश-प्रतिबद्धता लागू नहीं हो जाती है, या बफ़र प्रोग्रामेटिक रूप से सेट किए गए बफर आकार के आधार पर या "hbase.client.write.buffer" पैरामीटर के साथ कॉन्फ़िगर किया गया है।

चूंकि पंक्ति कुंजी को सॉर्ट किया गया है, इसलिए यह निर्धारित करना आसान है कि कौन सा क्षेत्र सर्वर किस कुंजी का प्रबंधन करता है। एक विशिष्ट पंक्ति के लिए एक परिवर्तन अनुरोध है। प्रत्येक पंक्ति कुंजी एक विशिष्ट क्षेत्र से संबंधित होती है जिसे एक क्षेत्र सर्वर द्वारा परोसा जाता है। इसलिए पुट या डिलीट की के आधार पर, एक HBase क्लाइंट एक उचित क्षेत्र सर्वर का पता लगा सकता है। सबसे पहले, यह ZooKeeper कोरम से -ROOT- क्षेत्र को होस्ट करने वाले क्षेत्र सर्वर के पते का पता लगाता है। रूट क्षेत्र सर्वर से, क्लाइंट -मेटा-क्षेत्र को होस्ट करने वाले क्षेत्र सर्वर के स्थान का पता लगाता है। मेटा क्षेत्र सर्वर से, फिर हम अंत में वास्तविक क्षेत्र सर्वर का पता लगाते हैं जो अनुरोधित क्षेत्र में कार्य करता है। यह एक तीन-चरणीय प्रक्रिया है, इसलिए इस महंगी श्रृंखला के संचालन से बचने के लिए क्षेत्र के स्थान को कैश किया जाता है। यदि कैश्ड स्थान अमान्य है (उदाहरण के लिए, हमें कुछ अज्ञात क्षेत्र अपवाद मिलते हैं), तो यह समय क्षेत्र को फिर से खोजने और कैशे को अपडेट करने का है।

सही क्षेत्र सर्वर द्वारा अनुरोध प्राप्त होने के बाद, परिवर्तन को तुरंत HFile में नहीं लिखा जा सकता है क्योंकि HFile में डेटा को पंक्ति कुंजी द्वारा क्रमबद्ध किया जाना चाहिए। यह डेटा को पढ़ते समय कुशलता से यादृच्छिक पंक्तियों की खोज करने की अनुमति देता है। डेटा को बेतरतीब ढंग से HFile में सम्मिलित नहीं किया जा सकता है। इसके बजाय, परिवर्तन को एक नई फ़ाइल में लिखा जाना चाहिए। यदि प्रत्येक अद्यतन को किसी फ़ाइल में लिखा जाता है, तो कई छोटी फ़ाइलें बनाई जाएंगी। ऐसा समाधान बाद में विलय या पढ़ने के लिए स्केलेबल या कुशल नहीं होगा। इसलिए, परिवर्तन तुरंत एक नए HFile में नहीं लिखे जाते हैं।

इसके बजाय, प्रत्येक परिवर्तन memstore . नामक स्मृति में एक स्थान पर संग्रहीत किया जाता है , जो सस्ते और कुशलता से यादृच्छिक लेखन का समर्थन करता है। मेमस्टोर में डेटा उसी तरह से सॉर्ट किया जाता है जैसे एचएफआईएल में डेटा। जब मेमस्टोर पर्याप्त डेटा जमा करता है, तो संपूर्ण सॉर्ट किया गया सेट HDFS में एक नए HFile को लिखा जाता है। एक बड़े लेखन कार्य को पूरा करना कुशल है और एचडीएफएस की ताकत का लाभ उठाता है।

हालांकि मेमस्टोर में डेटा लिखना कुशल है, यह जोखिम का एक तत्व भी पेश करता है:मेमस्टोर में संग्रहीत जानकारी अस्थिर मेमोरी में संग्रहीत होती है, इसलिए यदि सिस्टम विफल हो जाता है, तो सभी मेमस्टोर जानकारी खो जाती है। इस जोखिम को कम करने में मदद करने के लिए, HBase एक राइट-फ़ॉरवर्ड-लॉग (WAL) में अपडेट सहेजता है ) memstore को जानकारी लिखने से पहले। इस तरह, यदि कोई क्षेत्र सर्वर विफल हो जाता है, तो उस सर्वर के मेमस्टोर में संग्रहीत जानकारी को उसके WAL से पुनर्प्राप्त किया जा सकता है।

नोट:डिफ़ॉल्ट रूप से, WAL सक्षम है, लेकिन डिस्क पर WAL फ़ाइल लिखने की प्रक्रिया में कुछ संसाधनों की खपत होती है। WAL को अक्षम किया जा सकता है, लेकिन यह केवल तभी किया जाना चाहिए जब डेटा हानि का जोखिम चिंता का विषय न हो। यदि आप WAL को अक्षम करना चुनते हैं, तो अपने स्वयं के आपदा पुनर्प्राप्ति समाधान को लागू करने पर विचार करें या डेटा हानि की संभावना के लिए तैयार रहें।

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

जैसे-जैसे WAL बढ़ते हैं, वे अंततः बंद हो जाते हैं और अतिरिक्त संपादन स्वीकार करने के लिए एक नई, सक्रिय WAL फ़ाइल बनाई जाती है। इसे WAL फ़ाइल "रोलिंग" कहा जाता है। एक बार WAL फ़ाइल को रोल करने के बाद, पुरानी फ़ाइल में कोई अतिरिक्त परिवर्तन नहीं किया जाता है।

डिफ़ॉल्ट रूप से, WAL फ़ाइल तब रोल की जाती है जब उसका आकार HDFS ब्लॉक आकार का लगभग 95% होता है। आप पैरामीटर का उपयोग करके गुणक को कॉन्फ़िगर कर सकते हैं:"hbase.regionserver.logroll.multiplier", और पैरामीटर का उपयोग करके ब्लॉक आकार:"hbase.regionserver.hlog.blocksize"। WAL फ़ाइल भी समय-समय पर कॉन्फ़िगर किए गए अंतराल "hbase.regionserver.logroll.period" के आधार पर रोल की जाती है, डिफ़ॉल्ट रूप से एक घंटा, यहां तक ​​कि WAL फ़ाइल का आकार भी कॉन्फ़िगर की गई सीमा से छोटा होता है।

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

एक क्षेत्र सर्वर कई क्षेत्रों में कार्य करता है, लेकिन प्रत्येक क्षेत्र के लिए एक WAL फ़ाइल नहीं होती है। इसके बजाय, एक सक्रिय WAL फ़ाइल क्षेत्र सर्वर द्वारा प्रस्तुत सभी क्षेत्रों के बीच साझा की जाती है। क्योंकि WAL फ़ाइलें समय-समय पर रोल की जाती हैं, एक क्षेत्र सर्वर में कई WAL फ़ाइलें हो सकती हैं। ध्यान दें कि एक निश्चित समय में प्रति क्षेत्र सर्वर में केवल एक सक्रिय WAL होता है।

"/hbase" के डिफ़ॉल्ट HBase रूट को मानते हुए, एक क्षेत्र सर्वर इंस्टेंस के लिए सभी WAL फ़ाइलें एक ही रूट फ़ोल्डर के अंतर्गत संग्रहीत की जाती हैं, जो इस प्रकार है:

/hbase/.logs/<host>,
<port>,<startcode>

उदाहरण के लिए:

/hbase/.logs/srv.example.com,60020,1254173957298

WAL लॉग फाइलों के नाम इस प्रकार हैं:

/hbase/.logs/<host>,
<port>,<startcode>/<host>%2C
<port>%2C<startcode>.<timestamp>

उदाहरण के लिए:

/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495

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

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

वाल फाइल रोलिंग और मेमस्टोर फ्लश दो अलग-अलग क्रियाएं हैं, और एक साथ नहीं होना चाहिए। हालाँकि, हम प्रति क्षेत्र सर्वर में बहुत अधिक WAL फ़ाइलें नहीं रखना चाहते हैं ताकि क्षेत्र सर्वर के विफल होने की स्थिति में समय लेने वाली पुनर्प्राप्ति से बचा जा सके। इसलिए, जब एक WAL फ़ाइल को रोल किया जाता है, तो HBase जाँचता है कि क्या बहुत अधिक WAL फ़ाइलें हैं, और तय करें कि किन क्षेत्रों को फ़्लश किया जाना चाहिए ताकि कुछ WAL फ़ाइलों को संग्रहीत किया जा सके।

इस पोस्ट में, हम HBase लिखने के पथ की व्याख्या करते हैं, जो कि HBase में डेटा कैसे बनाया और/या अपडेट किया जाता है। इसके कुछ महत्वपूर्ण भाग हैं:

1. क्लाइंट किसी क्षेत्र सर्वर का पता कैसे लगाता है,
2. मेमस्टोर जो तेजी से यादृच्छिक लेखन का समर्थन करता है,
3. क्षेत्र सर्वर के विफल होने की स्थिति में डेटा हानि से बचने के तरीके के रूप में WAL फ़ाइलें।

हम बाद के पोस्ट में HFile फॉर्मेट, WAL फाइल स्प्लिटिंग आदि के बारे में बात करेंगे।