Power BI Performance Optimization: DAX, Models, and Queries

پاور BI رپورٹ جو لوڈ ہونے میں 15 سیکنڈ لیتی ہے وہ رپورٹ ہے جسے صارفین استعمال کرنا چھوڑ دیتے ہیں۔ کارکردگی کوئی تکنیکی خوبی نہیں ہے --- یہ BI کو اپنانے اور BI ترک کرنے کے درمیان فرق ہے۔ رپورٹ لوڈ ٹائم کا ہر سیکنڈ صارف کی مصروفیت کو کافی حد تک کم کرتا ہے۔ تحقیق مستقل طور پر ظاہر کرتی ہے کہ انٹرایکٹو ڈیش بورڈز (3 سیکنڈ سے کم لوڈ ٹائم) سست والے (10 سیکنڈ سے زیادہ) کے مقابلے میں 4-5x زیادہ آراء حاصل کرتے ہیں، اور جو صارفین مسلسل سست روی کا تجربہ کرتے ہیں وہ 30 دنوں کے اندر دستی عمل کی طرف لوٹ جاتے ہیں۔

اچھی خبر یہ ہے کہ پاور BI کی کارکردگی کے مسائل تقریباً ہمیشہ ہی حل ہوتے ہیں۔ ہمارے سینکڑوں پاور BI ماحول کو بہتر بنانے کے تجربے میں، 90% کارکردگی کے مسائل پانچ بنیادی وجوہات میں سے ایک کا پتہ لگاتے ہیں: ناکارہ DAX اقدامات، بڑے ڈیٹا ماڈل، ناقص رشتہ ڈیزائن، DirectQuery کا نامناسب استعمال، یا کام کے بوجھ کے لیے ناکافی صلاحیت۔ یہ گائیڈ ان مسائل میں سے ہر ایک کی تشخیص اور حل کرنے کے لیے ایک منظم طریقہ فراہم کرتا ہے۔

اگر آپ کا پاور BI ماحول کارکردگی کے مسائل کا سامنا کر رہا ہے جسے آپ کی ٹیم اندرونی طور پر حل نہیں کر سکتی ہے، تو ہماری Power BI کارکردگی کو بہتر بنانے کی خدمات ہینڈ آن تجزیہ اور تدارک فراہم کرتی ہے۔

اہم ٹیک ویز

• پاور BI ڈیسک ٹاپ میں کارکردگی کا تجزیہ کار اس بات کی نشاندہی کرتا ہے کہ کون سے بصری اور سوالات سست ہیں --- اصلاح کرنے سے پہلے ہمیشہ یہاں سے شروع کریں۔
• DAX اسٹوڈیو سے پتہ چلتا ہے کہ آیا سٹوریج انجن (ڈیٹا اسکیننگ) یا فارمولہ انجن (کیلکولیشن) میں سست استفسارات میں رکاوٹ ہے --- فکس ڈرامائی طور پر مختلف ہے۔
• DAX کی کارکردگی کی سب سے عام غلطیاں غیر ضروری CALCULATE nesting ہیں، تکرار کرنے والوں کا استعمال کرتے ہوئے جہاں ایگریگیٹرز کافی ہیں، اور بڑے درمیانی میزوں کو عملی شکل دینا
• ماڈل کا سائز کارکردگی کو براہ راست متاثر کرتا ہے: غیر استعمال شدہ کالموں کو ہٹانا، کارڈینیلیٹی کو کم کرنا، اور ڈیٹا کی قسموں کو بہتر بنانا ماڈلز کو 40-70% سکڑ سکتا ہے۔
• جمع کرنے کی میزیں پہلے سے کمپیوٹنگ سمری ڈیٹا کے ذریعے بڑے ڈیٹا سیٹس کے لیے 10-100x استفسار کی کارکردگی میں بہتری فراہم کرتی ہیں
• DirectQuery انٹرایکٹو رپورٹس کے لیے امپورٹ موڈ سے 10-100x سست ہے --- اسے صرف اس وقت استعمال کریں جب ڈیٹا کی تازہ کاری کے تقاضے حقیقی طور پر اس کا مطالبہ کریں۔
• دستاویزی میٹرکس کے ساتھ بینچ مارکنگ سے پہلے/بعد اصلاح کے اثرات کو ثابت کرنے اور رجعت کو روکنے کے لیے ضروری ہے۔

---

تشخیصی ٹولز اور طریقہ کار

کارکردگی کا تجزیہ کرنے والا

پرفارمنس اینالائزر پاور BI ڈیسک ٹاپ کا بلٹ ان ڈائیگنوسٹک ٹول ہے۔ یہ رپورٹ کے صفحے پر ہر بصری کے ذریعہ پیدا ہونے والے ہر سوال کے عمل کے وقت کو ریکارڈ کرتا ہے، وقت کو تین اجزاء میں تقسیم کرتا ہے:

پرفارمنس اینالائزر کا استعمال کیسے کریں:

1. پاور BI ڈیسک ٹاپ میں اپنی رپورٹ کھولیں۔
2. دیکھیں > پرفارمنس اینالائزر پر جائیں۔
3. "ریکارڈنگ شروع کریں" پر کلک کریں۔
4. رپورٹ کے ساتھ تعامل کریں (فلٹرز تبدیل کریں، صفحات پر جائیں، سلائسرز لگائیں)۔
5. "اسٹاپ" پر کلک کریں۔
6. کل مدت کے لحاظ سے ترتیب دیئے گئے نتائج کا جائزہ لیں۔

نتائج کی تشریح:

• اگر DAX استفسار کا وقت غالب ہے، تو مسئلہ آپ کے اقدامات یا ماڈل میں ہے۔ گہرے تجزیہ کے لیے DAX اسٹوڈیو استعمال کریں۔
• اگر بصری ڈسپلے کا وقت غالب ہے، تو مسئلہ بصری ترتیب میں ہے (بہت زیادہ ڈیٹا پوائنٹس، پیچیدہ مشروط فارمیٹنگ، یا خراب کارکردگی کا مظاہرہ کرنے والا حسب ضرورت بصری)۔
• اگر "دوسرے" وقت کا غلبہ ہوتا ہے، تو مسئلہ بنیادی ڈھانچے کا ہے (ڈائریکٹ کیوری کے لیے نیٹ ورک میں تاخیر، گیٹ وے کی رکاوٹیں، یا صلاحیت کی تھروٹلنگ)۔

