Hadoop भाग 2: फ्लूम के माध्यम से डेटा एकत्र करना

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

क्लस्टर में डेटा ट्रांसफर करने का सबसे आसान तरीका ह्यु कंट्रोल पैनल में फाइल मैनेजर वेब इंटरफेस के माध्यम से फाइलों को कॉपी करना है। वेब इंटरफ़ेस http: // [Hue_node]: 8888 / filebrowser / ([Hue_node] के बजाय, उस नोड का पता, जहां Hue तैनात है, संकेत दिया गया है) पर स्थित है। यह सहज है और इसके लिए किसी और स्पष्टीकरण की आवश्यकता नहीं है।

वेब इंटरफ़ेस नौसिखिए उपयोगकर्ताओं के लिए अच्छा है; एचडीएफएस की निर्देशिका संरचना का पता लगाना सुविधाजनक है। इसी समय, बड़ी फ़ाइलों (कुछ गीगाबाइट से) को डाउनलोड करने के लिए यह असुविधाजनक है।



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

  hadoop fs -put file_for_hadoop / path / to / put / file / in / HDFS / 

इस स्थिति में, आप हमेशा सर्वर पर पारंपरिक पाइप या प्री-कॉपी फ़ाइलों का उपयोग कर सकते हैं।

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

फ्लूम के बारे में

अनुवाद में प्रवाह शब्द का अर्थ है "चैनल"। यह उपकरण डेटा प्रवाह का प्रबंधन करने के लिए डिज़ाइन किया गया है: उन्हें विभिन्न स्रोतों से इकट्ठा करें और उन्हें एक केंद्रीकृत भंडार में भेजें।

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

आर्किटेक्चर

मूल अवधारणाएँ

हम मूल अवधारणाओं को परिभाषित करके फ्ल्यूम वास्तुकला के विवरण के साथ शुरू करते हैं:

• घटना (घटना) - एक उपसमूह मूल से गंतव्य के लिए Flume द्वारा प्रेषित;
• प्रवाह - गंतव्य के बिंदु से उत्पत्ति के बिंदु तक घटनाओं का प्रवाह;
• क्लाइंट - कोई भी एप्लिकेशन जो डेटा को फ़्ल्यूम एजेंट में स्थानांतरित करता है;
• एजेंट - एक स्वतंत्र प्रक्रिया जिसमें घटकों जैसे स्रोतों, चैनलों और नालियों को निष्पादित किया जाता है; घटनाओं का भंडारण और अगले नोड में स्थानांतरण;
• source - एक इंटरफ़ेस जो विभिन्न डेटा ट्रांसफर प्रोटोकॉल के माध्यम से संदेश प्राप्त करता है। स्रोत प्राप्त घटनाओं को एक या अधिक चैनलों तक पहुंचाता है। फ़्लुम बाहरी स्रोतों से डेटा स्थानांतरित करने के लिए निम्न मानकों का समर्थन करता है: एआरएनओ, लॉग 4 जे, सिसलॉग, एचटीएन पोस्ट, जोसन बॉडी के साथ। Execource लाइब्रेरी का उपयोग करके, आप अन्य मानकों के लिए समर्थन लागू कर सकते हैं;
• चैनल - घटनाओं के लिए अस्थायी भंडारण। यह कार्यक्रम चैनल में है जब तक कि इसे नाली से वापस नहीं लिया जाता है। चैनल ईवेंट कतारें संग्रहीत करते हैं, जो आपको अलग-अलग प्रदर्शन और वास्तुकला के साथ धाराओं और स्रोतों को अलग करने की अनुमति देता है। चैनल के प्रकार के आधार पर, घटनाओं को मेमोरी में, डिस्क पर या एक डेटाबेस में एक नियमित फ़ाइल में संग्रहीत किया जा सकता है (उदाहरण के लिए, एक जेडीबीसी चैनल);
• सिंक - एक इंटरफ़ेस कार्यान्वयन जो एक चैनल से एक घटना लेता है और इसे स्ट्रीम में अगले एजेंट को भेजता है या इसे अंतिम भंडारण में संग्रहीत करता है (उदाहरण के लिए, एचडीएफएस)। घटना को गंतव्य भंडार में स्थानांतरित करने वाले सिंक को गंतव्य सिंक कहा जाता है। अंतिम सिंक के उदाहरण एचडीएफएस फाइल सिस्टम, हाइव डेटाबेस, सोलर सर्च सर्वर हैं। एक विशिष्ट प्रवाह का एक उदाहरण एवरो है, जो बस अन्य एजेंटों को संदेश भेजता है।

