دریاچه داده و ذخیره سازی متمرکز

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

Data Lake لایه اصلی ذخیره سازی متمرکز مواد خام و مجموعه داده های یکپارچه است. برای iGaming، رویدادهای ورود به سیستم شرط بندی/پرداخت/بازی، آپلود های وابسته، CDC از OLTP را می پذیرد و آنها را به تجزیه و تحلیل، ضد تقلب، CRM و BI می دهد. تمرین مدرن - Lakehouse: فرمت های ستون باز + لایه جدول ACID + دایرکتوری تک + معاملات/نسخه های داده. کلید موفقیت، نظم و انضباط طرح ها و پارتیشن بندی، مدیریت هزینه، امنیت PII و یک فرهنگ عملیاتی دقیق (DQ، lineage، DR) است.

نقش Data Lake در پلتفرم iGaming

یک نکته واقعی برای تجزیه و تحلیل: ذخیره سازی داده های خام و خالص بدون در نظر گرفتن منبع و فرمت.
انعطاف پذیری: پشتیبانی از دسته ای و جریان (CDC/اتصالات، جریان رویداد).
تکامل: از برنز خام تا موارد تجاری نقره و طلا.
تقسیم مسئولیت: خدمات تولید نوشتن به تایر/مرحله بندی، تجزیه و تحلیل/ML مصرف از لایه های دریاچه.

مدل های معماری: دریاچه در مقابل دریاچه

Data Lake (S3/ADLS/GCS + Parquet/ORC): schema-on-read، ذخیره سازی ارزان، فرمت های انعطاف پذیر.
خانه دریاچه (دلتا/کوه یخ/هودی بیش از پارکت): معاملات اسید، upsert/ادغام، زمان سفر، فایل های جمع و جور، خلاء، نمایه سازی/خوشه بندی.
تمرین: دریاچه برای iGaming به عنوان لایه اصلی و OLAP های خارجی (ClickHouse/BigQuery/Snowflake/Pinot) به عنوان ویترین و موتورهای ویژه مفید است.

مدل لایه مدال

Bronze (Raw/Staging): فایل های خام از منابع (CDC، log dumps، CSV وابسته، webhooks). حداقل اعتبار، «همانطور که هست».
نقره ای (مطابق): تمیز کردن/dedup، عادی سازی ارزها/مناطق زمانی، تایپ کردن، اندازه گیری SCD، کلیدهای سازگار.
طلا (Marts/Serving): جمع آوری برای GGR/NGR/LTV/Retention، فروشگاه های مادی شده برای BI/CRM/ضد تقلب.
TTL: تهاجمی در برنز، متوسط در نقره، بلند مدت در واحدهای طلا.

فرمت ها و لایه های جدول

ستون: پارکت (عملا استاندارد)، ORC.

