पारंपरिक संदेश दलाल और स्ट्रीमिंग डेटा


14

कफका साइट के अनुसार :

" काफा का उपयोग वास्तविक समय डेटा पाइपलाइन और स्ट्रीमिंग ऐप के निर्माण के लिए किया जाता है। "

इंटरनेट को दूर-दूर तक खोजते हुए, मैंने " स्ट्रीम डेटा " क्या है, इसकी आम तौर पर स्वीकृत परिभाषा निम्नलिखित है:

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

अब, अगर मैंने ऊपर जो कुछ भी कहा है वह गलत है, अधूरा है या पूरी तरह से गलत है, कृपया मुझे सुधार कर शुरू करें! यह मानकर कि मैं कमोबेश ट्रैक पर हूं, तब ...

अब जब मैं समझता हूं कि "स्ट्रीमिंग डेटा" क्या है, तो मैं समझता हूं कि काफ्का और काइनिस का क्या मतलब है जब वे स्ट्रीमिंग डेटा के साथ अनुप्रयोगों के लिए प्रसंस्करण / ब्रोकरिंग मिडलवेयर के रूप में खुद को बिल करते हैं। लेकिन इसने मेरे हितों को धक्का दिया है: पारंपरिक संदेश दलालों की तरह गैर-स्ट्रीमिंग डेटा के लिए काफ्का या काइनिस की तरह "स्ट्रीम मिडिलवेयर" का उपयोग किया जा सकता है? और इसके विपरीत: क्या RabbitMQ, ActiveMQ, Apollo, आदि जैसे पारंपरिक MQ को स्ट्रीमिंग डेटा के लिए उपयोग किया जाना चाहिए?

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

  • केस # 1: संदेश एक फिल्म के प्रत्येक फ्रेम हैं; यह फ्रेम डेटा और कुछ सहायक मेटाडेटा वाले वीडियो फ्रेम प्रति एक JSON मैसेंजर है
  • केस # 2: संदेश समय-श्रृंखला के डेटा हैं, शायद समय के कार्य के रूप में किसी के दिल की धड़कन। इसलिए संदेश # 1 को t = 1 पर मेरे दिल की धड़कन का प्रतिनिधित्व करने के लिए भेजा जाता है, संदेश # 2 में t = 2, आदि पर मेरे दिल की धड़कन होती है।
  • केस # 3: डेटा समय के अनुसार या किसी भी "डेटा स्ट्रीम" के हिस्से के रूप में पूरी तरह से असमान और गैर-संबंधित है। शायद ऑडिट / सुरक्षा ईवेंट जो सैकड़ों उपयोगकर्ताओं के रूप में निकाल दिए जाते हैं, बटन क्लिक करने और कार्रवाई करने वाले एप्लिकेशन को नेविगेट करते हैं

कफ़्का / किनसिस कैसे बिल किया जाता है और "स्ट्रीमिंग डेटा" की मेरी समझ के आधार पर, वे मामलों # 1 (सन्निहित वीडियो डेटा) और # 2 (सन्निहित समय-श्रृंखला डेटा) के लिए स्पष्ट उम्मीदवार प्रतीत होते हैं। हालाँकि मुझे कोई कारण नहीं दिखता है कि RabbitMQ जैसे पारंपरिक संदेश ब्रोकर इन दोनों इनपुटों को कुशलता से संभाल नहीं पाए

और केस # 3 के साथ, हमें केवल एक ईवेंट प्रदान किया गया है जो घटित हुआ है और हमें उस ईवेंट पर प्रतिक्रिया देने की आवश्यकता है। तो मेरे लिए यह RabbitMQ जैसे पारंपरिक ब्रोकर की जरूरत है। लेकिन वहाँ भी कोई कारण नहीं है कि आप काफ्का या किनेसिस घटना डेटा के प्रसंस्करण को संभाल नहीं सकते थे।

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

इसलिए मैं पूछता हूं: डेटा के बारे में कौन से कारक (या अन्यथा) स्ट्रीम प्रोसेसर या संदेश ब्रोकर के बीच निर्णय लेने में मदद करते हैं, क्योंकि दोनों स्ट्रीमिंग डेटा को संभाल सकते हैं, और दोनों (गैर-स्ट्रीमिंग) संदेश डेटा को संभाल सकते हैं?

जवाबों:


6

काफ्का परमाणु संदेशों के आदेशित लॉग में डील करता है। आप इसे pub/subसंदेश दलालों के मोड की तरह देख सकते हैं , लेकिन सख्त आदेश और अतीत में किसी भी बिंदु पर संदेशों की धारा के चारों ओर फिर से खेलना या तलाश करने की क्षमता के साथ जो अभी भी डिस्क पर बनाए रखा जा रहा है (जो हमेशा के लिए हो सकता है)।

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

बैच प्रोसेसिंग के विपरीत, आप संदेशों के विशाल संग्रह ही नहीं, एकल संदेशों में भी रुचि रखते हैं। (हालांकि यह HDF पर Parquet फ़ाइलों में Kafka संदेशों को संग्रहीत करने और उन्हें हाइव तालिकाओं के रूप में क्वेरी करने के लिए असामान्य नहीं है)।

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

