ანალიტიკური კონვეიერები და ETL

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

ანალიტიკური კონვეიერი iGaming- ის „ნედლეულ“ ოპერაციულ მოვლენებს (განაკვეთები, ანაბრები, PSP ვებჰუკები, თამაშების ლოგოები) მეტრიკის სტაბილურ ფანჯარებად აქცევს (GGR/NGR, LTV, retenshny, ანტიფროდიული სიგნალები). დამხმარე პრინციპები: ფენის ერთიანი მოდელი (Bronze/Silver/Gold), ინსტრუმენტული დისციპლინა DQ/lineage, სავარაუდო და idempotence, დაკვირვება და SLO, ღირებულების კონტროლი. გადაწყვეტილებები მიიღება დატვირთვის პროფილის გათვალისწინებით (ტურნირების მწვერვალები), მარეგულირებელი (PII/ლოკალიზაცია) და ბიზნესის მოთხოვნების გათვალისწინებით, მონაცემების განახლებისთვის.

1) არქიტექტურები: ETL vs ELT, batch vs stream

ETL (Extract - Transform - Load): ტრანსფორმაციები დატვირთვამდე DWH- ში. შესაფერისია იქ, სადაც ტრანსფორმაციებს სჭირდება კონტროლირებადი გარემო/საიდუმლოებები „ღრუბელში“.
ELT (Extract - Load - Transform): ნედლეული ტბაში/Lakehouse/DWH, შემდეგ SQL/ძრავა (dbt/SQL სკრიპტები). მოსახერხებელია სვეტების ძრავები და მოქნილი გამეორება.
Batch: დაგეგმილი ფანჯრები (ყოველ 5/15/60 წუთში, nightly). იაფი და პროგნოზირებადი.
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP). near-real-time (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, წინამორბედი (დღეები/ქვეყნები/პროდუქტები).

დადებითი: რეპროდუქცია, გამჭვირვალე ევოლუცია, სხვადასხვა SLO და TTL ფენებში.

3) წყაროები და დატვირთვა: CDC, outbox, ფაილები

CDC (Change Data Capture): ცვლილებების ნაკადები OLTP (Postgres/MySQL) - დან, წესრიგისა და იდემპოტენტურობის გარანტიით.
Outbox შაბლონი: მოვლენები იწერება ცხრილში/outbox- ის კოლექციაში მომსახურების გარიგებებში, კონექტორი აქვეყნებს საბურავებს/ტბას.
ფაილების დატვირთვა: PSP გადმოტვირთვის, პარტნიორობის ანგარიშები; გამოიყენეთ მანიფესტები, დუბლის კონტროლი (checksum) და მისაღები კატალოგები.

პრაქტიკა: წყაროების ვერსია (schema ვერსია), თითოეული წყაროსთვის - ველების ხელშეკრულება და ხარისხის მოლოდინები.

4) ორკესტრი: DAG, დამოკიდებულება, დუპლექსი

DAG: აშკარა დამოკიდებულება (raw - staging - dims - facts - marts).
დავალებების idempotence: მეორე გაშვება გვერდითი მოვლენების გარეშე (წვეულება-overwrite, 'MERGE '/upsert).
გარემოსდაცვითი გამიჯვნა: Dev/Stage/Stage, არტეფაქტების პოპულარიზაცია, ძვირადღირებული ზურგჩანთისთვის „სახელმძღვანელო კარიბჭე“.
დაგეგმვა: 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, ვალუტა საცნობარო წიგნში).
მოქმედების ბარიერი: მკაცრი გაჩერება/რბილი ფალეტი ალერტით, ცხრილის კრიტიკულობის მიხედვით.
ხაზის/კატალოგის: რეპორტიდან წყაროსკენ (ცხრილები, სვეტები, მეტრიკა), მფლობელები, დოკუმენტაცია, 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 - უნიკალურობისთვის.
გაზომვების ნორმალიზაცია: თოვლი, სადაც იერარქიები ღრმაა; წინააღმდეგ შემთხვევაში, ვარსკვლავი სიჩქარეზე.

