آموزش بیش از ۵۰۰ سوال و جواب مصاحبه Power BI سال ۲۰۲۶ - آخرین آپدیت

پوشش جامع حوزه‌های آزمون

این مخزن آزمون‌های تمرینی به صورت سیستماتیک سازماندهی شده است تا دقیقاً مشابه توزیع‌های فنی و مسائل سناریو-محور باشد که در مصاحبه‌های سطح بالای هوش تجاری (BI) با آن‌ها مواجه می‌شوید.

• مدل‌سازی داده‌ها (۲۰٪): طراحی Star Schemaهای مستحکم، مدیریت رابطه‌های پیچیده فعال/غیرفعال، پیکربندی ایمن cross-filtering دوطرفه، تعریف قوانین حاکمیت داده‌ها و پیاده‌سازی اتصال به منابع داده مقیاس‌پذیر.

• بصری‌سازی داده‌ها (۱۸٪): ایجاد گزارش‌های حرفه‌ای و داشبوردهای مدیریتی تعاملی، شخصی‌سازی بصری‌های پیشرفته، پیکربندی Slicerهای همگام‌سازی شده و بهره‌گیری از فیلترهای چندلایه (سطوح Visual، Page، Report و Drill-through).

• DAX و ویرایشگر کوئری (۱۵٪): نوشتن فرمول‌های پیشرفته DAX (Time Intelligence، دستکاری Filter Context، توابع iterator)، کدنویسی زبان M در Power Query Editor، بهینه‌سازی وظایف GetData و اجرای تبدیل‌های داده‌ای پیچیده و چندمرحله‌ای.

• Power BI Desktop و Service (۱۲٪): مدیریت چرخه کامل انتشار از Power BI Desktop تا Power BI Service، زمان‌بندی بازه‌های به‌روزرسانی خودکار داده‌ها، مدیریت معماری Gateway و راه‌اندازی محیط‌های کاری collaborative.

• بهینه‌سازی عملکرد (۱۰٪): عیب‌یابی گلوگاه‌ها با استفاده از Performance Analyzer، بهینه‌سازی گزارش‌ها، طراحی Aggregationهای کارآمد داده‌ها، اعمال مفاهیم Indexing، پیاده‌سازی استراتژی‌های Caching کوئری و بازسازی بهینه‌سازی کوئری‌های بک‌اند.

• تحلیل و تفسیر داده‌ها (۸٪): استخراج ارزش تجاری از طریق تحلیل پیشرفته داده‌ها، ترجمه معیارها به تفسیرهای شفاف، پیاده‌سازی ساختار داستان‌سرایی با داده‌ها (Data Storytelling) و ارائه بینش‌های خودکار و توصیه‌های عملیاتی.

• امنیت و کنترل دسترسی (۵٪): پیاده‌سازی امنیت سطح ردیف (RLS) استاتیک و دینامیک، ایجاد کنترل دسترسی مبتنی بر نقش (RBAC)، درک رمزنگاری داده‌های ابری و اجرای قوانین احراز هویت و مجوزهای سازمانی.

• تحلیل‌های پیشرفته و AI (۱۲٪): استقرار بصری‌های داخلی یادگیری ماشین، استفاده از بینش‌های هوش مصنوعی بومی (Key Influencers، Q&A، Decomposition Tree)، ساخت مدل‌های تحلیل پیش‌بینانه، اجرای تحلیل متن و پیکربندی چیدمان‌های تحلیل‌های Geospatial.

درباره دوره

به دست آوردن جایگاه توسعه‌دهنده Power BI یا مشاور ارشد BI نیازمند مهارتی بسیار فراتر از کشیدن و رها کردن (drag-and-drop) برای ساخت گزارش است. مصاحبه‌کنندگان مدرن سازمانی می‌خواهند ببینند شما چگونه با گلوگاه‌های عملکردی مقابله می‌کنید، حجم‌های عظیم داده را مدیریت می‌کنید، امنیت دقیق را اعمال می‌کنید و تحت فشار، عبارات DAX بدون نقص می‌نویسید. من این بانک جامع سوالات تمرینی را برای شبیه‌سازی دقیق سناریوهای دنیای واقعی و چالش‌های معماری طراحی کرده‌ام که شرکت‌های برتر در مراحل غربالگری فنی خود تست می‌کنند.

