GH GambleHub

მონაცემთა ნაკადის არქიტექტურა

1) დანიშვნა და პრინციპები

მიზნები: სწორი, დროული და კომპოზიციური მონაცემების მიწოდება ანალიტიკის, ანგარიშგების, ანტიფროდის, პერსონალიზაციის და ML- სთვის.

პრინციპები:
  • Datas a Product: მკაფიო მფლობელები, კონტრაქტები, SLO და ვერსიები.
  • Schema-first: სქემები სავალდებულოა; ევოლუცია წესების შესაბამისად.
  • Privacy-by-Design: შემცირება PII, ფსევდონიზაცია, დაშვების მენეჯმენტი.
  • Observability-by-Default: ტრეკები, მეტრიკები, ხაზები, ხარისხის პროფილები.
  • Cost-aware: tiered-storage, ხმაურიანი მოვლენების სემპლაცია, კომპრესია.

2) წყაროების და მოვლენების ლანდშაფტი

გარიგება: ანაბრები/დასკვნები, განაკვეთები/გადახდები, პრემიები, chargeback.
მომხმარებლის: სესიები, დაწკაპუნება, კონვერტაცია, RG ლიმიტები, KYC სტატუსები.
ოპერაციული: პროგრამების ლოგოები, შესრულების მეტრიკა, ალერტები.
პროვაიდერები: PSP/KYC/სანქციები/თამაშის სტუდიები (აგრეგატორები).
რეფერენდუმი: თამაშების კატალოგები, ქვეყნების საცნობარო წიგნები/ვალუტები, ტარიფები/გადასახადები.

მოვლენების ტიპიზაცია (მაგალითი):
json
{
"event_time":"2025-10-31T19:20:11Z",
"event_type":"payment. deposit",
"schema_version":"1. 3. 0",
"user":{"id":"U-123","country":"EE","age_band":"18-24"},
"payment":{"amount":200. 00,"currency":"EUR","method":"card","psp_ref":"PSP-222"},
"ctx":{"ip":"198. 51. 100. 10","session_id":"s-2233","trace_id":"f4c2..."}
}

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

1. Ingest ფენა

კარიბჭეები (HTTP/gRPC), CDC კონექტორები (OLTP- დან), რიგები/საბურავები (Kafka/Redpanda), ტელემეტრიული კოლექციონერები.
ვალიდაცია, ნორმალიზაცია, შესასვლელი PII გამოცემა, კონტრაქტირება.

2. Streaming ფენა

ნაკადის ჯობი (Flink/Spark Streaming Streaming/Beam) დუპლიკაციით, watermark, stateful აგრეგატებით.
Fang-out საცავებში და ონლაინ სერვისებში (შუამავალი, ანტიფროდი).

3. Batch ფენა

ორკესტრი (Airflow/Dagster), სავარაუდო დატვირთვები, ბექტესტები და რეტროპროცესები, SCD ტიპები.

4. შენახვა (Lakehouse)

Bronze: ნედლეული მოვლენები (append-only, immutable).
Silver: გაწმენდილი, კონფორმული ცხრილი ხარისხით და ბაბუით.
ოქროს: ფანჯრები/მარტი კონკრეტული შემთხვევებისთვის (BI/მარეგულირებელი/ML).
ფირფიტის ფორმატები ACID (Delta/Iceberg/Hudi), განაწილება ცხელი/თბილი/ცივი ფენებით.

5. სერვინგი და წვდომა

BI/SQL (Trino/Presto/DuckDB), სემანტიკური ფენა (metrics layer), API/GraphQL, Feature Store ონლაინ/ოფლაინ კოორდინაციისთვის.

6. ჰოვერნანსი და უსაფრთხოება

კატალოგი/ლინგვისტიკა, DQ წესები, პოლიტიკური წვდომის ძრავა (RBAC/ABAC), შენიღბვა/ტოკენიზაცია, მოხსენების WORM არქივი.

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

