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

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

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

• مفاهیم اصلی Spark (۲۰٪): بررسی عمیق RDDها، DataFrameهای ساختاریافته، بهینه‌ساز Catalyst، موتور اجرای Tungsten، مکانیسم‌های موتور Spark SQL و تفاوت‌های ساختاری بین Transformations و Actions.

• پردازش و بهینه‌سازی داده‌ها (۲۵٪): تسلط بر Lazy Evaluation، گراف‌های جهت‌دار بدون چرخه (DAG)، استراتژی‌های کشینگ حافظه (PERSIST/CACHE)، متغیرهای Broadcast، مکانیسم‌های Accumulator، پارتیشن‌بندی هوشمند، Coalescing و بهینه‌سازی کلی جاب‌های PySpark.

• دستکاری و تحلیل داده‌ها (۱۵٪): Joinهای پیشرفته Wide و Narrow (مانند Shuffle Hash و Broadcast Hash)، تغییرات Wide مانند groupByKey در مقابل reduceByKey، فیلترینگ ساختاری و توابع پیچیده Window.

• مهندسی داده و معماری (۱۵٪): مدیران کلاستر (YARN, Kubernetes, Standalone)، حالت‌های استقرار کلاستر (Client vs Cluster)، معماری هسته Spark (Driver, Executor, Slot)، ادغام با پلتفرم Databricks و مدیریت تراکنش‌های ACID با جداول Delta Lake.

• بهینه‌سازی عملکرد و عیب‌یابی (۱۰٪): کاهش اثرات Data Skewness، مدیریت مجموعه‌داده‌های پراکنده یا ناقص، رفع خطاهای Out-Of-Memory (OOM)، تخصیص حافظه Driver/Executor و تنظیم دقیق پیکربندی‌های هسته Spark.

• سناریوهای واقعی و مطالعات موردی (۱۰٪): پردازش داده‌های استریم با Structured Streaming، مکانیسم‌های میکرو-بچینگ، حاکمیت داده‌های حجیم، الگوهای کنترل دسترسی و مدیریت متادیتا با استفاده از Unity Catalog.

• Spark SQL و DataFrameها (۵٪): نوشتن عبارات Spark SQL به شدت بهینه، عملیات ساختاری DataFrame، مفاهیم Dataset بین‌زبانی، بهینه‌سازی مستقیم کوئری‌ها و تحلیل پلان منطقی.

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

پیروزی در مصاحبه‌های مدرن مهندسی داده یا علوم داده نیازمند درک عمیق و مکانیکی از محاسبات توزیع شده است. مصاحبه‌کنندگان فنی در شرکت‌های تراز اول به ندرت سینتکس‌های پایه را می‌پرسند؛ در عوض، آن‌ها توانایی شما را در دیباگ نشت حافظه (Memory Leak)، بهینه‌سازی Shuffleهای کند و طراحی معماری‌های مقیاس‌پذیر برای مدیریت پتابایت‌ها داده به طور بهینه می‌سنجند. من این مجموعه جامع آزمون‌های تمرینی را برای پر کردن شکاف بین آموزش‌های پایه و سناریوهای واقعی سطح تولید (Production) که در مراحل ارزیابی فنی سخت با آن‌ها مواجه می‌شوید، طراحی کرده‌ام.

با ۵۵۰ سوال بسیار دقیق و اختصاصی، این دوره بر چالش‌های مهندسی دنیای واقعی تمرکز دارد. من قطعه کدهای واقعی، پلان‌های اجرای کوئری، خطاهای کمبود حافظه و گلوگاه‌های منابع کلاستر را کالبدشکافی می‌کنم. هر سوال همراه با یک تحلیل فنی جامع است که توضیح می‌دهد چرا گزینه درست موفق می‌شود و چرا گزینه‌های جایگزین در یک کلاستر عملیاتی شکست می‌خورند. چه به دنبال نقش توسعه‌دهنده Spark باشید، چه برای ارزیابی پلتفرم Databricks آماده شوید یا بخواهید پیش از ارتقای شغلی، خط لوله‌های داده خود را مرور کنید، این مطالب آموزشی آمادگی سخت‌گیرانه‌ای را فراهم می‌کند تا در اولین تلاش، با اعتماد به نفس از مراحل فنی عبور کنید.

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

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

سوال ۱: حذف انحراف داده (Data Skew) در عملیات Wide Join

