7.6 रियल-टाइम और स्ट्रीमिंग डेटा

अवलोकन और प्रेरणा

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

बड़ी टीमों के लिए, स्ट्रीमिंग उसी पल सामने आती है जब विलंब व्यवसाय के लिए मायने रखने लगता है। कोई धोखाधड़ी-फ़ैसला जो एक घंटे देर से आता है बेकार है। कोई व्यक्तिगतकरण-संकेत जो कल आता है कुछ भी व्यक्तिगत नहीं बनाता। कोई परिचालन-डैशबोर्ड जो एक शिफ़्ट से वास्तविकता के पीछे रहता है उसे देखने वालों को भटकाता है। अध्याय 7.2 (डेटा इंजीनियरिंग) तर्क देता है कि आपको डिफ़ॉल्ट रूप से बैच चुनना चाहिए और स्ट्रीमिंग तक सिर्फ़ तभी पहुँचना चाहिए जब विलंब वाक़ई फल दे, और यह अध्याय आपको बाक़ी रास्ते ले जाता है: जब रियल टाइम अपनी लागत कमाता है, और अपने परिचालन-बजट में आग लगाए बिना इसे कैसे बनाया जाए। स्ट्रीमिंग अध्याय 3.12 (इवेंट-ड्रिवन आर्किटेक्चर और मैसेजिंग) के इवेंट-ड्रिवन मैसेजिंग पैटर्न, अध्याय 3.4 (डेटा आर्किटेक्चर और स्टोरेज) के स्टोरेज-चुनावों, और अध्याय 9.2 (ऑब्ज़र्वेबिलिटी और टेलीमेट्री) के टेलीमेट्री-अभ्यासों के क़रीब बैठती है।

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

मुख्य सिद्धांत

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

सिफ़ारिशें

इसे बनाने से पहले रियल टाइम उचित ठहराएँ

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

प्रोसेसिंग-समय के बजाय इवेंट-समय के इर्द-गिर्द डिज़ाइन करें

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

परिमित जवाब पाने के लिए विंडो और वॉटरमार्क इस्तेमाल करें

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

सिंक को इडेम्पोटेंट बनाएँ और असल-में-एक-बार को प्राथमिकता दें

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

स्टेटफ़ुल प्रोसेसिंग को चेकपॉइंट करें ताकि यह उबर सके

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

चेंज डेटा कैप्चर के साथ परिचालन-डेटाबेस से स्ट्रीम करें

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

दो कोडबेस बनाए रखने के बजाय स्ट्रीमिंग-प्रथम आर्किटेक्चर प्राथमिकता दें

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

स्ट्रीमों को एसक्यूएल, मैटीरियलाइज़्ड व्यू, और रियल-टाइम ओलैप के रूप में उजागर करें

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

शुरू से बैकप्रेशर और पुनर्प्रसंस्करण की योजना बनाएँ

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

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

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

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

अपनी टीम के साथ चर्चा के लिए प्रश्न

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

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

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

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

