On-premises Data Gateway، Scheduled Refresh، SLA و Monitoring در Power BI

شروع جلسه؛ داشبوردی که Refresh نشود، خیلی زود بی‌ارزش می‌شود

فرض کن مدیرعامل ساعت ۸ صبح Dashboard را باز می‌کند ولی آخرین داده مربوط به سه روز قبل است. ظاهر گزارش هرچقدر حرفه‌ای باشد، اعتماد مدیر از بین می‌رود.

در این جلسه Power BI را از زاویه عملیاتی نگاه می‌کنیم: داده چطور از SQL Server داخل شبکه شرکت به Power BI Service می‌رسد، Refresh چطور زمان‌بندی می‌شود و وقتی Refresh خراب شد چه کسی باید بفهمد و چه کاری انجام دهد.

۴۴.۱. Refresh یعنی چه؟

در مدل Import، Power BI یک نسخه از داده را داخل Semantic Model نگه می‌دارد. Refresh یعنی این نسخه را دوباره از Source به‌روز کنیم.

۴۴.۲. Refresh با باز شدن Report فرق دارد

باز کردن Report الزاماً Source Database را دوباره Query نمی‌کند. رفتار به Storage Mode و معماری مدل بستگی دارد.

۴۴.۳. Import Mode

در Import، سرعت Query معمولاً خوب است چون داده داخل مدل قرار دارد؛ ولی باید فرآیند Refresh مطمئن داشته باشیم.

۴۴.۴. DirectQuery

در DirectQuery بخش بزرگی از Query هنگام استفاده به Source می‌رود. این معماری مسئله‌های Performance، Availability و Security خودش را دارد.

۴۴.۵. Gateway چیست؟

On-premises Data Gateway مثل یک پل امن بین Power BI Service و منابعی است که داخل شبکه خصوصی سازمان قرار دارند.

۴۴.۶. مسیر اتصال

۴۴.۷. چرا Gateway لازم می‌شود؟

Power BI Service در Cloud است ولی SQL Server شرکت ممکن است پشت Firewall و داخل LAN باشد. Gateway ارتباط لازم را بدون Publish کردن مستقیم Database روی اینترنت فراهم می‌کند.

۴۴.۸. Gateway روی چه سیستمی نصب شود؟

برای محیط Production بهتر است Gateway روی ماشین پایدار و همیشه روشن نصب شود؛ نه لپ‌تاپ توسعه‌دهنده‌ای که شب خاموش می‌شود.

۴۴.۹. Gateway Machine

۴۴.۱۰. Personal vs Standard

برای سناریوهای سازمانی و چندکاربره معمولاً Standard/Enterprise-style gateway مناسب‌تر از راهکار شخصی است؛ معماری نهایی را با نیاز و Tenant واقعی تطبیق بده.

۴۴.۱۱. Gateway Cluster

در محیط‌های حساس می‌توان چند Gateway را در ساختار Cluster/High Availability بررسی کرد تا خرابی یک Node کل Refresh را متوقف نکند.

۴۴.۱۲. Single Point of Failure

اگر تنها Gateway روی یک VM بدون Backup باشد، همان VM می‌تواند Single Point of Failure سیستم BI شود.

۴۴.۱۳. Data Source Definition

بعد از نصب Gateway باید Data Source/Connection مناسب تعریف و Credentialها را مدیریت کنیم.

۴۴.۱۴. Server Name باید هماهنگ باشد

نام Server و Database در Dataset و Gateway Mapping باید با تنظیمات اتصال سازگار باشد. تفاوت Alias یا Connection Detail می‌تواند Mapping را خراب کند.

۴۴.۱۵. Credentials

Credential باید متعلق به یک هویت مناسب عملیاتی باشد. وابستگی Production به Password شخصی توسعه‌دهنده ریسک دارد.

۴۴.۱۶. Service Account