در طی یک پردازش داده در مقیاس بزرگ، یک جاب PySpark در هنگام Join بین یک DataFrame عظیم و دارای انحراف شدید (گروه‌بندی شده بر اساس کلید merchant_id که در آن ۵٪ از فروشندگان ۸۰٪ تراکنش‌ها را تشکیل می‌دهند) و یک DataFrame جستجوی متوسط، به شدت کند می‌شود. رابط کاربری مانیتورینگ کلاستر نشان می‌دهد که یک Executor با کمبود حافظه مواجه شده در حالی که بقیه بیکار هستند. کدام رویکرد بهینه‌سازی این گلوگاه را بدون انتقال داده‌ها به دیسک (Spilling) برطرف می‌کند؟

• الف) فراخوانی .repartition() روی هر دو DataFrame با استفاده از ستون merchant_id درست قبل از اجرای عملیات Join.

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

• ج) اعمال دستور .cache() روی DataFrame عظیم منحرف شده بلافاصله پس از خواندن آن از لایه ذخیره‌سازی.

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

• ه) کاهش مقدار پیکربندی spark.sql.shuffle.partitions برای کاهش تعداد کل تسک‌های فعال در کلاستر.

• و) تبدیل DataFrame بزرگ به RDD و استفاده از متد قدیمی groupByKey برای پردازش دستی رکوردها.

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

• پاسخ صحیح: ب

• چرا درست است: انحراف داده زمانی رخ می‌دهد که یک مقدار کلید خاص به طور قابل توجهی رکوردهای بیشتری نسبت به سایرین داشته باشد و یک پارتیشن (و Executor) واحد را مجبور کند حجم نامتناسبی از کار را انجام دهد. با Salting کلید Join (افزودن یک فاکتور تولید عدد تصادفی به کلید در مجموعه داده بزرگ و تکثیر ردیف‌های جستجو برای مطابقت با آن مقادیر در مجموعه داده کوچک)، شما یک کلید واحد عظیم را به چندین زیرکلید مجزا تقسیم می‌کنید. این کار بار پردازشی را به طور یکنواخت در چندین اسلات کلاستر توزیع کرده و از خطاهای OOM در Executor جلوگیری می‌کند.

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

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

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

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

  • گزینه ه نادرست است: کاهش پارتیشن‌های Shuffle باعث تجمع داده‌های بیشتر در پارتیشن‌های کمتر شده و فشار حافظه روی گره‌های فردی را تشدید می‌کند.

  • گزینه و نادرست است: متد groupByKey بسیار ناکارآمد است زیرا قبل از تجمیع داده‌ها، یک Shuffle عظیم و کنترل‌نشده از تمام رکوردها را در شبکه ایجاد می‌کند.

سوال ۲: بهینه‌سازی حافظه از طریق انتخاب نوع Transformation

یک مهندس داده نیاز دارد رکوردهای تراکنشی را در یک مجموعه داده بسیار بزرگ با استفاده از PySpark RDDها تجمیع کند. هدف، محاسبه کل حجم فروش به ازای هر دسته محصول است. کدام رویکرد سربار سریال‌سازی شبکه و ردپای حافظه (Memory Footprint) را در مرحله Shuffle به حداقل می‌رساند؟

• الف) استفاده از groupByKey().mapValues(lambda x: sum(x)) برای گروه‌بندی تمام رکوردها در مجموعه‌ها پیش از محاسبه مجموع.

• ب) استفاده از reduceByKey(lambda a, b: a + b) برای ترکیب مقادیر به صورت محلی در هر Executor پیش از انتقال داده‌ها در شبکه.

• ج) جمع‌آوری تمام داده‌ها در گره Driver با استفاده از .collect() و انجام تجمیع با استفاده از دیکشنری‌های استاندارد پایتون.

• د) تبدیل مجموعه داده به یک لیست، استفاده از itertools.groupby بومی پایتون و تبدیل خروجی مجدداً به ساختار RDD توزیع شده.

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

• و) اجرای عملیات sortBy() روی کلید دسته محصول و سپس یک مرحله map متوالی برای تجمع دستی مجموع‌ها.

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

• پاسخ صحیح: ب

