प्रत्यक्ष दृष्टिकोण (कोडी) here के निर्माता द्वारा एक महान, व्यापक ब्लॉग पोस्ट है।
सामान्य तौर पर, काफ्का वितरण अर्थ विज्ञान खंड को पढ़ने, अंतिम भाग का कहना है:
तो प्रभावी ढंग से काफ्का की गारंटी देता है कम से कम एक बार डिफ़ॉल्ट रूप से वितरण और की अनुमति देता है ज्यादा से ज्यादा वितरण एक बार को अक्षम करके लागू करने के लिए उपयोगकर्ता संदेशों के एक बैच को संसाधित करने से पहले निर्माता पर पुनः प्रयास करता है और इसके ऑफसेट को करता है। वास्तव में-एक बार डिलीवरी के लिए गंतव्य स्टोरेज सिस्टम के साथ सहयोग की आवश्यकता होती है लेकिन काफ्का ऑफसेट प्रदान करता है जो इस सीधे-आगे को कार्यान्वित करता है।
यह मूलतः इसका मतलब "हम आप कम से कम एक बार बॉक्स से बाहर, दे अगर आप ठीक एक बार चाहते हैं, कि तुम पर है"। इसके अलावा, की गारंटी के बारे में ब्लॉग पोस्ट वार्ता "ठीक एक बार" अर्थ विज्ञान आप स्पार्क से दोनों दृष्टिकोण (प्रत्यक्ष और रिसीवर आधारित, जोर मेरा) के साथ मिल:
दूसरा, समझते हैं कि स्पार्क वास्तव में एक बार की गारंटी नहीं देता उत्पादन कार्यों के लिए अर्थशास्त्र। जब स्पार्क स्ट्रीमिंग गाइड बिल्कुल एक बार के बारे में बात करता है, तो यह केवल एक आरडीडी में एक दिए गए आइटम को एक बार गणना की गई मान में शामिल किया जा रहा है, पूरी तरह कार्यात्मक अर्थ में। किसी भी साइड-इफेक्टिंग आउटपुट ऑपरेशंस (यानी परिणाम को सहेजने के लिए foreachRDD में जो कुछ भी आप करते हैं) दोहराया जा सकता है, क्योंकि का कोई भी चरण विफल हो सकता है और पुनः प्रयास किया जा सकता है।
इसके अलावा, यह है कि क्या स्पार्क प्रलेखन रिसीवर आधारित प्रसंस्करण के बारे में कहते हैं:
पहले दृष्टिकोण (रिसीवर आधारित) काफ्का के उच्च स्तर API का उपयोग करता Zookeeper में सेवन ऑफसेट स्टोर करने के लिए। यह परंपरागत रूप से काफका से डेटा का उपभोग करने का तरीका है। हालांकि यह दृष्टिकोण (आगे के लॉग लिखने के संयोजन में) शून्य डेटा हानि सुनिश्चित कर सकता है (यानी।कम से कम एक बार अर्थशास्त्र), छोटा मौका कुछ विफलताओं के तहत कुछ रिकॉर्ड दो बार उपभोग हो सकता है।
यह मूलतः इसका मतलब है कि आप स्पार्क के साथ रिसीवर आधारित धारा उपयोग कर रहे हैं तो आप अभी भी मामले उत्पादन परिवर्तन में विफल रहता है में डेटा का डुप्लिकेट हो सकता है, यह कम से कम एक बार है।
मेरी परियोजना में मैं प्रत्यक्ष स्ट्रीम दृष्टिकोण का उपयोग करता हूं, जहां डिलीवरी सेमेन्टिक्स पर निर्भर करता है कि आप उन्हें कैसे प्रबंधित करते हैं। इसका अर्थ यह है कि यदि आप वास्तव में एक बार अर्थशास्त्र सुनिश्चित करना चाहते हैं, तो आप ऑफसेट को लेनदेन में फैशन के साथ स्टोर कर सकते हैं, अगर कोई अन्य विफलताओं में विफल रहता है।
मैं ब्लॉग पोस्ट (उपरोक्त लिंक) और Delivery Semantics in the Kafka documentation page पढ़ने की अनुशंसा करता हूं। निष्कर्ष निकालने के लिए, मैं निश्चित रूप से आपको सीधे स्ट्रीम दृष्टिकोण देखने की सलाह देता हूं।