SQL साक्षात्कार: 30-मिनट के निष्क्रियता अंतराल (Inactivity Gap) के साथ उपयोगकर्ता इवेंट्स को सत्रों में विभाजित (Sessionize) करना

समस्या और लागू संदर्भ

मान लें कि यह PostgreSQL इवेंट तालिका है:

sql

CREATE TABLE events (
  event_id bigint PRIMARY KEY,
  user_id bigint NOT NULL,
  occurred_at timestamptz NOT NULL
);

प्रत्येक उपयोगकर्ता के इवेंट्स को occurred_at और event_id के अनुसार क्रमबद्ध करें। पहला इवेंट एक सत्र शुरू करता है। इसके बाद का प्रत्येक इवेंट एक नया सत्र शुरू करता है जब पिछले इवेंट से उसका अंतराल 30 मिनट से अधिक या उसके बराबर होता है। user_id, एक-आधारित session_seq, session_start, session_end, event_count, और session_duration लौटाएं। एक सटीक 30-मिनट का अंतराल एक नया सत्र शुरू करता है; वह सीमा अनुबंध (contract) का हिस्सा है।

यह पैटर्न क्लिकस्ट्रीम प्रोसेसिंग, उत्पाद विश्लेषण (product analytics), और व्यवहार फ़नल में दिखाई देता है। यह लगातार लॉगिन दिनों को खोजने जैसी समस्या नहीं है। एक दैनिक स्ट्रीक आसन्न कैलेंडर तिथियों की तुलना करती है; सत्र विभाजन (sessionization) एक उपयोगकर्ता के लिए आसन्न इवेंट्स के बीच बीते समय की तुलना करता है। मुख्य समाधान एक पूर्ण, तार्किक रूप से डुप्लिकेट-मुक्त इवेंट सेट पर एक सटीक परिणाम की गणना करता है। परिबद्ध प्रश्नों (bounded queries) और वृद्धिशील सामग्रीकरण (incremental materialization) के लिए अतिरिक्त सीमा नियमों की आवश्यकता होती है।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

पहला संकेत यह है कि क्या उम्मीदवार विवरण को एक निष्पादन योग्य अनुबंध में बदलता है। > 30 minutes और >= 30 minutes सीमा इवेंट को अलग तरह से सौंपते हैं। पिछले इवेंट से तुलना करना और एक सत्र में पहले इवेंट से तुलना करना भी अलग परिभाषाएं हैं। यह संकेत आसन्न अंतरालों का उपयोग करता है, इसलिए एक लगातार सक्रिय सत्र 30 मिनट से कहीं अधिक समय तक चल सकता है।

दूसरा संकेत तीन विंडो चरणों में अपघटन है: पूर्ववर्ती को पढ़ने के लिए LAG() का उपयोग करें, सत्र सीमाओं को चिह्नित करें, और उन चिह्नों पर एक संचयी SUM() चलाएं। आवश्यक विंडो गणनाओं को केवल एक PostgreSQL अभिव्यक्ति में मनमाने ढंग से नेस्ट नहीं किया जा सकता है। अलग-अलग CTEs निरीक्षण के लिए प्रत्येक मध्यवर्ती संबंध को भी उजागर करते हैं।

तीसरा संकेत नियतात्मक क्रमांकन (deterministic ordering) है। दो इवेंट्स एक ही occurred_at साझा कर सकते हैं। केवल समय के अनुसार क्रमबद्ध करना उनके सापेक्ष क्रम को अनिर्दिष्ट छोड़ देता है। अद्वितीय event_id को जोड़ने से LAG() और रनिंग योग को समान कुल क्रम मिलता है। समान टाइमस्टैम्प्स के बीच बीता हुआ समय शून्य होता है, इसलिए वे एक ही सत्र में बने रहते हैं।

चौथा संकेत समय शब्दार्थ (time semantics) है। एक timestamptz बीते समय की तुलना के लिए उपयुक्त एक पूर्ण क्षण को दर्शाता है। घटाने से पहले स्थानीय वॉल समय में कनवर्ट करना डेलाइट-सेविंग जंप जोड़ सकता है। नामित-ज़ोन रूपांतरण प्रस्तुति के समय का हिस्सा है, इस सत्र-सीमा गणना में नहीं।

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

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