მონაცემთა კონტრაქტები: OpenAPI/AsyncAPI/JSON Schema/Avro.
ევოლუცია: სემანტიკური ვერსიები; backward-compatible ცვლილებები - არასასურველი ველების დამატება; breaking - მხოლოდ '/v2 'და ორმაგი ჩაწერა მიგრაციის პერიოდისთვის.
რეგისტრატორები: Schema Registry, დომენის კატალოგი (Payments, Gameplay, Marketing).

5) ინტეგრაციის ნიმუშები

CDC (Change Data Capture): OLTP- დან საბურავამდე (Debezium), განლაგება დომენის გასაღებებზე.
Outbox/Inbox: დომენის ლოგიკის მოვლენების გარანტირებული მიწოდება.
Exactly-Once/Effectively-Once: გარიგებები state- ში, idempotent sink 'და, დედაპლაციის გასაღებები.
Late Data & Watermarks: დაგვიანებული მოვლენების დამუშავება; ფანჯრები allowed lateness.
Reprocessing: idempotent piplines, time-travel, snapshot კორექტირება.

6) Lakehouse მოდელი: bronze/silver/gold

Bronze (raw):
  • დროის წვეულებები (ღონისძიება _ თარიღი) და ბაზარი (იურისდიქცია).
  • მხოლოდ დამატება; საწყისი payload- ის შენახვა ფონიზაციისთვის.
Silver (clean):
  • ნორმალიზებული ტიპები, საცნობარო წიგნები, დუპლიკაცია '(event _ id, event _ time) ".
  • FK- ის გადამოწმება, ვალუტის/დროსონის სტანდარტიზაცია, გამდიდრება.
Gold (serve):
  • დენორმალიზებული ფანჯრები (GGR, RG სკორინგი, LTV, კოჰორტის ცხრილი).
  • განახლებისთვის SLA, BI დანაყოფები და ანგარიშები.

7) მონაცემთა ხარისხი

წესები: დიაპაზონი, დიაპაზონი, უნიკალურობა, სისრულე, რეფერენტული ინტეგრაცია.
პროფილირება: განაწილება, კარდინალობა, ნიშნების „დრიფტი“.
მონიტორინგი: p50/p95 შეფერხება pipline, drop-rate, error budget.
Degradation policy: ავტომატური fallback (ბოლო snapshot), alertes და t- ტესტები მეტრიკისთვის.

DQ ხელშეკრულების მაგალითი (YAML):
yaml table: silver. payments rules:
- name: amount_positive type: range column: amount min: 0. 01
- name: currency_valid type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: unique_tx type: unique columns: [transaction_id]
slo:
freshness_minutes: 15 completeness_percent: 99. 5

8) კონფიდენციალურობა და შესაბამისობა

PII მინიმიზაცია და შენიღბვა: ფსევდო-ID შენახვა, look-up mappings განცალკევება.
რეგიონალიზაცია: გეო-ადგილობრივი ბაქტერიები/კატალოგები (EEA/UK/BR), „მონაცემთა გამიჯვნა“.
იურიდიული ოპერაციები: DSAR/RTBF (გამოთვლილი პროგნოზები და შერჩევითი რედაქტორები), იურიდიული ჰოლდი, უცვლელი ანგარიშების არქივები.
წვდომის ლოგიკა: „მგრძნობიარე“ ცხრილების კითხვის აუდიტი, break-glass და JIT წვდომა.

9) დაკვირვება და კონტროლი

Linege: დამოკიდებულების ავტომატური კვალი წყაროდან ფანჯარამდე.
Paypline მეტრიკა: throughput, lag, failure-rate, cost/GB, cost/query.
ტრეკინგი (OTel): პროგრამებიდან 'trace _ id' გადაიქცევა მოვლენებში და აშენებს მოთხოვნის გზას.
ალერტები: SLO ბიუჯეტები, ახალი/მოცულობის/კარდინალების ანომალიები.

10) წვდომა და უსაფრთხოების მოდელი

