Data Lake და ცენტრალიზებული შენახვა
(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)
მოკლე რეზიუმე
Data Lake არის ნედლეულის ცენტრალიზებული შენახვის ძირითადი ფენა და კონსოლიდირებული Datasets. IGaming- ისთვის, იგი იღებს განაკვეთების/გადახდების/თამაშის ლოგოების მოვლენებს, პარტნიორობის გადმოტვირთვას, OLTP- ს CDC- ს და აძლევს მათ ანალიტიკას, ანტიფროდს, CRM- ს და BI- ს. თანამედროვე პრაქტიკა - Lakehouse: ღია სვეტების ფორმატები + ACID ფირფიტის ფენა + ერთჯერადი კატალოგი + გარიგებები/მონაცემთა ვერსიები. წარმატების გასაღებია სქემებისა და განაწილების დისციპლინა, ღირებულების მენეჯმენტი, PII უსაფრთხოება და მკაცრი ოპერაციული კულტურა (DQ, ხაზოვანი, DR).
მონაცემთა ტბის როლი iGaming პლატფორმაში
ანალიტიკოსებისთვის ჭეშმარიტების ერთი წერტილი: ნედლეული და გაწმენდილი მონაცემების შენახვა, მიუხედავად წყაროსა და ფორმატისა.
მოქნილობა: batch და streaming მხარდაჭერა (CDC/კონექტორები, ღონისძიების ნაკადები).
ევოლუცია: ნედლეული Bronze- დან კონფორმული Silver და Gold ბიზნეს ფანჯრები.
პასუხისმგებლობის გამიჯვნა: პრო-სერვისები იწერება საბურავზე/სტაგნაციაში, ანალიტიკა/ML მოიხმარს ტბის ფენებს.
არქიტექტურული მოდელები: Lake vs Lakehouse
Data Lake (S3/ADLS/GCS + Parquet/ORC): schema-on-read, იაფი საცავი, ფორმატის მოქნილობა.
Lakehouse (Delta/Iceberg/Hudi ზემოთ Parquet): ACID გარიგებები, upsert/merge, time-travel, კომპაქტური ფაილები, ვაკუუმი, ინდექსაცია/კლასტერიზაცია.
პრაქტიკა: Lakehouse სასარგებლოა iGaming- ისთვის, როგორც მთავარი ფენა, ხოლო გარე OLAP (ClickHouse/BigQuery/Snowflake/Pinot) - როგორც ფანჯრები და სპეციალური ძრავები.
მედალიონის ფენის მოდელი
Bronze (Raw/Staging): უმი წყაროების ფაილები (CDC, log dumps, პარტნიორი CSV, webhooks). მინიმალური ვალიდაცია, „როგორც არის“.
Silver (Conformed): გაწმენდა/დედობა, ვალუტის/დროის ზონების ნორმალიზაცია, ტიპების მიტანა, SCD გაზომვები, თანმიმდევრული გასაღებები.
Gold (Marts/Serving): განყოფილებები GGR/NGR/LTV/Retention, მატერიალიზებული ფანჯრები BI/CRM/ანტიფროდისთვის.
TTL: აგრესიული Bronze, ზომიერი Silver- ზე, გრძელვადიანი Gold განყოფილებებში.
ფორმატები და ფირფიტები
სვეტები: Parquet (დე ფაქტო სტანდარტი), ORC.
ღია ფირფიტის ფორმატები (ACID):- Delta Lake - გარიგებები, 'MERGE', time-travel, ოპტიმიზაცია/ვაკუუმი, Z-order.
- Apache Iceberg - ცხრილები მანიფესტებით/სნაიპშოტებით, ფარული ნაწილიზაციით, 'MERGE/DELETE/განახლება', დროის ბილიკი.
- Apache Hudi - copy-on-write/merge-on-read, upsert-ოპტიმიზაცია, სავარაუდო ამონაწერები.
- არჩევანი გააკეთეთ ეკოსისტემისა და მოთხოვნების შესაბამისად, სქემების ევოლუციის/ნაკადის/მოქნილობის მიხედვით.
კატალოგი და მეტასტორი
ერთი კატალოგი (Hive Metastore/Unity/Glue/Platform კატალოგები) ინახავს სქემებს, წვეულებებს, ვერსიებს, უფლებებს.
მოთხოვნები: გარიგების კოორდინაცია ფირფიტასთან, რამდენიმე ძრავის მხარდაჭერა (Spark, Trino/Presto, Flink, dbt), audit/lineage.
სქემები და ევოლუცია
Schema contract: ჩაწერეთ სავალდებულო ველები, ტიპები, სემანტიკა; ოფიციალური წყაროები ('schema _ version').
ევოლუცია: სურვილისამებრ ველების დამატება, მიგრაციის გარეშე დარღვევების აკრძალვა; ავტომატური გამშვები სქემები.
PII სეგმენტი: მგრძნობიარე ველები - ცალკეულ სვეტებში/ცხრილში დაშიფვრის და ცალკეული უფლებებით.
განლაგება და lay-out მონაცემები
თარიღი/საათი - მოვლენების ძირითადი გასაღები; დამატებითი ველები: 'country', 'product', 'tenant _ id'.
Hive-style путь: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001. parquet`.
კლასტერიზაცია/დახარისხება: Z-order/Sort keys ხშირად გაფილტრულ მინდვრებში (player _ id, country).
ფაილის ზომა: კოცნა 128-1024 MB; მოერიდეთ მცირე ფილმებს (იხ. ქვემოთ).
ვირტუალური სვეტები (Iceberg/Delta) ფარული პარტიზაციისთვის.
მცირე ფილმების პრობლემა და კომპაქტური
წყაროები ჭრიან პატარა მონკებს - სკანებისა და მეტამონაცემების დეგრადაციას.
გამოსავალი: პერიოდული optimize/coalesce (coalesce), კომპაქტური დავალებების დამგეგმავი, ingestion mikro-bundle, 'autOptimize' (თუ ხელმისაწვდომია).
merge-on-on-on-write პოლიტიკა არის ბალანსი ლატენტობასა და კითხვის სიჩქარეს შორის.
ინესტი: batch, stream, CDC
CDC OLTP (Debezium/კონექტორები) - Bronze (წუთიანი სიახლე).
Stream (Kafka/Flink/Spark Structured Streaming) - Silver/Gold სავარაუდო (upsert/merge).
Batch (პარტნიორობის მოხსენებები/CSV/JSON) - მანიფესტებით „მიმღების“ საშუალებით, ჩეკსუმის დუბლების კონტროლი.
Idempotence: გასაღებები (idempotence _ key), დედაპლატი (key, ts), „წყლის ნიშნები“ (watermarks) მოგვიანებით ჩამოსული ჩანაწერებისთვის.
მონაცემთა ხარისხი (DQ) და ხაზები
DQ შემოწმებები: სისრულე, კლავიშების უნიკალურობა, დიაპაზონი, რეფერენდუმის მთლიანობა (ქვეყნების/ვალუტის სიები), ბიზნეს წესები (GGR-0).
ხაზები: დამოკიდებულების გრაფიკი მოხსენებიდან წყაროზე, მოდელის კოდის ვერსია და მაგიდის სნაიპშოტი.
სქემების კონტროლი: ავტომატური საკომუნიკაციო ტესტები, რომლებიც ბლოკავს „დარღვევის“ ცვლილებებს.
ჩამოტვირთვის აუდიტი: ვინ/როდის/რამდენი, უარყოფილი ნაწილები, retrais.
Serving და წვდომა
SQL ძრავები: Spark/Trino/Presto ad-hoc და ტრანსფორმაციებისთვის; dbt ELT მოდელებისთვის.
ნამდვილი დრო/ნამდვილი დრო: Pinot/Druid/ClickHouse, როგორც ფანჯრები; Lakehouse არის წყარო სავარაუდო სინკის საშუალებით.
Data Sharing: გარე გუნდებისთვის ცხრილების/სნაიპერების ბურთი ასლების გარეშე (თუ მხარს უჭერს ფორმატს).
უსაფრთხოება, PII და მულტფილმი-ტენანტობა
დაშიფვრა: at-rest (KMS) და in-transit (TLS).
IAM/RBAC/ABAC: როლები დირექტორიის/ცხრილის/სვეტების/სტრიქონების დონეზე (შენიღბვა, დინამიური პოლიტიკა).
რეგიონების სეგმენტი (ევროკავშირის/თურქეთის/ლატამის ლოკალიზაცია): სატანკო და კომპიუტერული ტყვიების იზოლაცია.
მრავალ ტენანტობა: namespace/კატალოგები და ბილიკების პრეფიქსი, ფილტრები 'tenant _ id', სურვილისამებრ - row-level policies.
წვდომის აუდიტი: კითხვის ლოგოები/მეტამონაცემების ცვლილებები, რეცენზია და არაოდიფიცირებული ჟურნალები.
ღირებულების მენეჯმენტი
შენახვის კლასები: ცხელი (ხშირად წაკითხული) სტანდარტულ კლასში, არქივი - ცივ/Glacier კლასებში TTL პოლიტიკოსებთან.
განაწილება/მტევანი ამცირებს სკანებს $ დოლარზე ნაკლები.
მატერიალიზებული ფანჯრები ძვირადღირებული მოხსენებისთვის; BI შედეგების ქეში.
კომპაქტური და „ფაილის სწორი ზომა“ ნაკლებია, ვიდრე მეტამონაცემები და I/O.
კვოტები და ბიუჯეტი: კომპლექტის მტევანი/ჯობებზე შეზღუდვები, dataset/გუნდის ღირებულების ანგარიშები.
ნაგვის მოცილება: 'VACUUM/REWRITE' ფირფიტის ფორმატებში, TTL Bronze.
DR და რეპროდუქცია
ცხრილების (time-travel) და კატალოგის სლაიდების ვერსია.
სატანკო და მეტამონაცემების ჯვარედინი-რეგიონალური რეპლიკაცია.
PITR: ცხრილების გარიგების ჟურნალების შენახვა (Delta/Iceberg/Hudi) და pipline logs.
თამაშის დღე: რეგულარული სავარჯიშოები რეგიონების აღდგენისა და გადართვისთვის.
დაკვირვება და SLO
SLO სიახლე: Bronze - 5 წუთი, Silver - 15-30 წუთი, Gold - 60 წუთი (მაგალითი).
მეტრიკა: ფაილების მოცულობა/ქულა, პარკეტის ფაილის საშუალო ზომა, სკანირების დრო, გამოტოვებული ნაწილების წილი, კომპაქტური სიხშირე, ღირებულება/თარიღი, DQ შეცდომები, დაგვიანებული მონაცემები.
ალერტები: მცირე ფილმების ზრდა, ფასის ზრდა, p95/p99 დეგრადაცია, DQ/სქემების დარღვევა, ნაკადის სინქსის ჩამორჩენა.
ნეიმინგის და ბილიკების კონვენციები (შაბლონი)
s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/ # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/თარიღების სახელები: 'bets _ raw', 'payments _ cdc', 'players _ silver', 'mart _ ggr _ daily'.
მეტამონაცემების სვეტები: 'ingest _ ts', 'წყარო', 'schema _ version', 'trace _ id', 'tenant _ id'.
მაგალითები (განზოგადებული)
1) Iceberg: Silver ცხრილი ფარული თარიღით
sql
CREATE TABLE silver. bets (
bet_id BIGINT,
player_id BIGINT,
country STRING,
stake DECIMAL(18,2),
win DECIMAL(18,2),
event_ts TIMESTAMP,
ingest_ts TIMESTAMP,
schema_version INT
)
PARTITIONED BY (days(event_ts))
TBLPROPERTIES ('format-version'='2');2) Delta: CDC- სგან სავარაუდო upsert
sql
MERGE INTO silver. players t
USING bronze. players_cdc s
ON t. player_id = s. player_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;3) TTL პოლიტიკა Bronze- სთვის (იდეა)
bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)ჩეკის განხორციელების სია
1. შეარჩიეთ ფირფიტის ფორმატი (Delta/Iceberg/Hudi) და კატალოგი; კოორდინაცია გაუწიეთ ძრავებს (Spark/Trino/Flink/dbt).
2. განსაზღვრეთ მედალიონის ფენები, TTL წესები და გუნდების პასუხისმგებლობა.
3. დააფიქსირეთ სქემა კონტრაქტები, ევოლუციის კონტროლი, PII სეგმენტი და დაშიფვრა.
4. შეიმუშავეთ lay-out: წვეულებები, მრავალფეროვანი გასაღებები, ფაილის მიზნობრივი ზომა; ჩართეთ compaction.
5. ingest პარამეტრები (CDC/stream/batch) იდემპოტენტურობით და ბაბუით.
6. ჩართეთ DQ/lineage, მეტამონაცემების კატალოგი და აუდიტი.
7. განსაზღვრეთ SLO ახალი/ღირებულება, დაშბორდები მეტრიკი და ალერტები.
8. ორგანიზება DR: Snapshots/რეპლიკაცია/აღდგენა + რეგულარული წვრთნები.
9. სტანდარტიზდება ნეიმინგი და ბილიკები, მეტაკოლონები ('ingest _ ts', 'წყარო', 'schema _ version').
10. გამოიტანეთ ოქროს ფანჯრები და რეალური დრო სერვინგი შესაფერისი OLAP/RT ძრავებში.
ანტიპატერები
ერთი ზოგადი „ჩანთა“ ფენების გარეშე და TTL არის ქაოსი და ღირებულების აფეთქება.
განლაგება მხოლოდ დროში, ქვეყნის/პროდუქტის გამოკლებით, მძიმე სკანებია.
ნაკადები, რომლებიც ქმნიან ათასობით მცირე ფაილს/საათს, კომპაქტურობის გარეშე.
სქემების კონტროლის არარსებობა და DQ არის „დარღვევა“ ცვლილებები და ცნობების უნდობლობა.
PII- ის შერევა ოქროს ფანჯრებით, შენიღბვის/უფლებების განცალკევების გარეშე.
დირექტორიისა და ფირფიტის პოლიტიკოსის ნაცვლად, საბანკეტო დონეზე წვდომის უფლებების სქემა.
შედეგები
IGaming- ისთვის თანამედროვე Data Lake არის Lakehouse ღია ფირფიტის ფორმატით, ერთი კატალოგით და მედალიონის მოდელით. სქემების/წვეულებების დისციპლინა, კომპაქტური მცირე ფილმების, DQ/ხაზის, PII უსაფრთხოების და ღირებულების ჰიგიენის დისციპლინა გადაიქცევა სტაბილურ საძირკველად: იაფი შესანახად, სწრაფი კითხვისთვის, პროგნოზირებადი SLO- სთვის და მზადდება DR- სთვის. ასეთი საფუძველი ფართოვდება ტურნირის მწვერვალებისთვის და მხარს უჭერს ბატს ანალიტიკა და ნამდვილი დროის ფანჯრები.