و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
اگر با Power BI یا Fabric کار کرده باشید، احتمالاً یک نقطهٔ مشترک در تمام پروژهها وجود دارد: دادهها همیشه رشد میکنند و Refresh همیشه دیر یا زود به مشکل میخورد.
گاهی سیستم به ظاهر خوب کار میکند، اما پشت صحنه با هر بار Refresh فشار زیادی روی سیستم میگذارد و عملاً معماری آن «مقیاسپذیر» نیست. Dataflows Gen2 و قابلیت Incremental Refresh، راهحلی است که اگر درست طراحی شود، نهتنها Refresh را سریع و قابلپیشبینی میکند، بلکه یک لایهٔ دادهٔ قابلاعتماد و استاندارد برای چند تیم مختلف میسازد.
هدف این مقاله یک چیز است:
ساخت یک Pipe استاندارد، مرحلهبهمرحله، که روی Fabric یا Power BI Premium با حجم بالا، قابل اتکا، قابل دیباگ و قابل نگهداری باشد.
Dataflows Gen2 واقعاً چه میگوید؟
یک نکتهٔ مهم که اغلب نادیده گرفته میشود:
Gen2 فقط یک نسخهٔ «بهروز» نیست؛ بلکه کاملاً مهندسی دوباره شده است.
چند تفاوت حیاتی:
۱. تمام Refresh روی Fabric Engine انجام میشود، نه روی Capacity معمولی
این یعنی Refresh بزرگ حتی روی محیطهای شلوغ هم پایداری بالاتری دارد.
۲. Staging پنهان و Partitioning داخلی
Gen2 داده را خودکار به بخشهای کوچک تقسیم میکند، چیزی که در Gen1 فقط با Incremental Refresh روی Dataset بهدست میآمد.
۳. Transformهای پیچیده هزینه دارند، نه صرفاً حجم داده
یک اشتباه رایج: افراد فکر میکنند اگر حجم داده کم باشد، هر Transformی مجاز است.
اما در Gen2، Transformهای پیچیده (Joinهای چند مرحلهای، GroupByهای سنگین، منطق شرطی تو در تو) معمولاً مهمترین عامل کندی هستند.
۴. Dataflow باید «Pipeline» باشد نه «جایگزین ETL»
Gen2 برای انجام کارهای:
- تمیز کردن
- استانداردسازی
- تقسیمبندی
- آمادهسازی داده برای مدل
طراحی شده است، نه برای اجرای یک ETL کامل.
اگر از Dataflows بهعنوان «ETL کامل» استفاده شود، همیشه Refresh دیر یا زود خراب میشود.
معماری Pipe استاندارد: ۴ Stage ساده، اما دقیق
این همان معماریای است که معمولاً در پروژههای واقعی لاندا استفاده میکنیم. از سازمانهای کوچک تا Enterprise، این ساختار جواب داده است.
ساختار پیشنهادی:
Stage 0 – Parameters
Stage 1 – Landing (Raw, Clean but Untouched)
Stage 2 – Standardization (Types, Normalization, Fixes)
Stage 3 – Business Logic Layer (Joins, Rules, Aggregations)
Stage 4 – Output Model (Final Table for Dataset)
بگذار همینجا یک موضوع را شفاف کنم: این معماری قرار نیست پروژه را پیچیده کند؛ بلکه کاری میکند هر مرحله معنی داشته باشد و در آینده به راحتی قابل نگهداری باشد.
Stage 1 Landing: شفاف، تمیز و بدون منطق اضافه
در این مرحله فقط ۲ هدف داریم:
- ورود امن داده
- قابلیت ریکاوری
Landing باید:
- بدون Transformation سنگین باشد.
- بدون Join باشد.
- فقط شامل تغییرات اجباری باشد. (Rename، Format)
اگر منبع داده API، SQL یا فایلهای متعدد است، Landing باید یک نسخهٔ «قابل اتکا» از دادهها را نگه دارد.
چرا این مرحله حیاتی است؟
چون اگر منبع در دسترس نباشد، Refreshهای بعدی باید بتوانند ادامه پیدا کنند.
اگر همهچیز در مراحل بعد ترکیب شده باشد، Refresh صفر میشود.
نکته پروژهای
در سازمانها معمولاً فایلها و منابع نامنظم هستند.
Landing باعث میشود ورودی بینظم وارد یک لایهٔ منظم شود.
Stage 2 Standardization: جایی که داده «قابل استفاده» میشود.
در این مرحله چند کار مهم اتفاق میافتد:
۱. تعیین انواع دادهها (Data Types)
تجربه ثابت کرده:
۹۰٪ کندی Refresh در پروژهها از نوعگذاری اشتباه میآید.
تاریخ باید Date باشد، نه Text.
Amount باید Decimal باشد، نه Text.
۲. نرمالسازی مقادیر
مثل:
- Trim کردن
- جایگزینی Null
- یکسانسازی کدها
- اصلاح Region/Country
- پاکسازی متن
۳. حذف رکوردهای خراب
این مرحله در حقیقت «پاکسازی اولیه» است.
۴. ساخت ستون Partitioning
Incremental Refresh به یک ستون نیاز دارد که داده بر اساس آن «دورهای» باشد:
مثل:
- LoadDate
- ModifiedDate
- TransactionDate
اگر چنین ستونی ندارید، باید بسازید.
Stage 3 Business Logic Layer: جایی که اصل کار انجام میشود.
این مرحله باید «دقیق» باشد، اما «بیش از حد پیچیده» نباشد.
قرار نیست یک ETL کامل داخل Dataflows نوشته شود.
کارهای این مرحله:
۱. Joinهای اصلی
نه همهٔ Joinها.
فقط Joinهایی که خروجی به آنها نیاز دارد.
۲. Aggregation
نه برای گزارش نهایی،
بلکه برای ساخت مدل خروجی.
۳. محاسبهٔ ستونهای تحلیلی
مثل:
- وضعیت سفارش
- طبقهبندی محصول
- تبدیل کدها
- محاسبهٔ KPIهای پایه
۴. منطق تجاری (Business Rules)
این مرحله نباید سنگین شود.
Business Logic باید دقیقاً به اندازهٔ «نیاز» اعمال شود.
Stage 4 Output Model: خروجی آمادهٔ Dataset
در این مرحله خروجی:
- باید Stable باشد.
- باید فقط شامل ستونهای لازم باشد.
- باید Partition-ready باشد.
- باید با Dataset سازگار باشد.
- نباید Transform اضافی داشته باشد.
این جدول همان چیزی است که Dataset فراخوانی میکند.
ساخت Incremental Refresh
نکته:
Incremental Refresh روی Dataset نیست؛
اینجا روی Dataflow است.
تنظیمات پیشنهادی:
۱. Range
۳ سال
(برای سازمانهای بزرگ ۵ سال)
۲. Increment
۷–۳۰ روز، بسته به نرخ تغییر
۳. Detect Data Changes
اگر ستون ModifiedDate دارید، فعال کنید.
۴. حالت Archive
اگر گزارشها به دادهٔ قدیمی نیاز دارند، Archive را زیاد قرار دهید.
(۵–۱۰ سال).
۵. مناطق قابل تغییر (Hot Zone)
معمولاً:
- ۳۰ روز آخر
- یا ۶۰ روز برای سازمانهای بزرگ
۸ اشتباه رایج که معمولاً اصلیترین دلیل کندی Refresh هستند.
۱. انجام Transformationهای سنگین در یک مرحله
همیشه لایهبندی کنید.
۲. استفاده از Text برای Date
این اشتباه Refresh را ۵ تا ۲۰ برابر کند میکند.
۳. Join روی ستونهایی که Unique نیستند.
نتیجه:
داده ۱۰ برابر میشود، Refresh منفجر میشود.
۴. حذف Partitioning طبیعی
اگر تاریخ دارید، آن را نابود نکنید.
۵. ترکیب چندین منبع مختلف در یک Dataflow
مصیبت نگهداری.
۶. استفاده از GroupBy سنگین بدون Buffer یا Stage
Aggregation باید در لایهٔ درست انجام شود.
۷. استفاده از Dataflow بهجای یک ETL واقعی
برای ETL پیچیده، Fabric Pipeline بهتر است.
۸. Refresh روزانه بدون دلیل
بسیاری از دادهها هفتهای یکبار تغییر میکنند، نه روزانه.
سناریوهای واقعی از پروژههای Enterprise
در ادامه ۸ سناریوی واقعی که در پروژههای لاندا اجرا شده را مرور میکنم.
۱. دیتای ۱۵۰ میلیون ردیفی: Refresh از ۹۰ دقیقه → ۸ دقیقه
مشکل
- Transformهای سنگین
- Joinهای غیرضروری
- ستون تاریخ اشتباه
راهحل
- Stageها جدا شد.
- Partition با ModifiedDate اعمال شد.
- لایهٔ خروجی سبکسازی شد.
نتیجه
Refresh فوقالعاده پایدار شد.
۲. IF/ELSEهای پیچیده روی ۴۰ میلیون ردیف
مشکل
قواعد تجاری درون Dataflow نوشته شده بود.
راهحل
- منطق تجاری به Stage جدا منتقل شد.
- داده خلاصه شد.
- استانداردسازی انجام شد.
نتیجه
زمان Refresh به یکسوم کاهش پیدا کرد.
۳. گزارش فروش چند سایتی با منابع مختلف
مشکل
- منبع ترکیبی (SQL + فایل + API)
- Refresh غیرقابل پیشبینی
راهحل
- Landing جداگانه
- Standardization مشترک
- Merge در یک Stage کنترلشده
۴. خطاهای Refresh در ساعات Peak
مشکل
کمبود Capacity.
راهحل
- Incremental درست
- عایقسازی Stage
- انتقال Transformهای سنگین به قبل از Dataflow
۵. مدل چندتیمی (Finance + Sales + Operations)
مشکل
Output توسط هر تیم تغییر میکرد.
راهحل
- LDM مشترک
- Semantic Layer استاندارد
- خروجی مستقل از تیمها
۶. دادهٔ روزانه + دادهٔ Real-time
راهحل
- دو Layer جدا
- Merge را در Stage سوم انجام دهید.
- Refresh سبک
۷. Refresh طولانی بهخاطر Source Slow
راهحل
- Buffer در Landing
- Load incremental فقط در Landing
- Stageهای بعد فقط روی Fabric
۸. نیاز به محاسبهٔ KPIهای پیچیده
راهحل
- KPI فقط روی Dataset
- Dataflow فقط دادهٔ خام + استاندارد
چکلیست نهایی طراحی Pipe استاندارد
- Landing مستقل
- Standardization با نوعگذاری درست
- Business Logic فقط در مرحلهٔ مربوط
- Output سبک و Stable
- ستون Partition مناسب
- Incremental Refresh با بازههای منطقی
- اجتناب از Transform سنگین
- تست Load با دادهٔ واقعی
- عدم وابستگی مراحل به یکدیگر
- Pipeline قابل نگهداری و مستند
تماس و مشاوره با لاندا
اگر Dataflowهای سازمان شما کند هستند، Refresh غیرقابل پیشبینی دارید یا میخواهید یک معماری استاندارد و مقیاسپذیر برای Fabric یا Power BI طراحی کنید، لاندا آماده است یک Pipeline حرفهای، پایدار و مستند برای محیط شما طراحی و پیادهسازی کند.
نظری داده نشده