معماری متریک

معماری متریک

معماری متریک سیستمی از قوانین، مصنوعات و خدمات است که تعاریف بدون ابهام، محاسبه قابل تکرار، دسترسی شفاف و عملکرد قابل اعتماد شاخص ها را در سراسر سازمان ارائه می دهد. هدف این است که «MAU»، «Retention D30» یا «ARPPU» در همه داشبورد ها، آزمایش ها و گزارش ها یکسان باشد.

1) اصول

1. تنها منبع حقیقت برای فرمولها و کتابهای مرجع

2. جداسازی معانی از پیاده سازی: تعریف کسب و کار در یک لایه معنایی زندگی می کند، نه در هر SQL/لپ تاپ.
3. معیارهای نسخهبندی، طرحوارهها و فرمولها (v1 → v2) با مهاجرت تاریخ مدیریت شده.
4. تکرارپذیری و آزمونپذیری: محاسبات قطعی هستند و توسط آزمونها پوشش داده میشوند.
5. قابلیت مشاهده: طراوت، کامل بودن، سازگاری و رانش - با SLO ها و هشدارها.
6. امنیت و حریم خصوصی: به حداقل رساندن PII، RLS/CLS، ممیزی.
7. سیستم عامل به عنوان کد: تعاریف، تحولات، سیاست ها - در مخزن با CI/CD.

2) لایه های معماری

داده های منبع: رویدادها/معاملات، کتاب های مرجع، سیاهههای مربوط به مدل/infra.
ادغام و تمیز کردن: CDC/بارگذاری افزایشی، dedup، اتحاد مناطق زمانی.
مدل داده (DWH): ستاره/برف ریزه، اندازه گیری به آرامی در حال تغییر (SCD)، کلید جانشین.
لایه معنایی معیارها: تعاریف یکنواخت، aggregations، فیلترها، دانه زمان، منطق rollup.
لایه طراحی: دسته/میکروبچ/جریان ؛ پنجرهها، علامتهای آب، کلیدها.
کاتالوگ و فرهنگ لغت: «معیارهای گذرنامه»، اصل و نسب، صاحبان، حقوق.
دسترسی و مصرف: BI/داشبورد، معیارهای API، آپلود، آزمایش/AB.

3) قراردادهای داده و متریک

قرارداد منبع (رویدادها/جداول)

طرحواره: فیلدها، نوعها، پوچی، کلید اصلی.
SLA: طراوت (به عنوان مثال، «≤10 دقیقه تاخیر»)، فرکانس، حداکثر تاخیر در ورود.
کیفیت: منحصر به فرد کلیدی، دامنه ارزش معتبر، منطقه زمانی، idempotency.
تغییرات: سیاست تکامل طرح (عقب/جلو)، طرح انحراف.

قرارداد متریک

نام/شناسه: 'RET _ D30 _ v2'

Domaine/مالک: تجزیه و تحلیل محصول

تعریف (به زبان انسان)

فرمول: SQL/pseudocode + ورودی فروشگاه ها/اشیاء معنایی

دانه دانه/منطق زمانی: روز/هفته ؛ قوانین نقطه در زمان، منطقه زمانی

بخش های پیش فرض/فیلترها

واحد و ارز (نرخ تبدیل/تاریخ)

SLO: طراوت ≤ X، دقت ≥ Y، در دسترس بودن ≥ Z

نسخه/تغییر تاریخ/تاریخ موثر

Guardrails: محدوده معتبر، قوانین Winzorization p1/p99

4) لایه معنایی معیارها

• عناصر: ابعاد (تاریخ، کشور، پلت فرم)، حقایق (رویدادها، درآمد)، معیارها (ARPU، Retention D30)، زمینه های محاسبه شده، تقویم (کار/تعطیلات آخر هفته، تعطیلات).
• رفتار زمان: جداول تقویم، عقب ماندگی ها، گروه ها، پنجره های «کشویی» (7/30/90).
• Rollup و سازگاری: مقدار به روز = ماه، در حالی که به استثنای شمارش دو (کاربران متمایز).
• مخلوط تنظیم: عادی به یک ترکیب ثابت از کانال/کشور برای YoY صادق است.
• چند ارزی/منطقه زمانی: تنظیم شده به ارز پایه در تاریخ معامله ؛ محلی و «متعارف» برش UTC تنظیم شده اند.