5. क्या हम एक स्ट्रीमिंग-प्रथम कोडबेस चलाते हैं या अलग बैच-परत और स्पीड-परत, और दोनों को मिलाकर रखने की हमें वाक़ई क्या क़ीमत चुकानी पड़ती है? सटीक इतिहास के लिए बैच-परत और ताज़ा नतीजों के लिए स्पीड-परत का लैम्ब्डा पैटर्न आपको वही व्यावसायिक तर्क दो प्रणालियों में दो बार लिखने और उनके जवाबों को हमेशा के लिए मिलाने पर मजबूर करता है, जबकि स्ट्रीमिंग-प्रथम (कप्पा) आकार एक टिकाऊ, फिर-से-चलाने-योग्य लॉग रखता है और सारा प्रोसेसिंग स्ट्रीम-प्रोसेसिंग के रूप में चलाता है। बड़े संगठन के लिए दोहराया गया तर्क वह जगह है जहाँ बहाव और विवादित संख्याएँ पनपती हैं, क्योंकि कोई नियम एक परत में बदलता है और दूसरी में नहीं, और इंजीनियर यह समझाने में असली समय ख़र्च करते हैं कि दोनों क्यों असहमत हैं। दोनों रखने की तरफ़ खिंचाव है जड़ता और किसी सिद्ध बैच-परत का आराम, इसलिए इसे रखरखाव-कर के मुक़ाबले ईमानदारी से तौलें। वे गणनाएँ लाएँ जो आप अभी दोनों जगह चलाते हैं, दोनों परतों के असहमत होने से हुई घटनाएँ, और यह आँकलन कि क्या आपका इवेंट-लॉग बैच-ज़रूरतों को फिर-से-चलाने के रूप में व्यक्त करने लायक़ पर्याप्त इतिहास रखता है। सरकारी और ऑडिटेड उद्यम संदर्भों में, दो परतें जो एक ही अवधि के लिए अलग-अलग आँकड़े रिपोर्ट कर सकती हैं, ख़ुद एक अनुपालन-देनदारी है, क्योंकि आपको बताना होगा कि कौन-सी संख्या आधिकारिक है और क्यों।

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

क्षेत्र-लेंस

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

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

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

सरकार। ऑडिट-योग्यता और सार्वजनिक जवाबदेही हर चुनाव को आकार देते हैं। हर प्रोसेस की गई घटना को किसी टिकाऊ लॉग में रखें ताकि निगरानी-निकायों को रिपोर्ट किए गए आँकड़े, सवारी-संख्या, लाभ-विसंगतियाँ, धोखाधड़ी-फ़ैसले, को ठीक-ठीक फिर से बनाया जा सके, और घटनाओं को चुपचाप गिराने के बजाय देर-से-डेटा नीति को स्पष्ट और दस्तावेज़ित बनाएँ। ख़रीद-प्रक्रिया को डेटा-पोर्टेबिलिटी और किसी प्रबंधित-सेवा की डिलीवरी व प्रतिधारण-गारंटी के खुलासे की माँग करनी चाहिए, और किसी नियम-बदलाव के बाद कोई भी पुनः-कथन सुधारे गए तर्क के ज़रिए एक सुरक्षित फिर-से-चलाना होना चाहिए, ऐसा मैनुअल पैच नहीं जिसे कोई ट्रेस नहीं कर सकता।

उदाहरण

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

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

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

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

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

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

एंटी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

