अपाचे ज़ूकीपर वितरित समन्वय के लिए एक क्लाइंट/सर्वर सिस्टम है जो एक फाइल सिस्टम के समान इंटरफेस को उजागर करता है, जहां प्रत्येक नोड (जिसे znode कहा जाता है) ) में डेटा और बच्चों का एक समूह हो सकता है। प्रत्येक ज़नोड का एक नाम होता है और फ़ाइल सिस्टम जैसे पथ का उपयोग करके पहचाना जा सकता है (उदाहरण के लिए, /root-znode/sub-znode/my-znode)।
Apache HBase में, ZooKeeper मास्टर्स और रीजनसर्वर के बीच राज्य का समन्वय, संचार और साझा करता है। HBase की केवल क्षणिक डेटा (अर्थात समन्वय और राज्य संचार के लिए) के लिए ZooKeeper का उपयोग करने की एक डिज़ाइन नीति है। इस प्रकार यदि HBase के ज़ूकीपर डेटा को हटा दिया जाता है, तो केवल क्षणिक संचालन प्रभावित होते हैं - डेटा को HBase से/में लिखा और पढ़ा जा सकता है।
इस ब्लॉग पोस्ट में, आपको HBase znodes उपयोग का एक संक्षिप्त दौरा मिलेगा। यहां संदर्भ के लिए उपयोग किए गए HBase का संस्करण 0.94 है (CDH 4.2 और CDH 4.3 के अंदर भेजा गया), लेकिन अधिकांश ज़नोड पिछले संस्करणों में मौजूद हैं और भविष्य के संस्करणों में भी ऐसा होने की संभावना है।
HBase रूट znode पथ hbase-site.xml का उपयोग करके कॉन्फ़िगर करने योग्य है, और डिफ़ॉल्ट रूप से स्थान "/hbase" है। नीचे संदर्भित सभी znodes को डिफ़ॉल्ट /hbase स्थान का उपयोग करके उपसर्ग किया जाएगा, और कॉन्फ़िगरेशन गुण जो आपको विशेष znode का नाम बदलने देता है, डिफ़ॉल्ट znode नाम के आगे सूचीबद्ध किया जाएगा और बोल्ड प्रकार के साथ हाइलाइट किया जाएगा।
ZooKeeper एक इंटरैक्टिव शेल प्रदान करता है जो आपको ZooKeeper स्थिति का पता लगाने की अनुमति देता है — इसे hbase zkcli का उपयोग करके चलाएं। और znode के माध्यम से ls . के माध्यम से चलें , जैसा कि एक विशिष्ट फाइल सिस्टम में होता है। आप get . का उपयोग करके znode सामग्री के बारे में कुछ जानकारी भी प्राप्त कर सकते हैं आदेश।
$ hbase zkcli [zk: localhost:2181(CONNECTED) 0] ls / [hbase, zookeeper] [zk: localhost:2181(CONNECTED) 1] ls /hbase [splitlog, online-snapshot, unassigned, root-region-server, rs, backup-masters, draining, table, master, shutdown, hbaseid] [zk: localhost:2181(CONNECTED) 2] get /hbase/root-region-server 3008@u1310localhost,60020,1382107614265 dataLength = 44 numChildren = 0 ...
ऑपरेशन
जो ज़्नोड्स आप सबसे अधिक बार देखेंगे, वे हैं जो रीजन असाइनमेंट, लॉग स्प्लिटिंग, और मास्टर फ़ेलओवर जैसे संचालन का समन्वय करते हैं, या क्लस्टर स्थिति का ट्रैक रखते हैं जैसे कि रूट टेबल लोकेशन, ऑनलाइन रीजनसर्वर की सूची, और असाइन नहीं किए गए क्षेत्रों की सूची ।
| /hbase (zookeeper.znode.parent) | रूट znode जिसमें HBase द्वारा बनाए/उपयोग किए गए सभी znode शामिल होंगे |
| /hbase/hbaseid (zookeeper.znode.clusterId) | मास्टर द्वारा यूयूआईडी के साथ आरंभ किया गया जो क्लस्टर की पहचान करता है। आईडी को एचडीएफएस पर एचडीएफएस में भी स्टोर किया जाता है:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | ROOT क्षेत्र को होस्ट करने वाले सर्वर का स्थान समाहित करता है। क्लाइंट द्वारा रूट के लिए जिम्मेदार क्षेत्र सर्वर की पहचान करने और मेटा स्थानों के लिए पूछने के लिए पूछताछ की जाती है। (0.96 में, HBASE-3171 के भाग के रूप में ROOT तालिका को हटा दिया गया था, और इस znode को /hbase/meta-region-server [zookeeper.znode.metaserver] से बदल दिया गया है, जिसमें META होस्ट करने वाले सर्वर का स्थान है।) |
| /hbase/rs (zookeeper.znode.rs) | स्टार्टअप पर प्रत्येक RegionServer एक सब-ज़्नोड (जैसे /hbase/rs/m1.host) बनाएगा जो कि RegionServer की "ऑनलाइन" स्थिति का वर्णन करने वाला है। मास्टर "ऑनलाइन" रीजनसर्वर सूची प्राप्त करने के लिए इस ज़नोड की निगरानी करता है और असाइनमेंट/बैलेंसिंग के दौरान इसका उपयोग करता है। |
| /hbase/असाइन किया गया (zookeeper.znode.unassigned) | प्रत्येक अनिर्दिष्ट क्षेत्र के लिए एक उप-ज़्नोड होता है (उदा. /hbase/unassigned/<क्षेत्र का नाम>)। इस ज़नोड का उपयोग असाइनमेंट मैनेजर द्वारा असाइन किए जाने वाले क्षेत्रों को खोजने के लिए किया जाता है। (असाइनमेंट मैनेजर के बारे में अधिक जानने के लिए इसे पढ़ें।) |
| /hbase/मास्टर (ज़ूकीपर.ज़्नोड.मास्टर) | स्टार्टअप पर "सक्रिय" मास्टर इस ज़नोड में अपना खुद का पता दर्ज करेगा, जिससे यह पता चलेगा कि कौन सा सर्वर मास्टर है। |
| /hbase/बैकअप-मास्टर्स (zookeeper.znode.backup.masters) | प्रत्येक निष्क्रिय मास्टर एक सब-ज़्नोड (hbase/backup-master/m1.host) बनाकर स्वयं को बैकअप मास्टर के रूप में पंजीकृत करेगा। इस ज़नोड का उपयोग मुख्य रूप से यह ट्रैक करने के लिए किया जाता है कि विफलता के मामले में मास्टर को बदलने के लिए कौन सी मशीनें उपलब्ध हैं। |
| /hbase/शटडाउन (zookeeper.znode.state) | क्लस्टर स्थिति का वर्णन करता है, "क्या क्लस्टर ऊपर है?" यह स्टार्टअप पर मास्टर द्वारा बनाया जाता है और बंद होने पर मास्टर द्वारा हटा दिया जाता है। इसे RegionServers द्वारा देखा जाता है। |
| /hbase/ड्रेनिंग (zookeeper.znode.draining.rs) | serverName,port,startCode फॉर्म के साथ सब-ज़्नोड्स बनाकर एक समय में एक से अधिक रीजनसर्वर को डीकमिशन करने के लिए उपयोग किया जाता है (उदाहरण के लिए, /hbase/draining/m1.host,60020,1338936306752)। यह आपको क्षेत्रों के जोखिम के बिना एक से अधिक क्षेत्र सर्वर को अस्थायी रूप से एक ऐसे क्षेत्र सर्वर में स्थानांतरित करने देता है जिसे बाद में निष्क्रिय कर दिया जाएगा। /hbase/ड्रेनिंग के बारे में अधिक जानने के लिए इसे पढ़ें। |
| /hbase/टेबल (zookeeper.znode.masterTableEnableDisable) | असाइनमेंट के दौरान तालिका स्थिति को ट्रैक करने के लिए मास्टर द्वारा उपयोग किया जाता है (उदाहरण के लिए राज्यों को अक्षम/सक्षम करना)। |
| /hbase/स्प्लिटलॉग (zookeeper.znode.splitlog) | लॉग स्प्लिटर द्वारा उपयोग किया जाता है ताकि लंबित लॉग को फिर से चलाने और उसके असाइनमेंट को ट्रैक किया जा सके। (लॉग विभाजन के बारे में अधिक जानने के लिए इसे पढ़ें)। |
सुरक्षा
एक्सेस कंट्रोल लिस्ट (ACL) और टोकन प्रोवाइडर कोप्रोसेसर दो और znodes जोड़ते हैं:एक टेबल ACL तक एक्सेस को सिंक्रोनाइज़ करने के लिए और दूसरा क्लस्टर नोड्स में टोकन एन्क्रिप्शन कीज़ को सिंक्रोनाइज़ करने के लिए।
| /hbase/acl (zookeeper.znode.acl.parent) | acl znode का उपयोग अनुदान/निरस्त आदेश द्वारा _acl_ तालिका में किए गए परिवर्तनों को सिंक्रनाइज़ करने के लिए किया जाता है। प्रत्येक तालिका में एक उप-ज़्नोड (/hbase/acl/tableName) होगा जिसमें तालिका के ACL होंगे। (एक्सेस कंट्रोलर और ज़ूकीपर इंटरैक्शन के बारे में अधिक जानकारी के लिए इसे पढ़ें।) |
| /hbase/टोकनौथ (zookeeper.znode.tokenauth.parent) | टोकन प्रदाता का उपयोग आमतौर पर MapReduce जॉब को HBase क्लस्टर तक पहुंचने की अनुमति देने के लिए किया जाता है। जब कोई उपयोगकर्ता एक नया टोकन मांगता है तो जानकारी कुंजी (/hbase/tokenauth/keys/key-id) के लिए बनाए गए उप-ज़्नोड में संग्रहीत की जाएगी। |
प्रतिकृति
सामान्य नियम के रूप में, सभी znodes अल्पकालिक हैं, जिसका अर्थ है कि वे एक "अस्थायी" स्थिति का वर्णन कर रहे हैं - इसलिए, भले ही आप ZooKeeper से सब कुछ हटा दें, HBase उन्हें फिर से बनाने में सक्षम होना चाहिए। हालांकि प्रतिकृति znodes एक अस्थायी स्थिति का वर्णन नहीं करते हैं, वे प्रत्येक मशीन की प्रतिकृति स्थिति का वर्णन करते हुए, प्रतिकृति राज्य के लिए सत्य का स्रोत होने के लिए हैं। (प्रतिकृति के बारे में अधिक जानने के लिए इसे पढ़ें)।
| /hbase/प्रतिकृति (zookeeper.znode.replication) | रूट znode जिसमें सभी HBase प्रतिकृति स्थिति की जानकारी होती है |
| /hbase/प्रतिकृति/साथियों (zookeeper.znode.replication.peers) | प्रत्येक सहकर्मी के पास एक उप-ज़्नोड होगा (उदा. /hbase/replication/peers/ |
| /hbase/प्रतिकृति/पीयर्स/ | /hbase/replication/peers znode का मिरर, लेकिन यहां प्रत्येक सब-ज़्नोड (/hbase/replication/peer-state/ |
| /hbase/प्रतिकृति/स्थिति (zookeeper.znode.replication.state) | यह दर्शाता है कि प्रतिकृति सक्षम है या नहीं। प्रतिकृति को hbase.replication कॉन्फ़िगरेशन को सही पर सेट करके सक्षम किया जा सकता है, या HBase शेल में स्टार्ट/स्टॉप कमांड का उपयोग करके सक्षम/अक्षम किया जा सकता है। (0.96 में, इस ज़नोड को हटा दिया गया था और उपरोक्त पीयर-स्टेट ज़नोड को संदर्भ के रूप में उपयोग किया जाता है।) |
| /hbase/प्रतिकृति/आरएस (zookeeper.znode.replication.rs) | मुख्य क्लस्टर (/hbase/replication/rs/<क्षेत्र सर्वर>) में RegionServers की सूची शामिल है। और प्रत्येक रीजनसर्वर ज़नोड के लिए प्रति पीयर एक सब-ज़्नोड है जिसकी वह प्रतिकृति बना रहा है। पीयर सब-ज़्नोड के अंदर hlogs दोहराने की प्रतीक्षा कर रहे हैं (/hbase/replication/rs/ |
ऑनलाइन स्नैपशॉट प्रक्रिया
ऑनलाइन स्नैपशॉट को मास्टर द्वारा दो-चरण-प्रतिबद्ध-जैसे लेनदेन का उपयोग करके क्षेत्र सर्वर के साथ संवाद करने के लिए चिड़ियाघरकीपर का उपयोग करके समन्वयित किया जाता है। (स्नैपशॉट के बारे में अधिक जानकारी के लिए इसे पढ़ें।)
| /hbase/ऑनलाइन-स्नैपशॉट/अधिग्रहीत | अधिग्रहीत znode स्नैपशॉट लेनदेन के पहले चरण का वर्णन करता है। मास्टर स्नैपशॉट (/hbase/online-snapshot/acquired/ |
| /hbase/ऑनलाइन-स्नैपशॉट/पहुंच गया | एक बार जब प्रत्येक क्षेत्र सर्वर अधिग्रहीत ज़नोड में शामिल हो जाता है, तो मास्टर स्नैपशॉट (/hbase/ऑनलाइन-स्नैपशॉट/पहुंच/<स्नैपशॉट नाम>) के लिए पहुंच गया ज़नोड बनाएगा और प्रत्येक रीजनसर्वर को बताएगा कि यह अंतिम रूप देने का समय है/ स्नैपशॉट प्रतिबद्ध करें। फिर से, प्रत्येक रीजनसर्वर मास्टर को सूचित करने के लिए एक सब-ज़्नोड बनाएगा कि काम पूरा हो गया है। |
| /hbase/ऑनलाइन-स्नैपशॉट/निरस्त | यदि मास्टर साइड या रीजनसर्वर की ओर से कुछ विफल हो जाता है, तो स्नैपशॉट के लिए निरस्त ज़नोड बनाया जाएगा जो सभी को बताएगा कि स्नैपशॉट के साथ कुछ गलत हुआ है और नौकरी को निरस्त करने के लिए। |
निष्कर्ष
जैसा कि आप देख सकते हैं, ज़ूकीपर HBase का एक मूलभूत हिस्सा है। सभी संचालन जिनमें समन्वय की आवश्यकता होती है, जैसे कि क्षेत्र असाइनमेंट, मास्टर-फेलओवर, प्रतिकृति और स्नैपशॉट, चिड़ियाघरकीपर पर बनाए जाते हैं। (आप अपने अनुप्रयोगों में ज़ूकीपर का उपयोग क्यों/कैसे करेंगे, इसके बारे में अधिक जान सकते हैं।)
हालाँकि अधिकांश znodes केवल HBase के लिए उपयोगी होते हैं, कुछ - जैसे कि RegionServers (/hbase/rs) की सूची या अनिर्दिष्ट क्षेत्रों की सूची (/hbase/unassigned) - का उपयोग डिबगिंग या निगरानी उद्देश्यों के लिए किया जा सकता है। या, जैसा कि /hbase/draining के मामले में होता है, आप HBase को यह बताने के लिए उनके साथ बातचीत कर सकते हैं कि आप क्लस्टर के साथ क्या कर रहे हैं।
Matteo Bertozzi, Cloudera में एक सॉफ्टवेयर इंजीनियर और HBase प्रोजेक्ट पर एक कमिटर हैं।
