Λίμνη δεδομένων και κεντρική αποθήκευση

(Τμήμα: Τεχνολογία και Υποδομές)

Σύντομη Περίληψη

Η λίμνη δεδομένων είναι το βασικό στρώμα κεντρικής αποθήκευσης πρώτων υλών και ενοποιημένων συνόλων δεδομένων. Για το iGaming, δέχεται εκδηλώσεις στοιχημάτων/πληρωμής/καταγραφής παιχνιδιών, uploads θυγατρικών, CDC από το OLTP και τα δίνει στην αναλυτική, την καταπολέμηση της απάτης, CRM και BI. Σύγχρονη πρακτική - Lakehouse: ανοιχτές μορφές στήλης + στρώμα πίνακα ACID + ενιαίος κατάλογος + συναλλαγές/εκδόσεις δεδομένων. Το κλειδί για την επιτυχία είναι η πειθαρχία των συστημάτων και ο διαχωρισμός, η διαχείριση του κόστους, η ασφάλεια των PII και μια αυστηρή λειτουργική νοοτροπία (DQ, γενεαλογία, DR).

Ο ρόλος της λίμνης δεδομένων στην πλατφόρμα iGaming

Ένα μόνο σημείο αλήθειας για την ανάλυση: αποθήκευση ακατέργαστων και καθαρών δεδομένων ανεξάρτητα από την πηγή και τη μορφή.
Ευελιξία: υποστήριξη για παρτίδα και ροή (CDC/συνδέσεις, ροές γεγονότων).
Εξέλιξη: από ακατέργαστο χάλκινο έως συμμορφούμενο ασημένιο και χρυσό επιχειρηματικές υποθέσεις.
Κατανομή ευθύνης: οι υπηρεσίες παραγωγής γράφουν στο ελαστικό/στάβλο, η αναλυτική/ML καταναλώνεται από στρώματα της λίμνης.

Αρχιτεκτονικά μοντέλα: Λίμνη εναντίον Λίμνης

Λίμνη δεδομένων (S3/ADLS/GCS + Parquet/ORC): σχήμα σε ανάγνωση, φθηνή αποθήκευση, ευέλικτες μορφές.
Lakehouse (Delta/Iceberg/Hudi over Parquet): συναλλαγές ACID, upsert/συγχώνευση, ταξίδι στο χρόνο, συμπαγή αρχεία, κενό, ευρετηρίαση/ομαδοποίηση.
Πρακτική: Το Lakehouse είναι επωφελές για το iGaming ως κύριο στρώμα και τα εξωτερικά OLAPs (ClickHouse/BigQuery/Snowflake/Pinot) ως βιτρίνες και ειδικούς κινητήρες.

Μοντέλο στρώματος μενταγιόν

Bronze (Raw/Staging): ακατέργαστα αρχεία από πηγές (CDC, log dumps, affiliate CSV, webhooks). Ελάχιστη επικύρωση, «όπως είναι».
Άργυρος (συμμορφωμένος): καθαρισμός/αφαίρεση, ομαλοποίηση νομισμάτων/ζωνών ώρας, δακτυλογράφηση, μετρήσεις SCD, σταθερά κλειδιά.
Χρυσός (Marts/Serving): συγκεντρωτικά στοιχεία για GGR/NGR/LTV/Διατήρηση, πραγματικές αποθήκες για BI/CRM/καταπολέμηση της απάτης.
TTL: Επιθετική στο χάλκινο, μέτρια στο ασήμι, μακροχρόνια σε μονάδες χρυσού.

Μορφότυποι και επιτραπέζια στρώματα

Στήλη: Parquet (de facto πρότυπο), ORC.

Μορφότυποι ανοικτού τραπεζιού (ACID):

Delta Lake - συναλλαγές, 'MERGE', time-travel, βελτιστοποίηση/κενό, Z-order.
Apache Iceberg - πίνακες με δηλωτικά/στιγμιότυπα, κρυφή κατάτμηση, 'MERGE/DELETE/UPDATE', ταξίδι στο χρόνο.
Apache Hudi - αντίγραφο/συγχώνευση-on-write, upsert-βελτιστοποίηση, στοιχειώδεις εκχυλίσεις.
Επιλέξτε με βάση το οικοσύστημα και τις απαιτήσεις για την ανοδική ροή/ευελιξία της εξέλιξης των συστημάτων.

Κατάλογος και μεταστάτης

Ένας ενιαίος κατάλογος (Hive Metastore/Unity/Glue/platforms) αποθηκεύει σχήματα, μέρη, εκδόσεις, δικαιώματα.
Απαιτήσεις: συνοχή συναλλαγών με επιτραπέζιο στρώμα, υποστήριξη πολλαπλών κινητήρων (Spark, Trino/Presto, Flink, dbt), έλεγχος/γενεαλογία.