اہم قدم جسے زیادہ تر لوگ چھوڑتے ہیں: پرفارمنس اینالائزر سے DAX استفسار کو کاپی کریں (دائیں کلک کریں > "استفسار کاپی کریں") اور اسے DAX اسٹوڈیو میں چسپاں کریں۔ کارکردگی کا تجزیہ کار آپ کو بتاتا ہے کہ کون سا بصری سست ہے۔ DAX اسٹوڈیو آپ کو اس کی وجہ بتاتا ہے۔

DAX اسٹوڈیو

DAX اسٹوڈیو ایک مفت، اوپن سورس ٹول ہے جو پاور BI کے تحت تجزیہ خدمات کے انجن کے لیے گہری تشخیصی صلاحیتیں فراہم کرتا ہے۔ یہ کسی بھی پاور BI کارکردگی انجینئر کی ٹول کٹ میں سب سے اہم ٹول ہے۔

** کلیدی DAX اسٹوڈیو کی صلاحیتیں:**

سرور کے اوقات: اسٹوریج انجن (SE) اور فارمولا انجن (FE) کے استفسار کے وقت کے درمیان خرابی کو ظاہر کرتا ہے۔

• اسٹوریج انجن (SE) سوالات کالمر اسٹوریج (VertiPaq انجن) کے خلاف کیے گئے ڈیٹا اسکین ہیں۔ وہ انتہائی متوازی اور تیز ہیں۔ SE سوالات ٹریس میں xmSQL بیانات کے طور پر ظاہر ہوتے ہیں۔
• فارمولہ انجن (FE) آپریشن SE سوالات کے نتائج پر کیے جانے والے سنگل تھریڈڈ حسابات ہیں۔ FE آپریشنز سب سے سست DAX اقدامات میں بنیادی رکاوٹ ہیں۔

آپٹمائزیشن کا مقصد اسٹوریج انجن میں زیادہ سے زیادہ کام کو آگے بڑھانا اور فارمولا انجن کے کاموں کو کم سے کم کرنا ہے۔

استفسار کے منصوبے: DAX اسٹوڈیو منطقی اور فزیکل استفسار کے منصوبوں کو ظاہر کر سکتا ہے، یہ ظاہر کرتا ہے کہ انجن آپ کی پیمائش پر کیسے عمل کرتا ہے۔ اعلی درجے کے صارفین کے لیے، استفسار کے منصوبے صرف ٹائمنگ ڈیٹا میں نظر نہ آنے والے آپٹیمائزیشن کے مواقع کو ظاہر کرتے ہیں۔

VertiPaq تجزیہ کار: پورے ڈیٹا ماڈل کو اسکین کرتا ہے اور ہر ٹیبل میں ہر کالم کے لیے کالم کے سائز، کارڈینیلیٹی، انکوڈنگ کی قسم اور لغت کے سائز کی اطلاع دیتا ہے۔ اس طرح آپ بڑے کالموں اور میزوں کی شناخت کرتے ہیں جو آپ کے ماڈل کو بڑھا رہے ہیں۔

نظامی اصلاح کا طریقہ کار

1. بیس لائن: پرفارمنس اینالائزر کا استعمال کرتے ہوئے ہر صفحے کے لیے لوڈ ٹائم ریکارڈ کریں۔ دستاویز کے ماڈل کا سائز (فائل> معلومات> فائل کا سائز کم کریں> تجزیہ کریں)۔ اگر پریمیم/فیبرک پر ہو تو صلاحیت کے میٹرکس کو ریکارڈ کریں۔

2. شناخت: کارکردگی کے تجزیہ کار کے نتائج کو کل مدت کے مطابق ترتیب دیں۔ سرفہرست 5 سب سے سست بصری پر توجہ مرکوز کریں --- یہ بہترین ہونے پر سب سے زیادہ اثر ڈالتے ہیں۔

3. تشخیص: ہر سست استفسار کو DAX اسٹوڈیو میں کاپی کریں۔ SE بمقابلہ FE وقت کا تجزیہ کریں۔ مخصوص DAX پیٹرن کی شناخت کریں جو FE رکاوٹوں کا باعث بنتے ہیں۔

4. آپٹمائز کریں: ھدف شدہ اصلاحات کا اطلاق کریں (ذیل میں تفصیل سے احاطہ کیا گیا ہے)۔ ہر تبدیلی کو اس کے اثرات کی پیمائش کرنے کے لیے انفرادی طور پر جانچیں۔

5. تصدیق کریں: پرفارمنس اینالائزر کو دوبارہ چلائیں اور بیس لائن سے موازنہ کریں۔ ہر اصلاح کے لیے بہتری کو دستاویز کریں۔

6. مانیٹر: رجعت کو روکنے کے لیے جاری کارکردگی کی نگرانی (صلاحیت میٹرکس، صارف کی طرف سے رپورٹ کردہ مسائل، وقتاً فوقتاً کارکردگی کا تجزیہ کرنے والا چیک) مرتب کریں۔

---

سست DAX پیٹرنز اور اصلاحات

پیٹرن 1: غیر ضروری کیلکولیٹ نیسٹنگ

مسئلہ:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

Nested CALCULATE اسٹیٹمنٹس طاقت کا اضافہ نہیں کرتے ہیں --- وہ کنفیوژن اور بعض اوقات کارکردگی کو اوور ہیڈ کا اضافہ کرتے ہیں۔ ہر CALCULATE ایک نیا فلٹر سیاق و سباق تخلیق کرتا ہے، اور ان کا گھونسلا غیر متوقع نتائج پیدا کر سکتا ہے اور فارمولا انجن کو بے کار سیاق و سباق کی منتقلی کرنے پر مجبور کر سکتا ہے۔

** درستگی:**

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

فلٹر آرگیومینٹس کو ایک CALCULATE میں یکجا کریں۔ ایک سے زیادہ فلٹر آرگیومینٹس ایک ساتھ لاگو ہوتے ہیں (چوراہے)۔ یہ کلینر عملدرآمد کے ساتھ ایک ہی نتیجہ پیدا کرتا ہے۔

پیٹرن 2: براہ راست کالم فلٹرز کے بجائے سب کے ساتھ فلٹر کریں۔

مسئلہ:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Products),...) انجن کو فارمولا انجن میں پوری مصنوعات کی میز کو عملی شکل دینے پر مجبور کرتا ہے، پھر فلٹر کو لاگو کرنے کے لیے ہر قطار میں اعادہ کریں۔ لاکھوں قطاروں والی میز کے لیے، یہ غیر معمولی طور پر سست ہے۔

** درستگی:**

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

