पुस्तक "वर्क विथ बिगडाटा इन द क्लाउड्स। Microsoft Azure से उदाहरण के साथ डेटा को संसाधित करना और संग्रहीत करना »

यहां पहली मूल रूसी भाषा की पुस्तक है जिसमें बादलों में बिग डेटा प्रोसेसिंग के वास्तविक जीवन के रहस्यों की वास्तविक उदाहरणों के साथ जांच की जाती है।

ध्यान Microsoft Azure और AWS समाधान पर है। कार्य के सभी चरणों पर विचार किया जाता है - क्लाउड में प्रसंस्करण के लिए तैयार डेटा प्राप्त करना, क्लाउड स्टोरेज, क्लाउड डेटा विश्लेषण टूल का उपयोग करना। एसएएएस सेवाओं पर विशेष रूप से ध्यान दिया जाता है, समर्पित सर्वर या आभासी मशीनों पर तैनात समाधानों की तुलना में क्लाउड प्रौद्योगिकियों के लाभों का प्रदर्शन किया जाता है।

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

हम आपको पासिंग "स्ट्रीमिंग डेटा का प्रत्यक्ष डाउनलोड" पढ़ने के लिए आमंत्रित करते हैं

10.1। सामान्य वास्तुकला

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

इस तरह के कार्य इंटरनेट कनेक्शन के माध्यम से जुड़े IoT उपकरणों के साथ-साथ ऑनलाइन लॉग विश्लेषण प्रणालियों में काम करने वाले सिस्टम में बहुत आम हैं। हमारी समर्पित सेवा के लिए ऊपर सूचीबद्ध आवश्यकताओं के अलावा, "चीजों की इंटरनेट" की बारीकियों से संबंधित और विश्वसनीय संदेश प्रसंस्करण सुनिश्चित करने के लिए दो और आवश्यकताएं हैं। सबसे पहले, क्लाइंट और सेवा-रिसीवर के बीच बातचीत का प्रोटोकॉल बहुत सरल होना चाहिए, ताकि इसे सीमित कंप्यूटिंग क्षमताओं और बहुत सीमित मेमोरी वाले डिवाइस पर लागू किया जा सके (उदाहरण के लिए, Arduino, Intel Edison, STM32 Discovery, और अन्य "अनुचित" प्लेटफॉर्म, जैसे कि रास्पबेरीपी से पहले)। प्रसंस्करण सेवाओं की संभावित विफलताओं की परवाह किए बिना अगली आवश्यकता विश्वसनीय संदेश वितरण है। यह उच्च विश्वसनीयता की आवश्यकता से अधिक मजबूत आवश्यकता है। वास्तव में, पूरे सिस्टम की समग्र विश्वसनीयता सुनिश्चित करने के लिए, यह आवश्यक है कि इसके सभी घटकों की विश्वसनीयता काफी अधिक हो और एक नए घटक को जोड़ने से विफलताओं की संख्या में उल्लेखनीय वृद्धि न हो। क्लाउड इन्फ्रास्ट्रक्चर में विफलता के अलावा, उपयोगकर्ता द्वारा बनाई गई सेवा में त्रुटि हो सकती है। और फिर भी, उपयोगकर्ता सेवा बहाल होते ही संदेश को संसाधित किया जाना चाहिए। इसके लिए, संदेश प्रवाह सेवा प्राप्त करने वाले को संदेश को संसाधित होने तक या उसके जीवनकाल की समाप्ति तक (यह लगातार संदेश प्रवाह के दौरान मेमोरी अतिप्रवाह को रोकने के लिए आवश्यक है) संदेश को स्टोर करना होगा। इन गुणों वाली सेवा को इवेंट हब कहा जाता है। IoT उपकरणों के लिए विशेष हब (IoT हब) होते हैं, जिनमें कई अन्य गुण होते हैं जो इंटरनेट ऑफ थिंग्स डिवाइस के साथ संयोजन के लिए उपयोग करने के लिए बहुत महत्वपूर्ण हैं (उदाहरण के लिए, एक बिंदु से द्विदिश संचार, अंतर्निहित संदेश मार्ग, डिवाइस का "डिजिटल डबल्स" और एक नंबर। अन्य)। हालांकि, ये सेवाएं अभी भी विशिष्ट हैं, और हम उन पर विस्तार से विचार नहीं करेंगे।

संदेश एकाग्रता की अवधारणा पर आगे बढ़ने से पहले, आइए हम इसे अंतर्निहित विचारों की ओर मोड़ें।

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


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