მონაცემთა კატეგორიები: public/internal/confidential/restricted.
პოლიტიკოსები: row/column-level უსაფრთხოება; დინამიური შენიღბვა (PAN/IBAN/email).
კლავიშების მართვა: KMS/CMK, დაშიფვრა at-rest/in-transit, როტაცია.
პასუხისმგებლობის სეგრეგაცია: ცალკეული როლები პროდ/ანალიტიკა/ადმინ/რევუერი.

11) მონაცემთა მესა და სასურსათო მიდგომა

Домены: Payments, Gameplay, Marketing, Risk, Compliance.
Data Product: მფლობელი, SLA ახალი, საველე ლექსიკონი, ტესტები, ვერსიები, მოხმარების მეტრიკა.
დომენებს შორის კონტრაქტები: ვერსირებული, პაკეტის თავსებადობით, მომხმარებლის ტესტები (consumer-driven).

12) ფიჩესტორი და ML ნაკადები

Feature registry: მახასიათებლების, წყაროების, ტრანსფორმაციების აღწერა, SLO.
ონლაინ/ოფლაინ კოორდინაცია: ერთი ტრანსფორმაციის კოდი, ონლაინ მატერიალიზაციის შეფერხება 200-500 ms.
დრიფტის მონიტორინგი: PSI/KS, მოდელების ავტო ალერტები და გამოტოვება, PII კონტროლი.
ექსპერიმენტების ჟურნალი: მეტამონაცემები, ვერსიები, reproducibility, სამოდელო რუქები.

13) Finmodel და cost ოპტიმიზაცია

განლაგება და Z-order/Cluster ხშირი პრედიკატებით.
ცივი შენახვა და TTL გამოუყენებელი ცხრილებისთვის, VACUUM.
Materialized views მხოლოდ მოთხოვნის სტაბილური ნიმუშებისთვის.
კვოტები და ბიუჯეტები მძიმე ჯობებისთვის; chargeback გუნდები.

14) რეგიონალური და მულტფილმი-ჩრდილოვანი ტოპოლოგია

Multi-region აქტიური აქტივობა: თემებისა და ცხრილების რეპლიკაცია, დამოუკიდებელი მილის პერიმეტრები.
Failover/DR: RPO/RTO მიზნები, ორკესტრის მეტამონაცემების სლაიდები, აღდგენის შემოწმება.
მრავალ ტენანტობა: დირექტორიების/გასაღებების/კვოტების იზოლაცია, ტენანტის ეტიკეტი _ id.

15) პროცესები და RACI (მოკლედ)

R: მონაცემთა პლატფორმა (ingest, შენახვა, ორკესტრი), მონაცემთა ინჟინერია (ტრანსფორმაცია).
A: Head of Data / Chief Data Officer.
C: კომპლექსი/ლეგალური/DPO, არქიტექტურა, SRE.
I: BI/ანალიტიკა, პროდუქტი, მარკეტინგი, ფინანსები.

16) SLO/SLI ნაკადებისთვის

სიახლე: p95 Silver შეფერხება 15 წუთის განმავლობაში, Gold (daily) მზად არის 06:00 საათზე. დრო.
სისრულე: ევრო 99. მოვლენების 5% T- ს ფანჯარასთან.
სანდოობა: error-rate შემოწმება DQ <0. მოცულობის 5%.
სერვინგის ხელმისაწვდომობა: 99 ევრო. 9% BI/Feature API- სთვის.

17) ცხრილების შაბლონები და განაწილება

sql
-- Bronze: Deposit events
CREATE TABLE bronze. payment_deposits (
event_time TIMESTAMP,
event_id STRING,
user_pseudo_id STRING,
amount DECIMAL(18,2),
currency STRING,
psp_ref STRING,
payload VARIANT
)
PARTITION BY DATE(event_time)
CLUSTER BY (currency);