CALCULATE میں ڈائریکٹ کالم فلٹرز کو سٹوریج انجن میں حل کیا جاتا ہے، جو کہ زیادہ تیزی سے آرڈر کرتا ہے۔ FILTER کا استعمال صرف اس صورت میں کریں جب آپ کو ایک پیچیدہ حالت کو لاگو کرنے کی ضرورت ہو جس کا اظہار ایک سادہ کالم موازنہ کے طور پر نہیں کیا جا سکتا ہے (مثلاً، پیمائش کی قدر پر فلٹر کرنا یا ایک سے زیادہ کالموں پر مشتمل شرط)۔

** انگوٹھے کا اصول:** اگر آپ کے فلٹر کی حالت ایک سادہ موازنہ کے ساتھ ایک کالم کا حوالہ دیتی ہے، تو اسے براہ راست CALCULATE فلٹر دلیل سے بدل دیں۔ حقیقی پیچیدہ حالات کے لیے FILTER محفوظ کریں۔

پیٹرن 3: تکرار کرنے والے جہاں جمع کرنے والے کافی ہیں۔

مسئلہ:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX سیلز ٹیبل کی ہر قطار میں اعادہ کرتا ہے، فارمولا انجن میں ہر قطار کے اظہار کا اندازہ لگاتا ہے۔ 10 ملین قطاروں والی سیلز ٹیبل کے لیے، اس کا مطلب ہے 10 ملین FE آپریشنز۔

** درستگی:**

اگر حساب دو کالموں کی سادہ ضرب ہے، تو اسے حسابی کالم کے طور پر پہلے سے گنیں:

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM سٹوریج انجن میں کام کرتا ہے، جو کالمی ڈیٹا کو انتہائی بہتر بیچوں میں پروسیس کرتا ہے۔ حساب شدہ کالم ماڈل کے سائز میں اضافہ کرتا ہے لیکن ڈرامائی طور پر استفسار کے وقت کو کم کرتا ہے۔

SUMX کو کب رکھنا ہے: جب آپ کو قطار کی سطح کی مشروط منطق (جیسے، SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) کی ضرورت ہو یا جب ایک چھوٹی میز پر (طول و عرض کی میزیں ہزاروں، لاکھوں نہیں، قطاروں کے ساتھ) کی ضرورت ہو تو SUMX استعمال کریں۔

پیٹرن 4: بڑے انٹرمیڈیٹ ٹیبلز

مسئلہ:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE فارمولا انجن میں ایک انٹرمیڈیٹ ٹیبل بناتا ہے۔ اگر زمرہ اور مہینے کے امتزاج سے 10,000 قطاریں بنتی ہیں، اور [کمپلیکس کیلکولیشن] ہر قطار کے لیے اضافی SE سوالات کو متحرک کرتا ہے، تو نتیجہ 10,000+ سوالات --- ایک تباہ کن کارکردگی کا نمونہ ہے جسے "SE استفسار طوفان" کہا جاتا ہے۔

** درستگی:**

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

ADDCOLUMNS (جو سیاق و سباق کی منتقلی کو مؤثر طریقے سے استعمال کرتا ہے) کے اندر ذیلی ٹوٹل کو عملی شکل دینے سے، @SubTotal کے بعد کے حوالہ جات اضافی SE سوالات کو متحرک نہیں کرتے ہیں۔ متغیرات (VAR) اس بات کو بھی یقینی بناتے ہیں کہ ٹیبل کا صرف ایک بار جائزہ لیا جائے، چاہے کئی بار حوالہ دیا جائے۔

پیٹرن 5: قطار کی سطح کی سیکیورٹی پرفارمنس کا اثر

مسئلہ:

پیچیدہ DAX ایکسپریشنز کے ساتھ RLS ہر استفسار کے لیے جائزہ لیتا ہے، جس میں اوور ہیڈ کو شامل کیا جاتا ہے جو بصریوں میں شامل ہوتا ہے۔ ناقص لکھا ہوا RLS قاعدہ رپورٹ کے لوڈ ٹائم کو دوگنا یا تین گنا کر سکتا ہے۔

عام RLS کارکردگی کے قاتل:

• RLS فلٹرز میں LOOKUPVALUE (فی قطار FE کی تشخیص پر مجبور کرتا ہے)
• بڑی میزوں پر موجود یا آپریٹرز میں
• RLS سادہ کالم فلٹرز کے بجائے حوالہ دینے والے اقدامات کے اصول
• کراس فلٹر سمت کے مسائل کے ساتھ ملٹی ٹیبل RLS

** درستگی:**

• سادہ کالم موازنہ استعمال کریں: [TenantId] = USERNAME() یا [Region] IN VALUES(SecurityTable[Region])
• براہ راست تعلقات کے ساتھ ایک وقف شدہ طول و عرض کی میز میں حفاظتی نقشہ جات کا پہلے سے حساب کریں۔
• RLS قواعد میں اقدامات سے گریز کریں --- صرف کالم کی سطح کے فلٹرز استعمال کریں۔
• RLS فعال کے ساتھ اور بغیر استفسار کے اوقات کا موازنہ کرکے DAX اسٹوڈیو کے ساتھ RLS کی کارکردگی کی جانچ کریں۔

---

ماڈل کے سائز میں کمی

ماڈل کا سائز کیوں اہمیت رکھتا ہے۔

پاور BI امپورٹ موڈ ڈیٹا کو انتہائی کمپریسڈ کالمر فارمیٹ (VertiPaq انجن) میں اسٹور کرتا ہے۔ ماڈل کا سائز براہ راست اثر انداز ہوتا ہے:

• میموری کی کھپت: پورا ماڈل میموری میں فٹ ہونا چاہیے۔ پریمیم/فیبرک پر، بڑے ماڈل زیادہ صلاحیت استعمال کرتے ہیں اور میموری پریشر تھروٹلنگ کو متحرک کر سکتے ہیں۔
• ریفریش کا دورانیہ: بڑے ماڈلز کو ریفریش ہونے میں زیادہ وقت لگتا ہے کیونکہ مزید ڈیٹا پر عملدرآمد، کمپریسڈ اور لوڈ ہونا ضروری ہے۔
• استفسار کی کارکردگی: بڑے ماڈلز بڑے اسکین تیار کرتے ہیں، جو اچھی طرح سے بہتر بنائے گئے DAX کے لیے بھی استفسار کا وقت بڑھاتا ہے۔
• فائل کا سائز: بڑے ماڈلز والی PBIX فائلیں محفوظ کرنے، شائع کرنے اور ڈاؤن لوڈ کرنے میں سست ہیں۔

ماڈل سائز کنٹریبیوٹرز کی شناخت کرنا