این منبع با ۵۵۰ سوال اصلی و با کیفیت بالا، از تعاریف پیش‌پاافتاده فاصله گرفته است. در عوض، تمرکز شدیدی بر چالش‌های تحلیلی سناریو-محور، معماهای مدل‌سازی داده‌ها و مشکلات عیب‌یابی DAX دارم. هر سوال دارای یک تحلیل جامع و گام‌به‌گام است که دقیقاً توضیح می‌دهد چرا پاسخ صحیح، بهینه‌ترین انتخاب است و چرا گزینه‌های جایگزین شکست می‌خورند یا باعث افت عملکرد در محیط عملیاتی می‌شوند. چه در حال اعتبارسنجی تجربه خود قبل از یک تغییر شغلی بزرگ باشید، چه برای کسب اولین نقش تخصصی به عنوان کارشناس Power BI مطالعه کنید یا برای قبولی در گواهینامه‌های حرفه‌ای در اولین تلاش آماده شوید، این آزمون‌ها تمرین سخت‌گیرانه‌ای را فراهم می‌کنند که نیاز دارید تا با آمادگی کامل وارد اتاق مصاحبه شوید.

نمونه‌ای از سوالات تمرینی

این سه سوال نمونه را بررسی کنید تا عمق فنی و سبک توضیحات ارائه شده در این مجموعه را درک کنید.

سوال ۱: ارزیابی Filter Context در DAX با استفاده از CALCULATE و ALL

یک توسعه‌دهنده نیاز دارد درصد مشارکت هر دسته‌بندی محصول در کل فروش را محاسبه کند. این Measure با استفاده از CALCULATE(SUM(Sales[Amount]), ALL(Sales[Category])) نوشته شده است، اما زمانی که ستون‌های دیگر از جدول Sales به عنوان Slicer گزارش اضافه می‌شوند، نتایج غیرمنتظره‌ای برمی‌گرداند. علت این رفتار چیست؟

• الف) تابع ALL تمام فیلترها را در کل مدل داده پاک می‌کند، نه فقط ستون مشخص شده از جدول.

• ب) دستور CALCULATE به طور خودکار Row Context را به Filter Context تبدیل می‌کند که باعث دو برابر شدن مقدار مخرج می‌شود.

• ج) تابع ALL تنها Filter Context اعمال شده به ستون Sales[Category] را حذف می‌کند و فیلترهای ستون‌های دیگر را فعال نگه می‌دارد.

• د) Measureهای Power BI نمی‌توانند تقسیم ریاضی را ارزیابی کنند مگر اینکه تابع DIVIDE صراحتاً در داخل سینتکس ALL قرار گیرد.

• ه) Filter Context شکست می‌خورد زیرا SUM نمی‌تواند به عنوان یک آرگومان تودرتو در توابع تغییر‌دهنده فیلتر استفاده شود.

• و) ستون Sales[Category] باید به عنوان یک کلید اصلی صریح علامت‌گذاری شود تا دستور ALL به درستی اجرا شود.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• چرا صحیح است: در DAX، وقتی یک ستون خاص را به تابع ALL می‌فرستید، به موتور دستور می‌دهید که فیلترهای اعمال شده فقط روی آن ستون خاص را نادیده بگیرد. اگر کاربر با Slicer-ی تعامل داشته باشد که شامل ستون دیگری باشد (مانند Sales[Region] یا Sales[Year])، آن فیلترها در Filter Context کاملاً فعال می‌مانند، مخرج را تغییر می‌دهند و محاسبه درصد را منحرف می‌کنند.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: ALL(Sales[Category]) رفتار حذف فیلتر خود را دقیقاً به ستون هدف محدود می‌کند؛ فیلترهای سایر ستون‌ها یا جداول را پاک نمی‌کند.

  • گزینه ب نادرست است: اگرچه انتقال Context هنگام اجرای CALCULATE در یک Row Context رخ می‌دهد، اما علت اصلی تاثیر سایر Slicerها بر مخرج در اینجا نیست.

  • گزینه د نادرست است: اگرچه استفاده از تابع DIVIDE برای مدیریت تقسیم بر صفر یک استاندارد است، اما نبود آن نحوه ارزیابی Filter Context توسط تابع ALL را تغییر نمی‌دهد.

  • گزینه ه نادرست است: SUM یک آرگومان تجمیعی کاملاً استاندارد و معتبر برای استفاده در عبارت CALCULATE است.

  • گزینه و نادرست است: تعاریف کلید در مدل داده، رفتار عملکردی یا اعتبار اصلاح‌کننده فیلتر ALL را تعیین نمی‌کنند.