सेवा के प्रोग्राम कोड में एक चक्र शामिल होता है जो कतार में "सुनता है", प्रत्येक चरण पर अगले संदेश को पुनर्प्राप्त करता है, और यदि कतार में कोई संदेश है, तो इसे निकाला और संसाधित किया जाता है। यदि सेवा संदेश को सफलतापूर्वक संसाधित करती है, तो इसे कतार से हटा दिया जाता है। यदि प्रसंस्करण के दौरान कोई त्रुटि होती है, तो उसे हटा नहीं दिया जाता है और सही कोड के साथ सेवा का नया संस्करण लॉन्च किए जाने पर उसे फिर से संसाधित किया जा सकता है। कतार को एक क्लाइंट (या समान क्लाइंट के एक समूह) और बिल्कुल एक प्रसंस्करण सेवा (हालांकि बाद वाले को सर्वर क्लस्टर या सर्वर फ़ार्म पर स्थित किया जा सकता है) को सिंक्रनाइज़ करने के लिए डिज़ाइन किया गया है। क्लाउड कतारिंग सेवाओं में Azure Storage Queue, Azure Service Bus Queue, और AWS SQS शामिल हैं। वर्चुअल मशीनों पर होस्ट की गई सेवाओं में RabbitMQ, ZeroMQ, MSMQ, IBM MQ, आदि शामिल हैं।

विभिन्न कतार सेवाएँ विभिन्न प्रकार के संदेश वितरण की गारंटी देती हैं:

• कम से कम एक बार संदेश वितरण
• सख्ती से एक बार वितरण;
• आदेश को बनाए रखते हुए संदेश वितरण;
• आदेश बनाए रखने के बिना संदेश वितरण।

कतार एक स्रोत से एक प्रसंस्करण सेवा, यानी वन-टू-वन इंटरैक्शन के लिए संदेशों की विश्वसनीय डिलीवरी प्रदान करती है। लेकिन क्या होगा अगर कई सेवाओं के लिए संदेश वितरण प्रदान करना आवश्यक है? इस मामले में, आपको "विषय" (विषय) (छवि। 10.2) नामक एक सेवा का उपयोग करने की आवश्यकता है।


इस वास्तुकला का एक महत्वपूर्ण तत्व "सदस्यता" है। यह उस अनुभाग में पंजीकृत पथ है जिसके साथ संदेश भेजा जाता है। ग्राहक द्वारा विषय में संदेश प्रकाशित किए जाते हैं और एक सदस्यता के लिए स्थानांतरित कर दिए जाते हैं, जिसमें से उन्हें एक सेवा द्वारा निकाला जाता है और इसके साथ संसाधित किया जाता है। विषय एक-से-कई ग्राहक-सेवा सहभागिता वास्तुकला प्रदान करते हैं। ऐसी सेवाओं के उदाहरणों में Azure Service Bus Topic और AWS SNS शामिल हैं।

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


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

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

• संदेश प्रवाह के लिए पोस्ट करना और सदस्यता लेना
• संदेशों का विश्वसनीय भंडारण;
• तृतीय-पक्ष स्ट्रीमिंग संदेश प्रसंस्करण सेवाओं का अनुप्रयोग।

शारीरिक रूप से, काफ्का एक या अधिक सर्वरों के समूह में चलता है। काफ्का बाहरी ग्राहकों के साथ बातचीत करने के लिए एक एपीआई प्रदान करता है (चित्र। 10.4)।


क्रम में इन एपीआई पर विचार करें।

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

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

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


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


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

वर्गों की अवधारणा का उपयोग करने के निम्नलिखित उद्देश्य हैं।

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

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

अब मैं काफ्का द्वारा गारंटीकृत संदेश वितरण और भंडारण के मुख्य मापदंडों का संक्षेप में वर्णन करूंगा।

• निर्माता द्वारा किसी विशिष्ट विषय पर भेजे गए संदेशों को उस क्रम में सख्ती से जोड़ा जाएगा, जिसमें उन्हें भेजा गया था।
• क्लाइंट उस विषय में संदेश क्रम देखता है जो संदेश सहेजे जाने पर प्राप्त हुआ था। नतीजतन, निर्माता से उपभोक्ता को प्राप्त होने वाले आदेशों में सख्ती से संदेश दिया जाता है।
• विषय का एन-फोल्ड प्रतिकृति प्रदर्शन की हानि के बिना एन - 1 नोड्स की विफलता के लिए विषय की स्थिरता सुनिश्चित करता है।

तो, अपाचे काफ्का सेवा का उपयोग निम्नलिखित मोड में किया जा सकता है।

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

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

10.2। Azure इवेंट हब