Συστήματα και εξέλιξη

Σύμβαση σχήματος: καθορισμός υποχρεωτικών πεδίων, τύπων, σημασιολογίας. πηγές έκδοσης ('schema _ version').
Εξέλιξη: προσθήκη προαιρετικών πεδίων, απαγόρευση των μεταβολών χωρίς μετανάστευση. συστήματα αυτόματου ελέγχου στους αγωγούς.
Κατάτμηση PII: ευαίσθητα πεδία - σε ξεχωριστές στήλες/πίνακες με κρυπτογράφηση και ξεχωριστά δικαιώματα.

Κατάτμηση και διάταξη δεδομένων

Ημερομηνία/ώρα - κλειδί βάσης για εκδηλώσεις· προαιρετικά πεδία: «χώρα», «προϊόν», «ενοικιαστής _ id».
Κυψέλες путь: 's3 ://lake/bronze/payments/source = pspA/dt = 2025-11-05/hour = 13/part-0001. παρκέ '.
Συστοιχία/διαλογή: Z-order/Ταξινόμηση κλειδιών από συχνά φιλτραρισμένα πεδία (player_id, χώρα).
Μέγεθος αρχείου: Στόχος 128-1024 MB. αποφυγή «μικρών αρχείων» (βλέπε παρακάτω).
Εικονικές στήλες (Iceberg/Delta) για κρυφή κατάτμηση.

Μικρά αρχεία και πρόβλημα συμπίεσης

Πηγές διοχετεύουν μικρά κομμάτια → αποικοδόμηση σαρώσεων και μεταδεδομένων.
Λύση: περιοδική βελτιστοποίηση/συμπίεση (coalesce), προγραμματιστής εργασιών συμπίεσης, μικρο-δέσμη παρτίδων κατά την κατάποση, 'autoOptimize' (αν υπάρχει).
Η πολιτική συγχώνευσης σε ανάγνωση έναντι αντιγραφής είναι μια ισορροπία μεταξύ της καθυστέρησης εγγραφής και της ταχύτητας ανάγνωσης.

Ενέσιμο: παρτίδα, ρεύμα, CDC

CDC από OLTP (Debezium/connectors) → χάλκινο (λεπτή φρεσκάδα).
Stream (Kafka/Flink/Spark Structured Streaming) → Silver/Gold σταδιακά (upsert/merge).
Παρτίδα (αναφορές εταίρων/CSV/JSON) - μέσω «δεκτών» με δηλωτικά, έλεγχος των αντιγράφων με έλεγχο.
Idempotency: κλειδιά (idempotency_key), dedup by (κλειδί, ts), «υδατογραφήματα» για μεταγενέστερες καταγραφές.

Ποιότητα δεδομένων (DQ) και γενεαλογία

Έλεγχοι DQ: πληρότητα, μοναδικότητα των κλειδιών, εύρος τιμών, ακεραιότητα αναφοράς (κατάλογοι χωρών/νομισμάτων), επιχειρηματικοί κανόνες (GGR ≥ 0).
Liniage: γράφημα εξαρτήσεων από την αναφορά στην πηγή, έκδοση του κώδικα μοντέλου και στιγμιότυπο του πίνακα.
Έλεγχος σχήματος: αυτόματες δοκιμές back/forward-compat που μπλοκάρουν τις αλλαγές «θραύσης».
Λήψη ελέγχου: ποιος/πότε/πόσοι, απορριφθείσες παρτίδες, retrays.

Υπηρεσία και πρόσβαση

κινητήρες SQL: Spark/Trino/Presto για ad-hoc και μετασχηματισμούς· dbt για μοντέλα ELT.
Σε πραγματικό χρόνο/σχεδόν σε πραγματικό χρόνο: Pinot/Druid/ClickHouse ως καταστήματα. Το Lakehouse είναι πηγή μέσω του αυξανόμενου νεροχύτη.
Κοινοχρησία δεδομένων: κοινοχρησία πινάκων/στιγμιότυπων σε εξωτερικές εντολές χωρίς αντίγραφα (εάν υποστηρίζεται από τη μορφή).

Ασφάλεια, PII και πολυκατοικία

Κρυπτογράφηση: κατά την ανάπαυση (KMS) και κατά τη διαμετακόμιση (TLS).
IAM/RBAC/ABAC: ρόλοι σε επίπεδο καταλόγου/πίνακα/στήλη/σειρά (συγκάλυψη, δυναμικές πολιτικές).
Κατάτμηση ανά περιφέρεια (ΕΕ/Τουρκία/LatAm τοπικοποίηση): απομόνωση κουβάδων και ομάδων υπολογισμού.
Πολυπλοκότητα: χώρος ονομάτων/κατάλογοι και προθέματα διαδρομής, φίλτρα από τον «ενοικιαστή _ id», προαιρετικά - πολιτικές επιπέδου γραμμής.
Έλεγχος πρόσβασης: αρχεία καταγραφής ανάγνωσης/αλλαγής μεταδεδομένων, διατήρηση και μη τροποποιήσιμα αρχεία καταγραφής.