سب سے بڑے ٹیبلز اور کالمز کی شناخت کے لیے DAX اسٹوڈیو کے VertiPaq تجزیہ کار (اعلیٰ> میٹرکس دیکھیں) کا استعمال کریں:

اصلاح کی تکنیک

غیر استعمال شدہ کالم ہٹائیں:

واحد سب سے زیادہ اثر والی اصلاح۔ آپ کے ماڈل میں ہر کالم میموری استعمال کرتا ہے چاہے وہ استعمال ہو یا نہ ہو۔ اپنے ماڈل کا آڈٹ کریں اور کسی بھی کالم کو ہٹا دیں جس کا بصری، پیمائش، رشتہ، یا RLS اصول میں حوالہ نہیں دیا گیا ہے۔

عام اثر: 20-40٪ ماڈل سائز میں کمی۔

ٹیکسٹ کالم کی کارڈنلٹی کو کم کریں:

بہت سی منفرد اقدار (تفصیلات، پتے، نوٹس) والے ٹیکسٹ کالم خراب طور پر کمپریس ہوتے ہیں۔ اگر کالم صرف ڈسپلے کے لیے درکار ہے (فلٹرنگ یا گروپ بندی نہیں)، تو اسے صرف تفصیل کی میز پر منتقل کرنے یا لمبی قدروں کو تراشنے پر غور کریں۔

گروپ بندی/فلٹرنگ میں استعمال ہونے والے کالموں کے لیے، بکٹنگ پر غور کریں: 50,000 منفرد پروڈکٹ کے ناموں کے بجائے، انفرادی پروڈکٹ کی تفصیلات کے لیے علیحدہ تلاش کی میز کے ساتھ 500 پروڈکٹ کیٹیگریز میں گروپ کریں۔

ڈیٹا کی اقسام کو بہتر بنائیں:

• جب اقدار پورے نمبر ہوں تو اعشاریہ کے بجائے عدد کا استعمال کریں (فی کالم میں 50% کی بچت ہوتی ہے)
• جب وقت کی ضرورت نہ ہو تو ڈیٹ ٹائم کی بجائے تاریخ کا استعمال کریں (کارڈینلٹی کو کم کرتا ہے)
• عددی اقدار کو متن کے طور پر ذخیرہ کرنے سے گریز کریں (متن نمبروں سے بدتر کمپریس ہوتا ہے)
• ہاں/نہیں یا سچ/غلط کالم کے لیے متن کی بجائے بولین استعمال کریں۔

عام اثر: 10-20٪ ماڈل سائز میں کمی۔

بڑی میزیں تقسیم کریں:

ایک 100-ملین قطار والے فیکٹ ٹیبل کو فعال ڈیٹا (موجودہ سال، ہر ریفریش پر بھرا ہوا) اور تاریخی ڈیٹا (پچھلے سال، کم کثرت سے لوڈ کیا گیا یا جمع کے طور پر ذخیرہ کیا گیا) میں تقسیم کیا جا سکتا ہے۔ یہ ماڈل سائز اور ریفریش کی مدت دونوں کو کم کرتا ہے۔

مجموعی میزیں (تفصیل سے نیچے دی گئی ہے):

بڑے فیکٹ ٹیبلز کے لیے، ایگریگیشن ٹیبلز عام طور پر پوچھے گئے گرانولیریٹیز پر پری کمپیوٹنگ سمری ڈیٹا کے ذریعے کارکردگی میں سب سے بڑی بہتری فراہم کرتی ہیں۔

---

جمع کرنے کی میزیں۔

جمع کرنے کی میزیں کیا ہیں؟

ایگریگیشن ٹیبلز پہلے سے کمپیوٹیڈ سمری ٹیبلز ہیں جو پاور BI پوری تفصیل کے ٹیبل کو اسکین کرنے کے بجائے استفسار کرتی ہیں۔ جب صارف علاقے کے لحاظ سے ماہانہ آمدنی کو ظاہر کرنے والا چارٹ دیکھتا ہے، تو پاور BI تفصیلی جدول (جس میں 50 ملین ٹرانزیکشن قطاریں ہو سکتی ہیں) کی بجائے ایگریگیشن ٹیبل (جس میں 120 قطاریں ہو سکتی ہیں: 10 ریجنز x 12 ماہ) سے استفسار کرتا ہے۔

ایگریگیشن ٹیبلز کی طاقت یہ ہے کہ وہ صارفین کو رپورٹ کرنے کے لیے شفاف ہیں۔ صارفین ایک ہی بصری اور اقدامات کے ساتھ تعامل کرتے ہیں۔ پاور BI خود بخود استفسارات کو ایگریگیشن ٹیبل پر روٹ کرتا ہے جب استفسار کی گرانولیریٹی مماثل ہو جاتی ہے، اور ڈرل ڈاؤن یا تفصیلی سطح کے سوالات کے لیے تفصیلی جدول تک پہنچ جاتی ہے۔

ڈیزائننگ ایگریگیشن ٹیبلز

مرحلہ 1: ایگریگیشن گرینولریٹی کی شناخت کریں۔

سب سے زیادہ عام استفسار کے گرانولیریٹیز کا تعین کرنے کے لیے اپنی رپورٹس کا تجزیہ کریں۔ سیلز ڈیش بورڈ کے لیے:

• مہینہ + علاقہ + پروڈکٹ کیٹیگری کی سطح پر زیادہ تر ایگزیکٹو بصری سوالات
• ہفتہ + اسٹور + مصنوعات کی سطح پر مینیجر بصری استفسار
• انفرادی لین دین کی سطح پر تفصیلی جدولوں کا استفسار

سب سے عام طور پر پوچھے گئے گرانولیریٹیز پر ایک یا دو ایگریگیشن ٹیبلز ڈیزائن کریں۔

مرحلہ 2: ایگریگیشن ٹیبل بنائیں۔

پاور کوئری میں، ایک نیا ٹیبل بنائیں جو آپ کے فیکٹ ٹیبل کو ایگریگیشن گرینولریٹی پر گروپ کرتا ہے:

| AggKey | سال | مہینہ | علاقہ | پروڈکٹ کیٹیگری | ٹوٹل ریونیو | کل مقدار | آرڈر کاؤنٹ | |---------|------|------|---------|---|------------| | 1 | 2025 | 1 | شمالی | الیکٹرانکس | 1,245,000 | 8,432 | 3,210 | | 2 | 2025 | 1 | شمالی | لباس | 876,000 | 12,104 | 5,670 | | ... | ... | ... | ... | ... | ... | ... | ... |

مرحلہ 3: ایگریگیشن میپنگ کو کنفیگر کریں۔

