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

پوشش تفصیلی حوزه‌های آزمون

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

• تبدیل و بارگذاری داده‌ها (۲۰٪): بررسی عمیق موتور Power Query، اتصال به منابع داده متنوع ابری و محلی، استانداردسازی تبدیلات، بهینه‌سازی کدهای سفارشی M و تسلط بر قوانین Query Folding.

• مدل‌سازی و طراحی داده‌ها (۲۵٪): پیاده‌سازی ساختارهای Star Schema، ایجاد جداول Fact و Dimension نرمال‌شده، تنظیم Cardinality مناسب (یک به چند، یک به یک) و به‌کارگیری بهترین روش‌های جهت فیلتر متقاطع.

• تجسم داده‌ها و گزارش‌گری (۲۰٪): طراحی گزارش‌های مقیاس‌پذیر Power BI، ساخت بصری‌سازی‌های پیشرفته Matrix، نمودارهای خطی چندسری، کارت‌های پویا و بهینه‌سازی چیدمان بوم بصری.

• تحلیل داده‌ها و محاسبات (۱۵٪): نوشتن فرمول‌های قدرتمند DAX (هم ستون‌های محاسباتی و هم Measures)، پیاده‌سازی معیارهای Running Total، محاسبه فروش تجمعی، مدیریت Refreshهای پیچیده و پیکربندی کلاسترهای Power BI Gateway.

• حاکمیت داده‌ها و امنیت (۱۰٪): پیکربندی Row-Level Security (RLS) پویا و استاتیک، تنظیم مجوزهای صریح Workspace، رعایت سیاست‌های حاکمیت داده‌ها و تعیین کنترل‌های دسترسی دقیق به داده‌ها.

• معماری راهکارهای BI (۵٪): پیاده‌سازی چارچوب معماری منسجم راهکارهای BI، مدیریت دارایی‌ها در سرویس Power BI، استقرار Gatewayهای امن و مدیریت استراتژی‌های استقرار ابری سازمانی.

• کیفیت داده‌ها و مدیریت خطاها (۵٪): ایجاد بررسی‌های پیش‌دستانه کیفیت داده‌ها، پیاده‌سازی استراتژی‌های مدیریت خطای M-code (استفاده از try...otherwise)، اعتبارسنجی عمیق داده‌ها و ساختاربندی مراحل خودکار پاکسازی داده‌ها.

درباره این دوره

قبولی در مصاحبه فنی برای نقش‌های مدرن تحلیلگر داده یا هوش تجاری، بسیار فراتر از کشیدن و رها کردن (Drag & Drop) فیلدها در یک قالب بصری است. شرکت‌ها به مهندسانی نیاز دارند که بدانند موتور mashup در Power Query تحت بارهای سنگین چگونه رفتار می‌کند، چگونه از شکست Query Folding جلوگیری کنند و چگونه Star Schemaهای تمیزی طراحی کنند که عملکرد داشبورد را سریع و بهینه نگه دارد. من این مجموعه تست تمرینی ۵۵۰ سوالی را ایجاد کردم تا شبیه‌سازی واقع‌گرایانه و دقیقی از چالش‌های فنی و نکات تئوریک مصاحبه‌های سطح بالای سازمانی را در اختیار شما قرار دهم.

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

پیش‌نمایش نمونه سوالات تمرینی

برای ارزیابی سخت‌گیری فنی و عمق آموزشی این دوره، لطفاً این سه نمونه سوال را بررسی کنید.

سوال ۱: تحلیل Query Folding و بهینه‌سازی مراحل در Power Query

یک توسعه‌دهنده در حال اتصال به یک View عظیم در پایگاه داده Microsoft SQL Server با استفاده از Power Query است. توالی تبدیلات شامل فیلتر کردن سطرها، تغییر نوع داده یک ستون به متن و سپس ادغام (Merge) کوئری با یک فایل CSV محلی است. در هنگام ارزیابی، سرعت بارگذاری داده‌ها به شدت کاهش می‌یابد. توضیح فنی این افت عملکرد چیست؟

• الف) سیستم فایل محلی به طور خودکار اتصال SQL Server را از طریق کنترل‌های امنیتی داخلی مسدود می‌کند.

• ب) تغییر نوع داده به متن، موتور Power Query را مجبور می‌کند تا چیدمان View پایگاه داده زیرین را تکثیر کند.