Διαχείριση κόστους

Κλάσεις αποθήκευσης: θερμές (συχνά αναγνώσιμες) σε μια τυπική κλάση, αρχείο - σε τάξεις ψυχρών/παγετώνων με πολιτικές TTL.
Η κατάτμηση/συστάδες μειώνουν τις σαρώσεις → λιγότερο από $ $.
Πραγματικές αποθήκες για δαπανηρές εκθέσεις. BI αποτελέσματα cache.
Συμπίεση και «σωστό μέγεθος αρχείου» - λιγότερα μεταδεδομένα και I/O.
Ποσοστώσεις και κατάρτιση του προϋπολογισμού: όρια για τους υπολογιστικούς συνεργατικούς σχηματισμούς/θέσεις εργασίας, εκθέσεις κόστους για το σύνολο δεδομένων/ομάδα.
Αφαίρεση απορριμμάτων: 'VACUUM/REWRITE' σε μορφή τραπεζιού, TTL Bronze.

DR και αναπαραγωγιμότητα

Time-travel table versioning και στιγμιότυπα καταλόγου.
Διαπεριφερειακή αναπαραγωγή κουβάδων και μεταδεδομένων.
PITR: αποθήκευση επιτραπέζιων κορμών συναλλαγών (Delta/Iceberg/Hudi) και κορμών αγωγών.
Ημέρα παιχνιδιού: τακτικές ασκήσεις αποκατάστασης και περιοχές αλλαγής.

Παρατηρησιμότητα και SLO

Φρεσκάδα SLO: χάλκινο ≤ 5 λεπτά, ασήμι ≤ 15-30 λεπτά, χρυσό ≤ 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 _ t ,' source ',' schema _ version ',' trace _ id ',' tenant _ id '.

Παραδείγματα (γενικευμένα)

1) Iceberg: Αργυρό τραπέζι με κρυφό μέρος μέχρι την ημερομηνία

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) Δέλτα: Αυξητική αναταραχή από το ΚΕΕΛΠΝΟ

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/: 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. Διάταξη σχεδιασμού: μέρη, κλειδιά ταξινόμησης, μέγεθος αρχείου-στόχου. ενεργοποίηση συμπίεσης.
5. Ρυθμίστε την απορρόφηση (CDC/ρεύμα/παρτίδα) με ιδιοτέλεια και αφαίρεση.
6. Ενεργοποίηση DQ/γενεαλογίας, καταλόγου μεταδεδομένων και ελέγχου.
7. Ορισμός της φρεσκάδας/του κόστους SLO, ταμπλό μετρήσεων και συναγερμών.
8. Οργάνωση DR: στιγμιότυπα/αντιγραφή/ανάκτηση + τακτικές ασκήσεις.
9. Τυποποίηση ονοματοδοσίας και μονοπατιών, μετα-στήλες ('ingest _ t ,' source ',' schema _ version ').
10. Φέρτε χρυσές βιτρίνες και σε πραγματικό χρόνο εξυπηρετώντας τους σωστούς κινητήρες OLAP/RT.

Αντι-μοτίβα

Ένας κοινός «σάκος» χωρίς στρώματα και TTL → χάος και έκρηξη κόστους.
Διαχωρισμός μόνο στο χρόνο, εξαιρουμένης της χώρας/προϊόντος → βαριές σαρώσεις.
Κλωστές που δημιουργούν χιλιάδες μικρά αρχεία/ώρα χωρίς συμπίεση.
Έλλειψη ελέγχου των συστημάτων και των DQ → «σπάσιμο» αλλαγών και δυσπιστία των εκθέσεων.
Αναμειγνύοντας PII με Gold showcases χωρίς συγκάλυψη/διαχωρισμό δικαιωμάτων.
Hardcode των δικαιωμάτων πρόσβασης στο επίπεδο των κουβάδων αντί για μια πολιτική καταλόγου και πίνακα.

Περίληψη

Το Modern Data Lake for iGaming είναι ένα Lakehouse με ανοιχτό τραπέζι, ενιαίο κατάλογο και μοντέλο μενταγιόν. Η πειθαρχία των συστημάτων/μερών, η συμπίεση σε μικρά αρχεία, η DQ/γενεαλογία, η ασφάλεια PII και η υγιεινή του κόστους μετατρέπουν το στρώμα της λίμνης σε βιώσιμο θεμέλιο: φθηνή αποθήκευση, γρήγορη ανάγνωση, προβλέψιμη σε SLO και έτοιμη για DR.