سوال ۲: تنظیم عملکرد Power Query و قابلیت Query Folding در DirectQuery

یک مهندس داده در حال اتصال Power BI به یک پایگاه داده ابری بزرگ SQL از طریق حالت DirectQuery است. آن‌ها مجموعه‌ای از تبدیل‌ها را در Query Editor اعمال می‌کنند، از جمله ادغام متن (text merge)، عملیات group-by و یک مرحله unpivot. پس از انتشار، گزارش‌ها دچار تأخیر (Latency) شدید می‌شوند. مشکل فنی اصلی چیست؟

• الف) عبارات زبان M مورد استفاده در Query Editor کاملاً با پایگاه‌های داده SQL ابری رابطه‌ای ناسازگار هستند.

• ب) تبدیل unpivot باعث شکست Query Folding شد و Power BI را مجبور کرد میلیون‌ها ردیف خام را برای پردازش محلی تبدیل‌ها وارد حافظه کند.

• ج) اتصالات DirectQuery به توسعه‌دهندگان اجازه نمی‌دهند طرح‌های داده (Schemas) را در پنجره Power Query Editor تغییر داده یا پاکسازی کنند.

• د) Power BI Service برای فشرده‌سازی مجموعه‌داده‌های DirectQuery قبل از رندر شدن بصری، به یک Gateway داده محلی نیاز دارد.

• ه) عملیات group-by به طور خودکار کل رشته اتصال را به یک لایه حافظه موقت (Cache) استاتیک بدون ایندکس تبدیل می‌کند.

• و) عملیات Merge همیشه با موفقیت اجرا می‌شوند اما موتور محاسباتی DAX گزارش را برای همیشه غیرفعال می‌کنند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا صحیح است: Query Folding قابلیت Power Query برای ترجمه مراحل M به یک دستور SQL واحد است که روی سرور پایگاه داده منبع اجرا می‌شود. برخی مراحل پیچیده، مانند unpivot کردن ستون‌ها، اغلب این زنجیره folding را می‌شکنند. وقتی folding در حالت DirectQuery می‌شکند، Power BI مجبور است مقادیر عظیمی از داده‌های تراکنشی خام و بهینه نشده را استخراج کرده و آن مراحل را در منابع موتور داخلی خود پردازش کند که منجر به تأخیر شدید در رندرینگ می‌شود.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: توابع زبان M کاملاً با منابع داده SQL سازگار هستند؛ آن‌ها در صورت امکان در پشت صحنه به کوئری‌های SQL ترجمه می‌شوند.

  • گزینه ج نادرست است: شما قطعاً می‌توانید روی منابع DirectQuery تبدیل‌ها را انجام دهید، هرچند باید نظارت کنید که آیا آن مراحل fold می‌شوند یا خیر تا عملکرد حفظ شود.

  • گزینه د نادرست است: پایگاه‌های داده SQL میزبانی شده در ابر برای فشرده‌سازی داده‌ها یا بهینه‌سازی رندرینگ به Gateway محلی نیاز ندارند.

  • گزینه ه نادرست است: تبدیل‌های Group-by از مراحلی هستند که به شدت با Folding سازگارند و به راحتی به بندهای Native SQL GROUP BY ترجمه می‌شوند بدون اینکه بر Caching تاثیر بگذارند.

  • گزینه و نادرست است: ادغام داده‌ها بسته به منبع داده می‌تواند بر folding تاثیر بگذارد، اما هرگز پردازش موتور محاسباتی DAX را غیرفعال نمی‌کند یا با آن تداخل نمی‌دهد.

سوال ۳: معماری امنیت سطح ردیف دینامیک (Dynamic RLS) و USERPRINCIPALNAME

