वास्तव में एक बार बिल्कुल वैसा ही नहीं है: लेख विश्लेषण

परिचय

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

चलिए शुरू करते हैं।

के विश्लेषण

यह सब बहुत अच्छी तरह से शुरू होता है:

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

अर्थात्, डेटा प्रोसेसिंग अत्यंत महत्वपूर्ण है, आदि, और चर्चा के तहत विषय बिल्कुल एक बार है। इसकी चर्चा करते हैं।

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

वास्तव में, यह समझना बहुत महत्वपूर्ण है कि यह क्या है। ऐसा करने के लिए, उचित तर्क से पहले सही परिभाषा देना अच्छा होगा। और मैं कौन हूँ इस तरह के लानत ध्वनि सलाह देने के लिए?

मैं चर्चा करता हूँ कि कैसे "बिल्कुल-एक बार" प्रसंस्करण शब्दार्थ कई लोकप्रिय एसपीआई में भिन्न होते हैं और क्यों "बिल्कुल-एक बार" बेहतर ढंग से-एक बार वर्णित किया जा सकता है

निस्संदेह, नए शब्दों का आविष्कार एक महत्वपूर्ण कार्य है। मैं खुद इस बात को प्यार करता हूं। बस इसके लिए औचित्य की जरूरत है। चलो उसे खोजने की कोशिश करते हैं।

मैं स्पष्ट चीजों का वर्णन नहीं करूँगा जैसा कि निर्देशित प्रसंस्करण ग्राफ़ और इतने पर। पाठक मूल लेख को स्वयं पढ़ सकते हैं। इसके अलावा, इन विवरणों के विश्लेषण के लिए अप्रासंगिक हैं। मैं केवल एक तस्वीर दूंगा:

अगला, शब्दार्थ का विवरण है:

• सबसे अधिक-एक बार, अर्थात्। एक बार से अधिक नहीं। स्पष्ट स्पष्टता के साथ, इस तरह के व्यवहार की सीमा-स्तरीय परिदृश्यों जैसे कि क्रैश, नेटवर्क कनेक्टिविटी के विघटन, और बहुत कुछ की गारंटी देना बेहद मुश्किल है। लेकिन लेखक के लिए सब कुछ सरल है:

• कम से कम-एक बार, अर्थात्। कम से कम एक बार। योजना अधिक जटिल है। और रेक अधिक एकत्र किया जा सकता है:

• वास्तव में एक बार। वास्तव में एक बार क्या है?

विभिन्न विफलताओं की स्थिति में भी, सभी ऑपरेटरों द्वारा स्ट्रीम एप्लिकेशन में "ठीक एक बार" संसाधित होने की गारंटी दी जाती है।

यानी प्रसंस्करण की गारंटी बिल्कुल एक बार है जब प्रसंस्करण "ठीक एक बार" हुआ है।

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

निम्नलिखित इस तरह के शब्दार्थ को लागू करने का वर्णन है। और यहाँ मैं और अधिक विस्तार से जानना चाहूंगा।

दो लोकप्रिय तंत्र आमतौर पर "बिल्कुल-एक बार" प्रसंस्करण शब्दार्थ को प्राप्त करने के लिए उपयोग किए जाते हैं।

1. वितरित स्नैपशॉट / राज्य चेकपॉइंटिंग
2. कम से कम-एक बार ईवेंट डिलीवरी प्लस संदेश समर्पण

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

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

हालांकि, हम सबसे स्वादिष्ट की ओर मुड़ते हैं:

क्या वास्तव में एक बार वास्तव में एक बार है?

अब आइए reexamine करें कि "बिल्कुल एक बार" प्रसंस्करण शब्दार्थ वास्तव में अंतिम उपयोगकर्ता को क्या गारंटी देता है। "बिल्कुल-एक बार" लेबल यह वर्णन करने में भ्रामक है कि वास्तव में एक बार क्या किया जाता है।

यह कहा जाता है कि इस अवधारणा पर पुनर्विचार करने का समय आ गया है, जैसा कि कुछ विसंगतियां हैं।

कुछ लोग सोच सकते हैं कि "बिल्कुल-एक बार" ईवेंट प्रसंस्करण की गारंटी का वर्णन करता है जिसमें स्ट्रीम में प्रत्येक ईवेंट को केवल एक बार संसाधित किया जाता है। वास्तव में, कोई SPE नहीं है जो बिल्कुल-एक बार प्रसंस्करण की गारंटी दे सकता है। यह सुनिश्चित करने के लिए कि प्रत्येक ऑपरेटर में उपयोगकर्ता-परिभाषित तर्क केवल एक बार निष्पादित होता है, जब मनमाने ढंग से विफलताओं का सामना करना असंभव है, क्योंकि उपयोगकर्ता कोड का आंशिक निष्पादन कभी-कभी होने वाली संभावना है।

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

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

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

लेख में उदाहरण कोड स्पष्ट रूप से कैसे संचालकों को लिखने की समझ की कमी दर्शाता है:

Map (Event event) { Print "Event ID: " + event.getId() Return event } 

पाठक को स्वतंत्र रूप से कोड को फिर से लिखने के लिए आमंत्रित किया जाता है ताकि लेख के लेखक की गलतियों को न दोहराएं।

जब वे "ठीक-ठीक एक बार" शब्दार्थ प्रसंस्करण का दावा करते हैं, तो SPEs की क्या गारंटी है? यदि उपयोगकर्ता तर्क को एक बार ठीक से निष्पादित करने की गारंटी नहीं दी जा सकती है, तो क्या एक बार निष्पादित किया जाता है? जब एसपीएस "बिल्कुल-एक बार" शब्दार्थ प्रसंस्करण का दावा करते हैं, तो वे वास्तव में क्या कह रहे हैं कि वे गारंटी दे सकते हैं कि एसपीई द्वारा प्रबंधित अपडेट केवल एक टिकाऊ बैकएंड स्टोर के लिए एक बार प्रतिबद्ध हैं।

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

अधिक जानकारी के लिए, आप मेरे लेख को संक्षेप में पढ़ सकते हैं: वास्तविक समय में एक बार सख्ती से प्रतिस्पर्धी डेटा प्रसंस्करण ।

दूसरे शब्दों में, किसी घटना का प्रसंस्करण एक से अधिक बार हो सकता है लेकिन उस प्रसंस्करण का प्रभाव केवल टिकाऊ बैकेंड स्टोर में एक बार ही दिखाई देता है।

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

यहाँ Streamlio में, हमने फैसला किया है कि इन प्रसंस्करण शब्दार्थों का वर्णन करने के लिए प्रभावी रूप से एक बार सबसे अच्छा शब्द है।

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

निष्कर्ष

अमूर्तता के सार की गलतफहमी मौजूदा अवधारणाओं के मूल अर्थ के विरूपण और खरोंच से नए शब्दों के निर्माण की ओर ले जाती है।

[१] वास्तव में एक बार बिलकुल नहीं है ।
[२] विषम वास्तविक समय प्रतिस्पर्धी डेटा प्रसंस्करण एक बार सख्ती से ।