پاور BI ڈیسک ٹاپ میں، ایگریگیشن ٹیبل کو منتخب کریں، پراپرٹیز> مینیج ایگریگیشنز پر جائیں، اور ہر ایگریگیشن کالم کو اس کے متعلقہ ڈیٹیل ٹیبل کالم اور فنکشن سے نقشہ بنائیں:

مرحلہ 4: جمع کرنے کی میز کو چھپائیں۔

صارفین کو ایگریگیشن ٹیبل کے ساتھ براہ راست تعامل نہیں کرنا چاہیے۔ اسے رپورٹ کے منظر سے چھپائیں۔ پاور BI اسے خود بخود اور شفاف طریقے سے استعمال کرتا ہے۔

مجموعی کارکردگی کا اثر

| منظر نامہ | جمع کے بغیر | جمع کے ساتھ | بہتری | |------------|----------------------------|------------| | علاقے کے لحاظ سے ماہانہ آمدنی (10M قطاریں) | 2,800ms | 35ms | 80x تیز | | سہ ماہی مصنوعات کے زمرے کے رجحانات (10M قطاریں) | 3,200ms | 42ms | 76 گنا تیز | | سال بہ سال موازنہ (10M قطاریں) | 4,100ms | 55ms | 75x تیز | | لین دین کی سطح کی تفصیل (ڈرل کے ذریعے) | 1,200ms | 1,200ms | کوئی تبدیلی نہیں (تفصیل میں آتا ہے) |

یہ اصلاحات رپورٹ کے تمام صفحات پر مشتمل ہیں۔ 10 بصریوں کے ساتھ ایک صفحہ، ہر ایک تفصیلی جدول کے بجائے مجموعی جدول سے استفسار کرتا ہے، 30 سیکنڈ کے بجائے 1 سیکنڈ میں لوڈ ہو سکتا ہے۔

جمع ٹیبل کی دیکھ بھال

• مستقل مزاجی کو برقرار رکھنے کے لیے تفصیلی جدولوں کی طرح ایک ہی شیڈول پر جمع کرنے کی میزیں تازہ کریں۔
• DAX اسٹوڈیو کا استعمال کرتے ہوئے ایگریگیشن ہٹ ریٹ کی نگرانی کریں (ٹریس ایونٹس سے پتہ چلتا ہے کہ آیا سوالات جمع ہوئے یا گرے)
• جب آپ اضافی عام استفسار کے نمونوں کی نشاندہی کرتے ہیں تو نئی جمع جدولیں شامل کریں۔
• جمع کرنے والی میزیں ہٹا دیں جن کی ہٹ ریٹ 50% سے کم ہو (وہ کافی فائدہ کے بغیر جگہ استعمال کرتے ہیں)

---

DirectQuery آپٹیمائزیشن

جب DirectQuery ضروری ہو۔

DirectQuery پاور BI کے ان میموری انجن میں ڈیٹا درآمد کرنے کے بجائے اصل وقت میں سورس ڈیٹا بیس سے استفسار کرتی ہے۔ یہ ضروری ہے جب:

• ڈیٹا کی تازہ کاری کے تقاضے ذیلی منٹ میں تاخیر کا مطالبہ کرتے ہیں (اسٹاک ٹریڈنگ، IoT مانیٹرنگ، فراڈ کا پتہ لگانا)
• ڈیٹاسیٹ پاور BI کے ماڈل سائز کی حد سے زیادہ ہے (10GB پریمیم P1 پر، 25GB پر P2، وغیرہ)
• تعمیل یا سیکیورٹی کا تقاضہ ہے کہ ڈیٹا کبھی بھی سورس سسٹم کو نہ چھوڑے۔
• ماخذ ڈیٹا بیس میں پہلے سے ہی وسیع پیمانے پر مادی نظریات اور مجموعی بنیادی ڈھانچہ موجود ہے۔

دیگر تمام منظرناموں کے لیے، امپورٹ موڈ کو سختی سے ترجیح دی جاتی ہے۔ انٹرایکٹو سوالات کے لیے امپورٹ موڈ 10-100x تیز ہے اور صارف کا بہتر تجربہ فراہم کرتا ہے۔

DirectQuery کارکردگی کی حکمت عملی

فی صفحہ بصریوں کی تعداد کو کم کریں۔

DirectQuery موڈ میں ہر بصری ماخذ ڈیٹا بیس کے لیے ایک الگ سوال پیدا کرتا ہے۔ 20 ویژولز والا صفحہ صفحہ لوڈ ہونے پر 20 ایک ساتھ سوالات پیدا کرتا ہے، نیز فلٹرز تبدیل ہونے پر اضافی سوالات پیدا کرتا ہے۔ DirectQuery صفحات کو زیادہ سے زیادہ 8-10 بصری تک محدود کریں۔

ذریعہ ڈیٹا بیس کو بہتر بنائیں۔

پاور BI ماخذ کو SQL سوالات (یا غیر SQL ذرائع کے لیے مقامی سوالات) بھیجتا ہے۔ ماخذ ڈیٹا بیس کی کارکردگی براہ راست رپورٹ کی کارکردگی کا تعین کرتی ہے۔ یقینی بنائیں:

• اشاریہ جات تمام کالموں پر موجود ہیں جو فلٹرز، تعلقات اور اقدامات میں استعمال ہوتے ہیں۔
• اعدادوشمار استفسار کردہ میزوں پر تازہ ترین ہیں۔
• ڈیٹا بیس سرور کے پاس آپریشنل کام کے بوجھ کے ساتھ ساتھ ساتھ تجزیاتی سوالات کے لیے کافی CPU اور میموری ہے
• عام استفسار کے نمونوں کے لیے مادی نظریات یا انڈیکس شدہ نظارے بنانے پر غور کریں۔

استفسار میں کمی کے اختیارات کو فعال کریں۔

پاور BI ڈیسک ٹاپ > اختیارات > استفسار میں کمی، فعال کریں:

• "کراس ہائی لائٹنگ سوالات نہ بھیج کر بھیجے گئے سوالات کی تعداد کو کم کریں": اضافی سوالات پیدا کرنے سے بصریوں کے درمیان کراس فلٹرنگ کو روکتا ہے
• "ہر سلائیسر میں ایک اپلائی بٹن شامل کریں": صارفین سوالات کے عمل سے پہلے متعدد سلائسرز کو ایڈجسٹ کرتے ہیں، جس سے سوال کا کل حجم کم ہو جاتا ہے۔
• "فلٹر پین میں اپلائی بٹن شامل کریں": فلٹر پین کے لیے بھی یہی اصول

دوہری اسٹوریج وضع کو حکمت عملی کے ساتھ استعمال کریں۔