30-मिनट की सीमा का स्वामित्व किस तरफ है? यह संकेत >= 30 minutes पर एक नया सत्र शुरू करता है। एक

सख्त-अधिक-से-बड़ा उत्पाद नियम एक ऑपरेटर और सभी सीमा अपेक्षाओं को बदल देता है।

क्या हम आसन्न इवेंट्स या सत्र के पहले इवेंट की तुलना करते हैं? यहाँ आसन्न इवेंट्स। एक अधिकतम

सत्र लंबाई के लिए सत्र की शुरुआत में स्थित अलग स्थिति की आवश्यकता होती है।

डुप्लिकेट को कैसे संभाला जाता है? event_id तार्किक इवेंट कुंजी है, इसलिए इस क्वेरी से पहले

पुनर्वितरण (redeliveries) को डिडुप्लिकेट किया जाना चाहिए। समान उपयोगकर्ता और टाइमस्टैम्प पर अलग-अलग इवेंट्स मान्य पंक्तियाँ बनी रहती हैं।

अंतराल को कौन सा समय क्षेत्र परिभाषित करता है? पूर्ण क्षणों के बीच बीता हुआ समय। एक नामित समय क्षेत्र

प्रदर्शन को बदलता है, बीते हुए सेकंडों की संख्या को नहीं।

क्या क्वेरी समय-सीमित है? पूरा इतिहास सीधा है। एक रिपोर्टिंग सीमा को यह निर्दिष्ट करना होगा

कि क्या सीमा से पहले शुरू हुए सत्र बरकरार रहेंगे और उन्हें पूर्ववर्ती संदर्भ पढ़ना होगा।

इवेंट्स कितनी देर से आ सकते हैं? एक तदर्थ क्वेरी पुनर्गणना कर सकती है। एक भौतिक परिणाम को एक

सुधार सीमा, वॉटरमार्क और डाउनस्ट्रीम अपडेट या रिट्रेक्शन प्रोटोकॉल की आवश्यकता होती है।

एक खाली तालिका या एक-इवेंट उपयोगकर्ता को क्या लौटाना चाहिए? खाली तालिका के लिए शून्य पंक्तियाँ; एक-इवेंट

उपयोगकर्ता के लिए एक शून्य-अवधि सत्र।

30-सेकंड उत्तर ढांचा

“प्रत्येक उपयोगकर्ता के भीतर, मैं occurred_at, event_id द्वारा एक नियतात्मक क्रम बनाता हूँ और पूर्ववर्ती प्राप्त करने के लिए LAG(occurred_at) का उपयोग करता हूँ। मैं पहली पंक्ति और कम से कम 30 मिनट के प्रत्येक अंतराल को 1 के रूप में चिह्नित करता हूँ, बाकी सभी पंक्तियों को 0 के रूप में चिह्नित किया जाता है। एक स्पष्ट ROWS फ्रेम पर एक संचयी योग एक-आधारित सत्र अनुक्रम देता है। फिर मैं प्रारंभ, अंत, गणना और अवधि की गणना करने के लिए उपयोगकर्ता और अनुक्रम द्वारा समूहीकृत करता हूँ। परीक्षण 29 मिनट 59 सेकंड, ठीक 30 मिनट, समान टाइमस्टैम्प, एक-इवेंट उपयोगकर्ता, डुप्लिकेट आईडी, विलंबित डेटा, और रिपोर्टिंग सीमा की शुरुआत को कवर करते हैं। वृद्धिशील सामग्रीकरण के लिए, मैं यह मानने के बजाय कि सत्र केवल जुड़ते हैं, अनुमत विलंबता विंडो के अंदर प्रभावित उपयोगकर्ता की पुनर्गणना करता हूँ।”

चरण-दर-चरण गहन विश्लेषण

पहले एक साझा क्रमांकन नियम के साथ पूर्ववर्ती प्राप्त करें। event_id बीते हुए समय को प्रभावित नहीं करता है; यह केवल समान टाइमस्टैम्प्स को स्थिर करता है:

sql

