Conveyor аналитика жана ETL

(Бөлүк: Технология жана инфраструктура)

Кыскача резюме

Аналитикалык конвейер "чийки" iGaming операциялык окуяларын (коюмдар, депозиттер, PSP веб-хактери, оюндардын логдору) туруктуу метрикалык витриналарга (GGR/NGR, LTV, retenshn, антифрод сигналдары) айландырат. Таяныч принциптери: катмарлардын бирдиктүү модели (Bronze/Silver/Gold), DQ/lineage аспаптык дисциплинасы, инкременттүүлүк жана идемотенттүүлүк, байкоо жана SLO, чыгымдарды көзөмөлдөө. Чечимдер жүктүн профилин (турнирлердин туу чокулары), жөнгө салууну (PII/локализация) жана бизнестин маалыматтардын сергектигине болгон талаптарын эске алуу менен кабыл алынат.

1) Архитектура: ETL vs ELT, batch vs stream

ETL (Extract → Transform → Load): DWH жүктөп чейин өзгөртүү. Трансформация "булут" үчүн көзөмөлдөнүүчү чөйрөнү/сырларды талап кылган жерде ылайыктуу.
ELT (Extract → Load → Transform): Lake/Lakehouse/DWH чийки зат, андан ары SQL/кыймылдаткыч (dbt/SQL скрипттер). Колонка кыймылдаткычтары жана ийкемдүү итерация үчүн ыңгайлуу.
Batch: пландаштырылган терезелер (ар бир 5/15/60 мүнөт, nightly). Арзан жана алдын ала.
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP). жакынкы-реалдуу убакыт (5-60 секунд) жана антифрод/CRM сигналдары үчүн.
Гибрид: Bronze агымы менен толтурулган, Silver/Gold - инкременталдык batch моделдер.

Сунуш: iGaming ELT + агымын кармап: CDC/outbox → Bronze (мүнөттүк сергектик) аркылуу окуялар, Silver/Gold үчүн инкременталдык өзгөрүүлөр.

2) катмарлуу модели (Medallion)

Bronze (Raw): бизнес-логикасы жок чийки окуялар/CDC. Parquet/ORC форматтары, схемалар, минималдуу валидация.
Silver (Conformed): тазалоо, дедупликация, идентификаторлорду нормалдаштыруу, өлчөө SCD, валюта/убакыт зоналарын унификациялоо.
Gold (Marts): бизнес-терезелер (фактылар/өлчөмдөр, куб), materialized views, pre-агрегация (күндөр/өлкөлөр/буюмдар).

Артыкчылыктары: кайталануучулук, ачык-айкын эволюция, катмарлар боюнча ар кандай SLO жана TTL.

3) булактары жана жүктөө: CDC, outbox, Files

CDC (Change Data Capture): OLTP өзгөртүү агымдары (Postgres/MySQL) тартиби жана ыктымалдыгы кепилдик менен.
Outbox үлгү: иш-чаралар кызмат бүтүм outbox стол/чогултуу жазылган → коннектор шинага/көлгө жарыялайт.
File Download: PSP жүктөмөлөр, өнөктөш отчеттор; манифесттерди колдонуу, дубль контролдоо (checksum) жана кабыл алуу каталогдору.

Практикалар: булактар ​ ​ версияланат (schema version), ар бир булак үчүн - талаалар жана сапат күтүүлөр келишими.

4) Оркестр: DAG, көз карандылык, деплой

DAGi: ачык көз карандылык (raw → staging → dims → facts → marts).
Милдеттердин ыктымалдыгы: терс таасирлери жок кайра баштоо (partition-overwrite, 'MERGE '/upsert).
Айлана-чөйрөнү бөлүштүрүү: Dev/Этап/Прод, экспонаттарды жарнамалоо, кымбат backfill үчүн "кол дарбаза" (manual approval).
Пландаштыруу: cron/убактылуу терезелер + иш-аракет триггерлери (файлдар/партиялар келгенде).
Сырлар: жашыруун менеджерден; DAG кодундагы сырларга тыюу салуу.