ٹیبلز کو "ڈبل" موڈ پر سیٹ کیا جا سکتا ہے، جو ڈیٹا کو امپورٹ موڈ (تیز مقامی سوالات کے لیے) دونوں میں اسٹور کرتا ہے اور DirectQuery کنکشن (DirectQuery ٹیبلز کے ساتھ تعلقات کے لیے) کو برقرار رکھتا ہے۔ ڈائیمینشن ٹیبلز (پروڈکٹس، کسٹمرز، ڈیٹس) کو ڈوئل موڈ پر سیٹ کریں جبکہ ڈائریکٹ کیوری میں بڑے فیکٹ ٹیبلز رکھیں۔ یہ فیکٹ ٹیبلز پر ڈیٹا کی تازگی کو قربان کیے بغیر فلٹر اور سلائسر کی کارکردگی کو ڈرامائی طور پر بہتر بناتا ہے۔

استفسار کیشنگ کو لاگو کریں۔

پاور BI سروس ڈیٹا سیٹ کی ترتیبات میں "استفسار کیشنگ" کو فعال کریں۔ یہ ایک قابل ترتیب مدت کے لیے استفسار کے نتائج کو کیش کرتا ہے، ایک جیسے سوالات کے لیے کیش شدہ نتائج پیش کرتا ہے۔ استفسار کیشنگ خاص طور پر ان ڈیش بورڈز کے لیے موثر ہے جو ایک جیسے فلٹرز والے بہت سے صارفین کے ذریعے دیکھے جاتے ہیں (مثال کے طور پر، ایک ایگزیکٹو ڈیش بورڈ جس میں کمپنی کے وسیع میٹرکس دکھائے جاتے ہیں)۔

---

صلاحیت کی کارکردگی کی نگرانی

کلیدی صلاحیت میٹرکس

پریمیم یا فیبرک کی صلاحیت پر تنظیموں کے لیے، انفراسٹرکچر کی کارکردگی رپورٹ کے ڈیزائن کی طرح اہم ہے۔ صلاحیت کی تھروٹلنگ اچھی طرح سے بہتر رپورٹس کو بھی خراب کارکردگی کا مظاہرہ کر سکتی ہے۔

** مانیٹر کرنے کے لیے میٹرکس:**

Microsoft Fabric Capacity Metrics ایپ

مائیکروسافٹ پاور BI سروس میں ایک وقف صلاحیت کی نگرانی کرنے والی ایپ فراہم کرتا ہے۔ اسے AppSource سے انسٹال کریں اور اسے اپنی صلاحیت سے جوڑیں۔ یہ فراہم کرتا ہے:

• کام کے بوجھ کی قسم کے لحاظ سے خرابی کے ساتھ حقیقی وقت اور تاریخی CPU استعمال
• انٹرایکٹو تھروٹلنگ تجزیہ یہ دکھاتا ہے کہ کون سے آپریشن نے تھروٹلنگ کو متحرک کیا۔
• بے دخلی کی تاریخ کے ساتھ ڈیٹاسیٹ کے ذریعہ میموری کی کھپت
• کارکردگی کے رجحانات کو تازہ کریں۔
• استفسار کی کارکردگی پرسنٹائلز

اصلاح کے مراحل کے دوران ہفتہ وار اور مستحکم حالت کے دوران ماہانہ اس ایپ کا جائزہ لیں۔

صلاحیت کا صحیح سائز کرنا

کم فراہم کردہ صلاحیت تھروٹلنگ اور خراب صارف کے تجربے کا سبب بنتی ہے۔ ضرورت سے زیادہ گنجائش پیسہ ضائع کرتی ہے۔ دائیں سائز کے لیے آپ کے کام کے بوجھ کے پیٹرن کو سمجھنے کی ضرورت ہے:

• سب سے زیادہ استعمال کے اوقات: زیادہ تر تنظیمیں رات بھر کے مقابلے کاروباری اوقات کے دوران 2-3x زیادہ بوجھ دیکھتی ہیں۔ اگر آپ کا سائز چوٹی کے لیے ہے اور آپ کے پاس فیبرک F SKUs ہیں، تو راتوں رات وقفے پر غور کریں یا آف اوقات کے دوران کم کرنے پر غور کریں۔
• ریفریش بمقابلہ انٹرایکٹو تنازعہ: ڈیٹا ریفریشز اور انٹرایکٹو سوالات ایک ہی صلاحیت کے وسائل کے لیے مقابلہ کرتے ہیں۔ چوٹی کے انٹرایکٹو اوقات سے باہر ہیوی ریفریشس کو شیڈول کریں۔ اگر یہ ممکن نہیں ہے تو، ریفریش اور انٹرایکٹو کام کے بوجھ کے لیے علیحدہ صلاحیتوں پر غور کریں۔
• ترقی کا تخمینہ: ترقی کے 6-12 ماہ کے لیے منصوبہ بنائیں۔ ماڈل کا سائز، صارف کی تعداد، اور استفسار کی پیچیدگی سبھی وقت کے ساتھ بڑھتے جاتے ہیں۔ صلاحیت کے سائز میں 30-50% ہیڈ روم بنائیں۔

---

بینچ مارکنگ سے پہلے/بعد

بینچ مارکنگ کیوں اہم ہے۔

پیمائش کے بغیر اصلاح قیاس ہے۔ بینچ مارکنگ سے پہلے/بعد میں یہ ثابت ہوتا ہے کہ بہتر کارکردگی میں تبدیلی آتی ہے، اسٹیک ہولڈرز کے لیے بہتری کا اندازہ لگاتا ہے، اور مستقبل کے رجعت کا پتہ لگانے کے لیے ایک بنیادی لائن بناتا ہے۔

بینچ مارکنگ کا طریقہ کار

مرحلہ 1: میٹرکس کی وضاحت کریں۔

مرحلہ 2: بیس لائن ریکارڈ کریں۔

کوئی تبدیلی کرنے سے پہلے، تمام میٹرکس ریکارڈ کریں۔ کیش وارمنگ اور تغیر پذیری کے لیے پرفارمنس اینالائزر کو 10 بار چلائیں۔ ہر میٹرک کے لیے میڈین (P50) اور 95 واں پرسنٹائل (P95) ریکارڈ کریں۔

مرحلہ 3: بتدریج تبدیلیاں لاگو کریں۔

ایک وقت میں ایک اصلاح کریں اور ہر تبدیلی کے بعد دوبارہ پیمائش کریں۔ یہ اس بات کی نشاندہی کرتا ہے کہ کون سی اصلاح سب سے زیادہ اثر کرتی ہے اور کسی اور جگہ بہتری کے ساتھ رجعت کو چھپانے سے روکتی ہے۔