• स्तर 1, आरंभ: सब कुछ बैच है, या कुछ हाथ से बने स्ट्रीमिंग-काम बिना निगरानी के प्रतिक्रियात्मक रूप से चलते हैं। संख्याएँ प्रोसेसिंग-समय पर गिनी जाती हैं, देर से आए डेटा को अनदेखा किया जाता है, और फिर से शुरू होना स्थिति खो देता है। कोई किसी बग को ठीक करने के लिए इतिहास फिर से नहीं चला सकता, और समस्याएँ तब खोजी जाती हैं जब नीचे के आँकड़े मिलने से इनकार करते हैं।
• स्तर 2, विकास: कुछ टीमें चेकपॉइंटिंग के साथ लॉग-आधारित ब्रोकर पर मुख्य स्ट्रीमिंग-पाइपलाइन चलाती हैं, और वे इवेंट-समय को प्रोसेसिंग-समय से अलग करती हैं और बुनियादी विंडो इस्तेमाल करती हैं। अभ्यास टीम-दर-टीम असंगत है: डिलीवरी कम-से-कम-एक-बार है पर सभी सिंक इडेम्पोटेंट नहीं हैं, देर-से-डेटा-प्रबंधन तात्कालिक है, और पिछड़ाव अनौपचारिक रूप से देखा जाता है, अलर्ट पर नहीं।
• स्तर 3, मानकीकरण: इवेंट-समय, वॉटरमार्क, और एक स्पष्ट देर-से-डेटा नीति पूरे संगठन में दस्तावेज़ित और लागू हैं। सिंक असल-में-एक-बार नतीजों के लिए इडेम्पोटेंट हैं, स्थिति की समाप्ति है, और चेंज डेटा कैप्चर परंपरा से नीचे की प्रणालियों को खिलाती है। एक बनाए रखा गया लॉग फिर-से-चलाने का समर्थन करता है, और पिछड़ाव, थ्रूपुट, और ताज़गी को प्रति-टीम आदत के बजाय संगठन-व्यापी मानक के रूप में अलर्ट के साथ निगरानी किया जाता है।
• स्तर 4, प्रबंधन: स्ट्रीमिंग-संपत्ति को आधार-रेखाओं के मुक़ाबले मापा और नियंत्रित किया जाता है। हर पाइपलाइन छोर-से-छोर विलंब, उपभोक्ता-पिछड़ाव, पुनर्प्राप्ति-समय, इवेंट-समय-तिरछापन, देर-से-घटना-दर, स्थिति-आकार, और प्रति-मिलियन-घटना लागत के लिए सेवा-स्तर उद्देश्य रखती है, ये सब सहमत लक्ष्यों के मुक़ाबले ट्रैक और रिग्रेशन पर अलर्ट किए जाते हैं। पुनर्प्राप्ति को मान लेने के बजाय ड्रिल और समय दिया जाता है, बैकप्रेशर-गुंजाइश और स्थिति-वृद्धि को क्षमता-संकेत के रूप में देखा जाता है, और किसी नई स्ट्रीम को उत्पादन में जाने से पहले इन मेट्रिक्स को पार करना चाहिए।
• स्तर 5, संयोजन: एक स्ट्रीमिंग-प्रथम आर्किटेक्चर एक फिर-से-चलाने-योग्य लॉग से ताज़ा और ऐतिहासिक दोनों ज़रूरतें पूरी करती है, और स्ट्रीमिंग एसक्यूएल, मैटीरियलाइज़्ड व्यू, और रियल-टाइम ओलैप ताज़ा डेटा को व्यापक रूप से सुलभ बनाते हैं। पुनर्प्रसंस्करण नियमित और परीक्षित है, प्लेटफ़ॉर्म मापे गए भार और लागत के मुक़ाबले ऑटोस्केल और फिर से संतुलित होता है, और स्ट्रीमों को प्रमाण पर सेवानिवृत्त, फिर से दायरा, या प्रतिस्थापित किया जाता है। स्ट्रीमिंग व्यावसायिक और जोख़िम-योजना के साथ एकीकृत है, और भार व लागत-तस्वीर बदलने के साथ हर स्ट्रीम छोर-से-छोर अवलोकनीय और ऑडिट-योग्य है।

चर्चा के लिए विचार

1. आपके स्टैक में “रियल-टाइम” वाक़ई अपनी लागत कहाँ कमाता है, और यह अपरीक्षित इच्छा कहाँ है?
2. आपके स्रोतों में इवेंट-समय और प्रोसेसिंग-समय के बीच का अंतराल कितना बड़ा है, और क्या आप इसे मापते हैं?
3. क्या आप लैम्ब्डा बैच-और-स्पीड सेटअप को एक अकेले स्ट्रीमिंग-प्रथम कोडबेस में समेट सकते हैं, और उसे क्या रोकेगा?
4. आपके कौन-से सिंक वाक़ई इडेम्पोटेंट हैं, और क्या आप आज सुधारे गए तर्क से पिछली तिमाही का डेटा सुरक्षित रूप से फिर से चला सकते हैं?
5. किसी विंडो बंद होने के बाद आने वाले डेटा के लिए आपकी नीति क्या है, और क्या नीचे हर कोई इसे जानता है?
6. चेंज डेटा कैप्चर खोज, कैश, और एनालिटिक्स को सिंक में रखने का तरीक़ा कैसे बदलेगी?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

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