ETL/ELT პროცესები

1) დანიშნულება და კონტექსტი

ETL/ELT კონვეიერები უზრუნველყოფენ პროგნოზირებულ დატვირთვას, ტრანსფორმაციას და მონაცემების გამოქვეყნებას საანგარიშო მონაცემებისთვის (GGR/NGR, რეგულატორები), ანალიტიკოსები/ML და ოპერატიული პანელები.

ETL: გადაქცევა დატვირთვაზე DWH/Lakehouse (ნაკლებად ხშირად თანამედროვე სტეკებში).
ELT: ჯერ დატვირთეთ Lakehouse (Bronze/Silver), შემდეგ კი SQL/ძრავებად გადაქცევა (რეკომენდებულია).

2) სტანდარტული არქიტექტურა

1. Ingest/Edge: HTTP/gRPC/Batch, CDC OLTP- დან, პროვაიდერის S3/FTP გადმოტვირთვისთვის.
2. Bronze (raw, append-only): უცვლელი payload's, წვეულებები თარიღი/ბაზარი/ტენანტი.
3. Silver (clean/conform): ნორმალიზაცია, დედაპლატი, საცნობარო წიგნები, SCD, FX/Timesons.
4. ოქროს (სერვერი): დენორმალიზებული ფანჯრები BI/მარეგულირებელი/მოდელის ქვეშ.
5. ორკესტრი: Airflow/Dagster/Prefect (DAG 'და, SLA, retray, ძვრები).
6. DQ/Contracts: Schema Registry + DQ-как-код, consumer-driven tests.
7. დაკვირვება: payplines, lineage, logs, cost dashbords.

3) ETL vs ELT არჩევანი

პრაქტიკა: iGaming- ში - ELT + CDC: სწრაფად დატვირთული, შემდეგ სტანდარტიზებული და მიგვაჩნია.

4) ჩანართები და CDC

• CDC (Debezium/log რეპლიკაცია): ცვლილებები OLTP - Bronze - MERGE Silver- ში.
• დროულად Watermark: 'განახლება _ at> max _ loaded _ ts'.
• Hesh: შედარება 'md5 (wow)' დეტალური ცვლილებებისთვის.
• Upsert/MERGE: დატვირთვის იდემპოტენტურობა.

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) კონტრაქტები და სქემები

Schema-first: JSON/Avro/Protobuf in Registry; 'schema _ version' მოვლენებში/ფაილებში.
ევოლუცია: უკუკავშირის დამატება; breaking - '/v2 '+ ორმაგი ჩანაწერი.
სავალდებულო ველები: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market'.

6) DQ კოდი (მინიმალური ნაკრები)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: unique_tx # uniqueness of transactions type: unique columns: [transaction_id]
severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

7) ორკესტრი: DAG 'და დამოკიდებულია SLA

DAG დიზაინი: წყაროებიდან ფანჯრებამდე; მკაფიო დამოკიდებულება დავალებებს შორის.
Retrai და idempotence: backoff, „სუფთა“ გამეორება, checkpoint 'y.
ძვრები (catchup): გამოტოვებული პერიოდების სისუფთავე დოგონი.
SLA: მაგალითად, Gold. daily მზად არის ადგილობრივი დროით 06:00 საათამდე; გაფრთხილებები დარღვევების შესახებ.
პარამეტრიზაცია: ბაზრები/ტენანტები/თარიღები vars- ის საშუალებით; ერთი job შაბლონი.

8) Idempotence და exactly-once

ingest- ზე: დუბლიკატები შეიძლება იყოს dedup '(event _ id, წყარო)'.
დამუშავებისას: upsert/merge; ტრანსფორმაციების „სუფთა“ ფუნქციები.
სინკში: გარიგების კომუნები ან იდუმალი ჭორები; „ორმაგი აღრიცხვის“ კონტროლი.
Outbox/Inbox: დომენის მოვლენების გარიგების გამოქვეყნება OLTP- დან.

9) Backfill и reprocessing

Backfill: პირველადი შევსება/ისტორიული დიაპაზონი.
რეპროდუქცია: გადაანგარიშება ლოგიკის/კორექტირების შეცვლისას.
Guardrails: დიაპაზონის ლიმიტები, კვოტები, დროის ფანჯრები, dry-run მეტრული შედარებით.
მარკირება: 'logic _ version', 'reprocessession _ at', 'recalc _ reason'.

10) ვერცხლის/ოქროს მოდელირება

Silver (3NF/BCNF): ფაქტები 'fact _ bets/payments/payouts', გაზომვები 'dim _ users/games/providers/barkets (SCD II II)', ვალუტის/დროის სტანდარტიზაცია.
გოლდი: დენორმალიზებული ფანჯრები BI/მარეგულირებელი/მოდელების ქვეშ; უცვლელი საექსპორტო პაკეტები (WORM) + ხელმოწერა.

ოქროს მაგალითი: GGR Daily

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

11) კონფიდენციალურობა და რეზიდენცია

PII მინიმიზაცია: ტოკენიზაცია; რეალური ID mappings იზოლირებული წრე.
RLS/CLS: როლზე/იურისდიქციებზე წვდომის პოლიტიკოსები, შენიღბვა.
Residency: ინდივიდუალური კატალოგები/გასაღებები EEA/UK/BR; ჯვრის რეგიონალური join აკრძალვის გარეშე.
DSAR/RTBF & Legal Hold: შერჩევითი რედაქტორები, WORM ანგარიშგების არქივები, ექსპორტის აუდიტი.