प्रवाह संरचना

प्रवाह क्लाइंट के साथ शुरू होता है, जो ईवेंट को एजेंट तक पहुंचाता है (अधिक सटीक रूप से, एजेंट के भीतर स्रोत तक)। ईवेंट को प्राप्त करने वाला स्रोत इसे एक या अधिक चैनलों तक पहुंचाता है। चैनलों से, घटना नालियों में प्रेषित होती है जो उसी एजेंट का हिस्सा होती हैं। वह इसे किसी अन्य एजेंट को स्थानांतरित कर सकता है, या (यदि यह अंतिम एजेंट है) गंतव्य नोड के लिए।

चूंकि स्रोत कई चैनलों पर घटनाओं को प्रसारित कर सकता है, धाराओं को कई गंतव्य नोड्स पर भेजा जा सकता है। यह नीचे दिए गए आंकड़े में स्पष्ट रूप से दिखाया गया है: एजेंट घटना को दो चैनलों (चैनल 1 और चैनल 2) में पढ़ता है, और फिर उन्हें स्वतंत्र सिंक में स्थानांतरित करता है।



एकाधिक थ्रेड्स को एक में जोड़ा जा सकता है। इसके लिए आवश्यक है कि एक ही एजेंट के भीतर कई स्रोत एक ही चैनल पर डेटा संचारित करें। प्रवाह के संयोजन के दौरान घटकों की इंटरैक्शन स्कीम नीचे दिए गए चित्र में दिखाई गई है (यहां, तीन स्रोतों में से प्रत्येक, कई स्रोतों सहित, एक ही चैनल और फिर नाली तक डेटा पहुंचाता है):

विश्वसनीयता और त्रुटि से निपटने

स्रोतों और चैनलों के साथ-साथ एजेंटों के बीच डेटा हस्तांतरण, लेनदेन का उपयोग करके किया जाता है, जो डेटा सुरक्षा सुनिश्चित करता है।

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



स्ट्रीम में त्रुटि से निपटने में: (ए) क्लाइंट से केंद्रीय रिपॉजिटरी में संचार समस्याओं के बिना ईवेंट चलते हैं; (b) Agent2 और केंद्रीय रिपॉजिटरी के बीच के क्षेत्र में एक संचार समस्या है, और घटना Agent2 पर बफ़र की जाती हैं; (c) संचार समस्याओं को हल करने के बाद, Agent2 पर बफर की गई घटनाओं को केंद्रीय भंडार में भेजा गया।

Cloudera Manager के माध्यम से फ़्लुम स्थापित करें

चूँकि हमने पहले से ही Cloudera Hadoop क्लस्टर (पिछले लेख देखें) को तैनात किया है, हम Cloudera प्रबंधक का उपयोग करके Flume स्थापित करेंगे। क्लस्टर सेवाओं की सूची वाले पृष्ठ पर, "क्रियाएँ" → "एक सेवा जोड़ें" चुनें।



"फ़्ल्यूम" चुनें और "जारी रखें" बटन पर क्लिक करें:



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



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



"जारी रखें" बटन पर क्लिक करें। जल्द ही एक नई सेवा के सफल जोड़ के बारे में स्क्रीन पर एक संदेश दिखाई देगा:



अब आइए Cloudera प्रबंधक में "सेवाओं" → "flume1" का चयन करके फ़्लम डैशबोर्ड पर जाएं:



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