नेटफ्लिक्स एक आंतरिक प्रणाली में फ़्रेम को स्थानांतरित करने के लिए काफ्का का उपयोग कर सकता है जो प्रति घंटे वीडियो के टेराबाइट्स को ट्रांसकोड करता है और इसे डिस्क पर बचाता है, लेकिन उन्हें आपकी स्क्रीन पर शिप करने के लिए नहीं।

केस 2 : बिल्कुल। हम अपने नियोक्ता पर इस तरह से काफ्का का उपयोग करते हैं।

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


1
धन्यवाद @closeparen (+1) - मुझे एक बड़े अपवाद के साथ आपके कहने का सबसे ज्यादा मिलता है। वाक्य के साथ आपके पैराग्राफ की शुरुआत " कफ़्का फ्लेवर ऑफ़ स्ट्रीमिंग का विरोध करती है ... ", मुझे लगता है कि मैं "काफ्का" शब्द के अधिकांश उदाहरणों को "रैबिटमक्यू" से बदल सकता हूं, और वाक्य सही होगा। RabMMQ के लिए: निर्माता एक संदेश भेज सकते हैं और एक उपभोक्ता इसे नीचे खींचेगा और इसके घंटों / दिनों बाद प्रक्रिया करेगा। उपभोक्ता अपनी पसंद के अनुसार कभी भी एक कतार में संलग्न हो सकते हैं, और इसलिए RabbitMQ के लिए, समय में विभिन्न बिंदुओं पर कई अलग-अलग प्राप्तकर्ता हो सकते हैं।
Smeeb

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

1
इन-मेमोरी कतार डेटा संरचना के वितरित संस्करण की तरह RabbitMQ के बारे में सोचें। एक बार जब आप एक कतार से कुछ पॉप करते हैं, तो यह कतार पर नहीं होता है। निश्चित रूप से, आपके पास एक टोपोलॉजी हो सकती है जहां इसे अन्य उपभोक्ताओं के लाभ के लिए अन्य कतारों में दोहराया गया है, लेकिन आप आम तौर पर यह नहीं कह पाएंगे "मुझे वह संदेश दें जो मैंने 500 संदेशों से पहले संभाला था" या "कॉपी के रूप में कतार बी शुरू करें" कतार ए जहां कल से कतार ए थी। "
करीब

2
एक काफ्का आधारित प्रणाली क्षमाशील है। यदि आपको यह पसंद नहीं है कि आपका प्रोग्राम कैसे व्यवहार करता है, तो आप एक कोड परिवर्तन को धक्का दे सकते हैं और फिर इसके इनपुट को रिवाइंड कर सकते हैं। आप उत्पादकों को प्रभावित किए बिना एक RabbitMQ उपभोक्ता को रोक सकते हैं, लेकिन आप अतीत को फिर से नहीं देख पाएंगे।
closeparen

1
अहह: लाइटबल्ब: धन्यवाद (सभी 3 के लिए +1)! तो यह निश्चित रूप से काफ्का के लिए एक सम्मोहक मामला है: अतीत को फिर से समझने की क्षमता। मुझे लगता है कि वहाँ कुछ ऊपरी सीमा या सही पर चल रहा है? वरना काफ्का की याद हमेशा ऊपर चढ़ती रहती। यहां तक ​​कि अगर डेटा डिस्क पर फैल जाता है, तो फाइलें जहां विषय डेटा संग्रहीत है, डिस्क को बहुत जल्दी से भर देगा, हां?
18-30 को स्माइब

6

काफ्का / किनेसिस को एक धारा के रूप में तैयार किया गया है। संदेशों की तुलना में एक स्ट्रीम में अलग-अलग गुण होते हैं।

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

आम तौर पर, ऑफ़लाइन स्ट्रीम प्रसंस्करण के लिए काफ्का का उपयोग करें, वास्तविक समय क्लाइंट-सर्वर संदेशों के लिए संदेश कतारों का उपयोग करें।

उदाहरण उपयोग के मामले पिवट से :

काफ्का: वेबसाइट एक्टिविटी ट्रैकिंग, मेट्रिक्स, लॉग एग्रीगेशन, स्ट्रीम प्रोसेसिंग, इवेंट सोर्सिंग और कमिट लॉग

RabbitMQ: सामान्य प्रयोजन मैसेजिंग ..., अक्सर वेब सर्वर को संसाधन-भारी प्रक्रियाओं को करने के लिए मजबूर करने के बजाय जल्दी से अनुरोधों का जवाब देने की अनुमति देता था, जबकि उपयोगकर्ता परिणाम का इंतजार करता है। जब आपको मौजूदा प्रोटोकॉल जैसे AMQP 0-9-1, STOMP, MQTT, AMQP 1.0 का उपयोग करना हो