در سازمان، Service Account یا Identity مدیریت‌شده طبق سیاست IT می‌تواند Ownership و Continuity بهتری ایجاد کند.

۴۴.۱۷. Least Privilege برای Source

Account مربوط به Refresh فقط Permission لازم برای خواندن داده موردنیاز را داشته باشد؛ دسترسی DBA بی‌دلیل نده.

۴۴.۱۸. Credential Rotation

اگر Password تغییر کند ولی Gateway Connection به‌روزرسانی نشود، Refresh شکست می‌خورد. Rotation باید فرآیند هماهنگ داشته باشد.

۴۴.۱۹. Scheduled Refresh

در Service می‌توان Refresh را در زمان‌های مشخص اجرا کرد. تعداد و Frequency مجاز به License/Capacity و تنظیمات محیط وابسته است.

۴۴.۲۰. زمان Refresh

زمان‌بندی را بر اساس آماده شدن Source Data انجام بده؛ نه صرفاً یک ساعت رند.

۴۴.۲۱. مثال اشتباه

ETL ساعت ۶:۳۰ تمام می‌شود ولی Power BI ساعت ۶ Refresh می‌شود؛ Dashboard هر روز داده دیروز را نشان می‌دهد.

۴۴.۲۲. Data Pipeline Timing

۴۴.۲۳. SLA چیست؟

SLA در اینجا یعنی تعهد عملیاتی مشخص؛ مثلاً «Dashboard فروش تا ساعت ۷ صبح باید داده روز قبل را با موفقیت نمایش دهد».

۴۴.۲۴. SLA خوب

باید قابل اندازه‌گیری باشد: زمان آماده بودن، Freshness، Availability و مسئول رسیدگی.

۴۴.۲۵. Freshness KPI

Data Freshness = Current Time - Last Successful Data Time

۴۴.۲۶. Last Refresh روی Report

در Dashboard مهم، زمان آخرین Refresh یا آخرین تاریخ داده را به کاربر نشان بده تا Context روشن باشد.

۴۴.۲۷. Data Date vs Refresh Time

ممکن است Report امروز Refresh شده باشد ولی Source فقط تا دو روز قبل داده داشته باشد. پس Last Refresh و Max Business Date دو مفهوم متفاوت‌اند.

۴۴.۲۸. Max Data Date

Last Data Date = MAX(FactSales[OrderDate])

۴۴.۲۹. Refresh Operations

۴۴.۳۰. Refresh History

تاریخچه Refresh را مرتب بررسی کن: Success/Failure، Duration و الگوی خطاها.

۴۴.۳۱. Duration Baseline

اگر Refresh معمولاً ۸ دقیقه بوده و ناگهان ۴۵ دقیقه شده، حتی اگر Success شود باید علت بررسی شود.

۴۴.۳۲. Refresh Failure

Failure را به عنوان رخداد عملیاتی مدیریت کن؛ نه اینکه صبر کنیم مدیر گزارش خراب را پیدا کند.

۴۴.۳۳. دسته‌بندی خطا

۴۴.۳۴. Gateway Offline

اول Availability ماشین، Service مربوط به Gateway، Network و وضعیت Cluster را بررسی کن.

۴۴.۳۵. SQL Timeout

ممکن است Query سنگین شده، Index تغییر کرده، حجم داده زیاد شده یا Source تحت فشار باشد.

۴۴.۳۶. Schema Drift

اگر تیم ERP نام Column را تغییر دهد، Power Query ممکن است Fail شود. Contract داده و Change Management اهمیت دارد.

۴۴.۳۷. Source Contract

برای Sourceهای حیاتی مشخص کن چه Table/Columnهایی قرارداد BI هستند و تغییرشان باید قبل از Production اطلاع داده شود.

۴۴.۳۸. Retry

Retry می‌تواند خطاهای موقت را پوشش دهد، ولی نباید خطای ساختاری را ساعت‌ها مخفی کند.

