Агым иштетүү
Агым иштетүү деген эмне
Агым иштетүү - минималдуу кечигүү жана шарттардын тууралыгына кепилдик берүү менен окуялардын (транзакциялардын, чыкылдатуулардын, төлөмдөрдүн, телеметриянын) чексиз ырааттуулугуна үзгүлтүксүз реакция. "Мезгил ичинде топтолгон нерселердин баарын алып жаткан" батчдан айырмаланып, агым маалыматтарды кабыл алуу менен иштетет, абалды сактап, иш-чаранын убактысын эске алат.
Негизги түшүнүктөр
Окуя (event) - 'event _ time' жана уникалдуу 'event _ id' менен өзгөрүлбөгөн факт.
Окуя убактысы (event time) vs иштетүү убактысы (processing time) - биринчиси булактан келет, экинчиси - оператор иш жүзүндө окуяны көргөндө.
- Tumbling (жабылбаган), Hopping/Sliding (жабылган), Session (активдүүлүк боюнча ажырымдар).
- Суу белгилери (watermarks) - терезелерди жабууга жана кеч маалыматтарды күтүүнү чектөөгө мүмкүндүк берүүчү "Т учуруна чейинки окуялар келди" деген баа.
- Кечиккен маалыматтар (lateness) - 'event _ time' менен окуялар учурдагы watermark аз; эрежелери көп колдонулат.
- Статус (state) - агрегаттар, join's, deduplication үчүн операторлордун жергиликтүү таблицалары/сактагычтары (keyed state).
- Backpressure - downstream кубаттуулугу ашкан учурда басым; протокол жана буферлер менен башкарылат.
Архитектуралык негиздер
1. Булак (source): иш-чара брокери (Kafka/NATS/Pulsar), CDC DD, кезек, Files/журнал жыйноочулар.
2. Агым кыймылдаткычы: терезелерди, агрегаттарды, джойндарды, үлгүлөрдү (CEP) эсептеп чыгат, абалды жана текшерүүнү башкарат.
3. Кабыл алуучу (sink): OLTP/OLAP DD, издөө кыймылдаткычы, кэш, топиктер, витриналар/отчеттор үчүн сактоо.
4. Схемалардын реестри: payload жана шайкештикти контролдоо.
5. Байкоо: метрика, Trace, Логи, Дашборд Лагуна жана суу белгилери.
Убакыт семантикасы жана тартиби
Ар дайым иш-чара убакыт артык: бул кечигүү жана үзгүлтүктөр менен гана башка болуп саналат.
Окуялар тартиптен тышкары келиши мүмкүн; тартиби партиянын ачкычынын чегинде гана кепилденет.
- терезелерди жабуу жана жыйынтыктарды чыгаруу;
- "канча күтөбүз" кечигип иш-чараларды чектөө ('allowed _ lateness').
- кечигип окуялар үчүн retractions/upserts колдонуңуз: агрегаттарды кайра саноо жана оңдоочу окуялар.
Абалы жана ишенимдүүлүгү
Keyed state: агрегаттардын маалыматтары (суммалар, эсептегичтер, чоң атанын структуралары) ачкычтар боюнча бөлүштүрүлөт.
Checkpoint/Savepoint: калыбына келтирүү үчүн мезгил-мезгили менен сүрөттөр; savepoint - коддун көчүрүү версиясы үчүн башкарылуучу сүрөт.
- транзакциялык "окуп-иштеп-жазып" (commit sink + окуу позициясы);
- демпотенттик sinks (upsert/merge) + жадыбал таблицалар;
- агрегаттарды чыгаруу (optimistic concurrency).
Терезелер, агрегациялар, join's
Терезелер:- Tumbling: жөнөкөй мезгилдүү отчеттор (мүнөт, саат).
- Hopping/Sliding: "жылма" метриктер (1 мин кадам менен 5 мин).
- Session: колдонуучу сессиялар жана antifrod үчүн табигый.
- Aggregations: sum/count/avg/approx-distinct (HyperLogLog), percentiles (TDigest/CKMS).
- Stream-Stream join: эки тарапты тең ачкыч жана убакыт боюнча буферизациялоону талап кылат, урматтоо 'allowed _ skew'.
- Stream-Table join (KTable): колдонмону же учурдагы абалын туташтыруу (мисалы, "колдонуучунун активдүү лимиттери").
Кечиккен жана кайталанган маалыматтар менен иштөө
Дедупликация: 'event _ id' же '(producer_id, sequence)'; кайталоо терезелер ≥ TTL менен "көрүнгөн" ачкычтарды сактоо.
Late events: жабылгандан кийин 'X' ичинде терезени кайра карап чыгууга уруксат (retractions/upserts).
Жалган дубликаттар: Идемпотенттик агрегаттарды тууралап, логторго "ALREADY_APPLIED" жазыңыз.
Масштабдоо жана аткаруу
Ачкыч боюнча шардарлоо: параллелизмди камсыз кылат; "ысык" ачкычтарды ээрчип.
Backpressure: параллелдүүлүктү чектөө, жарыялоодо батчи жана компрессияны колдонуу.
Суу белгилери: өтө агрессивдүү коюуга болбойт - катуу watermarks күтүүнү кыскартат, бирок кошумча жаңыртуулардын үлүшүн көбөйтөт.
Абалы: формат тандоо (RocksDB/мамлекеттик дүкөн/эс) өлчөмү жана жеткиликтүүлүк үлгүлөрүн эске алуу менен; TTL тазалоо.
Автоматтык масштабдоо: лагы, CPU, мамлекеттик көлөмү, убакыт GC.
Ишенимдүүлүк жана кайра баштоо
Идемпотенттик sink же офсетти бекитүү менен транзакциялык коммит - тууралыктын негизи.
Кайра иштетүүгө жол берилет; таасири "так бир жолу" болушу керек.
DLQ/паркинг лот: себептери менен өзүнчө агымына көйгөйлүү жазууларды жөнөтүү; кайра иштетүүнү камсыз кылсын.
Байкоо (өлчөө)
Lag булактары боюнча (убакыт жана отчет боюнча).
Watermark/current event time жана late окуялардын үлүшү.
Throughput/latency операторлору, p95/p99 end-to-end.
State size/rocksdb I/O, checkpoint 's/узактыгы жыштыгы.
DLQ rate, deduplication/retrains пайызы.
CPU/GC/heap, тыныгуу убактысы.
Коопсуздук жана комплаенс
Маалыматтардын классификациясы: PII/PCI схемаларында белгилөө, минималдуу сактоо, мамлекеттик жана снапшотторду шифрлөө.
Access control: жеке ACL боюнча топик/мамлекеттик таблицалар жана sinks.
Retents: юридикалык талаптарга ылайык (GDPR/унутулуу укугу).
Аудит: логин 'event _ id', 'trace _ id', натыйжасы: 'APPLIED/ALREADY _ APPLIED/RETRIED'.
Киргизүү үлгүлөрү
1. CDC → нормалдаштыруу → домендик иш-чаралар: чийки DD өзгөрүүлөрдү уктуруу эмес, түшүнүктүү бизнес-чындыктарга mape.
2. Outbox продюсерлерде: транзакция фактысы + окуя - бир DD транзакциясында.
3. Core vs Enriched: критикалык агымында минималдуу төлөм, байытуу - асинхрондук.
4. Replay достук: проекциялар/витриналар ийбадатканадан кайра чогултулушу керек.
5. Idempotency by design: operation/event key, upsert-схемалар, агрегаттардын версиялары.
Тестирлөө
Unit/Property-based: агрегаттар жана өзгөрүүлөр башка.
Stream tests: out-of-order жана дубликаттары менен иш-чаралардын туруктуу агымы → терезелерди жана чоң атаны текшерүү.
Golden Windows: эталондук терезелер/агрегаттар жана алгылыктуу кеч түзөтүүлөр.
Fault-injection: "жаздырган таасири" жана "committel ofset" ортосунда кулап.
Replay tests: Logo = Учурдагы абалы башынан терезе кайра.
Наркы жана оптималдаштыруу
Терезелер жана суу маркасы кечигүүгө/ресурстарга таасир этет: терезе канчалык узун жана көп 'allowed _ lateness', ошончолук көп мамлекет.
Codec & кысуу: CPU/тармак балансы.
чыгуу боюнча Batching: аз тармак чалуулар жана бүтүмдөр.
эрте чыпкалоо ("pushdown"): булагы мүмкүн болушунча жакын ашыкча ыргытып.
Антипаттерндер
иш-чара убакыт → туура эмес аналитика керек болгон жерде processing убакыт боюнча байлап.
Sink → кайра баштоодо кош эффекттерде боштук жок.
Глобалдык "мега-ачкычтар": бир ысык бөлүм параллелизмди бузат.
Коомдук иш-чаралар катары чийки CDC: DD схемаларынын агып чыгышы, эволюциянын алсыздыгы.
Жок DLQ: "уулуу" билдирүүлөр бүт конвейерди бөгөттөйт.
watermark ордуна туруктуу катуу кечигүү: же түбөлүк күтүү, же маалыматтарды жоготуу.
Домендик мисалдар
Төлөмдөр/финансы
Агым 'payment.', антифрод үчүн терезелер (session + CEP), дедуп 'operation _ id'.
бухгалтердик ledger (upsert + версия) жайгаштыруу боюнча Exactly-once таасири.
Маркетинг/жарнама
Sliding терезе CTR/Conversion, Join чыкылдатуу жана '± Δ t' жеткиликтүүлүгү менен көрсөтүү, bidding үчүн бириктирүү.
iGaming/Онлайн кызматтар
Реалдуу убакыт балансы/лимиттер, миссиялар/ачивкалар (терезелер сессиясы), антифрод үлгүлөрү жана эскертүүлөр.
Мини-шаблондор (псевдокод)
Суу белгилери жана жаңыртуулар менен терезе
pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)
Ofset бекитүү менен транзакциялык sink
pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit
Production чек тизмеси
- event time жана watermark стратегиясы аныкталган; терезелер жана 'allowed _ lateness' тандалган.
- Idempotent sink же ofset менен транзакциялык коммит.
- Схемалардын реестри жана шайкештик режимдери киргизилген; кошумча эволюция.
- Метрика: лаг, watermark, p95/p99, DLQ, мамлекеттик көлөмү, checkpoint узактыгы.
- Tests: out-of-order, кайталоо, кайра баштоо, replay.
- Мамлекеттик жана Snapshot үчүн PII/Retency саясаты.
- Масштабдоо планы жана backpressure стратегиясы.
- Терезе келишимдери жана түзөтүүлөр боюнча документтер (late updates).
FAQ
Иш-чара убактысы милдеттүү?
Метриканын тууралыгы жана ырааттуулугу маанилүү болсо, ооба. Processing time техникалык эсептер/мониторинг үчүн ылайыктуу, бирок аналитиканы бурмалайт.
exactly-once керек?
Так: критикалык таасирлер үчүн. Көбүнчө жетиштүү at-least-once + idempotent sink.
Терезелерди кантип тандоо керек?
бизнес-SLA баштап: "акыркы 5 мүнөт ичинде" → hopping, "колдонуучу сессиялары" → сессия, "мүнөт отчеттору" → tumbling.
кеч маалыматтар менен эмне кылуу керек?
Чектелген 'allowed _ lateness' жана түзөтүүлөрдү чыгарууга уруксат берүү (upsert/retract). Кардарлардын витринасы жаңыланышы керек.
Жыйынтык
Агымды иштетүү - бул бир гана аз кечигүү эмес, ошондой эле убакыт, абалы жана келишимдер тартиби. Туура иш-чара убакыт, терезелер жана суу белгилерин тандоо, плюс демпотенттик эффекттер, байкоо жана тесттер конвейерди ишенимдүү, кайталануучу жана үнөмдүү кылат - жана бизнеске "түн ичинде" эмес, "бул жерде жана азыр" чечимдерди берет.