डिफ़ॉल्ट रूप से, सभी फ़्ल्यूम एजेंटों की सेटिंग एक कॉन्फ़िगरेशन फ़ाइल में संग्रहीत होती है (इसकी सामग्री कॉन्फ़िगरेशन फ़ाइल फ़ील्ड में प्रदर्शित होती है)। यह फ़ाइल सभी एजेंटों द्वारा साझा की गई है और उनमें से प्रत्येक को विरासत में मिली है:

फ़्लुम एजेंट कॉन्फ़िगर करें

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

  ### syslog सीएफजी
 a1.source = r1
 a1.channels = c1
 a1.sinks = k1

 # स्रोत
 a1.source.r1.type = syslogudp
 a1.sources.r1.port = 5140
 a1.sources.r1.host = cdh2.example.com
 a1.sources.r1.channels = c1

 # टाइमस्टैम्प डालें
 a1.sources.r1.interceptors = i1
 a1.sources.r1.interceptors.i1.type = टाइमस्टैम्प

 # सिंक
 a1.sinks.k1.type = hdfs
 a1.sinks.k1.channel = c1
 a1.sinks.k1.hdfs.path = / log / flume / घटनाएँ /% y-% m-% d /% H-% M
 a1.sinks.k1.hdfs.filePrefix = फ़्ल्यूम-
 a1.sinks.k1.hdfs.round = true
 a1.sinks.k1.hdfs.roundValue = 5
 a1.sinks.k1.hdfs.roundUnit = मिनट
 a1.sinks.k1.hdfs.fileType = DataStream
 a1.sinks.k1.hdfs.rollCount = 100000
 a1.sinks.k1.hdfs.rollSize = 0

 # चैनल
 a1.channels.c1.type = मेमोरी
 a1.channels.c1.capacity = 1000 

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

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

आप दस्तावेज़ में फ़्लूम एजेंटों को कॉन्फ़िगर करने के बारे में अधिक पढ़ सकते हैं।

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

  a1.source = r1
 a1.channels = c1
 a1.sinks = k1 

कई वस्तुओं को निर्दिष्ट करते समय, उनके नाम एक स्थान के साथ सूचीबद्ध होते हैं (उदाहरण के लिए, "a1.source = r1 r2 r3")

चैनल शुरू करके चलो। चैनल के रूप में, हम तथाकथित मेमोरी चैनल का उपयोग करते हैं, जो मेमोरी में ईवेंट कतार को संग्रहीत करता है। गतिविधि के अप्रत्याशित फटने के मामले में, अधिकतम कतार का आकार 1000 संदेशों पर सेट है, हालांकि कतार में संदेशों की संख्या आमतौर पर 10 से अधिक नहीं होती है।

  # चैनल
 a1.channels.c1.type = मेमोरी
 a1.channels.c1.capacity = 1000 

Syslog UDP स्रोत कॉन्फ़िगरेशन

स्रोत के रूप में, हम UDP Syslog का उपयोग करेंगे, जो मानक Flume पैकेज का हिस्सा है:

  a1.source.r1.type = syslogudp
 a1.sources.r1.port = 5140
 a1.sources.r1.host = cdh2.example.com
 a1.sources.r1.channels = c1 

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

अगला, एक ऑब्जेक्ट इंगित किया जाता है, जिसे अधिक विस्तार से चर्चा की जानी चाहिए - एक इंटरसेप्टर। इंटरसेप्टर अलग निकाय नहीं हैं, लेकिन स्रोतों का हिस्सा हैं।

  # टाइमस्टैम्प डालें
 a1.sources.r1.interceptors = i1
 a1.sources.r1.interceptors.i1.type = टाइमस्टैम्प 

फ्लूम में घटनाओं के घटक शरीर (स्वयं डेटा) और अतिरिक्त हेडर हैं, जिनमें से सूची स्रोत के प्रकार के आधार पर भिन्न हो सकती है। इंटरसेप्टर चैनल पर संचारित होने से पहले मक्खी पर डेटा प्रीप्रोसेस करता है।