• ج) عملیات Merge با یک فایل محلی باعث شکست Query Folding می‌شود و موتور را مجبور می‌کند میلیون‌ها سطر فیلترنشده پایگاه داده را برای پردازش محلی دانلود کند.

• د) Power Query نمی‌تواند عملیات Merge رابطه‌ای را اجرا کند مگر اینکه منبع داده ابتدا به یک بلوک Native Query تبدیل شود.

• ه) View در SQL Server فاقد کلید اصلی است که مانع از اجرای هرگونه تبدیل موازی توسط موتور Mashup می‌شود.

• و) ادغام یک فایل محلی، سرویس Power BI را مجبور می‌کند تمام Refreshهای زمان‌بندی شده برای آن Workspace را به طور دائم غیرفعال کند.

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

• پاسخ صحیح: ج

• دلیل صحت: قابلیت Query Folding به Power Query اجازه می‌دهد مراحل تبدیل را به یک دستور SQL واحد ترجمه کند که مستقیماً روی سرور پایگاه داده منبع اجرا شود. اما به محض اینکه مرحله‌ای به یک منبع داده غیرقابل Folding (مانند فایل CSV محلی) ارجاع دهد، Query Folding می‌شکند. هر مرحله بعد از آن نقطه — از جمله Merge — باید به صورت محلی در حافظه موتور mashup اجرا شود که مستلزم کشیدن حجم انبوه داده‌های Folding‌نشده از طریق شبکه است.

• دلیل نادرست بودن سایر گزینه‌ها:

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

  • گزینه ب نادرست است: تغییرات نوع داده بسته به نوع هدف ممکن است بر Folding تاثیر بگذارند، اما دارایی‌های View را تکثیر نمی‌کنند.

  • گزینه د نادرست است: کوئری‌های Native مفید هستند اما پیش‌نیاز اجباری برای فرآیندهای استاندارد Merge رابطه‌ای نیستند.

  • گزینه ه نادرست است: Viewهای پایگاه داده اغلب فاقد کلید اصلی هستند؛ در حالی که این مورد سرعت برخی ایندکس‌ها را کاهش می‌دهد، اما خط لوله کامپایل موازی را کاملاً متوقف نمی‌کند.

  • گزینه و نادرست است: این کار Refreshها را غیرفعال نمی‌کند؛ بلکه صرفاً به معنای نیاز به یک Gateway داده محلی فعال برای هماهنگی مسیر فایل محلی در هنگام استقرار است.

سوال ۲: رفتار Cardinality و Cross-Filtering در مدل‌های Star Schema

یک تحلیلگر مدل داده‌ای را طراحی می‌کند که شامل یک جدول مرکزی Fact_Sales است که به جدول Dim_Product متصل شده است. رابطه ستونی از طریق ProductKey با Cardinality یک به چند (1:*) از Dimension به Fact تعریف شده است. جهت Cross-filter صریحاً روی "Single" تنظیم شده است. اگر تحلیلگر سعی کند یک بصری (Visual) که دموگرافی مشتریان را از داخل جدول Fact نشان می‌دهد، با کشیدن یک فیلد دسته‌بندی از جدول Dimension فیلتر کند، چه اتفاقی می‌افتد؟

• الف) بصری دچار خطای شدید Dependency حلقوی شده و از نمایش هرگونه داده خودداری می‌کند.

• ب) فیلتر به طور روان از جدول Dimension به جدول Fact منتقل شده و سوابق فروش را به طور دقیق فیلتر می‌کند.

• ج) فیلتر اعمال نمی‌شود زیرا تنظیمات یک به چند برای انتقال مقادیر به پایین، نیاز به تنظیم cross-filter روی "Both" دارند.

• د) بصری مجموع‌های دقیقی را نمایش می‌دهد اما محاسبات سطرهای زیرین را در تعداد کل کلیدها ضرب می‌کند.

• ه) فیلتر از جدول Fact به عقب و به سمت جدول Dimension منتقل شده و به جای آن، لیست محصولات را فیلتر می‌کند.

• و) رابطه به طور خودکار جدا شده و در هنگام اجرای زمان اجرا به حالت غیرفعال (Inactive) تغییر می‌کند.

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

• پاسخ صحیح: ب