5) محاسبه: دسته ای، microbatch، جریان

دسته: شغل های شبانه/ساعتی، محاسبه مجدد کامل/افزایشی، کنترل idempotency.
Microbatch: ویندوز 1-15 دقیقه برای داشبورد عملیاتی.
جریان: حوادث از طریق تایر ؛ ویندوز (غلت زدن/کشویی/جلسه)، علائم آب (داده های اواخر)، دقیقا یک بار معنایی (بن بست + فروشگاه افست).

• 'HOP 5m، WINDOW 1h' برای KPI های عملیاتی ؛
• 'TUMBLE 1d' برای معیارهای روزانه ؛
• جلسه 30 جلسه برای جلسات.

6) کیفیت و قابلیت اطمینان

تست داده ها: شماتیک، دامنه (محدوده)، لینک های ارجاعی.
تست معیارها: ثابت (DAU≤MAU)، بخش های غیر خالی، انتظارات یکنواختی (تجمعی).
آشتی: بین لایه معنایی و گزارش های مرجع/حسابداری.
سلامت داده ها: طراوت، کامل بودن، تکراری، کسر NULL، جهش های غیر طبیعی.
معیارهای رانش: PSI/KL/JS در ویژگی های کلیدی، به ویژه برای معیارهای ML.

7) نسخه و مهاجرت

فرمول آن 'METRIC _ NAME _ vN' است. تغییر «بی سر و صدا» تعریف بدون تغییر نسخه ممنوع است.

• Side-by-side: v1 و v2 به صورت موازی شمارش می شوند. هماهنگی و آموزش کاربران انجام می شود.
• برش: تغییر مصرف کنندگان به v2 در پنجره بار کم ؛ آرشیو v1
• محاسبه مجدد تاریخ: پر کردن با توجه به داده های تاریخی ؛ پروتکل تفاوت (گزارش تفاوت).
• ارتباطات: تغییرات، تاریخ ورود، چه کسی تحت تاثیر قرار خواهد گرفت، دستورالعمل ها.

8) مدل داده برای معیارها

حقایق: دانه (event_id، transaction_id، user_day)، زمان رویداد، مجموع/ارزش.

ابعاد: کاربر، دستگاه، جغرافیا، کانال، محصول، تقویم ؛ نوع SCD برای تاریخی بودن

کلید: شناسه جانشین، کلید کسب و کار پایدار، جداول نقشه برداری.
ضد تکراری: قوانین هویت (ادغام کاربر)، جلسه «چسباندن» ویندوز.

9) واحد، ارز، فصلی

واحد/فرمت: واحد صریح، گرد، مقیاس (ورود/خطی).
چند ارزی: تبدیل در نرخ ارز در تاریخ معامله ؛ هر دو مقدار «خام» و نرمال را ذخیره کنید.
فصلی: شاخص های YoY و فصلی ؛ اثرات «تعطیلات» جداگانه.

10) امنیت و دسترسی

Row-Level Security (RLS): دسترسی به معیارهای کشور/نام تجاری/شریک.
امنیت سطح ستون (CLS) - زمینه های PII/زمینه های مالی.
ممیزی: چه کسی درخواست متریک، کدام فیلتر، که داده ها را صادر می کند.
تمایز API: «aggregates by role» در مقابل «آپلود دقیق».

11) قابلیت مشاهده و SLO

تازگی SLO: به عنوان مثال، «KPI عملیاتی - تاخیر ≤ 15 دقیقه، روزانه - تا 06:00 به وقت محلی».
در دسترس بودن SLO: ≥ 99. 9٪ برای API/لایه معنایی.
هشدارها: بزهکاری SLO، جهش متریک، رشد NULL/تکراری، واریانس v1 در مقابل v2> X٪.
Runbooks: چه کاری باید انجام دهید زمانی که تنزل - مراحل RCA, برگشت (برای مثال, تعویض به آخرین معتبر «متریک عکس فوری»).

12) آزمایش ها و معیارها

