अस्वीकरण: मैं अपाचे फ्लिंक कमिटर और पीएमसी सदस्य हूं और केवल स्टॉर्म के उच्च स्तरीय डिज़ाइन से परिचित हूं, न कि इसके आंतरिक।
अपाचे फ्लिंक एकीकृत स्ट्रीम और बैच प्रोसेसिंग के लिए एक ढांचा है। Flink के रनटाइम समानांतर कार्यों के बीच पाइपलाइन डेटा स्थानान्तरण के कारण दोनों डोमेन का मूल रूप से समर्थन करता है जिसमें पाइपलाइन शफल शामिल हैं। रिकॉर्ड्स को कार्यों को प्राप्त करने के लिए तत्काल कार्यों को भेज दिया जाता है (नेटवर्क हस्तांतरण के लिए बफर एकत्र करने के बाद)। डेटा स्थानांतरण को अवरुद्ध करके बैच नौकरियों को वैकल्पिक रूप से निष्पादित किया जा सकता है।
अपाचे स्पार्क एक ढांचा है जो बैच और स्ट्रीम प्रोसेसिंग का भी समर्थन करता है। फ्लिंक की बैच एपीआई काफी समान दिखती है और समान उपयोग के मामलों को स्पार्क के रूप में संबोधित करती है लेकिन आंतरिक में अलग होती है। स्ट्रीमिंग के लिए, दोनों सिस्टम बहुत अलग दृष्टिकोण (मिनी-बैचों बनाम स्ट्रीमिंग) का पालन करते हैं जो उन्हें विभिन्न प्रकार के अनुप्रयोगों के लिए उपयुक्त बनाता है। मैं कहूंगा कि स्पार्क और फ्लिंक की तुलना वैध और उपयोगी है, हालांकि स्पार्क फ्लिंक के लिए सबसे समान स्ट्रीम प्रसंस्करण इंजन नहीं है।
मूल प्रश्न पर आ रहा है, अपाचे स्टॉर्म बैच क्षमताओं के बिना डेटा स्ट्रीम प्रोसेसर है। वास्तव में, फ्लिंक का पाइपलाइन इंजन आंतरिक रूप से तूफान के समान दिखता है, यानी, फ्लिंक के समांतर कार्यों के इंटरफेस तूफान के बोल्ट के समान होते हैं। तूफान और झुर्रियों में आम बात है कि वे पाइपलाइन डेटा स्थानांतरण द्वारा कम विलंबता धारा प्रसंस्करण का लक्ष्य रखते हैं। हालांकि, फ्लिंक तूफान की तुलना में अधिक उच्च स्तरीय एपीआई प्रदान करता है। एक या अधिक पाठकों और कलेक्टरों के साथ बोल्ट की कार्यक्षमता को लागू करने के बजाय, फ्लिंक का डेटास्ट्रीम एपीआई मानचित्र, ग्रुपबी, विंडो, और जॉइन जैसे कार्यों को प्रदान करता है। तूफान का उपयोग करते समय इस कार्यक्षमता को मैन्युअल रूप से कार्यान्वित किया जाना चाहिए। एक और अंतर अर्थशास्त्र प्रसंस्करण कर रहे हैं। तूफान कम से कम एक बार प्रोसेसिंग की गारंटी देता है जबकि फ्लिंक बिल्कुल एक बार प्रदान करता है। इन प्रसंस्करण गारंटी देने वाले कार्यान्वयन काफी अलग हैं। जबकि तूफान रिकॉर्ड-स्तरीय स्वीकृति का उपयोग करता है, फ्लिंक चांडी-लैमपोर्ट एल्गोरिदम का एक संस्करण उपयोग करता है। संक्षेप में, डेटा स्रोत समय-समय पर डेटा स्ट्रीम में मार्कर इंजेक्ट करते हैं। जब भी एक ऑपरेटर ऐसे मार्कर प्राप्त करता है, तो यह अपनी आंतरिक स्थिति की जांच करता है। जब सभी डेटा सिंक द्वारा मार्कर प्राप्त किया गया था, तो मार्कर (और सभी रिकॉर्ड जो पहले संसाधित किए गए हैं) प्रतिबद्ध हैं। विफलता के मामले में, सभी स्रोत ऑपरेटर अपने राज्य में रीसेट करते हैं जब उन्होंने अंतिम प्रतिबद्ध मार्कर और प्रसंस्करण जारी रखा। यह मार्कर-चेकपॉइंट दृष्टिकोण तूफान के रिकॉर्ड-स्तरीय स्वीकृति से अधिक हल्का है। यह slide set और संबंधित talk फ़्लेंक की स्ट्रीमिंग प्रोसेसिंग दृष्टिकोण पर चर्चा करता है जिसमें गलती सहनशीलता, चेकपॉइंटिंग और राज्य हैंडलिंग शामिल हैं।
तूफान भी एक बार, उच्च स्तरीय एपीआई प्रदान करता है जिसे ट्राइडेंट कहा जाता है। हालांकि, ट्रिडेंट मिनी बैचों पर आधारित है और इसलिए फ्लिंक की तुलना में स्पार्क के समान है।
फ्लिंक की समायोज्य विलंबता इस प्रकार से संदर्भित करती है कि फ्लिंक एक कार्य से दूसरे कार्य में रिकॉर्ड भेजता है। मैंने पहले कहा था कि फ्लिंक पाइपलाइन डेटा ट्रांसफर का उपयोग करता है और जैसे ही उन्हें उत्पादित किया जाता है। दक्षता के लिए, ये रिकॉर्ड एक बफर में एकत्र किए जाते हैं जो नेटवर्क पर भेजे जाने पर एक बार पूर्ण हो जाता है या एक निश्चित समय सीमा पूरी हो जाती है। यह थ्रेसहोल्ड रिकॉर्ड्स की विलम्ब को नियंत्रित करता है क्योंकि यह अधिकतम कार्य निर्दिष्ट करता है कि एक रिकॉर्ड बफर में अगले कार्य में भेजे बिना भेजेगा। हालांकि, इसका उपयोग किसी प्रोग्राम को छोड़ने के लिए रिकॉर्ड करने के समय के बारे में कठिन गारंटी देने के लिए नहीं किया जा सकता है क्योंकि यह कार्यों के भीतर प्रसंस्करण समय और अन्य चीज़ों के बीच नेटवर्क हस्तांतरण की संख्या पर भी निर्भर करता है। इसके साथ ही निम्न तरीकों से भी
Flink तूफान पर सुधार:
स्रोत
2015-06-08 21:08:56
ध्यान दें कि अपाचे * स्पार्क * (लिंक किए गए प्रश्न का ध्यान) अपाचे * तूफान * (यह प्रश्न यहां) जैसा नहीं है - इसलिए, नहीं, यह किसी भी तरह से डुप्लिकेट नहीं है। – fnl