مرحلہ 4: اصلاح کے بعد کی پیمائشیں ریکارڈ کریں۔

تمام اصلاح کے بعد، ایک ہی طریقہ کار کا استعمال کرتے ہوئے ایک ہی میٹرکس کو ریکارڈ کریں۔ موازنہ ٹیبل میں نتائج پیش کریں:

مرحلہ 5: جاری نگرانی کا شیڈول بنائیں۔

کارکردگی میں وقت کے ساتھ ساتھ کمی آتی ہے جیسے جیسے ڈیٹا بڑھتا ہے، نئے اقدامات شامل کیے جاتے ہیں، اور نئے بصری تخلیق ہوتے ہیں۔ رجعت کو جلد پکڑنے کے لیے اسی طریقہ کار کو استعمال کرتے ہوئے سہ ماہی کارکردگی کے جائزوں کو شیڈول کریں۔

ان تنظیموں کے لیے جن کو میٹرکس سے پہلے/بعد میں دستاویزی دستاویز کے ساتھ منظم کارکردگی کی اصلاح کی ضرورت ہے، ECOSIRE DAX اسٹوڈیو کا تجزیہ، ماڈل کی اصلاح، اور صلاحیت کی ٹیوننگ سمیت جامع پاور BI کارکردگی کی خدمات فراہم کرتا ہے۔

---

اعلی درجے کی اصلاح کی تکنیکیں۔

حسابی گروپس

کیلکولیشن گروپس دوبارہ قابل استعمال کیلکولیشن منطق سے دہرائی جانے والی پیمائش کی مختلف حالتوں کو بدل دیتے ہیں۔ ہر بنیادی پیمائش کے لیے MTD، QTD، YTD، پرائی ایئر، اور YoY گروتھ کے لیے الگ الگ اقدامات بنانے کے بجائے، ایک کیلکولیشن گروپ ان تبدیلیوں کو متحرک طور پر لاگو کرتا ہے۔

کارکردگی کا فائدہ: ماڈل میں کم اقدامات کا مطلب ہے ایک چھوٹا میٹا ڈیٹا فوٹ پرنٹ اور تیز ماڈل لوڈنگ۔ زیادہ اہم بات یہ ہے کہ حسابی گروپس آسان بنیادوں کے اقدامات کی حوصلہ افزائی کرتے ہیں، جو پیچیدہ تمام اقدامات سے بہتر کارکردگی کا مظاہرہ کرتے ہیں۔

جامع ماڈلز

کمپوزٹ ماڈلز ایک ماڈل میں Import mode اور DirectQuery ٹیبلز کو یکجا کرتے ہیں۔ ڈائمینشن ٹیبلز اور اکثر پوچھے گئے فیکٹ ٹیبلز کے لیے امپورٹ موڈ استعمال کریں، بہت بڑی ٹیبلز کے لیے DirectQuery جو امپورٹ کے لیے بہت زیادہ تبدیل ہوتی ہیں۔

کارکردگی کا فائدہ: طول و عرض کی تلاش اور فلٹر آپریشنز امپورٹ اسپیڈ (مائیکروسیکنڈز) پر چلتے ہیں جبکہ فیکٹ ٹیبل کے سوالات DirectQuery اسپیڈ (سینکڑوں ملی سیکنڈ سے سیکنڈز) پر چلتے ہیں۔ خالص نتیجہ خالص DirectQuery سے نمایاں طور پر بہتر ہے۔

اضافی ریفریش

اضافی ریفریش پورے ڈیٹاسیٹ کو دوبارہ لوڈ کرنے کے بجائے ریفریش کے دوران صرف نیا اور تبدیل شدہ ڈیٹا لوڈ کرتا ہے۔ 100 ملین قطار والے ٹیبل کے لیے جہاں روزانہ صرف 100,000 قطاریں تبدیل ہوتی ہیں، انکریمنٹل ریفریش ریفریش کے وقت کو 99% تک کم کر دیتا ہے۔

کنفیگریشن: پاور کوئری میں رینج اسٹارٹ اور رینج اینڈ پیرامیٹر کی وضاحت کریں۔ اعداد و شمار کے کتنے دن/مہینوں کو ریفریش کرنا ہے اور کتنے تاریخی ڈیٹا کو برقرار رکھنا ہے یہ بتانے کے لیے اضافی ریفریش پالیسی کو کنفیگر کریں۔ پاور BI ڈیٹا سیٹ کو خود بخود تقسیم کرتا ہے اور صرف فعال پارٹیشنز کو تازہ کرتا ہے۔

کارکردگی کا فائدہ: ریفریش کے دوران ریفریش کے دورانیے اور صلاحیت کی کھپت میں ڈرامائی کمی۔ فیبرک کی گنجائش پر DirectQuery پارٹیشنز کے ساتھ ریئل ٹائم ریفریش کو بھی قابل بناتا ہے۔

استفسار فولڈنگ

استفسار فولڈنگ پاور کوئری کی تبدیلیوں کو ماخذ ڈیٹا بیس میں واپس دھکیلتا ہے، انہیں پاور کوئری انجن کی بجائے مقامی SQL کے طور پر عمل میں لاتا ہے۔ فولڈ کیے گئے سوالات بہت تیزی سے چلتے ہیں کیونکہ ڈیٹا بیس انجن ان کو مقامی طور پر بہتر اور ان پر عمل درآمد کرتا ہے۔

توثیق کرنے کا طریقہ: پاور کوئری ایڈیٹر میں کسی بھی مرحلے پر دائیں کلک کریں اور چیک کریں کہ آیا "دیکھیں مقامی سوال" دستیاب ہے۔ اگر یہ ہے تو، استفسار اس قدم پر ہو جاتا ہے۔ اگر خاکستری ہو جائے تو پچھلے مرحلے پر فولڈنگ ٹوٹ گئی۔

عام فولڈنگ بریکرز: M اظہار کے ساتھ حسب ضرورت کالم، مختلف ذرائع سے میزوں کو ضم کرنا، بعض تبدیلیاں (محور، پیچیدہ قسم کی تبدیلیاں)۔ فولڈنگ بریک ہونے پر، تمام بعد میں ہونے والی تبدیلیاں Power Query انجن میں عمل میں آتی ہیں، جو بڑے ڈیٹا سیٹس کے لیے نمایاں طور پر سست ہوتی ہے۔

---

اکثر پوچھے گئے سوالات

Power BI رپورٹ لوڈ ٹائم کے لیے ایک اچھا ہدف کیا ہے؟

