انبارهای داده

1) هدف و نقش DWH در iGaming

• تعاریف متریک مشترک (GGR/NGR، ARPPU، احتباس، Churn).
• گزارش های تجدید پذیر برای تنظیم کننده ها و ذینفعان داخلی.
• فروشگاه های سریع برای پانل های BI/عامل و منابع برای مدل ها.
• کنترل کیفیت سطح پلت فرم، اصل و نسب و ایمنی.

2) گزینه های معماری

2. 1 DWH کلاسیک

ETL → DWH → BI.
مزایا: مدل های قابل کنترل، سازگاری قوی.
منفی: دانلود گران قیمت، پر کردن پیچیده، انعطاف پذیری محدود است.

2. 2 دریاچه DWH

برنز/نقره/طلا در جداول ACID (Delta/Iceberg/Hudi) + موتور SQL/MPP.
مزایا: ذخیره سازی یکپارچه، سفر در زمان، پردازش مجدد ساده.
منفی: نیاز به نظم و انضباط از لایه ها و DQ، ارکستراسیون بالغ.

2. 3 ترکیبی

دریاچه به عنوان «منبع حقیقت» (برنز/نقره ای)، DWH-مارس در MPP (ClickHouse/Pinot/Druid/Cloud DWH) برای خواندن با سرعت بالا.
مزایا: تعادل هزینه و عملکرد، فروشگاه های انعطاف پذیر.
منفی: پشتیبانی دوگانه برای مدارات و اسکیت، هماهنگ سازی مورد نیاز است.

توصیه: برای iGaming - دریاچه + DWH-مارس (ترکیبی). برنز/نقره - استاندارد، طلا/مارک های زمان واقعی - بارهای خواندن را خدمت می کنند.

3) مدل سازی داده ها

3. 1 ستاره و برف ریزه

جداول واقعیت: باریک، رویداد محور: 'fact _ bets'، 'fact _ payouts'، 'fact _ payments'.
ابعاد: 'dim _ users' (SCD)، 'dim _ games'، 'dim _ providers'، 'dim _ markets'.
دانه برف در نقره (عادی)، ستاره - در طلا (خواندن) مناسب است.

3. 2 طاق داده 2. 0 (هسته ادغام)

هاب ها (کلید های کسب و کار)، لینک ها (روابط)، ماهواره ها (زمینه/تاریخ).
درخواست در نقره ای برای ادغام ارائه دهنده طولانی مدت/PSP.

3. 3 SCD I/II/III

SCD II برای RG/KYC/کانال ها و ویژگی های بازی (RTP/نوسانات).
فواصل دقیق 'valid _ from/valid _ to'، صحیح پیوستن در زمان.

4) بار: ETL/ELT، CDC و افزایش

رویکرد ELT: بارگذاری در نقره → تبدیل در DWH.
CDC: تکثیر Debezium/log از OLTP ؛ merzhi idempotent هستند.
افزایش: با زمان آب ('updated _ at> max_loaded_ts') و/یا هش دلتا.
Backfill/Reprocessing: زمان سفر، محدوده، سهمیه، مقایسه خشک اجرا.

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) لایه معنایی و معیارها

متریک فروشگاه/لایه معنایی: فرمول یکنواخت GGR/NGR/تبدیل/LTV.
معیارهای نسخهبندی و محاسبات «as-of» برای تکرارپذیری.
قراردادها عبارتند از نام متریک، واحد، ارز (پایه EUR) و «fx _ source».

6) فروشگاه ها و خدمات

ویترین طلا: denormalized، SLA آماده (به عنوان مثال، تا 06:00 قفل.) .
Marts عملیاتی: ClickHouse/Pinot/Druid برای پانل های 1-5 دقیقه ای.
صادرات: CSV/JSON/PDF + هش ؛ بسته های غیر قابل تغییر (WORM) برای تنظیم کننده ها.

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;

7) کیفیت داده ها (DQ) و قراردادها

Schema-first: رجیستری JSON/Avro + تست های سازگاری (مبتنی بر مصرف کننده).
DQ- как - код: کامل بودن/اعتبار/منحصر به فرد بودن/FK/محدوده/زمانی.
سیاست های واکنش: بحرانی → شکست + DLQ ؛ major/minor → برچسب و گزارش.
مشاهده پذیری DQ: داشبورد تازگی/کامل بودن/اعتبار، قیف سوابق از دست رفته.

8) امنیت، حفظ حریم خصوصی و اقامت

به حداقل رساندن PII: کاربران از طریق شبه شناسه ؛ جداگانه نصب شود.
RLS/CLS: خط به خط/دسترسی پس از جدول توسط نقش و صلاحیت.
رمزگذاری: TLS در حمل و نقل ؛ در حالت استراحت - KMS/CMK با چرخش.
اقامت داده ها: دایرکتوری ها و کلید های جداگانه برای EEA/UK/BR ؛ ممنوعیت عضویت بین المللی بدون دلیل.
DSAR/RTBF: پیش بینی های قابل محاسبه و ویرایش های انتخابی ؛ نگه حقوقی در گزارش مصنوعات.

9) عملکرد و هزینه (مهندسی هزینه)

تقسیم بندی: بر اساس تاریخ/بازار/مستاجر ؛ خوشه بندی/Z-order بر اساس 'market', 'provider _ id', 'game _ id', 'user _ pseudo _ id'.
فرمت ها: پارکت + آمار و فشرده سازی ؛ بهینه سازی/خلاء در برنامه.
Materialization: aggregates پایدار و جداول خلاصه ؛ اجتناب از «چربی» در پرواز می پیوندد.
سهمیه/بازپرداخت: بودجه برای درخواست های سنگین/تکرار ؛ گزارش هزینه/پرس و جو، هزینه/GB.
ذخیره سازی چند لایه: گرم/گرم/سرد ؛ SLA های بازیابی روشن.