معیارهای Guardrail: تاخیر، انعطاف پذیری، FPR/FNR برای نمره.
تعاریف یکنواخت برای A/B: تبدیل، نگهداری، NSM - از طریق همان لایه معنایی.
حداقل اثر قابل تشخیص (MDE)، تجزیه و تحلیل قدرت: پارامترهای فروشگاه در کارت متریک.
انتساب علی: سیاست های گروه های مخلوط تنظیم و کنترل.

13) معیارهای API و مصرف

Запросы: «GET/metrics/{ name}? from = 2025-09-01 & to = 2025-10-01 & dims = کشور، پلتفرم و فیلترها = کانال: پرداخت شده».
سیاست: محدودیت, کش, صفحه بندی, idempointent «صادرات».
نسخه ها: هدر X-Metric-Version: v2، هشدارهای کاهش ارزش.

14) الگوها و مصنوعات

گذرنامه متریک (مثال)

کد/نسخه: «ARPPU _ v3»

تعریف: درآمد متوسط برای هر کاربر پرداخت کننده برای دوره

: 'sum ( )/ (where)'

دانه بندی: روز ؛ rollup: هفته/ماه = مجموع صورت/مخرج کسر

منابع: 'fact _ payments _ v2'، 'dim _ users _ scd'

واحد: ارز 'پایه _ CCY'; تبدیل در نرخ ارز از

فیلترهای پیش فرض: بازارهای فعال، معاملات آزمایشی را حذف می کنند

SLO: طراوت ≤ 1 ساعت ؛ API ≥ 99 در دسترس بودن. 9%

گارد محافظ: ∈ ARPPU [0 ؛ 10 000]; vinzorization p1/p99

صاحبان: تجزیه و تحلیل کسب درآمد ؛ تاریخ تجدید نظر: 2025-10-01

انتشار متریک چک لیست

• تعریف و فرمول توافق شده، تحت پوشش آزمایش
• شیء معنایی ایجاد شده است ؛ اصل و نسب مستند
• پر کردن و مراجع تکمیل شده است
• SLO/هشدارها پیکربندی می شوند ؛ کتاب اجرا آماده است
• حقوق و RLS پیکربندی شده ؛ PII پنهان شده است
• نسخه های قدیمی جایگزین در داشبورد/آزمایش
• تغییرات/ارتباطات ارسال شده است

نقطه در زمان کد شبه SQL (به عنوان مثال D30 نگهداری)

sql
WITH cohort AS (
SELECT user_id, MIN(event_date) AS signup_date
FROM fact_events
WHERE event_type = 'signup'
GROUP BY 1
),
activity AS (
SELECT user_id, event_date
FROM fact_events
WHERE event_type = 'app_open'
),
ret AS (
SELECT c. signup_date,
COUNT(DISTINCT CASE WHEN a. event_date = c. signup_date + INTERVAL '30 day' THEN a. user_id END) AS returned,
COUNT(DISTINCT c. user_id) AS cohort_size
FROM cohort c
LEFT JOIN activity a
ON a. user_id = c. user_id
AND a. event_date BETWEEN c. signup_date AND c. signup_date + INTERVAL '30 day'
GROUP BY 1
)
SELECT signup_date, returned / cohort_size AS retention_d30
FROM ret;

15) اشتباهات مکرر و چگونگی اجتناب از آنها

ویرایش فرمول آرام: همیشه از طریق نسخه و changelog.
معیارهای «متفاوت در هر لپ تاپ»: نیروی لایه معنایی/API.
ساعت های ناسازگار/ارزها: تقویم متمرکز و جدول FX.
حسابداری دو کاربر: قوانین رول آپ و کلید های منحصر به فرد.
طراوت مات: به وضوح زمان تاخیر/به روز رسانی را نشان می دهد.
وابستگی به یک مهندس: همه چیز مانند یک کد، با بررسی و یک آنکال است.

مجموع

معماری معیارها dictionary + semantic layer + strong calculation + governance و SLO است. با پیروی از اصول شرح داده شده (قراردادها، آزمایشات، نسخه ها، قابلیت مشاهده، ایمنی)، شما معیارها را از «اختلافات تعداد» به یک محصول پایدار و مکانیسم مدیریت کسب و کار تبدیل می کنید.