इंटरसेप्टर एक साथ चेन कर सकते हैं; वे इनडीनर्टेक्टर निर्देश (उदाहरण के लिए, "a1.sources.r1.interceptors = i1 i2 i3") में निर्दिष्ट आदेश के अनुसार निष्पादित किए जाते हैं। हमारे मामले में, "r1" स्रोत के लिए केवल एक इंटरसेप्टर "i1" का उपयोग किया जाता है।

Syslog स्रोत केवल ईवेंट बॉडी के लिए केवल संदेश लिखता है। अन्य सभी हेडर (सिसलॉग आरएफसी के अनुरूप) फ्लूम इवेंट के संबंधित हेडर को लिखे जाते हैं।

सीसलॉग स्रोत टाइमस्टैम्प हेडर में टाइमस्टैम्प को एकरूप प्रारूप में नहीं, बल्कि मानव-पठनीय रूप में लिखते हैं (उदाहरण के लिए, "2013: 09: 17-09: 03: 00")। इसे ठीक करने के लिए, हम टाइमस्टैम्प इंटरसेप्टर का उपयोग करते हैं, टाइमस्टैम्प हेडर को यूनिक्स टाइम प्रारूप में ओवरराइट करते हैं। हमें प्रवाह सेटिंग्स में इस हेडर की आवश्यकता होगी, जिस पर बाद में चर्चा की जाएगी।

HDFS में स्टॉक सेट करना

अंत में, चलो अपवाह को कॉन्फ़िगर करने के लिए आगे बढ़ते हैं, जो HDFS में हमारे डेटा को बचाएगा:

  a1.sinks.k1.type = hdfs
 a1.sinks.k1.channel = c1
 a1.sinks.k1.hdfs.path = / log / flume / घटनाएँ /% y-% m-% d /% H-% M
 a1.sinks.k1.hdfs.filePrefix = फ़्ल्यूम-
 a1.sinks.k1.hdfs.fileType = DataStream
 a1.sinks.k1.hdfs.round = true
 a1.sinks.k1.hdfs.roundValue = 5
 a1.sinks.k1.hdfs.roundUnit = मिनट
 a1.sinks.k1.hdfs.rollCount = 100000
 a1.sinks.k1.hdfs.rollSize = 0 

प्रकार और चैनल मापदंडों के साथ, सब कुछ स्पष्ट है, लेकिन बाकी पर अधिक विस्तार से चर्चा की जानी चाहिए।

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

FilePrefix पैरामीटर फ़ाइलों के लिए उपसर्ग सेट करता है, जो विभिन्न एजेंटों से एक ही फ़ोल्डर में लॉग एकत्र करने के लिए सुविधाजनक है।

फ़ाइल टाइप पैरामीटर उन फ़ाइलों के प्रारूप को निर्दिष्ट करता है जिनमें घटनाओं को सहेजा जाएगा। DataStream एक मानक प्रारूप है जिसमें प्रत्येक घटना को एक सादे पाठ फ़ाइल में एक स्ट्रिंग के रूप में सहेजा जाता है।

पैरामीटर्स राउंड, राउंडवैल्यू और राउंडउनिट से संकेत मिलता है कि टाइमस्टैम्प वैल्यू को 5 मिनट के लिए राउंड किया जाएगा। यह सबफ़ोल्डर्स में फ़ाइलों को 5 मिनट की वृद्धि में बचाएगा। इन मापदंडों के बिना, सबफ़ोल्डर 1 मिनट की वेतन वृद्धि में बनाया जाएगा, जो बहुत सुविधाजनक नहीं है।

बड़े संदेश प्रवाह के साथ काम करते समय, एक बड़ी फ़ाइल लिखने के बजाय सबफ़ोल्डर्स के अंदर फ़ाइलों को विभाजित करना उचित लगता है। यह रोल * मापदंडों का उपयोग करके किया जा सकता है:
रोलकाउंट = 100000 एक फ़ाइल में संदेशों की संख्या को इंगित करता है, जिसके बाद वर्तमान फ़ाइल बंद हो जाती है और एक नया बनाया जाता है।
RollSize = 0 इंगित करता है कि हम प्रत्येक फ़ाइल के आकार को सीमित नहीं करते हैं।

