Real-time analytics — hodisalar yuz berganidan keyin biznes uchun foydali bo‘lgan juda qisqa muddat ichida ularni qayta ishlab, ko‘rsatkich, alert yoki qaror chiqarish amaliyotidir. “Real-time” universal millisekund chegarasi emas: firibgarlikni bloklash uchun yuz millisekund, operatsion dashboard uchun o‘n soniya, logistika uchun bir necha daqiqa yetarli bo‘lishi mumkin. Talab end-to-end deadline bilan belgilanadi.
Arxitektura oqimi
Producer eventni brokerga yuboradi. Stream processor schema tekshiradi, enrich, filter, window va aggregate bajaradi. Natija serving database, search engine, time-series ombor, cache yoki alert tizimiga yoziladi. Dashboard materialized view yoki precomputed metricni o‘qib, katta tarixiy datasetni har refreshda qayta skan qilmaydi.
Event ID, event time, entity key va schema version asosiy maydonlardir. Partition key bir entity hodisalarini tartibda ushlashi mumkin. CDC operatsion database o‘zgarishini transaction logdan olib, analitik oqimga uzatadi; production jadvalini tez-tez full scan qilishdan qochiladi.
Vaqt va correctness
Processing time past kechikish beradi, event time tartibsiz kelgan hodisani to‘g‘ri windowga qo‘yadi. Watermark qachon natijani chiqarish va state ni tozalashni belgilaydi. Late event dastlabki natijani yangilasa, serving layer upsert yoki changelogni tushunishi kerak.
Exactly-once engine ichki state va offset uchun berilishi mumkin, ammo tashqi email yoki payment side effect avtomatik aynan bir marta bo‘lmaydi. Idempotency key, transactional outbox va deduplication qo‘llanadi. Foydalanuvchiga ko‘rsatilgan metricning “provisional” yoki final holati aniq bo‘lishi mumkin.
Lambda va Kappa
Lambda architecture batch layer orqali to‘liq aniq view, speed layer orqali tez taxminiy view yaratadi va servingda birlashtiradi. Ikki alohida kod yo‘li semantika farqi hamda operatsion murakkablik keltiradi. Kappa architecture bir event log va stream engine bilan real-time hamda replayni bajarishga intiladi. Tarixni qayta ishlash uchun broker retention yoki arxiv source yetarli bo‘lishi kerak.
Modern lakehouse pipeline streaming ingestni transaction tablega yozib, incremental query va batch backfillni bir formatda boshqarishi mumkin. Tanlov nomli arxitekturadan ko‘ra latency, qayta hisoblash, state hajmi va jamoa tajribasiga asoslanadi.
Serving va dashboard
Low-latency store query access pattern bo‘yicha indekslanadi. Time bucket, tenant va metric key oldindan tanlanadi. Har eventni dashboard databasega individual yozish write overhead yaratadi; micro-batch va local aggregation kamaytiradi. Hot key bitta shardni band qilishi mumkin.
Cache freshness va invalidation nazorat qilinadi. Dashboard refresh intervali bir soniya bo‘lsa ham pipeline watermarki o‘n daqiqa ortda qolsa real-time emas. UI data timestamp, delay va oxirgi muvaffaqiyatli yangilanishni ko‘rsatadi.
Operatsion mezonlar
End-to-end latency event yaratilishidan natija ko‘rinishigacha o‘lchanadi. p95 va p99, consumer lag, watermark delay, checkpoint, late event, dropped record va sink error kuzatiladi. Throughput testida burst, broker restarti, schema change va backfill bilan odatiy trafik birga sinov qilinadi.
Real-time tizim katta xarajat va on-call yukini keltiradi. Qaror besh daqiqada ham foydali bo‘lsa, murakkab sub-second pipeline shart emas. Foyda yo‘qotiladigan vaqt, correctness, narx va recovery qobiliyati bilan birga baholanadi.
Natija biznes amalini avtomatik boshlasa, guardrail, manual override va audit talab qilinadi. Noto‘g‘ri real-time signal bir necha soniyada katta ta’sir tarqatishi mumkin; tezlik nazoratni bekor qilmaydi.
Bog‘liq tushunchalar
Stream processing, Event time, Watermark, Change Data Capture, Lambda architecture, Materialized view, Consumer lag