۴۴.۳۹. Alert Owner

هر Refresh حیاتی باید Owner داشته باشد؛ مثلاً BI Operations و Backup Owner.

۴۴.۴۰. Escalation

۴۴.۴۱. Runbook

Runbook یعنی راهنمای مرحله‌به‌مرحله رفع خطا: چه چیزی را چک کنیم، Log کجاست، Owner کیست و Escalation به چه کسی انجام شود.

۴۴.۴۲. Runbook نمونه

1. Check refresh history
2. Check gateway status
3. Validate credentials
4. Test source availability
5. Identify failed query/table
6. Retry if transient
7. Escalate if SLA at risk

۴۴.۴۳. Monitoring Dashboard

برای محیط بزرگ می‌توان خود عملیات BI را هم Dashboard کرد: Refresh Success Rate، Duration، Failures، SLA Breaches و Gateway Health.

۴۴.۴۴. Success Rate

Refresh Success Rate = Successful Refreshes / Total Refreshes

۴۴.۴۵. SLA Breach

هر بار که داده بعد از زمان تعهدشده آماده شود یک Breach ثبت کن؛ حتی اگر Refresh در نهایت Success شده باشد.

۴۴.۴۶. Incremental Refresh

برای Factهای بزرگ لازم نیست همیشه تمام تاریخ را دوباره Load کنیم. Incremental Refresh می‌تواند فقط Window موردنیاز را پردازش کند.

۴۴.۴۷. چرا Incremental؟

مثلاً FactSales پنج سال داده دارد ولی فقط چند روز اخیر تغییر می‌کند. Refresh کامل هزینه بی‌دلیل ایجاد می‌کند.

۴۴.۴۸. RangeStart / RangeEnd

در الگوهای Incremental Refresh از Parameterهای زمانی برای Partition/Filter Window استفاده می‌شود.

۴۴.۴۹. Query Folding

برای Refresh کارآمد، بهتر است Filter تا حد ممکن به Source Push شود. اگر Query Folding شکسته شود ممکن است حجم زیادی داده بی‌دلیل منتقل شود.

۴۴.۵۰. Folding Check

Power Query transformations را از نظر Folding و Performance بررسی کن؛ مخصوصاً قبل از Incremental Refresh.

۴۴.۵۱. Refresh Window

Window باید با رفتار Business هماهنگ باشد. اگر سفارش‌های ۳۰ روز قبل قابل اصلاح‌اند، Refresh فقط یک روز اخیر کافی نیست.

۴۴.۵۲. Late-arriving Data

داده دیررس می‌تواند باعث شود رکورد قدیمی بعداً وارد DWH شود. Strategy Refresh باید این حالت را پوشش دهد.

۴۴.۵۳. Detect Data Changes

در سناریوهای مناسب می‌توان تغییرات داده را با Column زمانی مناسب تشخیص داد؛ طراحی دقیق به Source بستگی دارد.

۴۴.۵۴. Full Refresh هنوز لازم است؟

گاهی برای Dimension کوچک یا مدل کم‌حجم Full Refresh ساده‌تر و قابل اعتمادتر است. Incremental را فقط چون حرفه‌ای‌تر به نظر می‌رسد اضافه نکن.

۴۴.۵۵. Refresh Dependency

اگر Dimension یا Dataflow قبل از Semantic Model باید Refresh شود، ترتیب Dependency را طراحی کن.

۴۴.۵۶. Orchestration

در معماری Enterprise ممکن است ETL، Dataflow، Warehouse و Semantic Model یک Pipeline وابسته داشته باشند.

۴۴.۵۷. Refresh Chain

Source → ETL → Warehouse → Data Quality → Semantic Model → App consumers

۴۴.۵۸. Data Quality Gate

قبل از انتشار داده جدید می‌توان Checkهایی مثل Row Count، Null Rate، Duplicate و Balance را اجرا کرد.