شما در حال طراحی یک گزارش فروش متمرکز Power BI هستید که با ۵۰۰ مدیر منطقه‌ای به اشتراک گذاشته می‌شود. هر مدیر باید فقط داده‌های مربوط به قلمرو خاص خود را ببیند. شما امنیت سطح ردیف دینامیک را با استفاده از [Manager_Email] = USERPRINCIPALNAME() پیکربندی می‌کنید. در طول تست، یک مدیر گزارش می‌دهد که می‌تواند تمام داده‌های سازمانی را بدون هیچ فیلتری ببیند. محتمل‌ترین اشتباه مدیریتی چیست؟

• الف) تابع USERPRINCIPALNAME() فقط در محیط‌های دسکتاپ کار می‌کند و در محیط ابری Power BI Service کاملاً نادیده گرفته می‌شود.

• ب) توسعه‌دهنده فراموش کرده است حساب سازمانی کاربر را به نقش امنیتی ایجاد شده در صفحه تنظیمات امنیتی Power BI Service اختصاص دهد.

• ج) فیلد Manager_Email در مدل داده زیرین حاوی حروف بزرگ است که منطق مطابقت رشته‌ای حساس به حروف (case-sensitive) در DAX را می‌شکند.

• د) عبارات Dynamic RLS اجرا نمی‌شوند مگر اینکه cross-filtering دوطرفه صراحتاً در هر یک از جداول بعد (Dimension) فعال شده باشد.

• ه) مدیر از یک اپلیکیشن موبایل برای مشاهده گزارش استفاده می‌کند که به طور خودکار تمام منطق‌های احراز هویت سطح ردیف را دور می‌زند.

• و) تابع USERPRINCIPALNAME() برای پردازش ارزیابی‌های ساده رشته متنی، به یک لایسنس فعال و اختصاصی Premium per User نیاز دارد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا صحیح است: تعریف نقش امنیتی RLS و عبارت فیلترینگ DAX در Power BI Desktop تنها اولین قدم است. برای اینکه امنیت در محیط عملیاتی اعمال شود، مدیر باید به تنظیمات مجموعه داده (dataset settings) در Power BI Service برود و صراحتاً کاربران یا گروه‌های امنیتی را به آن نقش خاص اضافه کند. اگر کاربری گزارش را بدون اینکه به یک نقش متصل شده باشد مشاهده کند، هیچ فیلتر RLS بر جلسه (Session) او اعمال نمی‌شود.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: USERPRINCIPALNAME() کاملاً پشتیبانی می‌شود و دقیقاً برای بازگرداندن هویت ورود ابری کاربر (مثلاً آدرس ایمیل) در Power BI Service ساخته شده است.

  • گزینه ج نادرست است: مقایسه‌های رشته‌ای در DAX به طور پیش‌فرض به حروف بزرگ و کوچک حساس نیستند (case-insensitive)؛ تفاوت در حروف بین داده‌ها و ورود کاربر، منطق فیلتر را نمی‌شکند.

  • گزینه د نادرست است: فیلترینگ دوطرفه یک پیش‌نیاز جهانی برای RLS نیست؛ جهت رابطه‌ها فقط باید به درستی از جدول امنیت به جدول واقعیت (Fact table) جریان یابد.

  • گزینه ه نادرست است: اپلیکیشن‌های موبایل Power BI به طور کامل تمام قوانین امنیت سطح ردیف پیکربندی شده در سمت سرور را رعایت و اجرا می‌کنند.

  • گزینه و نادرست است: Dynamic RLS یک ویژگی اصلی و بنیادی Power BI است و برای عملکرد، نیازی به لایسنس‌های تخصصی Premium یا مدل‌های گران‌قیمت per-user ندارد.

انتظارات از دوره

• به آزمون‌های سوالات مصاحبه خوش آمدید تا شما را برای آزمون تمرینی سوالات مصاحبه Power BI آماده کنیم.

• می‌توانید آزمون‌ها را هر چند بار که بخواهید تکرار کنید.

• این یک بانک سوالات اصلی و بسیار گسترده است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح مفصل است.

• با اپلیکیشن Udemy کاملاً با موبایل سازگار است.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.