قالبهای جدول باز) ACID (:

دلتا دریاچه - معاملات, 'MERGE', زمان سفر, بهینه سازی/خلاء, Z-منظور.
Apache Iceberg - جداول با تظاهرات/عکس های فوری، پارتیشن بندی پنهان، «MERGE/DELETE/UPDATE»، زمان سفر.
Apache Hudi - copy-on-write/merge-on-read, upsert-optimization, استخراج افزایشی.
انتخاب خود را بر اساس اکوسیستم و الزامات برای upsert/streaming/انعطاف پذیری تکامل طرح ها انتخاب کنید.

کاتالوگ و متاستور

یک دایرکتوری واحد (دایرکتوری های Hive Metastore/Unity/Glue/platform) طرح ها، احزاب، نسخه ها، حقوق را ذخیره می کند.
الزامات: سازگاری معاملات با یک لایه جدول، پشتیبانی از موتورهای چندگانه (Spark، Trino/Presto، Flink، DBT)، حسابرسی/اصل و نسب.

طرح ها و تکامل

قرارداد طرح: رفع زمینه های اجباری، انواع، معانی ؛ منابع نسخهبندی («schema _ version»).
تکامل: اضافه کردن زمینه های اختیاری، ممنوعیت تغییرات شکستن بدون مهاجرت ؛ طرح های چک اتوماتیک در خطوط لوله.
تقسیم بندی PII: زمینه های حساس - به ستون ها/جداول جداگانه با رمزگذاری و حقوق جداگانه.

پارتیشن بندی داده ها و قرار دادن

تاریخ/ساعت - کلید پایه برای رویدادها ؛ زمینه های اختیاری: 'کشور'، 'محصول'، 'tenant _ id'.
путь به سبک کندو: 's3 ://lake/bronze/payments/source = pspA/dt = 2025-11-05/hour = 13/part-0001. پارکت...
خوشه بندی/مرتب سازی: کلید های مرتب سازی Z-order/Sort با فیلدهای فیلتر شده (player_id، کشور).
اندازه فایل: هدف 128-1024 مگابایت ؛ اجتناب از «فایل های کوچک» (پایین را ببینید).
ستون های مجازی (Iceberg/Delta) برای پارتیشن بندی پنهان.

فایل های کوچک و مشکل تراکم

منابع جریان تکه های کوچک → تخریب اسکن و ابرداده.
راه حل: بهینه سازی دوره ای/تراکم (coalesce)، زمانبندی کار تراکم، دسته ای میکرو بسته نرم افزاری در بلع، 'autoOptimize' (در صورت موجود بودن).
سیاست merge-on-read در مقابل copy-on-write تعادل بین تاخیر نوشتن و سرعت خواندن است.

Injest: دسته ای، جریان، CDC

CDC از OLTP (Debezium/connectors) → برنز (طراوت دقیقه).
جریان (Kafka/Flink/Spark Structured Streaming) → نقره/طلا به صورت تدریجی (upsert/ادغام).
دسته ای (گزارش شریک/CSV/JSON) - از طریق «گیرنده» با مانیفست، کنترل تکراری توسط checksum.
Idempotency: کلید (idempotency_key)، dedup توسط (کلید، TS)، «علامت» برای سوابق بعد از ورود.

کیفیت داده ها (DQ) و اصل و نسب

DQ چک: کامل، منحصر به فرد از کلید، محدوده، تمامیت مرجع (لیست کشور/ارز)، قوانین کسب و کار (GGR ≥ 0).
Liniage: نمودار وابستگی از گزارش به منبع، نسخه کد مدل و عکس فوری از جدول.
کنترل Schema: تست های اتوماتیک back/forward-compat که تغییرات «breaking» را مسدود می کند.
بارگیری حسابرسی: چه کسی/چه زمانی/چند نفر، دسته های رد شده، بازپرداخت می کند.

خدمات و دسترسی

موتورهای SQL: Spark/Trino/Presto برای تحولات ad-hoc و ؛ DBT برای مدل های ELT

زمان واقعی/نزدیک به زمان واقعی: Pinot/Druid/ClickHouse به عنوان ویترین فروشگاه ؛ دریاچه یک منبع از طریق سینک افزایشی است.
به اشتراک گذاری داده ها: به اشتراک گذاری جداول/عکس های فوری به دستورات خارجی بدون کپی (اگر توسط فرمت پشتیبانی می شود).

امنیت، PII و چند اجاره

رمزگذاری: در حالت استراحت (KMS) و در حمل و نقل (TLS).
IAM/RBAC/ABAC: نقش ها در سطح دایرکتوری/جدول/ستون/ردیف (پوشش، سیاست های پویا).
تقسیم بندی بر اساس منطقه (محلی سازی اتحادیه اروپا/ترکیه/LatAm): جداسازی سطل ها و استخرهای محاسبه شده.
Multi-tenancy: namespace/directories و پیشوندهای مسیر، فیلترهای «tenant _ id»، سیاست های سطح ردیف اختیاری.
حسابرسی دسترسی: ابرداده خواندن/تغییر سیاهههای مربوط، حفظ و سیاهههای مربوط غیر قابل تغییر.

مدیریت هزینه

کلاس های ذخیره سازی: گرم (اغلب قابل خواندن) در یک کلاس استاندارد، بایگانی - در کلاس های سرد/یخچال با سیاست های TTL.
Partitioning/clusters اسکنها را کمتر از $ $ کاهش میدهد.
فروشگاه های مادی برای گزارش های گران قیمت ؛ کش نتایج BI.
فشرده سازی و «اندازه فایل صحیح» - ابرداده کمتر و I/O.
سهمیه بندی و بودجه بندی: محدودیت در محاسبه خوشه/شغل، گزارش هزینه در مجموعه داده/تیم.
حذف زباله: «خلاء/بازنویسی» در فرمت های جدول، TTL برنز.

DR و تکرارپذیری

نسخه جدول زمان سفر و عکس های کاتالوگ.
تکرار بین منطقه ای سطل ها و ابرداده ها.
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 _ ts»، «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) دلتا: افزایش افزایشی از CDC

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) و دایرکتوری را انتخاب کنید. تراز با موتورهای (جرقه/ترینو/فلینک/DBT).
2. تعریف لایه های مدال، قوانین TTL و مسئولیت تیم.
3. ضبط قراردادهای طرح، کنترل تکامل، تقسیم بندی PII و رمزگذاری.
4. طرح بندی: قطعات، مرتب سازی کلید، اندازه فایل هدف ؛ تراکم را فعال کنید.
5. پیکربندی مصرف (CDC/جریان/دسته ای) با idemotency و deduplication.
6. فعال کردن DQ/lineage، کاتالوگ ابرداده و حسابرسی.
7. تعریف تازگی/SLO های هزینه، داشبورد معیارها و هشدارها.
8. سازماندهی DR: عکس های فوری/تکرار/بازیابی + تمرینات منظم.
9. نامگذاری استاندارد و مسیرها، ستون های متا («مصرف _ ts»، «منبع»، «schema _ version»).
10. را ویترین طلا و در زمان واقعی خدمت به موتورهای OLAP/RT راست.

ضد الگوهای

یک «کیسه» معمولی بدون لایه و TTL → هرج و مرج و انفجار هزینه.
تقسیم بندی فقط زمان به استثنای کشور/محصول → اسکن های سنگین.
موضوعاتی که هزاران فایل کوچک/ساعت بدون تراکم ایجاد می کنند.
عدم کنترل طرح ها و DQ → تغییرات «شکستن» و بی اعتمادی به گزارش ها.
مخلوط کردن PII با ویترین طلا بدون جداسازی ماسک/حقوق.
Hardcode حقوق دسترسی در سطح سطل به جای یک دایرکتوری و سیاست های جدولی.

خلاصه

Modern Data Lake for iGaming یک Lakehouse با فرمت جدول باز، یک کاتالوگ واحد و یک مدل مدال است. نظم و انضباط طرح ها/احزاب، تراکم در برابر فایل های کوچک، DQ/lineage، امنیت PII و بهداشت هزینه، لایه دریاچه را به یک پایه پایدار تبدیل می کند: ارزان برای ذخیره، سریع برای خواندن، قابل پیش بینی در SLO و آماده برای دکتر چنین مقیاس پایه به قله مسابقات و پشتیبانی از هر دو تجزیه و تحلیل دسته ای و فروشگاه های نزدیک به زمان واقعی.