۴۴.۵۹. Silent Bad Data

Refresh موفق به معنی داده درست نیست. ممکن است Query بدون خطا اجرا شود ولی Sales صفر یا ناقص باشد.

۴۴.۶۰. Validation Rule

۴۴.۶۱. Freshness Indicator

روی Report می‌توان Status ساده ساخت: Fresh، Warning، Stale.

۴۴.۶۲. Freshness Logic

Freshness Status =
SWITCH(
 TRUE(),
 [Hours Since Data] <= 24, "Fresh",
 [Hours Since Data] <= 36, "Warning",
 "Stale"
)

۴۴.۶۳. Business Timezone

Refresh Time و Data Time را با Timezone کسب‌وکار هماهنگ کن؛ Cloud Service و Source ممکن است Timezone متفاوت داشته باشند.

۴۴.۶۴. Daylight Saving

در سازمان‌های بین‌المللی DST و چند Timezone می‌تواند Schedule و Timestamp را پیچیده کند.

۴۴.۶۵. Multiple Sources

اگر مدل از SQL، Excel شبکه و API استفاده می‌کند، هر Source Availability و Credential Strategy خودش را دارد.

۴۴.۶۶. Cloud Source

همه Cloud Sourceها Gateway نمی‌خواهند. نوع Connector و معماری Service را بررسی کن.

۴۴.۶۷. On-prem File

فایل روی Network Share هم برای Service نیاز به معماری دسترسی قابل اتکا دارد؛ مسیر محلی C:\ روی لپ‌تاپ توسعه‌دهنده انتخاب Production نیست.

۴۴.۶۸. Privacy Levels

ترکیب چند Source می‌تواند با Privacy/Connector behavior مرتبط شود. تنظیمات را بدون درک اثرشان خاموش نکن.

۴۴.۶۹. Gateway Security

Gateway را Patch و مدیریت کن، دسترسی Admin آن محدود باشد و Recovery/Ownership مستند شود.

۴۴.۷۰. Recovery Key

اطلاعات بازیابی Gateway باید طبق سیاست امن سازمان نگهداری شود؛ از وابستگی به حافظه یک نفر جلوگیری کن.

۴۴.۷۱. Gateway Update

نسخه Gateway را منظم به‌روز کن و قبل از تغییر Production برنامه Maintenance داشته باش.

۴۴.۷۲. Capacity Planning

اگر ده‌ها Dataset همزمان ساعت ۷ Refresh شوند، Gateway، Source و Capacity ممکن است تحت فشار قرار بگیرند.

۴۴.۷۳. Stagger Schedule

Refreshها را در صورت امکان پخش کن؛ همه مدل‌ها لازم نیست دقیقاً رأس یک ساعت اجرا شوند.

۴۴.۷۴. Source Load

BI نباید سیستم تراکنشی را در ساعت اوج با Queryهای سنگین از کار بیندازد. DWH/Replica می‌تواند معماری بهتری باشد.

۴۴.۷۵. Production Database

برای Analytics سنگین، مستقیم زدن به OLTP Production همیشه انتخاب مناسبی نیست. اثر Queryها را با DBA بررسی کن.

۴۴.۷۶. پروژه شرکت هانا؛ معماری

۴۴.۷۷. پروژه شرکت هانا؛ Validation

بعد از Refresh، Max Sales Date، تعداد سفارش و Total Sales با Thresholdهای تعریف‌شده بررسی شوند.

۴۴.۷۸. پروژه شرکت هانا؛ Alert

اگر Refresh تا ۶:۵۰ موفق نشد، تیم BI هشدار بگیرد؛ اگر SLA ساعت ۷ در خطر است، Escalation انجام شود.

۴۴.۷۹. پروژه شرکت هانا؛ Incremental

FactSales پنج‌ساله را Partition/Incremental طراحی کن؛ Window تغییرات را بر اساس رفتار واقعی ERP تعیین کن.