10) قابلیت مشاهده و مدیریت

معیارهای خط لوله: مدت زمان، حجم، بازپرداخت، عقب ماندگی، تحمل خطا.
معیارهای DWH: زمان پاسخ/رقابت/بازدیدها کش/ارزش.

Lineage: نمودار از منابع به گزارش ؛ تحلیل تاثیر بر تغییرات

SLO: طراوت نقره p95 ≤ 15 мин ؛ طلا روزانه - آماده تا 06:00 ؛ اعتبار ≥ 99 9%; کامل ≥ 99 5%; دسترسی ≥ 99 9%.

11) جداسازی چند اجاره ای و دامنه

تقسیم بر اساس طرح/پایگاه داده/کاتالوگ به مستاجر/بازار.
سهمیه ها و گروه های منابع ؛ محدود کردن «همسایگان پر سر و صدا».
سیاست های صادرات/واردات بین مستاجران، قراردادهای استاندارد.

12) ثبت اطلاعات و مستندات

کاتالوگ داده ها: مالک، SLA، طرح، نمونه، قوانین DQ، اصل و نسب.
معیارها/داشبورد: کارت با فرمول و مسئول.
Change Log: نسخه هایی از منطق، مهاجرت، تاثیر.

13) فرآیندها و RACI

R (مسئول): مهندسی داده (مدل نقره/طلا، DAG 'i)، پلت فرم داده (مادون قرمز، رجیستری، DQ).
A (پاسخگو): رئیس داده/CDO.
C (مشورت): انطباق/حقوقی/DPO، امور مالی (FX/GGR)، خطر (RG/AML)، SRE (SLO/стоимость).
I (مطلع): BI، محصول، بازاریابی، عملیات.

14) نقشه راه پیاده سازی

1. Lakehouse برنز/نقره ای (جداول اسید)، CDC/افزایش برای پرداخت/گیم پلی.

2. اولین ویترین طلا (GGR روزانه, تبدیل), SLAs تا 06:00.

3. DQ-like-code (قوانین 10-15) + داشبورد طراوت/کامل بودن.

4. کاتالوگ داده ها و لایه معنایی پایه معیارها.

• SCD II для کاربران/بازی ها/ارائه دهندگان ؛ گسترش دامنه
• مارس آنلاین (ClickHouse/Pinot) برای پانل های زمان واقعی/نزدیک به زمان واقعی.
• تجزیه و تحلیل خطی/تاثیر، روش DSAR/RTBF، منطقه بندی (EEA/UK).

• شبیه سازی خودکار تغییرات (خشک اجرا)، پخش و مقایسه معیارها.
• بازپرداخت/سهمیه، داشبورد هزینه ؛ تمرینات DR و بازیابی زمان سفر.
• تولید خودکار مستندات ویترین و کارت های متریک.

15) نمونه هایی از قالب های SQL

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) چک لیست پیش فروش

• طرح ها و قراردادها در رجیستری، تست سازگاری سبز هستند.
• CDC/increments و روشهای MERGE بی نظیر هستند.
• ویترین های طلا دارای SLA هستند، فرمول های متریک ثابت هستند.
• قوانین DQ فعال هستند (بحرانی → شکست + DLQ)، داشبورد طراوت/کامل بودن.
• RBAC/ABAC، رمزگذاری، اقامت در منطقه، سیاهههای مربوط به دسترسی.
• خط/تاثیر فعال ؛ زمان سفر/پشتیبان گیری/DR بررسی شده است.
• هزینه تحت کنترل: احزاب، خوشه بندی، تحقق، سهمیه.

17) ضد الگوهای و خطرات

«یک DWH چربی بدون لایه»: ترکیبی از داده های خام و گزارش شده → هرج و مرج و رفع گران قیمت.
بارگیری مجدد روزانه بدون نیاز: افزایش استفاده/CDC.

طلا بدون مالک و فرمول: عدم وجود یک نسخه واحد از حقیقت → اختلافات و رگرسیون

PII در لایه های تحلیلی: نگه داشتن mappings جداگانه، CLS/RLS.
بدون DQ/اصل و نسب: هیچ شواهدی برای تنظیم کننده/حسابرسی.
هزینه غیر قابل کنترل: بدون دسته/بهینه سازی/سهمیه.

18) واژه نامه (کوتاه)

DWH یک انبار داده برای تثبیت و تجزیه و تحلیل است.
دریاچه خانه - دریاچه داده + جداول اسید و موتور SQL.
CDC - گرفتن تغییرات از OLTP.
SCD - به آرامی تغییر اندازه گیری (I/II/III).
ویترین طلا - آماده به مصرف ورق گزارش/ارائه.
لایه معنایی - تعاریف یکنواخت معیارها و ویژگی ها.

19) خط پایین

DWH مدرن برای iGaming یک «جدول بزرگ» نیست، بلکه یک پلت فرم قابل کنترل است: لایه های برنز/نقره ای/طلا، قراردادهای سخت و DQ، معیارهای یکنواخت و اصل و نسب، حریم خصوصی و اقامت، عملکرد و کارایی. با ساخت یک هیبرید Lakehouse + DWH-March، شما تصمیم گیری سریع و قابل اطمینان را برای ممیزی، مقیاس و بازارهای جدید آماده خواهید کرد.