WITH ordered AS (
  SELECT
    event_id,
    user_id,
    occurred_at,
    LAG(occurred_at) OVER (
      PARTITION BY user_id
      ORDER BY occurred_at, event_id
    ) AS previous_at
  FROM events
),
marked AS (
  SELECT
    event_id,
    user_id,
    occurred_at,
    CASE
      WHEN previous_at IS NULL THEN 1
      WHEN occurred_at - previous_at >= INTERVAL '30 minutes' THEN 1
      ELSE 0
    END AS is_new_session
  FROM ordered
),
sessionized AS (
  SELECT
    event_id,
    user_id,
    occurred_at,
    SUM(is_new_session) OVER (
      PARTITION BY user_id
      ORDER BY occurred_at, event_id
      ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS session_seq
  FROM marked
)
SELECT
  user_id,
  session_seq,
  MIN(occurred_at) AS session_start,
  MAX(occurred_at) AS session_end,
  COUNT(*) AS event_count,
  MAX(occurred_at) - MIN(occurred_at) AS session_duration
FROM sessionized
GROUP BY user_id, session_seq
ORDER BY user_id, session_seq;

स्पष्ट ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW मायने रखता है। रनिंग कुल को डिफ़ॉल्ट विंडो फ्रेम से पीयर सेमेन्टिक्स प्राप्त करने के बजाय एक समय में एक भौतिक पंक्ति द्वारा सीमा मार्कर को अवशोषित करना चाहिए। अद्वितीय event_id इस क्वेरी में साथियों को हटा देता है, फिर भी फ्रेम को स्पष्ट रूप से बताना इरादे को लॉक करता है और भविष्य में टाई-ब्रेकर को हटाने से व्यवहार को चुपचाप बदलने से रोकता है।

सीमा की जांच करने के लिए इन इवेंट्स का उपयोग करें:

userid	eventid	occurred_at	पूर्ववर्ती से अंतराल	अपेक्षित सत्र
1	1	09:00	पहला इवेंट	1
1	2	09:05	5 मिनट	1
1	3	09:35	30 मिनट	2
1	4	09:50	15 मिनट	2
1	5	10:10	20 मिनट	2
2	6	09:00	पहला इवेंट	1
2	7	09:29	29 मिनट	1
2	8	09:58	29 मिनट	1

उपयोगकर्ता 1 के दो सत्र हैं: पाँच मिनट में दो इवेंट्स, फिर 35 मिनट में तीन इवेंट्स। उपयोगकर्ता 2 का कुल विस्तार 58 मिनट है, फिर भी प्रत्येक आसन्न अंतराल 30 मिनट से कम है, इसलिए तीनों इवेंट्स एक ही सत्र में रहते हैं। यह आसन्न-अंतराल सत्र विभाजन को अधिकतम सत्र अवधि से अलग करता है।

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

N इवेंट्स के लिए, विंडो योजना आमतौर पर उपयोगकर्ता और समय के अनुसार क्रमबद्ध करती है, जिससे O(N log N) समय मिलता है; विंडो स्कैन और एकत्रीकरण O(N) हैं। मध्यवर्ती स्थिति O(N) है और स्पिल हो सकती है। एक इंडेक्स तार्किक क्रम से मेल खा सकता है:

sql

CREATE INDEX events_session_order_idx
  ON events (user_id, occurred_at, event_id);

इंडेक्स सॉर्ट-मुक्त योजना की गारंटी नहीं देता है। पूर्ण-स्कैन लागत, दृश्यता, समानता (parallelism), और विधेय सभी ऑप्टिमाइज़र को प्रभावित करते हैं। इंडेक्स उपस्थिति से सफलता घोषित करने के बजाय प्रतिनिधि डेटा पर EXPLAIN (ANALYZE, BUFFERS) के साथ स्कैन, सॉर्ट, अस्थायी I/O, अनुमानित पंक्तियों और वास्तविक पंक्तियों का निरीक्षण करें।

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

विलंबित डेटा इतिहास को भी मर्ज कर सकता है। 09:00 और 09:50 के इवेंट्स शुरू में अलग-अलग सत्र बनाते हैं। एक विलंबित 09:25 इवेंट दोनों आसन्न अंतरालों को 25 मिनट में बदल देता है और उन्हें मर्ज कर देता है। बैच प्रोसेसिंग प्रभावित विभाजन की पुनर्गणना कर सकती है। एक वृद्धिशील प्रणाली को अनुमत विलंबता सीमा पर उपयोगकर्ता द्वारा पुनर्गणना करनी चाहिए और संस्करण या रिट्रेक्शन प्रकाशित करने चाहिए। अनुबंध में यह बताया जाना चाहिए कि वॉटरमार्क से परे डेटा को संगरोध (quarantine) किया गया है, छोड़ दिया गया है, या व्यापक सुधार को ट्रिगर करने की अनुमति दी गई है।

प्रत्येक चरण को मान्य करें। ordered में प्रत्येक गैर-पहला previous_at साझा क्रम में पूर्ववर्ती टाइमस्टैम्प के बराबर होना चाहिए। marked में केवल पहली पंक्तियों और सीमा सीमाओं पर 1 होता है। प्रत्येक उपयोगकर्ता के लिए, session_seq एक से शुरू होता है, कभी घटता नहीं है, और अधिकतम एक बढ़ता है। अंतिम संबंध में session_start <= session_end होना चाहिए; इसके इवेंट काउंट का योग तार्किक इनपुट इवेंट्स की संख्या के बराबर होना चाहिए; और आसन्न सत्रों के बीच का अंतर कम से कम 30 मिनट होना चाहिए।

उच्च गुणवत्ता वाला नमूना उत्तर

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

मैं 29 मिनट 59 सेकंड और ठीक 30 मिनट, समान टाइमस्टैम्प, एक-इवेंट उपयोगकर्ता और एक खाली तालिका का परीक्षण करूँगा। मैं रिपोर्टिंग सीमा से पहले एक पूर्ववर्ती का भी परीक्षण करूँगा, क्योंकि LAG से पहले फ़िल्टर करने से एक गलत सत्र सीमा बनती है। सॉर्टिंग लगभग O(N log N) पर हावी होती है। (user_id, occurred_at, event_id) पर एक इंडेक्स आवश्यक क्रम प्रदान कर सकता है, लेकिन निर्णय बफर-जागरूक निष्पादन योजना से आता है।

लगातार भौतिक परिणाम के लिए, मैं सत्र संख्याओं को अपरिवर्तनीय नहीं मानूंगा। 09:00 और 09:50 के इवेंट्स तब तक अलग होते हैं जब तक कि एक विलंबित 09:25 इवेंट उन्हें जोड़ नहीं देता। सिस्टम को विलंबता विंडो के अंदर उपयोगकर्ता-दायरे में पुनर्गणना और संस्करण-जागरूक उपभोक्ताओं की आवश्यकता होती है। वॉटरमार्क से परे इवेंट्स को एक स्पष्ट संगरोध या व्यापक-सुधार नीति का पालन करना चाहिए।”

सामान्य गलतियाँ

वर्तमान इवेंट से सत्र के पहले इवेंट को घटाना → कुल अवधि 30 मिनट से अधिक होने पर लगातार सक्रिय उपयोगकर्ता

विभाजित हो जाते हैं → निर्दिष्ट अनुसार आसन्न इवेंट्स की तुलना करें।

पुराने सत्र में ठीक 30-मिनट का अंतराल रखना → यह >= 30 minutes अनुबंध का उल्लंघन करता है →

एक समर्पित थ्रेशोल्ड परीक्षण लिखें।

केवल occurred_at द्वारा क्रमबद्ध करना → समान टाइमस्टैम्प में एक स्थिर कुल क्रम का अभाव होता है → **अद्वितीय

event_id जोड़ें और दोनों विंडो में क्रम का पुन: उपयोग करें।**

स्पष्ट ROWS फ्रेम को छोड़ना → डिफ़ॉल्ट पीयर व्यवहार पंक्ति-दर-पंक्ति संचय से भिन्न हो सकता है →

पहली पंक्ति से वर्तमान पंक्ति तक के फ्रेम को स्पष्ट रूप से बताएं।

स्थानीय वॉल समय घटाना → एक डेलाइट-सेविंग जंप एक घंटा बनाता या छुपाता है → **timestamptz

क्षणों की तुलना करें और केवल प्रदर्शन के लिए स्थानीयकृत करें।**

LAG से पहले रिपोर्ट प्रारंभ पर फ़िल्टर करना → पहला इन-रेंज इवेंट अपना पूर्ववर्ती खो देता है और

एक गलत सीमा बन जाता है → आउटपुट को ट्रिम करने से पहले सीमा-पूर्व संदर्भ पढ़ें।

पुनर्वितरण को इवेंट्स के रूप में गिनना → event_count बढ़ जाता है → तार्किक इवेंट कुंजी द्वारा डिडुप्लिकेट करें।
मान लें कि ऐतिहासिक सत्र केवल जुड़ते हैं → विलंबित डेटा सीमाओं को स्थानांतरित कर सकता है या सत्रों को मर्ज कर सकता है →

एक परिबद्ध सीमा की पुनर्गणना करें और सुधार योग्य परिणाम प्रकाशित करें।

मान लें कि एक मेल खाने वाला इंडेक्स हर सॉर्ट को समाप्त कर देता है → ऑप्टिमाइज़र स्कैन लागत और विधेय के आधार पर

एक अन्य योजना चुन सकता है → एक प्रतिनिधि योजना और अस्थायी I/O का निरीक्षण करें।

फॉलो-अप सवाल और जवाब

फॉलो-अप 1: यदि पुराने सत्र में ठीक 30 मिनट का अंतराल रहता है तो क्या बदलता है?

सीमा विधेय को >= INTERVAL '30 minutes' से > INTERVAL '30 minutes' में बदलें। विंडो पाइपलाइन का बाकी हिस्सा अपरिवर्तित रहता है, लेकिन मीट्रिक परिभाषा और प्रत्येक परीक्षण फिक्सचर को इसके साथ बदलना चाहिए। 29:59, 30:00, और 30:01 के मामलों को रखें ताकि नीति बाद में बदल न सके।

फॉलो-अप 2: क्या रनिंग-सम समाधान पर्याप्त है यदि कोई सत्र अधिकतम दो घंटे तक चल सकता है?

नहीं। आसन्न छोटे अंतराल एक सत्र को अनिश्चित काल तक बढ़ा सकते हैं, इसलिए अगली सीमा गतिशील सत्र प्रारंभ पर भी निर्भर करती है। एक पुनरावर्ती CTE, एक व्यवस्थित स्टेट मशीन, या स्ट्रीम प्रोसेसर में प्रति-उपयोगकर्ता स्थिति आमतौर पर अधिक स्पष्ट होती है। पहले एक निश्चित दो घंटे की विंडो को "सत्र के पहले इवेंट के दो घंटे बाद" से अलग करें; वे अलग अनुबंध हैं।

फॉलो-अप 3: 24 घंटे देर से आने वाले इवेंट के लिए आप भौतिक परिणाम को कैसे सही करेंगे?

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

फॉलो-अप 4: आप अरबों इवेंट्स के लिए इसे कैसे अनुकूलित करेंगे?

समय विभाजनों (time partitions) को पढ़ें जिन्हें प्रून किया जा सकता है और सॉर्टिंग को कम करने के लिए (user_id, occurred_at, event_id) क्रम का उपयोग करें। एक आवधिक कार्य प्रत्येक उपयोगकर्ता के अंतिम इवेंट और खुले सत्र की स्थिति को विभाजन सीमाओं के पार ले जाता है ताकि कोई फ़ाइल या दिनांक सीमा सत्र सीमा न बने। वास्तविक उपयोगकर्ता तिरछापन (skew), सॉर्ट स्पिल, स्कैन किए गए बाइट्स और एंड-टू-एंड विलंबता के साथ डिज़ाइन को मान्य करें। एक एकल सुपर-यूज़र हॉटस्पॉट के लिए एक समर्पित व्यवस्थित पथ की आवश्यकता हो सकती है।

फॉलो-अप 5: आप कैसे साबित करते हैं कि कोई इवेंट छूटा नहीं था या दो बार नहीं गिना गया था?

संरक्षण जांच (conservation checks) का प्रयोग करें। अंतिम event_count मानों का योग डिडुप्लिकेट की गई इनपुट पंक्ति गणना के बराबर होना चाहिए। प्रत्येक event_id ठीक एक (user_id, session_seq) से मैप होता है। सत्र अनुक्रम एक से शुरू होते हैं और प्रति उपयोगकर्ता लगातार बढ़ते हैं। एक सत्र के अंदर आसन्न अंतराल 30 मिनट से कम होते हैं, जबकि सत्रों के बीच की सीमाएँ कम से कम 30 मिनट की होती हैं। फिर फेरबदल किए गए इनपुट, पुनर्वितरण, समान टाइमस्टैम्प, विभाजन किनारों और विलंबित-इवेंट मर्ज के साथ संपत्ति परीक्षण (property tests) चलाएं।