क्लाइंट सेटअप

इसलिए, हमारा एजेंट डेटा प्राप्त करने और परिवर्तित करने के लिए कॉन्फ़िगर और तैयार है, और फिर इसे एचडीएफएस में सहेजें। यह केवल डेटा को UDP के माध्यम से Syslog प्रारूप में भेजने के लिए बना हुआ है।

एक उदाहरण के रूप में हमारी क्लाउड स्टोरेज सेवा के लिए डेटा संग्रह प्रक्रिया पर विचार करें। एक लोड बैलेंसर के रूप में, हम haproxy का उपयोग करते हैं, जो फ्लूम एजेंट के HTTP अनुरोधों के लॉग को पास करता है। इन लॉग में क्लाइंट का पता, अनुरोध URL, हस्तांतरित डेटा की मात्रा और अन्य सेवा डेटा शामिल हैं।
यहाँ लॉगिंग के लिए जिम्मेदार हाइप्रोक्सि कॉन्फिगरेशन के भाग का एक उदाहरण है:

  वैश्विक
  लॉग [FQDN_Flume_agent]: 5140 local0 जानकारी
  अधिकतम 60,000
  nbproc 16
  उपयोगकर्ता
  समूह haproxy
  डेमॉन
  ट्यून.मैक्सैप्ट -1
  ट्यून.बुफीज 65536

 चूक
  वैश्विक लॉग इन करें
  मोड http
  # हूप के लिए
  विकल्प httplog
  # गोद लेना
  log-format \ t% T \ t% ci \ t% cp \ t% ft \ t% b \ t% s \ t% ST \ t% B \ t% sq \ t% bq \ t% r
  विकल्प NOTlognull
  # दत्तक नाल-सामान्य 

लॉग विकल्प सर्वर पते और पोर्ट को इंगित करता है, जिस पर फ़्लूम एजेंट चल रहा है, साथ ही साथ syslog और अधिसूचित लॉग स्तर के लिए स्थानीय 0 पैरामीटर की सुविधा है।

Http और विकल्प httplog के निर्देश से संकेत मिलता है कि हम HTTP प्रोटोकॉल का उपयोग करके प्रवेश लॉग को बचाएंगे। आप प्रलेखन में हाइपोक्सी लॉग प्रारूपों के बारे में अधिक पढ़ सकते हैं।

अधिक से अधिक जानकारी सहेजने के लिए, लॉगपास और डिटॉल-सामान्य विकल्पों को अक्षम करें। यदि logasap विकल्प अक्षम है, तो haproxy अपने पूर्ण होने पर एक HTTP अनुरोध करेगा, जो प्राप्त और प्रेषित डेटा की मात्रा को दर्शाता है। सफल लोगों सहित सभी अनुरोधों को लॉग करने के लिए हैप्रोक्सी के लिए, आपको नॉटलॉग-सामान्य विकल्प को अक्षम करना होगा।

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

संदर्भ के लिए: प्रति दिन संग्रहण से पहुंच लॉग 20-30GB है। फिलहाल, हमने पहले ही 200TB से अधिक डेटा एकत्र कर लिया है। फ़्लुम एजेंट व्यावहारिक रूप से उस सर्वर को लोड नहीं करता है जिस पर वह काम करता है (लोड एवरेज ~ 0.01), और एचडीएफएस सेवा आसानी से विघटित हो जाती है और प्राप्त डेटा को तीन स्वतंत्र क्लस्टर नोड्स में बैकअप देती है। और यह सब - पारंपरिक धुरी ड्राइव के साथ सबसे अधिक उत्पादक सर्वरों से दूर।

निष्कर्ष

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

जो लोग हबेरा के पदों पर टिप्पणी नहीं कर सकते, उनके लिए हम अपने ब्लॉग पर आमंत्रित करते हैं।