მონაცემთა საცავი და OLAP მოდელები
(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)
მოკლე რეზიუმე
მონაცემთა საცავი (DWH) არის iGaming ანალიტიკის დამხმარე ფენა: რეგულატორების მოხსენებები, პროდუქციის/ბაზრების მომგებიანობა, კოჰორტული LTV, ანტიფროდიული ანალიტიკა, CRM სეგმენტი და რეალურ დროში დაშბორდები. სტაბილური DWH აგებულია წმინდა მონაცემთა მოდელზე (Star/Snowflake/Data Vault), საიმედო ინტეგრაცია (ETL/ELT + CDC), გააზრებული შესრულება (სვეტების ძრავები, წვეულებები, MVs), მკაცრი სემანტიკა, უსაფრთხოება/PII II - ი და ღირებულება.
არქიტექტურული მიდგომები
კლასიკური DWH (Kimball vs Inmon)
კიმბალი (Dimensional/Star/Snowflake): სწრაფი ანგარიშების ფანჯრები; ფოკუსი ფაქტებზე და გაზომვებზე, SCD ისტორია. სწრაფი დრო-ტუ-ველი.
Inmon (Corporate Information Factory): ნორმალიზებული ბირთვი + ფანჯრები; უფრო რთულია დროში, მაგრამ მკაცრად და ცენტრალურად.
Data Vault 2. 0
Hubs-Links-Satellites: მასშტაბური „ნედლეული“ მოდელი ცვლილებების წყაროების ინტეგრაციისა და აუდიტის მიზნით. Star ფანჯრები შენდება თავზე.
Data Lake / Lakehouse
Data Lake: ნედლეული ფაილები (Parquet/ORC) + კატალოგები (Hive/Glue/Unity/Metastore).
Lakehouse: ერთი ფენა batch/stream, ACID ცხრილი (Delta/Iceberg/Hudi), time-travel, upsert/merge, კომპაქტური ფაილები, Z-order/Clustering.
Medallion (Bronze–Silver–Gold)
Bronze: ნედლეული მონაცემები (raw) + CDC.
სილვერი: გაწმენდილი და კონფორმული.
ოქროს: ბიზნესის ფანჯრები/მეტრიკა/კუბურები.
შესაფერისია ჰიბრიდებისთვის (Kafka - Bronze; Silver в Lakehouse; Gold в ClickHouse/BigQuery/Snowflake).
OLAP მოდელები: Star, Snowflake, Data Vault
Star Schema (ვარსკვლავი)
ცხრილი: გარიგებები (განაკვეთები, ანაბრები, სესიები).
Dimensions: მოთამაშე, თამაში, პროვაიდერი, თარიღი/დრო, გეო, მოზიდვის არხი.
დადებითი: მარტივი ჯოინები, პროგნოზირებული შესრულება.
Snowflake
გაზომვების ნორმალიზაცია (ქვეყნების/რეგიონების/ქალაქების იერარქიები, პროდუქციის იერარქია).
დადებითი: ნაკლები დუბლირება; მინუს - მეტი ჯოინი.
Data Vault → Star
ჩვენ ვქმნით ნედლეულ ცვლილებებს DV- ში (აუდიტი სრული რეპროდუქციით), ჩვენ ვქმნით მოხსენების ფანჯრებს, როგორც Star/Snowflake.
ინტეგრაცია: ETL/ELT, CDC, ნელი ცვლილებები
Pipline
Outbox/CDC OLTP (Postgres/MySQL) - Kafka/კონექტორები Bronze.
ELT: გაწმენდა, დედობა, ნორმალიზაცია Silver- ში.
ბიზნეს ლოგიკა და აგრეგაცია ოქროს/ფანჯრებში.
SCD (Slowly Changing Dimensions)
ტიპი 1: გადაწერა (უმნიშვნელო ველებისთვის).
ტიპი 2: ისტორიულობა (დათარიღებული ვერსიები) - სტანდარტი პროფილების/არხების/ფასებისთვის.
ტიპი 3: წყვილი მნიშვნელობების შენახვა (იშვიათად).
sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;
-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;სემანტიკური ფენა და „ნამდვილი“ მეტრიკა
შეიყვანეთ ერთი მეტრიკის ფენა: GGR, NGR, Net Deposits, ARPPU, LTV, Churn, Retention Cohorts განმარტებები.
მეტრიკა, როგორც კოდი (dbt metrics/LookML/Semantic Layer), იგივე ფორმულებია ყველა ანგარიშში.
კალენდარი: თარიღების/საათების ცხრილი TZ/რეგიონების/შაბათ/კამპანიების ატრიბუტებით.
შენახვა და ძრავები: არჩევანი პროფილის ქვეშ
სვეტები და ღრუბლოვანი DWH
ClickHouse: სუპერ სწრაფი სკანერები/აგრეგაციები, მატერიალიზებული წარმოდგენები, პროგნოზები; გამოირჩევა მოვლენებისთვის/ტელემეტრიისთვის და მარკეტინგის ფანჯრებისთვის.
BigQuery: სერვერის ლესი, მასშტაბი, ავტომატური ქეში/მტევანი; სკანის ფასი; მოსახერხებელი შერეული დატვირთვისთვის და ad-hoc.
Snowflake: კომპლექსის/მშენებლობის განყოფილება, მოთხოვნის მტევანი, დრო-მოგზაურობა; გამჭვირვალე სხვადასხვა გუნდისთვის.
Redshift/Vertica/Pinot/Druid: ვარიანტები OLAP/real time.
პროფილის ტიუნინგი
განაწილება თარიღით/რეგიონში/არხზე.
კლასტერიზაცია/დახარისხება ფილტრაციის/ჯოინის გასაღებებზე.
ლექსიკონის შეკუმშვა და კოდირება.
წინამორბედები (rollup, cubes), მატერიალიზებული იდეები.
Approx ფუნქციები (HyperLogLog/approx _ distinct) იაფი შეფასებისთვის.
შესრულების დიზაინი
განლაგება და კლასტერიზაცია
წვეულება არის განყოფილების საზღვარი. დღის/საათების ნაწილები მოვლენებისთვის.
კლასტერიზაცია (sort keys/Z-order) - აჩქარებს დიაპაზონს და join-y.
მატერიალიზებული წარმოდგენები (MV)
პროგნოზი GGR/NGR დღეების/ქვეყნების/პროდუქტების მიხედვით.
CDC ნაკადის სავარაუდო განახლება.
sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win) AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;დამატებითი მოდელები (dbt/ELT)
სტრატეგიები 'insert _ overwrite' ნაწილებად, 'merge' CDC კლავიშებზე, "watermark" "განახლებული _ at '.
Join სტრატეგიები
გაზომვის რეპლიკა თითოეულ პარტიულ სეგმენტში (დენორმი).
Broadcast small dims; shuffle large facts, გასაღები დახარისხებით.
ღირებულება: კონტროლი და ოპტიმიზაცია
BigQuery/Snowflake: შეზღუდეთ სკანის ზომა (დაპროექტეთ ნაწილები/მტევანი), ჩართეთ result cache/materialized views, შეიზღუდეთ BI მანქანის სტუმარი.
ClickHouse: წვეულებების ზომა, მერჯების სიხშირე, შენახვის ბიუჯეტი (TTL ნედლეული მოვლენებისთვის, აგრეგაციები გამძლეა).
სემანტიკა მეტრიკა ამცირებს „ორმაგ“ გამოთვლებს.
Data pruning: retenshne for Bronze, აგრეგაცია Gold- ისთვის.
მონაცემთა ხარისხი (DQ), კატალოგი, ხაზები
DQ ჩეკები: სისრულე, უნიკალურობა, დიაპაზონი, ბიზნეს წესები (მაგალითად, GGR-0 ერთეულებში).
Data Catalog & Lineage: ცხრილების/ველების აღწერები, მფლობელები, PII კლასიფიკაცია, ანგარიში წყაროდან.
სქემების კონტროლი: ღონისძიებების ხელშეკრულება/CDC, ალერტები შეუთავსებელი ცვლილებებით.
უსაფრთხოება, შესაბამისობა და მულტფილმი-ტენანტობა
PII სეგმენტი: ცალკეული ზონები, შენიღბვა/ფსევდონიზაცია, სვეტები KMS დაშიფვრით.
RBAC/ABAC: როლები პროექტის დონეზე/სქემები/ცხრილები/სტრიქონები (RLS), ბუჩქები „ახლა“.
მონაცემთა ლოკალიზაცია: რეგიონალური buckets/warehouses (EU/TR/LATAM).
წვდომის აუდიტი: ვინ წაიკითხა/შეცვალა ფანჯრები და მოდელები.
DR, ზურგჩანთები და რეპროდუქცია
მონაცემთა კოდის (dbt/git) ვერსია, Dev/QA/Breakers გარემოცვა.
მეტასტორის/კატალოგის სარტყელები + ცხრილების ვერსირება (დროის ტრაველი).
Retenshn/TTL ფენები Bronze/Silver/Gold; კრიტიკული ფანჯრების ექსპორტი.
თამაშის დღე: ფანჯრების აღდგენა, მეტრიკის მთლიანობის შემოწმება.
ნამდვილი დრო და ჰიბრიდული ფანჯრები
Stream to-OLAP: Kafka - ClickHouse/Pinot/Druid წუთიერი ფანჯრებისთვის.
Materialized views + CDC თითქმის ონლაინ განახლებისთვის (5-15 წუთი).
სემანტიკური ფენა რჩება ერთგვაროვანი: მეტრიკები იდენტურია რეალურ დროში და batch.
ვიტრინის მაგალითი „GGR დღეთა და ქვეყნებში“ (განზოგადებული SQL)
sql
CREATE TABLE fact_bets (
bet_id BIGINT,
player_sk BIGINT,
game_sk BIGINT,
country_sk BIGINT,
stake DECIMAL(18,2),
win DECIMAL(18,2),
ts TIMESTAMP
) PARTITION BY DATE(ts);
CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2 STRING,
region STRING,
valid_from TIMESTAMP,
valid_to TIMESTAMP,
is_current BOOL
);
-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win) AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;ჩეკის განხორციელების სია
1. განსაზღვრეთ წყაროები და დომენები, დააფიქსირეთ მეტრული ლექსიკონი.
2. შეარჩიეთ მოდელი: DV ნედლეული/აუდიტის ფენებისთვის + Star ფანჯრებისთვის.
3. შეიმუშავეთ ნაწილები/მტევანი ძირითადი მოთხოვნებისა და ფანჯრებისთვის.
4. პარამეტრები CDC/ELT, SCD პოლიტიკა და surrogate keys.
5. შეიყვანეთ სემანტიკური ფენა (მეტრიკა, როგორც კოდი) და თარიღების/საათების კალენდარი.
6. შექმენით MVs/წინასწარი აგრეგაცია ძვირადღირებული ანგარიშებისთვის.
7. ჩართეთ DQ/დირექტორია/ხაზის კონტროლი და სქემების კონტროლი.
8. დაადგინეთ RBAC/PII/ლოკალიზაცია, დაშიფვრა, აუდიტი.
9. მონიტორინგი p95/p99, ღირებულება, ალერტები დეგრადაციისა და გადაადგილების შესახებ.
10. რეგულარული DR სწავლებები და გარემოს რეპროდუქცია.
ანტიპატერები
„ერთი გიგანტური ფაქტი წვეულებების გარეშე“ არის ტერაბიტის სკანერები და ანგარიში იზრდება.
მეტრის არაკოორდინირებული განმარტებები სხვადასხვა დაშბორდში.
SCD2- ის არარსებობა, სადაც ბიზნესი მოითხოვს ისტორიულობას.
გაზომვების ნაადრევი ნორმალიზაცია: დამატებითი ჯოინები და ნელი მოხსენებები.
უმი მონაცემები DQ შემოწმების და ხაზის გარეშე არის „არაფერი“.
გადაკეთების არარსებობა/TTL - ნაგვის შენახვა და ღირებულების აფეთქება.
შედეგები
საიმედო iGaming-DWH არის მკაფიო მოდელი (DV-Star), ერთი მეტრული ლექსიკონი, სწორი ნაწილები/კლასტერიზაცია, მატერიალიზებული ფანჯრები, მკაცრი DQ/ხაზები, ასევე RBAC/PII/ლოკალიზაცია. დაამატეთ ჰიბრიდული სიახლის ნაკადი, რომელსაც მართავს ELT და ღირებულების დისციპლინა - და მიიღეთ სტაბილური ანალიტიკური პლატფორმა, რომელიც ფართოვდება ტურნირებზე, მარეგულირებელ მოხსენებებზე და ad-hoc- ზე, p99 და ბიუჯეტში სიურპრიზების გარეშე.