streaming पाइपलाइन में देर से आने वाले events को आप कैसे संभालते हैं?

processing time के बजाय event time इस्तेमाल करें, और एक watermark तय करें, जो engine का यह अंदाजा है कि किसी दिए गए timestamp से पुराने events अब और नहीं आएंगे। windows तब बंद होती हैं जब watermark उनके अंत से आगे निकल जाता है। allowed lateness सेट करें ताकि थोड़ा देर से आए events नतीजे अपडेट कर सकें, और उससे भी देर वाली हर चीज को चुपचाप फेंकने के बजाय किसी side output या reconciliation table में भेजें।

सबसे पहले, हर चीज event time पर टिकी होती है, क्योंकि processing time के नतीजे हर replay पर बदल जाते हैं और इससे वे reconciliation के लिए बेकार हो जाते हैं। फिर watermark engine का यह दावा है कि उसे इस timestamp से पुराने events की और उम्मीद नहीं है, और windows तब अंतिम होती हैं जब वह उनसे आगे निकल जाता है। असली डिजाइन फैसला वही lag चुनना है: छोटा watermark तेज नतीजे देता है जो कभी कभी अधूरे होते हैं, लंबा watermark सही नतीजे देता है पर देर से। मैं इसे अंदाजे से नहीं, डेटा से तय करता हूं। एक mobile app पाइपलाइन पर हमने event time और ingestion time का अंतर नापा और पाया कि निन्यानबेवां percentile करीब चार मिनट था, क्योंकि फोन offline हो जाते थे, तो हमने allowed lateness दस मिनट रखी। उससे देर वाली हर चीज एक side output में जाती थी जो एक daily reconciliation job को खिलाती थी और वह warehouse में प्रभावित windows सुधार देती थी। जिस नियम पर मैं टिका रहता हूं वह यह है कि late data कभी चुपचाप नहीं गिराया जाता। अगर हम उसे छोड़ते भी हैं, तो पहले उसे गिना जाता है।