۴۴.۸۰. پروژه شرکت هانا؛ Report Header

در Header نمایش بده: Data through 2026-08-20 | Last refresh 06:42 | Status: Fresh.

۴۴.۸۱. Operational KPI

۴۴.۸۲. خطای رایج؛ Gateway روی لپ‌تاپ

با خاموش شدن سیستم، Refresh Production متوقف می‌شود.

۴۴.۸۳. خطای رایج؛ Password شخصی

کارمند Password را تغییر می‌دهد یا شرکت را ترک می‌کند و Refresh می‌خوابد.

۴۴.۸۴. خطای رایج؛ Schedule قبل از ETL

گزارش ظاهراً Refresh می‌شود ولی داده جدید هنوز آماده نبوده است.

۴۴.۸۵. خطای رایج؛ Success = Correct

Refresh سبز است ولی داده ناقص؛ Data Quality Check نداشته‌ای.

۴۴.۸۶. خطای رایج؛ همه Refreshها همزمان

Gateway و SQL در یک بازه کوتاه Saturate می‌شوند.

۴۴.۸۷. خطای رایج؛ بدون SLA

هیچ‌کس نمی‌داند تأخیر ۲۰ دقیقه‌ای مشکل محسوب می‌شود یا نه.

۴۴.۸۸. Best Practiceها

Gateway را روی زیرساخت پایدار نصب کن.

Production را به Credential شخصی وابسته نکن.

Least Privilege رعایت کن.

Schedule را بعد از آماده شدن Source تنظیم کن.

Last Data Date را نمایش بده.

Refresh History و Duration را مانیتور کن.

Runbook و Escalation داشته باش.

Data Quality را بعد از Refresh بررسی کن.

Incremental Refresh را برای حجم مناسب بررسی کن.

Query Folding را حفظ کن.

Refreshها را Stagger کن.

Gateway و Source را Capacity Plan کن.

۴۴.۸۹. تمرین ۱

برای SQL Server داخل شبکه، معماری Source → Gateway → Service را روی کاغذ طراحی کن.

۴۴.۹۰. تمرین ۲

یک SLA بنویس: زمان ETL، Refresh، Data Ready و Owner.

۴۴.۹۱. تمرین ۳

جدول Refresh Monitoring با Dataset، StartTime، EndTime، Status و ErrorCategory طراحی کن.

۴۴.۹۲. تمرین ۴

سه Data Quality Rule برای Sales Model تعریف کن.

۴۴.۹۳. تمرین ۵

برای FactSales بزرگ، Policy مفهومی Incremental Refresh طراحی کن و Window تغییرات را توضیح بده.

۴۴.۹۴. تمرین ۶

Runbook خطای Gateway Offline و Credential Failure بنویس.

۴۴.۹۵. تمرین چالشی

برای سازمانی با ۲۰ Semantic Model، دو Gateway Node و SQL Server مرکزی، Schedule طوری طراحی کن که بار Refresh پخش شود و Reportهای Executive قبل از ۷ صبح آماده باشند.

۴۴.۹۶. پروژه Session؛ Production Refresh Operations Pack

هدف این پروژه این است که Dashboard هر روز بدون دخالت دستی، در زمان مشخص و با داده قابل اعتماد آماده باشد.

جمع‌بندی Session 44

BI حرفه‌ای فقط ساخت نمودار نیست؛ عملیات پایدار داده بخش بزرگی از کار است. اگر Refresh قابل اعتماد نباشد، اعتماد به کل سیستم تحلیلی از بین می‌رود.

Reliable source → Stable gateway → Controlled refresh → Data validation → SLA → Trusted dashboard

Session 45: Performance Optimization حرفه‌ای؛ Performance Analyzer، DAX Studio، VertiPaq، Cardinality، Model Size، Query Optimization و پیدا کردن گلوگاه‌های واقعی.