اکثر استعمال ہونے والے ڈیش بورڈز کے لیے 3 سیکنڈ سے کم اور تفصیلی تجزیاتی رپورٹس کے لیے 5 سیکنڈ سے کم کا ہدف بنائیں۔ یہ اہداف ویب ایپلیکیشنز سے صارف کی توقعات کے مطابق ہیں اور مصروفیت کو بلند رکھتے ہیں۔ وہ رپورٹس جو مستقل طور پر 10 سیکنڈ سے زیادہ ہوتی ہیں ان کو اصلاح کے لیے ترجیح دی جانی چاہیے۔ صارف کے نقطہ نظر سے لوڈ ٹائم کی پیمائش کریں (بشمول نیٹ ورک اور رینڈرنگ)، نہ صرف DAX استفسار کا وقت۔ پرفارمنس اینالائزر DAX استفسار کا وقت اور بصری رینڈرنگ کا وقت ہر بصری کے لیے 2 سیکنڈ سے کم ہونا چاہیے تاکہ 8-10 ویژولز کے ساتھ 3-سیکنڈ صفحہ کا بوجھ حاصل کیا جا سکے۔

کیا مجھے ہمیشہ DirectQuery پر امپورٹ موڈ کو ترجیح دینی چاہیے؟

کاروباری صارفین کی طرف سے استعمال کی جانے والی انٹرایکٹو رپورٹس کے لیے، ہاں --- امپورٹ موڈ تقریبا ہمیشہ ہی بہتر انتخاب ہوتا ہے۔ امپورٹ موڈ سوالات کے لیے 10-100x تیز ہے، رپورٹ دیکھنے کے دوران ماخذ ڈیٹا بیس کی کارکردگی پر منحصر نہیں ہے، اور DAX فنکشنز اور AI خصوصیات کی مکمل رینج کو سپورٹ کرتا ہے۔ DirectQuery کا استعمال صرف اس صورت میں کریں جب آپ کو ذیلی منٹ کے ڈیٹا کی تازہ کاری کے لیے حقیقی ضرورت ہو، جب آپ کا ڈیٹا سیٹ درآمدی سائز کی حد سے تجاوز کر جائے، یا جب تعمیل کے لیے ڈیٹا کو سورس سسٹم میں رہنے کی ضرورت ہو۔ کمپوزٹ ماڈلز کو درمیانی بنیاد کے طور پر غور کریں: ڈائمینشنز اور اکثر پوچھے گئے حقائق کو درآمد کریں، DirectQuery صرف وہ ٹیبلز جن کو حقیقی وقت میں تازگی کی ضرورت ہے۔

مجھے اپنی پاور BI رپورٹس پر کارکردگی کا آڈٹ کتنی بار چلانا چاہیے؟

پیداواری رپورٹس کے لیے سہ ماہی پرفارمنس کا جامع آڈٹ کروائیں۔ آڈٹ کے درمیان، ہفتہ وار صلاحیت کی پیمائش کی نگرانی کریں اور صارف کی طرف سے اطلاع دی گئی سست روی کی فوری طور پر چھان بین کریں۔ اہم واقعات جن سے فوری آڈٹ کو متحرک کرنا چاہیے ان میں شامل ہیں: ڈیٹا کے حجم میں نمایاں اضافہ (25% سے زیادہ اضافہ)، نئے رپورٹ کے صفحات کا اضافہ یا پیچیدہ DAX اقدامات، صارف کی ہم آہنگی میں تبدیلیاں (لانچ کے بعد صارف کی ترقی)، اور صلاحیت میں تبدیلیاں (اپ گریڈ، ڈاؤن گریڈ، یا منتقلی)۔

کیا میں اپنی رپورٹس کو تبدیل کیے بغیر پاور BI کی کارکردگی کو بہتر بنا سکتا ہوں؟

ہاں، ایک حد تک۔ انفراسٹرکچر کی سطح کی اصلاح میں شامل ہیں: صلاحیت SKU کو اپ گریڈ کرنا، سروس سیٹنگز میں استفسار کیشنگ کو فعال کرنا، چوٹی کے اوقات سے باہر ہیوی ریفریشز کو شیڈول کرنا، بہتر تھرو پٹ کے لیے گیٹ وے کلسٹرنگ کو ترتیب دینا، اور سورس ڈیٹا بیس (اشاریہ جات، اعداد و شمار، مادی نظریات) کو بہتر بنانا۔ یہ تبدیلیاں رپورٹ فائلوں کو چھوئے بغیر کارکردگی کو بہتر بناتی ہیں۔ تاہم، سب سے زیادہ اثر انگیز اصلاحات میں عام طور پر رپورٹ کی سطح کی تبدیلیاں شامل ہوتی ہیں: DAX پیمائش دوبارہ لکھنا، ماڈل سائز میں کمی، جمع کرنے کی میزیں، اور بصری شمار میں کمی۔ انفراسٹرکچر کی اصلاح صلاحیت کی رکاوٹوں کو دور کرتی ہے۔ رپورٹ کی اصلاح کارکردگی کا پتہ دیتی ہے۔

وقت کے ساتھ ساتھ پاور BI رپورٹس کی رفتار سست ہونے کی کیا وجہ ہے؟

پانچ عام وجوہات: (1) ڈیٹا کے حجم میں اضافہ --- جدولوں کے 1 ملین سے 10 ملین قطاروں تک بڑھنے کے ساتھ ہی ان سوالات میں زیادہ وقت لگتا ہے۔ (2) جمع کی پیمائش کریں --- موجودہ اقدامات کو بہتر بنائے بغیر نئے اقدامات شامل کیے جاتے ہیں، اور اقدامات کے درمیان تعاملات پیچیدہ پیچیدگی پیدا کرتے ہیں۔ (3) بصری پھیلاؤ --- صارفین فی صفحہ مزید بصری شامل کرتے ہیں، ہر ایک اضافی سوالات پیدا کرتا ہے۔ (4) ماڈل بلوٹ --- نئے کالم اور میزیں غیر استعمال شدہ کو ہٹائے بغیر شامل کی جاتی ہیں۔ (5) ایک ساتھ صارف کی ترقی --- ایک ہی صلاحیت کے وسائل کے لیے مقابلہ کرنے والے زیادہ صارفین۔ ان کو سہ ماہی کارکردگی کے آڈٹ، گورننس کی پالیسیوں سے حل کریں جو بصری گنتی کو محدود کرتی ہیں اور پیچیدگی کی پیمائش کرتی ہیں، اور فعال صلاحیت کی نگرانی۔