-- Silver: normalized model
CREATE TABLE silver. payments AS
SELECT event_id,
CAST(event_time AS TIMESTAMP) AS ts,
user_pseudo_id,
amount,
currency,
psp_ref
FROM bronze. payment_deposits
QUALIFY ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY ts) = 1;

18) ორკესტრი და DevX

Infra-as-Code: Paypline საცავი, ტესტები, შურისძიება, GitOps.
Data Contracts CI: სქემების ლინზები, DQ ტესტები დეპლოზე.
Backfill ჩარჩო: უსაფრთხო რეტროპროცესები, რომლებიც შეზღუდულია R/W და idempotence.
კატალოგები და შაბლონები: payline გენერატორები (cookie-cutter), საუკეთესო ნიმუშები.

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

MVP (4-6 კვირა):

1. მოვლენების ავტობუსი + ingest 2-3 ძირითადი წყაროდან (OLTP CDC, API კარიბჭე).

2. Lakehouse Bronze/Silver, ფორმატი ACID, კატალოგი და ძირითადი DQ წესები.

3. 1-2 ოქროს ფანჯარა (ყოველდღიური GGR და კონვერსიული ძაბრი).

4. მეტრიკა lag/completeness, ძირითადი ხაზი, RBAC და შენიღბვა PII.

ეტაპი 2 (6-12 კვირა):
  • Streaming ერთეულები (p95 latence - 5 წთ), Feature Store, RG/AML ფანჯრები.
  • სემანტიკური მეტრიკის ფენა, SLA მოხსენებისთვის; cost deschbords.
  • რეგიონალიზაცია (EEA/UK), DSAR/RTBF პროცედურები, იურიდიული ჰოლდი არტეფაქტებისთვის.
ეტაპი 3 (12 + კვირა):
  • Data Mesh: სასურსათო დომენები, consumer-driven კონტრაქტები.
  • ML ოპერაციები დრიფტის მონიტორინგით, ონლაინ/ოფლაინის ავტომატური მონიტორინგი.
  • სქემების ცვლილების ავტომატური სიმულაციები (impact analysis) და „what-if“ ღირებულებით.

20) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ნედლეული payload's სქემების გარეშე: შემოიღეთ schema-first, რეესტრი და CI სავალდებულო.
დედუპლიკაციის არარსებობა: მოვლენების გასაღებები და idempotent synk Silver- ში.
PII- ის ნაზავი ანალიტიკასთან: გამოყავით მაპინგები და შენიღბეთ მინდვრები.
ოქრო მფლობელის გარეშე: დანიშნეთ owner, SLO და მოხმარების მეტრიკა.
არ არსებობს reprocessing სტრატეგია: time-travel, ლოგიკის ვერსია, „ორმაგი აღრიცხვის“ კონტროლი.
უკონტროლო ღირებულება: წვეულება, კომპრესია, TTL, ღირებულების დაკვირვება.

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

CDC არის OLTP- ში ცვლილებების მიღება.
Outbox - ჩვენ ვაქვეყნებთ დომენის მოვლენებს გარიგებით.
Watermark არის ფანჯრების ნაკადის სისრულის შეფასება.
Lakehouse - მონაცემთა lake + ACID ცხრილი.
Data Product არის მონაცემთა ერთეული მფლობელთან და SLO- სთან.
Feature Store არის შეთანხმებული განაწილება ML ნიშნების შესახებ.

22) შედეგი

მონაცემთა ნაკადის არქიტექტურა არის შეთანხმებების მართვადი სისტემა: მკაფიო კონტრაქტები, დაკვირვება, უსაფრთხოება და ღირებულება კონტროლის ქვეშ. აღწერილი ნიმუშების შემდეგ (schema-first, bronze/silver/gold, CDC + Outbox, DQ და ხაზის, პირადი დიზაინის) შემდეგ, პლატფორმა საიმედოდ აწვდის ბიზნესს, შესაბამისობას და ML- ს მაღალი ხარისხის მონაცემებს პროგნოზირებადი SLO- ით და საკუთრების გასაგები.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

Telegram
@Gamble_GC
ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.