• دلیل صحت: در یک Star Schema استاندارد، جهت Cross-filter "Single" به این معنی است که زمینه فیلترینگ به صورت یک‌طرفه از سمت "یک" (Dimension) به سمت "چند" (Fact) جریان می‌یابد. این امر باعث می‌شود عملکرد مدل پیش‌بینی‌پذیر و تمیز بماند و اجازه دهد ویژگی‌های داخل Dim_Product به راحتی تراکنش‌های عددی موجود در Fact_Sales را برش داده و تحلیل کنند.

• دلیل نادرست بودن سایر گزینه‌ها:

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

  • گزینه ج نادرست است: جهت "Both" تنها زمانی مورد نیاز است که بخواهید فیلتری در جدول Fact، سطرهای داخل جدول Dimension را محدود کند که معمولاً توصیه نمی‌شود.

  • گزینه د نادرست است: ضرب دکارتی بدون فیلتر زمانی رخ می‌دهد که هیچ رابطه‌ای وجود نداشته باشد؛ در اینجا یک مسیر معتبر وجود دارد.

  • گزینه ه نادرست است: وقتی پیکربندی صریحاً روی "Single" قفل شده باشد، فیلتر نمی‌تواند به عقب (از چند به یک) جریان یابد.

  • گزینه و نادرست است: روابط فعال می‌مانند مگر اینکه صریحاً توسط توسعه‌دهنده غیرفعال شوند یا از طریق معیارهای خاص DAX با استفاده از USERELATIONSHIP بازنویسی شوند.

سوال ۳: ایزوله‌سازی خطا با استفاده از عبارت‌های M-Code در خط لوله‌های پیچیده

یک خط لوله داده، داده‌ها را از یک منبع Web API استخراج می‌کند. گاهی اوقات، سطرهای خاصی حاوی رشته‌های متنی تودرتو در بلوک‌های عددی هستند که باعث می‌شود مرحله تبدیل، یک خطای استاندارد در سطح سلول تولید کند. اگر توسعه‌دهنده‌ای نیاز داشته باشد زیرساختی بسازد که این ناهنجاری‌های داده را بدون حذف کل رکورد یا متوقف کردن Refresh زمان‌بندی شده شناسایی کند، کدام ساختار سینتکس سفارشی M باید اعمال شود؟

• الف) if Error.Record == true then null else [Value]

• ب) try [Value] otherwise null

• ج) validate [Value] on error default 0

• د) catch (Exception e) { return null; }

• ه) Table.RemoveMatchingRows(Source, each [Value] == error)

• و) Expression.Evaluate([Value], Environment.Current)

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

• پاسخ صحیح: ب

• دلیل صحت: زبان M در Power Query از عبارت try...otherwise برای مدیریت ساختاری خطاهای داخلی استفاده می‌کند. بلوک try عبارت را ارزیابی می‌کند؛ اگر خطایی در سطح سلول برگرداند، اجرا آن را شناسایی کرده و هر مقدار جایگزینی که بلافاصله بعد از کلمه کلیدی otherwise مشخص شده است را خروجی می‌دهد.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: Error.Record یک عملگر منطقی Boolean یا متغیر بررسی متادیتای معتبر در سینتکس استاندارد M نیست.

  • گزینه ج نادرست است: کلمات کلیدی validate و on error متعلق به زبان‌های برنامه‌نویسی دیگر هستند و در Power Query کامپایل نمی‌شوند.

  • گزینه د نادرست است: این گزینه سینتکس استاندارد try/catch برنامه‌نویسی شی‌گرا (مانند Java یا #C) را نشان می‌دهد که در اسکریپت عبارت M کاملاً نامعتبر است.

  • گزینه ه نادرست است: تابع Table.RemoveMatchingRows رکوردهای منطبق را بر اساس مقادیر فیلتر می‌کند، اما پاس دادن یک شیء خطای خام به این صورت باعث شکست کامپایل می‌شود.

  • گزینه و نادرست است: تابع Expression.Evaluate رشته‌های متنی خام را به بلوک‌های کد فعال تبدیل می‌کند؛ این تابع شامل ویژگی‌های سرکوب خطا نیست.

چه انتظاراتی داشته باشید

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

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

• این یک بانک سوالات عظیم و اورجینال است.

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

• هر سوال دارای یک توضیح دقیق است.

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

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