python with DAG("dwh_daily", schedule="0  ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims  = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts

5) Маалымат сапаты (DQ) жана сызык

DQ чектери: толуктугу (count, late arrivals), ачкычтардын уникалдуулугу, диапазондору/домендик эрежелери (суммасы ≥ 0, маалымдамадагы валюта).
Иштөө босогосу: катуу токтотуу/таблицанын критикалуулугуна жараша алерт менен soft-fail.
Lineage/каталог: репорттон булакка (таблицалар, мамычалар, метриктер), ээлери, документтер, PII классификациясы.
Схемаларды көзөмөлдөө: автоматтык шайкештик тесттер (backward-/forward-compatible), "бузуучу" өзгөрүүлөр боюнча алерт.

6) моделдөө: SCD, surrogate keys, нормалдаштыруу

SCD2: 'valid _ from/valid _ to/is _ current', surrogate key ('_ sk') жана табигый ачкыч ('_ id').
SCD1: анча маанилүү эмес атрибуттар үчүн кайра жазуу (мисалы, интерфейстин локалы).
Surrogate keys: туруктуу '_ sk' үчүн join, natural keys - уникалдуулук үчүн.
өлчөө нормалдаштыруу: snowflake иерархия терең жерде; болбосо жылдыз үчүн ылдамдык.

7) Инкременталдык моделдер жана партиялаштыруу

Суу белгиси ('updated _ at', 'ingest _ ts'): жаңы/өзгөртүлгөн саптарды гана окуу.
Инкременталдык стратегиялар: бизнес ачкычтар боюнча 'MERGE', партиялар боюнча 'INSERT OVERWRITE', чакан партиялар үчүн 'DELETE + INSERT'.
Партиялаштыруу: датасы/сааты/аймагы боюнча; кластерлөө (sort keys/Z-order) чыпкалоо ачкычтары жана join.
Материалдаштырылган өкүлчүлүктөр: GGR/NGR алдын ала агрегациясы, популярдуу кесилиштердин кэши.

Approx-агрегаттар: HLL/approx_distinct-N. арзан дүкөндөр үчүн

sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);

8) Backfill, reprocessing жана тарых башкаруу

Backfill: ресурстардын жана терезелердин лимиттери менен өзүнчө DAGs; так "чындык терезе" (мисалы, 2024-01-01.. 2025-11-05).
Reprocessing: determinated өзгөрүүлөр → кайталап өтүү бирдей натыйжа берет. Моделдердин кодунун версияларын логикалоо.
Убакыт-саякат/таблицалардын версиялары: тергөө жана DR "логикалык каталар" үчүн ыңгайлуу.
Retraction: Маалыматтарды кайра карап чыгуу саясаты (өчүрүү/оңдоо) протоколдоо менен.

9) CLO/SLA/SLO конвейер

Freshness: Bronze ≤ 1-5 мин, Silver ≤ 15 мин, Gold ≤ 60 мин (мисал).
Ишенимдүүлүк: ТОО ийгиликтүү прогондорунун пайызы ≥ 99. x%.
Аткаруу: p95/p99 узун; партияга убакыт бюджети.
Lag мониторинг: ingest-агымдын артта калуусу, кезектердин тереңдиги, "late data" үлүшү.
Алерталар: сергектиктин/көлөмдүн бузулушу, DQ-фейл, сканерлердин наркынын өсүшү, MV деградациясы.

10) Наркы: болжолдоо жана оптималдаштыруу

Партиялар жана кластерлер сканерлердин көлөмүн азайтат.
ысык маркерлер материалдык (күн/өлкө/буюмдар).
көп колдонулган дашборддор үчүн натыйжалары/MVs кэш.
Кайра баштоо жыштыгын көзөмөлдөө (эч кандай себеп жок "ар бир 5 мүнөт").
TTL: агрессивдүү retenshn Bronze, орто күмүш, узак алтын (гана агрегаттар).
Capacity planning: каталогдук метрика, турнирлердин/кампаниялардын чокуларын болжолдоо.

11) Коопсуздук, PII жана локалдаштыруу

