प्रतिकृति (इस पिछले ब्लॉग आलेख में शामिल) कुछ समय के लिए जारी किया गया है और अपाचे एचबेस की सबसे अधिक उपयोग की जाने वाली सुविधाओं में से एक है। विभिन्न साथियों के साथ डेटा की नकल करने वाले क्लस्टर का होना एक बहुत ही सामान्य परिनियोजन है, चाहे वह DR रणनीति के रूप में हो या उत्पादन/स्टेजिंग/विकास वातावरण के बीच डेटा की प्रतिकृति के एक सहज तरीके के रूप में। यद्यपि यह सब-सेकंड लेटेंसी के भीतर विभिन्न HBase डेटाबेस को सिंक में रखने का एक कुशल तरीका है, प्रतिकृति केवल सुविधा के सक्षम होने के बाद अंतर्ग्रहीत डेटा पर संचालित होती है। इसका मतलब है कि प्रतिकृति परिनियोजन में शामिल सभी समूहों पर पहले से मौजूद किसी भी डेटा को अभी भी किसी अन्य तरीके से साथियों के बीच कॉपी करने की आवश्यकता होगी। ऐसे कुछ उपकरण हैं जिनका उपयोग विभिन्न सहकर्मी समूहों पर पहले से मौजूद डेटा को सिंक्रनाइज़ करने के लिए किया जा सकता है। स्नैपशॉट, बल्कलोड, कॉपीटेबल ऐसे टूल के जाने-माने उदाहरण हैं जिन्हें पिछले क्लौडेरा ब्लॉग पोस्ट में शामिल किया गया है। इस लेख में हम HashTable/SyncTable, . को कवर करने जा रहे हैं इसके कुछ आंतरिक कार्यान्वयन तर्क, इसका उपयोग करने के पेशेवरों और विपक्षों का विवरण, और यह ऊपर वर्णित कुछ अन्य डेटा कॉपी तकनीकों की तुलना कैसे करता है।
संक्षेप में हैशटेबल/सिंकटेबल
हैशटेबल/सिंकटेबल एक उपकरण है जिसे दो मानचित्र-कम करने वाली नौकरियों के रूप में कार्यान्वित किया जाता है जिन्हें अलग-अलग चरणों के रूप में निष्पादित किया जाता है। यह कॉपीटेबल . जैसा दिखता है टूल, जो आंशिक या संपूर्ण तालिका डेटा कॉपी दोनों को निष्पादित कर सकता है। कॉपीटेबलके विपरीत यह प्रतिलिपि प्रक्रिया के दौरान नेटवर्क और कंप्यूटिंग संसाधनों दोनों को सहेजते हुए, लक्ष्य समूहों के बीच डेटा को अलग करने की प्रतिलिपि बनाता है।
प्रक्रिया में निष्पादित होने वाला पहला चरण HashTable . है नक्शा कम करने का काम। इसे उस क्लस्टर पर चलाया जाना चाहिए जिसका डेटा रिमोट पीयर में कॉपी किया जाना चाहिए, आमतौर पर स्रोत क्लस्टर। इसे कैसे चलाना है इसका एक त्वरित उदाहरण नीचे दिखाया गया है, प्रत्येक आवश्यक पैरामीटर का विस्तृत विवरण इस लेख में बाद में दिया गया है:
hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job: map 100% कम करें 100 %20/04/28 05:05:49 INFO mapreduce.Job:Job job_1587986840019_0001 सफलतापूर्वक पूरा हुआ20/04/28 05:05:49 INFO mapreduce.Job:काउंटर्स:68… फ़ाइल इनपुट फ़ॉर्मेट काउंटर बाइट्स पढ़ें =0 फ़ाइल आउटपुट स्वरूप काउंटर बाइट्स लिखित=6811788
एक बार हैशटेबल उपरोक्त आदेश के साथ कार्य निष्पादन पूरा हो गया है, कुछ आउटपुट फ़ाइलें स्रोत hdfs /hashes/my-table में उत्पन्न हुई हैं निर्देशिका:
hdfs dfs -ls -R /hash/test-tbldrwxr-xr-x - रूट सुपरग्रुप 0 2020-04-28 05:05 /hash/test-tbl/hashes-rw-r--r-- 2 रूट सुपरग्रुप 0 2020-04-28 05:05 /हैश/टेस्ट-टीबीएल/हैश/_SUCCESSdrwxr-xr-x - रूट सुपरग्रुप 0 2020-04-28 05:05 /हैश/टेस्ट-टीबीएल/हैश/पार्ट-आर-00000 -rw-r--r-- 2 रूट सुपरग्रुप 6790909 2020-04-28 05:05 /hash/test-tbl/hash/part-r-00000/data-rw-r--r-- 2 रूट सुपरग्रुप 20879 2020-04-28 05:05 /हैश/टेस्ट-टीबीएल/हैश/पार्ट-आर-00000/इंडेक्स-आरडब्ल्यू-आर--आर-- 2 रूट सुपरग्रुप 99 2020-04-28 05:04 /हैश/टेस्ट- tbl/manifest-rw-r--r-- 2 रूट सुपरग्रुप 153 2020-04-28 05:04 /hash/test-tbl/partitions
ये सिंकटेबल . के इनपुट के रूप में आवश्यक हैं Daud। सिंकटेबल लक्ष्य सहकर्मी पर लॉन्च किया जाना चाहिए। कमांड के नीचे सिंकटेबल चलता है हैशटेबल . के आउटपुट के लिए पिछले उदाहरण से। यह ड्राईरन . का उपयोग करता है इस लेख में बाद में समझाया गया विकल्प:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source- क्लस्टर-सक्रिय-एनएन/हैश/टेस्ट-टीबीएल टेस्ट-टीबीएल टेस्ट-टीबीएल… org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLS=17MATCHINGROWS=2RANGESNOTISSNOTMATCELL=2RANGESNOTISSNOTMATCELL=2RANGESNOTSNOTMATCHED 1
एक त्वरित संदर्भ के रूप में, आप दोनों उदाहरणों पर दिए गए मापदंडों को अपने वास्तविक पर्यावरण मूल्यों से बदल सकते हैं। इस लेख के शेष भाग में कार्यान्वयन विवरण को अधिक गहराई से शामिल किया जाएगा।
दो अलग-अलग चरण क्यों?
इस टूल का मुख्य लक्ष्य केवल उन डेटा को पहचानना और कॉपी करना है जो दो समूहों के बीच गायब हैं। हैशटेबल तालिका डेटा के बैचों का विश्लेषण करने और हैश इंडेक्स उत्पन्न करने के लिए एक शार्डिंग/इंडेक्सिंग कार्य के रूप में कार्य करता है इनमें से प्रत्येक बैच के लिए। ये /hash/my-table . के तहत फाइलों में लिखे गए आउटपुट हैं hdfs निर्देशिका को नौकरी के मापदंडों में से एक के रूप में पारित किया गया। जैसा कि पहले उल्लेख किया गया है, यह आउटपुट SyncTable . द्वारा आवश्यक है काम। सिंकटेबल HashTable, . द्वारा उपयोग किए गए समान बैच आकारों में लक्ष्य तालिका को स्थानीय रूप से स्कैन करता है और HashTable द्वारा उपयोग किए जाने वाले समान फ़ंक्शन का उपयोग करके इन बैचों के लिए हैश मानों की गणना भी करता है। इसके बाद यह स्थानीय बैच हैश . की तुलना करता है HashTable . से एक के साथ मान आउटपुट यदि हैश मान समान हैं, तो इसका मतलब है कि पूरा बैच दो समूहों में समान है, और उस खंड पर कुछ भी कॉपी करने की आवश्यकता नहीं है। अन्यथा, यह स्रोत क्लस्टर में बैच के लिए एक स्कैन खोलता है, यह जाँचता है कि क्या प्रत्येक सेल पहले से ही लक्ष्य क्लस्टर में मौजूद है, केवल उन लोगों की नकल करता है जो अलग हो जाते हैं। विरल, थोड़े अलग डेटा सेट पर, इसके परिणामस्वरूप दो समूहों के बीच बहुत कम डेटा कॉपी किया जाएगा। बेमेल की जांच के लिए स्रोत में स्कैन करने के लिए केवल कुछ ही सेल की आवश्यकता होगी।
आवश्यक पैरामीटर
हैशटेबल केवल दो मापदंडों की आवश्यकता है:तालिका का नाम और आउटपुट पथ जहां संबंधित हैश और अन्य मेटा जानकारी फाइलें लिखी जाएंगी। सिंकटेबल हैशटेबल . का उपयोग करता है आउटपुट डीआईआर इनपुट के रूप में, क्रमशः स्रोत और लक्ष्य क्लस्टर में तालिका नामों के साथ। चूंकि हम हैशटेबल . का उपयोग कर रहे हैं /सिंकटेबल दूरस्थ समूहों के बीच डेटा स्थानांतरित करने के लिए, sourcezkcluster विकल्प को सिंकटेबल . के लिए परिभाषित किया जाना चाहिए . यह स्रोत क्लस्टर का ज़ूकीपर कोरम पता होना चाहिए। इस लेख के उदाहरण में, हमने सीधे स्रोत क्लस्टर सक्रिय नामेनोड पते का भी संदर्भ दिया था, ताकि सिंकटेबल स्रोत क्लस्टर से सीधे हैश आउटपुट फ़ाइल पढ़ेगा। वैकल्पिक रूप से, हैशटेबल आउटपुट को मैन्युअल रूप से स्रोत क्लस्टर से दूरस्थ क्लस्टर (उदाहरण के लिए, distcp के साथ) में कॉपी किया जा सकता है।
| ध्यान दें:अलग-अलग kerberos दायरे के अंतर्गत दूरस्थ समूहों के साथ कार्य करना केवल CDH 6.2.1 से समर्थित है। |
उन्नत विकल्प
दोनों हैशटेबल और सिंकटेबल अतिरिक्त वैकल्पिक विकल्प प्रदान करें जिन्हें इष्टतम परिणामों के लिए ट्यून किया जा सकता है।
हैशटेबल स्टार्ट्रो/स्टार्टटाइम, स्टॉप्रो/स्टॉपटाइम के साथ, पंक्ति कुंजी और संशोधन समय दोनों द्वारा डेटा को फ़िल्टर करने की अनुमति देता है गुण, क्रमशः। डेटासेट का दायरा संस्करणों . द्वारा भी सीमित किया जा सकता है और परिवार गुण। बैच आकार संपत्ति प्रत्येक भाग के आकार को परिभाषित करती है जिसे हैश किया जाएगा। यह सीधे सिंक प्रदर्शन पर प्रभाव डालता है। बहुत कम बेमेल के मामलों में, बड़े बैच आकार के मान सेट करने से बेहतर प्रदर्शन हो सकता है क्योंकि डेटा सेट के बड़े हिस्से को SyncTable द्वारा स्कैन किए बिना अनदेखा कर दिया जाएगा।
सिंकटेबल एक ड्राईरन . प्रदान करता है विकल्प जो लक्ष्य में लागू किए जाने वाले परिवर्तनों के पूर्वावलोकन की अनुमति देता है।
सिंकटेबल डिफ़ॉल्ट व्यवहार लक्ष्य डेटा पर स्रोत डेटा को मिरर करना है, इसलिए लक्ष्य में मौजूद कोई भी अतिरिक्त सेल लेकिन स्रोत में अनुपस्थित लक्ष्य पक्ष पर नष्ट हो जाता है। सक्रिय-सक्रिय प्रतिकृति सेटअप के तहत समूहों को समन्वयित करते समय यह अवांछनीय हो सकता है और ऐसे मामलों के लिए, doDeletes विकल्पों को गलत में बदला जा सकता है, लक्ष्य पर विलोपन की प्रतिकृति को छोड़ देना। एक समान doPuts . भी है उन मामलों के लिए फ़्लैग करें जहां लक्ष्य क्लस्टर में अतिरिक्त सेल नहीं डाले जाने चाहिए।
आउटपुट का विश्लेषण करना
हैशटेबल SyncTable, . के लिए मेटा जानकारी वाली कुछ फ़ाइलें आउटपुट करता है हालांकि, वे मानव पठनीय नहीं हैं। यह मौजूदा डेटा पर कोई परिवर्तन नहीं करता है, इसलिए संबंधित जानकारी उपयोगकर्ता के संदर्भ में बहुत कम रुचि रखती है।
सिंकटेबल वह कदम है जो वास्तव में लक्ष्य पर संशोधनों को लागू करता है और लक्ष्य क्लस्टर डेटा को वास्तव में बदलने से पहले इसके सारांश की समीक्षा करना महत्वपूर्ण हो सकता है (देखें dryrun ऊपर उल्लिखित विकल्प)। यह मानचित्र के अंत में निष्पादन को कम करने के लिए कुछ प्रासंगिक काउंटर प्रकाशित करता है। उपरोक्त उदाहरण के मूल्यों को देखते हुए, हम देख सकते हैं कि 97148 . थे विभाजन हैशेड (बैच द्वारा रिपोर्ट किया गया काउंटर), जो सिंकटेबल उनमें से केवल दो में विचलन का पता चला (HASHES_MATCHED के अनुसार) और HASHES_NOT_MACTHED काउंटर)। इसके अलावा, अलग-अलग हैश वाले दो पार्टिशन में, 17 सेल 2 पंक्तियों से अधिक मेल खा रहे थे (जैसा कि MATCHING_CELLS . द्वारा रिपोर्ट किया गया है और MATCHING_ROWS, क्रमशः), लेकिन 2 पंक्तियाँ . भी थीं विचलन, इन दो विभाजनों पर (RANGESNOTMATCHED के अनुसार) और ROWSWITHDIFFS ) अंत में, SOURCEMISSINGCELLS और TARGETMISSINGCELLS हमें विस्तार से बताएं कि क्या सेल केवल स्रोत या लक्ष्य क्लस्टर पर मौजूद थे। इस उदाहरण में, स्रोत क्लस्टर में एक सेल था जो लक्ष्य पर नहीं था, लेकिन लक्ष्य में एक सेल भी था जो स्रोत पर नहीं था। चूंकि सिंकटेबल dryrun . निर्दिष्ट किए बिना चलाया गया था विकल्प और सेटिंग doDeletes गलत . का विकल्प , जॉब ने लक्ष्य क्लस्टर में अतिरिक्त सेल को हटा दिया है और स्रोत में पाए गए अतिरिक्त सेल को लक्ष्य क्लस्टर में जोड़ दिया है। मान लें कि कोई लेखन नहीं या तो क्लस्टर पर होता है, बाद में उसी SyncTable . का एक रन लक्ष्य क्लस्टर में कमांड कोई अंतर नहीं दिखाएगा:
hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes /test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…
लागू परिदृश्य
डेटा सिंक
पहली नज़र में, हैशटेबल/सिंकटेबल कॉपीटेबल . के साथ ओवरलैप लग सकता है उपकरण, लेकिन अभी भी विशिष्ट परिदृश्य हैं जहां कोई भी उपकरण अधिक उपयुक्त होगा। पहले तुलना उदाहरण के रूप में, HashTable/SyncTable . का उपयोग करके 100,004 पंक्तियों वाली तालिका के आरंभिक लोड के लिए और 5.17 जीबी के कुल डेटा आकार के लिए केवल सिंकटेबल के लिए कुछ मिनटों की आवश्यकता होती है पूरा करने के लिए:
...20/04/29 03:48:00 INFO mapreduce.Job:रनिंग जॉब:job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job:Job job_1587985272792_0011 uber मोड में चल रहा है:false20/04/ 29 03:48:09 INFO mapreduce.Job: map 0% कम 0%20/04/29 03:54:08 INFO mapreduce.Job: map 100% कम 0%20/04/29 03:54:09 INFO mapreduce .जॉब:जॉब जॉब_1587985272792_0011 सफलतापूर्वक पूरा हुआ… org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROWSWIT1000HDIFFSpreINGROWSTARइतने छोटे डेटासेट पर भी, कॉपीटेबल तेजी से निष्पादित (लगभग 3 मिनट, जबकि सिंकटेबल पूरे डेटा सेट को कॉपी करने में 6 मिनट लगे):
...20/04/29 05:12:07 INFO mapreduce.Job:रनिंग जॉब:job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job:Job job_1587986840019_0005 uber mode में चल रहा है:false20/04/ 29 05:12:24 INFO mapreduce.Job: map 0% कम 0%20/04/29 05:13:16 INFO mapreduce.Job: map 25% कम 0%20/04/29 05:13:49 INFO mapreduce .नौकरी: नक्शा 50% कम 0%20/04/29 05:14:37 INFO mapreduce.Job: नक्शा 75% कम 0%20/04/29 05:15:14 INFO mapreduce.Job: नक्शा 100% कम 0 %20/04/29 05:15:14 INFO mapreduce.Job:Job job_1587986840019_0005 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2787236791BYTES_IN_RESULTS=5549784428MILLIS_BETWEEN_NEXTS=130808NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1334REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100004RPC_CALLS=2657RPC_RETRIES=0अब डेटासेट पर विरल अंतर से निपटने के लिए दोनों टूल का फिर से उपयोग करते हैं। टेस्ट-टीबीएल इन सभी उदाहरणों पर प्रयुक्त तालिका में स्रोत क्लस्टर में चार क्षेत्र हैं। सभी मूल डेटा सेट को पिछले उदाहरण में लक्ष्य क्लस्टर में कॉपी करने के बाद, हमने केवल स्रोत पक्ष में चार अतिरिक्त पंक्तियाँ जोड़ीं, प्रत्येक मौजूदा क्षेत्रों के लिए एक, फिर HashTable/SyncTable चलाएं। फिर से सिंक . के लिए दोनों क्लस्टर:
20/04/29 05:29:23 INFO mapreduce.Job:रनिंग जॉब:job_15879852792_001320/04/29 05:29:39 INFO mapreduce.Job:Job job_1587985272792_0013 uber mode में चल रहा है:false20/04/29 05:29:39 INFO mapreduce.Job: map 0% कम 0%20/04/29 05:29:53 INFO mapreduce.Job: map 50% कम 0%20/04/29 05:30:42 INFO mapreduce.Job:map 100% कम करें 0%20/04/29 05:30:42 INFO mapreduce.Job:जॉब जॉब_1587985272792_0013 सफलतापूर्वक पूरा हुआ...org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97144HASHES_NOT_MATCHED=42MATCHINGCINGCINGC 5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4हम इसे केवल चार . के साथ देख सकते हैं विभाजन बेमेल, सिंकटेबल काफी तेज था (पूरा होने में लगभग एक मिनट)। कॉपीटेबल . का उपयोग करना वही सिंक करने के लिए निम्नलिखित परिणाम दिखाए:
20/04/29 08:32:38 INFO mapreduce.Job:रनिंग जॉब:job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job:जॉब जॉब_1587986840019_0008 uber मोड में चल रहा है:false20/04/29 08:32:52 INFO mapreduce.Job: map 0% कम 0%20/04/29 08:33:38 INFO mapreduce.Job: map 25% कम 0%20/04/29 08:34:15 INFO mapreduce.Job:नक्शा 50% कम 0%20/04/29 08:34:48 जानकारी मेप्रिडस। नौकरी: नक्शा 75% कम 0% 20/04/29 08:35:31 जानकारी मैप्रेडस। नौकरी:नक्शा 100% कम 0% 20/ 04/29 08:35:32 INFO mapreduce.Job:Job job_1587986840019_0008 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2762547723BYTES_IN_RESULTS=5549784600MILLIS_BETWEEN_NEXTS=340672NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1323REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100008RPC_CALLS=2657RPC_RETRIES=0कॉपीटेबल तालिकाओं को समन्वयित करने में उतना ही समय लगा जितना पूरे डेटासेट को कॉपी करते समय, भले ही केवल चार थे कॉपी करने के लिए सेल। इस बहुत छोटे डेटासेट के लिए, और एक निष्क्रिय क्लस्टर के साथ यह अभी भी ठीक था, लेकिन उत्पादन के तहत बड़े डेटा सेट के साथ मामलों का उपयोग किया जाता है और जहां लक्ष्य क्लस्टर का उपयोग कई क्लाइंट एप्लिकेशन द्वारा डेटा लिखने के लिए भी किया जा सकता है, कॉपीटेबल सिंकटेबल . की तुलना में प्रदर्शन में गिरावट और भी अधिक होगा।
यह ध्यान देने योग्य है कि ऐसे अतिरिक्त उपकरण/सुविधाएँ भी हैं जिनका उपयोग लक्ष्य क्लस्टर के प्रारंभिक लोड के लिए संयोजन में किया जा सकता है (लक्ष्य में कोई डेटा नहीं है), जैसे स्नैपशॉट निर्यात, बल्क लोड, या यहां तक कि मूल की एक सीधी प्रति भी। स्रोत क्लस्टर से तालिका डीआईआर। कॉपी करने के लिए बड़ी मात्रा में डेटा के साथ प्रारंभिक लोड के लिए, एक टेबल स्नैपशॉट लेना और फिर ExportSnapshot का उपयोग करना टूल ऑनलाइन कॉपी टूल जैसे SyncTable . से बेहतर प्रदर्शन करेगा या कॉपीटेबल.
प्रतिकृति सत्यता की जांच करना
संभावित प्रतिकृति समस्याओं का निवारण करते समय, हैशटेबल/सिंकटेबल का एक अन्य सामान्य उपयोग क्लस्टर के बीच प्रतिकृति स्थिति की निगरानी के लिए है। इस परिदृश्य में यह VerifyReplication उपकरण के विकल्प के रूप में कार्य करता है। आमतौर पर दो समूहों के बीच की स्थिति की जाँच करते समय या तो कोई बेमेल नहीं होता है या अस्थायी रूप से एक अस्थायी समस्या के कारण बड़े डेटासेट का एक छोटा हिस्सा सिंक से बाहर हो जाता है। परीक्षण वातावरण में हम अपने पिछले उदाहरण के लिए उपयोग कर रहे हैं, दोनों समूहों पर मिलान मूल्यों के साथ 100,008 पंक्तियां होनी चाहिए। ड्राईरन विकल्प के साथ गंतव्य क्लस्टर पर सिंकटेबल चलाना हमें किसी भी अंतर की पहचान करने देगा:
20/05/04 10:47:25 जानकारी मैपरेड्यूस। जॉब:रनिंग जॉब:जॉब_1588611199158_0004…20/05/04 10:48:48 जानकारी मैप्रेड्यूस। जॉब: मैप 100% कम 0%20/05/04 10 :48:48 INFO mapreduce.Job:जॉब जॉब_1588611199158_0004 सफलतापूर्वक पूरा हुआ...HBase काउंटर्सBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008... org.apache.hadoop.hbase.mapperTable स्रोत क्लस्टर पर VerifyReplication उपकरण। हम पीयर आईडी को इसके एक पैरामीटर के रूप में पास करते हैं ताकि यह तुलना के लिए स्कैन करने के लिए दूरस्थ क्लस्टर ढूंढ सके:20/05/04 11:01:58 INFO mapreduce.Job:रनिंग जॉब:job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job: map 100% कम 0%20/05/04 11:04:39 INFO mapreduce.Job:जॉब जॉब_1588611196128_0001 सफलतापूर्वक पूरा हुआ...HBase CountersBYTES_IN_REMOTE_RESULTS=2761955495BYTES_IN_RESULTS=5549784600…org.apache.mapreduce_IN_RESULTS=5549784600…org.apache. .replication.VerifyReplication$Verifier$CountersGOODROWS=100008...बिना किसी अंतर के, SyncTable स्रोत और लक्ष्य विभाजन के बीच मेल खाने वाले सभी हैश ढूंढता है और इस प्रकार, दूरस्थ स्रोत क्लस्टर को फिर से स्कैन करने की आवश्यकता से बचा जाता है। VerifyReplication दोनों समूहों में प्रत्येक सेल के लिए एक-एक करके तुलना करता है, जो ऐसे छोटे डेटासेट से निपटने के दौरान पहले से ही एक उच्च नेटवर्क लागत वहन कर सकता है।
स्रोत क्लस्टर में एक अतिरिक्त पंक्ति जोड़ना और फिर से जाँच करना। VerifyReplication के साथ:
20/05/05 11:14:05 INFO mapreduce.Job:रनिंग जॉब:job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job: map 100% कम 0%20/05/05 11 :16:32 INFO mapreduce.Job:जॉब जॉब_1588611196128_0004 सफलतापूर्वक पूरा हुआ...org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008ONLY_IN_SOURCE_TABLE_ROWS=1…इससे पहले कि हम सिंकटेबल का उपयोग कर सकें, हमें हैशटेबल के साथ स्रोत पर हैश को फिर से बनाना होगा, क्योंकि अब एक नया सेल है:
20/05/04 11:31:48 INFO mapreduce.Job:रनिंग जॉब:job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job:Job job_1588611196128_0003 सफलतापूर्वक पूर्ण...अब सिंकटेबल:
20/05/07 05:47:51 INFO mapreduce.Job:रनिंग जॉब:job_1588611199158_0014…20/05/07 05:49:20 INFO mapreduce.Job:Job job_1588611199158_0014 सफलतापूर्वक पूरा हुआ… org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS=1TARGETMISSINGCELLS=1TARGETMISSINGCELLS=1TARGETMISSINGCELLS=1हम दो दूरस्थ समूहों के बीच अतिरिक्त स्कैन और सेल तुलना के कारण निष्पादन समय में वृद्धि देख सकते हैं। इस बीच, VerifyReplication निष्पादन समय में थोड़ा बदलाव दिखा।
निष्कर्ष
हैशटेबल/सिंकटेबल दो क्लस्टर डेटासेट के बीच विरल बेमेल से निपटने के दौरान, डेटा को इधर-उधर करने के लिए एक मूल्यवान उपकरण है। यह दो डेटा सेटों से श्रेणियों पर अंतर का कुशलतापूर्वक पता लगाने के लिए डेटा विभाजन और हैशिंग का उपयोग करता है, दो समूहों से डेटा की तुलना करते समय स्कैन की जाने वाली कोशिकाओं की संख्या को कम करता है, जबकि लक्ष्य क्लस्टर में पहले से मौजूद मूल्यों के अनावश्यक पुट से भी बचा जाता है। हालांकि, यह एक चांदी की गोली नहीं है, जैसा कि ऊपर दिए गए कुछ उदाहरणों में दिखाया गया है, जबकि यह कॉपीटेबल के साथ फ़ंक्शन में ओवरलैप हो सकता है। उपकरण, बेमेल कोशिकाओं की बड़ी, अनुक्रमिक श्रेणी को संभालते समय बाद वाला बेहतर प्रदर्शन प्रदान कर सकता है। उस अर्थ में, हैशटेबल/सिंकटेबल उन मामलों में सबसे अधिक लागू होगा जहां दोनों समूहों में पहले से ही कुछ डेटा मौजूद है, या ऐसे मामलों में जहां मौजूदा प्रतिकृति सेटअप किसी एक साथी की अस्थायी अनुपलब्धता से बाधित हो गया है।
संबंधित लेख:
https://blog.cloudera.com/apache-hbase-replication-overview/
https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/
https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/
https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/