7) სავარაუდო მოდელები და წვეულება

წყლის ნიშანი ('განახლება _ at', 'ingest _ ts'): წაიკითხეთ მხოლოდ ახალი/შეცვლილი ხაზები.
სავარაუდო სტრატეგიები: 'MERGE' ბიზნეს კლავიშებში, 'INSERT OVERWRITE' პარტიებისთვის, „DELETE + INSERT“ მცირე ნაწილებისთვის.
განაწილება: თარიღი/საათი/რეგიონი; კლასტერიზაცია (sort keys/Z-order) ფილტრაციის და join კლავიშებზე.
მატერიალიზებული წარმოდგენები: GGR/NGR- ის წინასწარ დანერგვა, პოპულარული მონაკვეთების ქეში.
Approx აგრეგატები: HLL/approx _ distinct იაფი top-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: DAG- ის ცალკეული რესურსები და ფანჯრები; მკაფიო „ჭეშმარიტების ფანჯარა“ (მაგალითად, 2024-01-01.. 2025-11-05).
Reprocessing: დეტერმინისტული ტრანსფორმაციები და განმეორებითი პროგონი ერთსა და იმავე შედეგს იძლევა. მოდელის კოდის ვერსიების ლოდინი.
ცხრილების დრო/ვერსია: მოსახერხებელია გამოძიებისთვის და DR „ლოგიკური შეცდომებისთვის“.
Retraction: მონაცემთა მიმოხილვის პოლიტიკა (წაშლა/კორექტირება) პროტოკოლით.

9) CLO/SLA/SLO კონვეიერი

სიახლე: Bronze - 1-5 წუთი, Silver - 15 წუთი, Gold - 60 წუთი (მაგალითი).
საიმედოობა: წარმატებული DAG პროგონების პროცენტი 99. x%.
პროდუქტიულობა: p95/p99 კვანძების ხანგრძლივობა; დროის ბიუჯეტი პარტიისთვის.
Lag მონიტორინგი: ინგესტის ნაკადის ჩამორჩენა, რიგების სიღრმე, „გრძელი მონაცემების“ წილი.
ალერტები: სიახლეების/მოცულობის დარღვევა, DQ-fayla, სკანების ღირებულების ზრდა, MV- ის დეგრადაცია.

10) ღირებულება: პროგნოზირება და ოპტიმიზაცია

მხარეები და მტევნები ამცირებენ სკანების მოცულობას.
ცხელი მარკერების მატერიალიზაცია (დღეები/ქვეყნები/პროდუქტები).
შედეგების ქეში/MVs ხშირად გამოყენებული დაშბორდებისთვის.
გადატვირთვის სიხშირის კონტროლი (მიზეზის გარეშე „ყოველ 5 წუთში“).
TTL: აგრესიული retenshing Bronze, შუა Silver, გრძელი Gold (მხოლოდ აგრეგატები).
Capacity planning: კატალოგის მეტრიკა, ტურნირების/კამპანიების მწვერვალების პროგნოზი.

11) უსაფრთხოება, PII და ლოკალიზაცია

მონაცემთა კლასიფიკაცია: PII/ფინანსური/ოპერაციული.
დაშიფვრა: მარტო და ტრანზიტში; KMS/როლი-ბაზაზე წვდომა.
დე იდენტიფიკაცია: ჰაშირება/შენიღბვა, ცალკეული სვეტები კლავიშებით.
RLS/ბუჩქები მულტფილმის ტენანტობისთვის ('tenant _ id').
ლოკალიზაცია: შენახვისა და დამუშავების ადგილები რეგიონებში (EU/TR/LATAM); ექსპორტი მხოლოდ ნებადართულ ადგილებში.
აუდიტი: კითხვა/ჩაწერა კრიტიკულ ცხრილში, დირექტორიაზე წვდომა.

12) დაკვირვება: მეტრიკა, ლოგოები, ტრეისი