Маалыматтардын классификациясы: PII/финансылык/операциялык.
Шифрлөө: тынч жана транзитте; KMS/ролу негизделген кирүү.
Де-идентификация: хэш/маскировка, ачкычтар менен өзүнчө мамычалар.
Көп тенанттуулук үчүн RLS/бургулоо ('tenant _ id' боюнча).
Локализация: региондор боюнча сактоо жана иштетүү зоналары (EU/TR/LATAM); уруксат берилген жерлерге гана экспорттоо.
Аудит: критикалык таблицаларды окуу/жазуу, каталогго кирүү.

12) Байкоо: метрика, Логи, соода

Конвейердин метрикасы: милдеттердин узактыгы, кезек, каталар, ретра, иштетилген байттардын/саптардын көлөмү, наркы.
Логи: структураланган; корреляция 'trace _ id '/' run _ id'.
Trace: булактан терезеге чейин (ingest → transform → load → BI).
Дашборддор: катмарлардын сергектиги, DAGs ийгилиги, жогорку кымбат суроо-талаптар, p95/p99.

13) Аспаптар (ролдору боюнча көрсөтмөлөр)

Оркестр: DAG-оркестраторлор (пландоочу, ретра, алерт, сырлар менен).
Трансформация: SQL-моделдөө ("код катары моделдер"), бирдиктик-тесттер моделдер, документтер.
DQ/келишимдер: маалымат топтомдоруна текшерүү жана SLA алкактары.
Lineage/каталог: автоматтык түрдө көз карандылык графасын түзүү, ээсин издөө.
Стриминг: терезе/агрегация процессорлору, sink/source коннекторлору.

(Конкреттүү сатуучулар компаниянын жана коопсуздук талаптарына ылайык тандалып алынган.)

14) үлгүлөрү мисалдар

GGR Sheet Shape (жалпыланган SQL)

sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win)  AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;

"Суу белгиси" менен инкременталдык модели

sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermark

DQ-текшерүү (идея)

sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;

-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;

15) Киргизүү чек-тизмеси

1. метрика сөздүгүн аныктоо (GGR/NGR/LTV/Retention) жана ээлери.
2. Bronze/Silver/Gold катмарлары боюнча SLO сергектигин бекитүү.
3. Булактардын келишимдерин стандартташтыруу (схемалар, DQ, SLA).
4. Демпотенттик кадамдар жана обочолонгон сырлар менен DAG графасын түзүңүз.
5. Инкременталдуулукту (MERGE/overwrite партиялары боюнча) жана "суу белгилерин" ишке ашыруу.
6. DQ (критикалык/жумшак текшерүү), сызык жана маалымат каталогу кирет.
7. байкоо жөндөө (метрика, Логи, соода) жана Алерт.
8. Retenshn/TTL жана backfill/reprocessing саясатын киргизиңиз.
9. PII контролдоо, шифрлөө, RLS жана локализацияны камсыз кылуу.
10. Оюн-күндү өткөрүңүз: булактын кулашын, "сындыруучу" схемаларды, массалык backfill.

16) Антипаттерндер

"Бардык үчүн бир түнкү ETL" партиялары жана инкременталдуулугу жок.
Жок DQ жана сызык → карама-каршы отчеттор жана "арбак мергенчилик".
Ар бир башталганда таблицаларды толук кайра иштетүү (наркын жардыруу).
Буферсиз/ретрассыз реалдуу убакытта катуу байланыш.
PII жана коомдук витриналарды сегменттөө жана жашыруу жок аралаштыруу.
retraction/алып салуу саясаты жок (каталарды оңдоо мүмкүн эмес).

Натыйжалары

iGaming туруктуу Conveyor Analytics - бул ELT + катуу DQ/сызык, инкременталдык моделдер, тунук оркестр жана өлчөнүүчү SLO менен катмарлуу моделге агым жүктөө. наркын контролдоо кошуу, PII/локалдаштыруу саясаты, үзгүлтүксүз backfill/DR-машыгуу - жана сиздин аналитикалык платформа ишенимдүү турнир чокулары боюнча масштабдуу болот, керектүү сергектик жана сапаты менен бизнес маалымат жооп берет.