12) დაკვირვება და SLO

• Freshness Silver p95-15 წთ; Gold daily მზად არის 06:00 საათამდე. დრო.
• Completeness ≥ 99. 5%, Validity (სქემა) - 99. 9%.
• Job- ის წარმატება 99. 0%, MTTR ინციდენტები - 24-48.

დაშბორდები: Freshness heatmap, DQ ზარალის ძაბვა, cost/query & cost/GB, ხაზის გრაფიკი.

13) პროდუქტიულობა და ღირებულება

განაწილება: თარიღი/ბაზარი/ტენანტი; კლასტერიზაცია/Z- შეკვეთა ფილტრებში.
ფორმატები: Parquet + ACID (Delta/Iceberg/Hudi), კომპრესია და სტატისტიკა.
კომპაქტური: მცირე ფილმების წინააღმდეგ ბრძოლა (OPTIMIZE/VACUUM).
მატერიალიზაცია: სტაბილური ერთეულები; თავიდან აიცილოთ გიგანტური ფრენა.
Chargeback: ბიუჯეტები, ამანათების კვოტები/backfill; დაბალი დატვირთვის ფანჯრების დაგეგმვა.

14) DAG- ის ტიპიური ამოცანების მაგალითები (ფსევდო კოდი Airflow)

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15) პროცესები და RACI

R (Responsible): Data Engineering (DAG "და, Silver/Gold მოდელები), Data Platform (infre, Registry, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (ინფორმირებული): BI/პროდუქტი/მარკეტინგი/ოპერაციები.

16) გზის განხორციელების რუკა

1. Lakehouse Bronze/Silver (ACID) + CDC/ნიშნები Payments/Gameplay.

2. DQ-როგორც კოდი (10-15 წესები) და ძირითადი დაშბორდები Freshness/Completeness.

3. პირველი ოქროს ვიტრინა (GGR Daily) SLA- დან „06:00 საათამდე“, WORM ექსპორტი ხელმოწერით.

4. DAG ორკესტრაცია და ალერტები SLA/DQ.

• დომენების გაფართოება, SCD II users/games/providers.
• სემანტიკური მეტრიკის ფენა; ხაზოვანი/იმპაქტიური ანალიზი; backfill/reprocessing პროცედურები.
• რეგიონალიზაცია (EEA/UK), RLS/CLS, ღირებულების კონტროლი (კვოტები/chargeback).

• Replay simulator (what-if), ვიტრინის/მეტრიკის დოკუმენტაციის ავტომატური წარმოება.
• Cost ოპტიმიზაცია (კლასტერიზაცია, მატერიალიზაცია, TTL, კომპონენტი).
• აღდგენილია DR- სავარჯიშოები და time-travel.

17) ჩეკის სია გაყიდვამდე

• კონტრაქტები/სქემები რეგისტერში, თავსებადობის ტესტები მწვანეა.
• CDC/ნიშნები და MERGE იდემპოტენტურია; დედაპლატი ინჯესტზე.
• DQ წესები აქტიურია (critical - fail + DLQ), SLA დაშბორდები.
• ოქროს ფანჯრები დოკუმენტირებულია, მეტრული ფორმულა სემანტიკურ ფენაში.
• RBAC/ABAC, დაშიფვრა, რეზიდენცია, DSAR/RTBF/Legal Hold შემოწმებულია.
• კომპაქტური/OPTIMIZE/VACUUM გრაფიკის მიხედვით; backfill/raples ლიმიტები.
• Runbook 'და ინციდენტები და რეპროდუქცია, ექსპორტის აუდიტი (WORM + hash).

18) ანტი შაბლონები და რისკები

Full reload „მხოლოდ შემთხვევაში“: გამოიყენეთ CDC/ნიშნები.
ნედლეული და საანგარიშო მონაცემების ნაზავი: ცალკე შეინახეთ Bronze/Silver/Gold.
DQ და ხაზის ნაკლებობა: არ არსებობს მტკიცებულება და რეპროდუქცია.
PII ანალიტიკურ ფენებში: იზოლირება mappings, გამოიყენეთ CLS/RLS.
მონოლითური „ღამის“ ჯობი: წვეულებების პარალელურად.
ფასის უგულებელყოფა: მიყევით მცირე ფილმებს, მოახდინეთ აგრეგატების მატერიალიზაცია, შეიტანეთ კვოტები.

19) გლოსარიუმი (მოკლედ)

ETL/ELT - ამონაწერი/ტრანსფორმაცია/დატვირთვა (დატვირთვის შემდეგ).
CDC - ცვლილებების დაჭერა.
SCD - გაზომვების ისტორიალიზაცია (I/II/III).
WORM - საანგარიშო პაკეტების უცვლელი შენახვა.
Time-travel - ცხრილების ისტორიული ვერსიების კითხვა.

20) შედეგი

თანამედროვე ETL/ELT არ არის სკრიპტები, არამედ კონტროლირებადი პლატფორმა: კონტრაქტები და DQ, idempotent ნიშნები/CDC, Bronze/Silver/Gold ფენების დისციპლინა, დაკვირვება და SLO, კონფიდენციალურობა და ეფექტურობა. ამ ხელმძღვანელობის შემდეგ, თქვენ მიიღებთ რეპროდუქციულ და აუდიტორულ კონვეიერებს, რომლებიც სტაბილურად კვებავენ ანგარიშგებას, პროდუქტს და მოდელებს მასშტაბით და სიურპრიზების გარეშე.