• چرا درست است: متد reduceByKey مشابه یک Map-side combiner در Hadoop MapReduce عمل می‌کند. این متد به طور خودکار مقادیر را به صورت محلی در هر پارتیشن Mapper ادغام می‌کند و سپس داده‌ها را در شبکه Shuffle می‌کند. این کار حجم داده‌های ارسالی بین گره‌های کلاستر را به شدت کاهش داده و I/O شبکه و فشار حافظه روی Executorهای گیرنده را به حداقل می‌رساند.

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

  • گزینه الف نادرست است: متد groupByKey هر رکورد را بدون هیچ تجمیعی در شبکه به پارتیشن کاهش‌دهنده منتقل می‌کند که در مجموعه‌داده‌های بزرگ منجر به خطاهای Out-of-Memory (OOM) می‌شود.

  • گزینه ج نادرست است: جمع‌آوری مجموعه‌داده‌های توزیع شده عظیم روی یک گره Driver واحد به راحتی حافظه Driver را پر کرده و باعث کرش کردن اپلیکیشن Spark می‌شود.

  • گزینه د نادرست است: انتقال داده‌ها از اکوسیستم Spark به لیست‌های حافظه بومی پایتون، تمام مزایای محاسبات توزیع شده و موازی‌سازی را از بین می‌برد.

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

  • گزینه و نادرست است: مرتب‌سازی یک مجموعه داده عظیم در کلاستر نیازمند یک عملیات Global Shuffle هزینه‌بر است که سربار پردازشی غیرضروری و عظیمی اضافه می‌کند.

سوال ۳: مدیریت Joinهای استریم به استاتیک و انقضای وضعیت (State Expiry)

شما در حال ساخت یک اپلیکیشن Real-time با PySpark Structured Streaming هستید که یک جریان ورودی کلیک‌های تبلیغاتی را با یک DataFrame پروفایل کاربر استاتیک (که از Delta Lake بارگذاری شده) Join می‌کند. داده‌های پروفایل کاربر گهگاه در پس‌زمینه به‌روزرسانی می‌شوند. چه اتفاقی برای State Store داخلی استریمینگ می‌افتد و چگونه باید مدیریت شود؟

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

• ب) Spark به طور پیش‌فرض ردیف‌های استریمینگ مطابقت‌نیافته را دقیقاً بعد از ۱۰ دقیقه حذف می‌کند تا خطرات ذخیره‌سازی وضعیت از بین برود.

• ج) مجموعه داده استاتیک به طور خودکار در حافظه JVM در Executorها کش شده و در هر حلقه اجرای میکرو-بچ رفرش می‌شود.

• د) Joinهای استریم-به-استاتیک برای رکوردهای مطابقت‌نیافته وضعیتی را حفظ نمی‌کنند؛ ردیف‌هایی که بلافاصله پس از ورود مطابقت پیدا نکنند، فوراً حذف می‌شوند.

• ه) Spark هر زمان که متادیتای Delta Lake استاتیک تغییر کند یا به‌روز شود، کلاستر را به طور کلی ری‌استارت می‌کند.

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

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

• پاسخ صحیح: د

• چرا درست است: در PySpark Structured Streaming، Joinهای استریم-به-استاتیک در سمت استریمینگ ذاتاً بدون وضعیت (Stateless) هستند. وقتی یک ردیف استریمینگ می‌رسد، Spark مجموعه داده استاتیک را برای یافتن مطابقت جستجو می‌کند. اگر مطابقت پیدا نشود، ردیف به صورت یک ردیف پر شده با null (در Outer Join) خروجی داده شده یا (در Inner Join) فوراً حذف می‌شود. چون بافر تاریخچه داخلی برای انتظار تغییر در سمت استاتیک نگه نمی‌دارد، هیچ وضعیتی در State Store جمع نمی‌شود.

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

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

  • گزینه ب نادرست است: هیچ روتین پاکسازی خودکار ۱۰ دقیقه‌ای داخلی برای وضعیت‌های داده‌های استریمینگ وجود ندارد.

  • گزینه ج نادرست است: DataFrame استاتیک به صورت Lazy ارزیابی می‌شود؛ این DataFrame تغییرات ذخیره‌سازی زیرین خود را در هر میکرو-بچ به طور خودکار بارگذاری مجدد یا رفرش نمی‌کند، مگر اینکه استریم ری‌استارت شود یا صریحاً با منطق رفرش سفارشی طراحی شده باشد.

  • گزینه ه نادرست است: تغییرات متادیتای زیرین باعث کرش یا ری‌بوت کلاستر نمی‌شود؛ موتور صرفاً نسخه‌ای از داده‌های استاتیک را می‌خواند که در زمان شروع کوئری فعال بوده است.

  • گزینه و نادرست است: منطق مطابقت کاملاً روی Executorهای توزیع شده با استفاده از مکانیسم‌های استاندارد Join اجرا می‌شود؛ گره Driver هرگز حلقه‌های مطابقت ردیف‌های تک‌به‌تک را پردازش نمی‌کند.

آنچه در انتظار شماست

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

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

• این یک بانک سوالات عظیم و اختصاصی است.

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

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

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

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