यह कभी-कभी दोनों का उपयोग करने के लिए उपयोगी हो सकता है! उदाहरण के लिए Use Case # 2 में, यदि यह एक गति-निर्माता के डेटा की एक धारा थी, तो मुझे एक RabbitMQ संदेश कतार (MQTT जैसे शांत प्रोटोकॉल का उपयोग करते हुए) में गति-निर्माता संचारित दिल की धड़कन का डेटा होगा, जहां इसे तुरंत संसाधित किया जाता है। देखें कि क्या स्रोत का दिल अभी भी धड़क रहा है। यह एक डैशबोर्ड और एक आपातकालीन प्रतिक्रिया प्रणाली को शक्ति प्रदान कर सकता है। संदेश पंक्ति समय श्रृंखला के डेटा को काफ्का में भी जमा करेगी ताकि हम समय के साथ दिल की धड़कन के आंकड़ों का विश्लेषण कर सकें। उदाहरण के लिए, हम हृदय की धड़कन की धारा को ध्यान में रखते हुए हृदय रोग का पता लगाने के लिए एक एल्गोरिथ्म को लागू कर सकते हैं।


1
धन्यवाद @Samuel (+1) - यह एक अद्भुत उत्तर है और चीजों को संदर्भ में थोड़ा बेहतर बनाने में मदद करता है। मेरे पास वास्तव में आपके लिए कुछ फॉलोअप प्रश्न हैं (यदि आप बुरा नहीं मानते हैं), लेकिन वे सभी एक प्रारंभिक स्पष्टीकरण पर टिका / आकस्मिक हैं, जिसकी मुझे आवश्यकता है: जब आप कहते हैं, " आप फ़ंक्शन को स्ट्रीम में लागू कर सकते हैं। आप एक स्ट्रीम को बदल सकते हैं। वास्तव में इसका उपभोग किए बिना ... ", क्या कफ़्का पर किए गए वे कार्य / परिवर्तन हैं , या क्या उन्हें पहले कार्यों / परिवर्तनों के माध्यम से संसाधित होने से पहले भस्म होने की आवश्यकता है?
मुस्कराहट

1
मतलब, आपके पास है KafkaProducer, Kafkaऔर KafkaConsumer। मान लें कि KafkaProducerएक जावा ऐप के अंदर रहता है, और वह KafkaConsumerकुछ रूबी ऐप / बैकएंड पर चल रहा है। KafkaProducerकफका Message1को भेजता है जिसे बदलने की जरूरत है Function1Function1कोड कहाँ रहता है? काफ्का (उचित) या KafkaConsumer(रूबी ऐप के) अंदर ?
मुस्कराहट

2
आप कफका में ही फंक्शंस निष्पादित नहीं कर सकते हैं और न ही कोई प्रोसेसिंग कर सकते हैं। अपाचे स्पार्क स्ट्रीमिंग और अपाचे स्टॉर्म दो वितरित स्ट्रीम प्रोसेसिंग फ्रेमवर्क हैं जो काफ्का से उपभोग कर सकते हैं। वे काफ्का के बाहर दौड़ते हैं और उससे जुड़ते हैं जैसे कि वह एक डेटाबेस था। फ्रेमवर्क उपयोगी कार्यों जैसे विभाजन, एकत्रीकरण, विंडोिंग आदि को उजागर करता है। आप अपने रूबी उपभोक्ता में बुनियादी कार्यों को लागू कर सकते हैं, लेकिन मैं किसी एक फ्रेमवर्क की अत्यधिक अनुशंसा करूंगा। spark.apache.org/streaming storm.apache.org/releases/2.0.0-SNAPSHOT/Trident-tutorial.html
सैमुअल

1
ठीक है, धन्यवाद और +1 फिर से - अगर वह कफका धाराओं पर ही प्रसंस्करण कर सकता है तो यह बहुत ही भयानक होता। तो शैतान के वकील की भूमिका निभाने के लिए, क्या आप सिर्फ एक RabbitMQ उपभोक्ता को एक कतार से संदेश नीचे नहीं ला सकते हैं, उन्हें टाइमस्टैम्प (या वास्तव में कोई अन्य मानदंड / गुण) के आधार पर एकत्र कर सकते हैं, और एक ही विंडो का प्रदर्शन कर सकते हैं और डेटा को कार्य में बदल सकते हैं: स्पार्क स्ट्रीमिंग या तूफान प्रदान करते हैं?
Smeeb

1
हां मुझे लगता है कि आप RabbitMQ के साथ ऐसा कर सकते हैं क्योंकि RabbitMQ के पास मैसेज ऑर्डर के बारे में गारंटी है। आप इसे हर संदेश कतार के साथ नहीं कर सकते हैं । और इसका निर्माण जटिल होगा। उदाहरण के लिए, अगर आपका RabbitMQ उपभोक्ता दुर्घटनाग्रस्त हो रहा है तो क्या होगा? काफ्का के साथ, आप इस बात पर नज़र रख सकते हैं कि आपके द्वारा संसाधित की गई स्ट्रीम में कहाँ है, इसलिए आप अपने उपभोक्ता को आपके द्वारा छोड़े गए बिंदु पर शुरू कर सकते हैं
सैमुअल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.