კონვეიერის მეტრიკა: დავალებების ხანგრძლივობა, რიგები, შეცდომები, ჭიდაობა, დამუშავებული ბაიტის/ხაზების მოცულობა, ღირებულება.
ლოგიკა: სტრუქტურირებული; 'trace _ id '/' run _ id' კორელაცია.
ტრეიდინგი: წყაროდან ფანჯარამდე (ingest - transform - load - BI).
დაშბორდები: ფენების სიახლე, DAG- ის წარმატება, ყველაზე ძვირადღირებული მოთხოვნა, p95/p99.

13) ინსტრუმენტები (მითითებები როლებზე)

ორკესტრი: DAG ორკესტრები (გრაფიკით, რეტრატორებით, ალერტებით, საიდუმლოებებით).
ტრანსფორმაციები: SQL მოდელირება („მოდელები, როგორც კოდი“), მოდელების ერთეული, დოკუმენტაცია.
DQ/კონტრაქტები: ინსპექტირების ჩარჩოები და SLA მონაცემთა პაკეტებისთვის.
ხაზები/კატალოგი: დამოკიდებულების გრაფიკის ავტომატური მშენებლობა, მფლობელის ძებნა.
ნაკადი: პროცესორები/აგრეგატები, sink/source კონექტორები.

(კონკრეტული გამყიდველები შერჩეულია კომპანიის დასტის ქვეშ და უსაფრთხოების მოთხოვნები.)

14) შაბლონების მაგალითები

GGR ფანჯრის შაბლონი (განზოგადებული 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. ჩაწერეთ სიახლის SLO Bronze/Silver/Gold ფენების მიხედვით.
3. სტანდარტიზებული წყაროების კონტრაქტები (სქემები, DQ, SLA).
4. ააშენეთ DAG გრაფიკი იდემპოტენტური ნაბიჯებით და იზოლირებული საიდუმლოებებით.
5. გააცნობიერეთ სავარაუდო (MERGE/overwrite ნაწილებად) და „წყლის ნიშნები“.
6. ჩართეთ DQ (კრიტიკული/რბილი შემოწმებები), ხაზები და მონაცემთა კატალოგი.
7. ეს დაკვირვება (მეტრიკა, ლოგოები, ტრეისი) და ალერტები.
8. შეიყვანეთ retenshn/TTL და backfill/reprocessing პოლიტიკა.
9. უზრუნველყეთ PII კონტროლი, დაშიფვრა, RLS და ლოკალიზაცია.
10. ჩაატარეთ თამაშის დღე: წყაროს დაცემის იმიტაცია, რომელიც „არღვევს“ სქემებს, მასობრივი ზურგჩანთა.

16) ანტიპატერები

„ერთი ღამის ETL ყველაფრისთვის“ წვეულებებისა და სავარაუდოობის გარეშე.
DQ და ხაზის არარსებობა არის კონფლიქტური მოხსენებები და „მოჩვენებითი ნადირობა“.
ცხრილების სრული დამუშავება თითოეული გაშვების დროს (ღირებულების აფეთქება).
რეალურ დროში მკაცრი ლიგატი ბუფერების/რეაგირების გარეშე.
PII და საზოგადოებრივი ფანჯრის შერევა სეგმენტაციისა და შენიღბვის გარეშე.
retraction/წაშლის პოლიტიკის ნაკლებობა (შეცდომების გამოსწორება შეუძლებელია).

შედეგები

IGaming- ში სტაბილური ანალიტიკური კონვეიერი არის ELT + სტრიმინგის დატვირთვა ფენოვან მოდელში, მკაცრი DQ/ხაზით, სავარაუდო მოდელებით, გამჭვირვალე ორკესტრით და გაზომილი SLO. დაამატეთ ღირებულების კონტროლი, PII/ლოკალიზაციის პოლიტიკა, რეგულარული backfill/DR სავარჯიშოები - და თქვენი ანალიტიკური პლატფორმა საიმედოდ იქნება მასშტაბური ტურნირის მწვერვალებზე, უპასუხებს ბიზნესს საჭირო სიახლის და ხარისხის მონაცემებზე.