एज़्योर इवेंट हब संदेश हब सेवा पर विचार करें। यह PaS मॉडल पर निर्मित एक सेवा है। विभिन्न क्लाइंट समूह Azure Event Hub (चित्र 10.8) के लिए संदेश स्रोत के रूप में कार्य कर सकते हैं। सबसे पहले, यह क्लाउड सेवाओं का एक बहुत बड़ा समूह है जिसके आउटपुट या ट्रिगर्स को सीधे इवेंट हब में संदेश भेजने के लिए कॉन्फ़िगर किया जा सकता है। ये स्ट्रीम एनालिटिक्स जॉब, ईवेंट ग्रिड और सेवाओं का एक महत्वपूर्ण समूह हो सकता है जो ईवेंट हब में लॉग-इन होने वाली घटनाओं को पुनर्निर्देशित करता है (मुख्य रूप से AppService: Api ऐप, वेब ऐप, मोबाइल ऐप और फ़ंक्शन ऐप का उपयोग करके बनाया गया है)।


हब को दिए गए संदेशों को सीधे कैप्चर किया जा सकता है और ब्लॉब स्टोरेज या डेटा लेक स्टोर में संग्रहीत किया जा सकता है।

स्रोतों का अगला समूह बाहरी सॉफ़्टवेयर क्लाइंट या डिवाइस है जिसके लिए कोई Azure Event Hub SDK नहीं है और जिसे सीधे Azure सेवाओं के साथ एकीकृत नहीं किया जा सकता है। इन ग्राहकों में मुख्य रूप से IoT डिवाइस शामिल हैं। वे HTTPS या AMQP के माध्यम से इवेंट हब को संदेश भेज सकते हैं। इन उपकरणों को कैसे जोड़ा जाए, इस पर विचार करना हमारी पुस्तक के दायरे से बाहर है।

अंत में, सॉफ़्टवेयर क्लाइंट जो संदेश उत्पन्न करते हैं और एज़्योर इवेंट हब एसडीके का उपयोग करके उन्हें इवेंट हब में भेजते हैं। इस समूह में Azure PowerShell और Azure CLI शामिल हैं।
इवेंट हब, स्ट्रीम एनालिटिक्स जॉब या इवेंट ग्रिड एकीकरण सेवा से संदेश प्राप्तकर्ताओं (उपभोक्ताओं - "उपभोक्ताओं") का उपयोग किया जा सकता है। इसके अलावा, एज़्योर इवेंट हब एसडीके का उपयोग करके सॉफ़्टवेयर क्लाइंट द्वारा संदेश प्राप्त करना संभव है। उपभोक्ता AMQP 1.0 प्रोटोकॉल का उपयोग करके ईवेंट हब से जुड़ते हैं।

एज़्योर इवेंट हब की बुनियादी अवधारणाओं पर विचार करें कि इसे कैसे उपयोग करें और इसे कॉन्फ़िगर करने के लिए समझने की आवश्यकता है। किसी भी स्रोत (प्रलेखन में प्रकाशक भी कहा जाता है) जो हब को संदेश भेजता है उसे HTTPS या AMQP 1.0 प्रोटोकॉल का उपयोग करना चाहिए। एक प्रोटोकॉल का विकल्प क्लाइंट के प्रकार, संचार नेटवर्क और संदेश दर के लिए आवश्यकताओं द्वारा निर्धारित किया जाता है। AMQP को दो द्विदिश टीसीपी सॉकेट के बीच एक स्थायी कनेक्शन की आवश्यकता होती है। यह TLS ट्रांसपोर्ट लेयर एन्क्रिप्शन प्रोटोकॉल या SSL / TLS का उपयोग करके सुरक्षित है। , , AMQP , HTTPS, . HTTPS.

, SAS (Shared Access Signature) tokens. SAS- SAS . SAS-, ( ).

256 . , .

, Event Hub. , , , -. EventHub (partitions). EventHub — , « — » (FIFO) (. 10.9).


— Event Hub. Event Hub 2 32 , Event Hub. , .

( ) , ( , — . ), (retention period), . . . , Azure Event Hub (offset). — , , , , . . Azure Event Hub SDK , , . -, .


, , , , . Azure Event Hub SDK , . , Storage Account. Azure, Event Hub, .

Event Hub (partition key), . — . , ( ) . , (round robin).

. , (consumer group) (. 10.11). . (view) ( ) , , . , . — 20, , .

. , . , (throughput unit). :

• — 1 M 1000 ( , );
• — 2 M .

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


संदेश सांद्रता तार्किक रूप से नेमस्पेस (नेमस्पेस) (छवि 10.12) में बांटा गया है।



»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

फेरीवालों के लिए कूपन पर 20% की छूट - BigData