Ingestion Time — event stream-processing platformasiga yoki birinchi ishonchli qabul nuqtasiga kirgan paytdagi timestamp. U cache, distributed snapshot yoki stream-processing tizimlaridagi muayyan data va vaqt semantikasini ifodalaydi. Aniq kafolatlar platforma, protocol hamda konfiguratsiyaga bog‘liq; termin nomi barcha implementatsiyada bir xil xulqni anglatmaydi.
Tizimdagi vazifasi
Broker yoki source connector event qabul qilganda ingestion timestamp beradi. U producer clockiga bog‘liqlikni kamaytiradi va processing timedan ko‘ra sourcega yaqinroq tartibni ifodalaydi.
Ingestion Time alohida feature emas, source, storage, tarmoq va consumer xulqi bilan birga ishlaydi. Request qabul qilinishi, state durable bo‘lishi va natijaning tashqi tizimda ko‘rinishi turli nuqtalar bo‘lishi mumkin. Shu chegaralar hujjatlashtirilsa retry va recoverydagi noaniqlik kamayadi.
Holat o‘zgarishi
Haqiqiy hodisa networkda uzoq kechiksa ingestion time event timedan farq qiladi. Shu timestampdan oldingi producer queue va offline davr ko‘rinmaydi.
Ingestion Time kafolati butun pipeline bo‘yicha baholanadi. Source timestamp to‘g‘ri bo‘lsa ham broker, operator, cache va sink boshqa ordering yoki durability semantikasini berishi mumkin. Har acknowledgement qaysi state durable va visible bo‘lganini ifodalaydi.
Ishonchlilik
Bir nechta ingress point clocklari sinxron bo‘lishi kerak. Replay qilingan eski event yangi ingestion time olsa, tarixiy hisob natijasi o‘zgarishi mumkin.
Ingestion Time bilan ishlovchi client retry uchun umumiy deadline, exponential backoff va jitter qo‘llaydi. Cheksiz retry backendni himoya qilmaydi. Side effect bo‘lsa idempotency key yoki checkpoint bilan duplicate effect cheklanadi; timeout operatsiya bajarilmadi degani emas.
Ingestion Time dizaynida correctness, freshness, latency va resource sarfi birga tanlanadi. Past latency uchun cache yoki early firing ishlatilsa stale yoki preliminary natija ehtimoli paydo bo‘ladi. Qat’iyroq ordering va completeness ko‘proq buffer, coordination yoki kutish vaqtini talab qiladi.
Kuzatuv
Ingestion Time uchun monitoring semantic metrikalarni qamrab oladi: hit ratio, stale age, watermark lag, late count, compaction backlog yoki offset distance. Process up signali correctnessni ko‘rsatmaydi. Alert aniq key, partition va vaqt oralig‘ini tekshirish qadamiga bog‘lanadi.
Ingestion Time optimallashtirilganda correctness testi qayta bajariladi. Batching, local cache, asynchronous flush yoki parallelism throughputni oshirishi mumkin, ammo ordering va freshnessni o‘zgartiradi. Feature flag bilan yoqilgan yo‘l ham shu semantic testdan o‘tadi.
Ingestion Time ko‘p tenantli muhitda adolatli resource taqsimotini talab qiladi. Bitta tenantning hot keylari, katta oynasi yoki sekin consumeri umumiy memory va diskni egallamasligi uchun per-tenant limit hamda isolation ishlatiladi. Limitga yetish correctnessni buzadigan yashirin drop emas, o‘lchanadigan va tushunarli javob bilan namoyon bo‘ladi.
Ingestion Timega bog‘liq default qiymatlar environmentlar orasida bir xil deb taxmin qilinmaydi. Developmentdagi kichik data va bitta node productiondagi parallelizm, retention hamda failure xulqini to‘liq takrorlamaydi.
Ingestion Time uchun qabul mezoni misol bilan tasdiqlanadi: bir xil input va boshlang‘ich state berilganda kutilgan output, metadata hamda tashqi effect birgalikda tekshiriladi. Faqat yakuniy qiymatni solishtirish oraliq yo‘qotish yoki takroriy yozuvni yashirishi mumkin.
Ingestion Time bo‘yicha o‘zgarishdan keyin faqat muvaffaqiyatli oqim emas, miss, timeout, duplicate, late data, restart va partial failure holati ham tekshiriladi. Qabul qilingan cheklovlar hujjatlashtiriladi va boshqa workloadga avtomatik ko‘chirilmaydi.
Bog‘liq tushunchalar
event time, processing time, source timestamp, stream ingestion, replay, watermark