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

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

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

• مفاهیم اصلی و معماری (۲۰%)

  • موضوعات پوشش داده شده:اجزای اکوسیستم Spark (درایور، اجراکننده‌ها، مدیر کلاستر)، تبار (Lineage) و ارزیابی RDDها، انتزاع‌های DataFrame و Dataset، بهینه‌ساز Catalyst در Spark SQL و تولید گراف جهت‌دار بدون دور (DAG).

• پردازش داده‌ها و عملکرد (۱۸%)

  • موضوعات پوشش داده شده:تبدیل‌های Narrow در مقابل Wide، اکشن‌ها، ساختارهای مدیریت حافظه، استراتژی‌های کشینگ فعال و ماندگاری (StorageLevels)، مقایسه Broadcast Joins با Shuffle Hash Joins و استراتژی‌های Repartitioning.

• مهندسی داده و خطوط لوله (۱۵%)

  • موضوعات پوشش داده شده:ورود داده‌های دسته‌ای (Batch) و جریانی (Streaming) سرتاسری، الگوهای پردازش داده مقاوم، فرمت‌های ذخیره‌سازی توزیع شده (Parquet, ORC, Delta Lake)، خطوط لوله تحلیل داده و فیدهای بصری‌سازی داده‌های ساختاریافته.

• Spark SQL و DataFrameها (۱۲%)

  • موضوعات پوشش داده شده:الزام و تکامل شمای داده (Schema Enforcement & Evolution)، تبدیل‌های DataFrame، مدیریت انواع پیچیده، توابع تعریف شده توسط کاربر (UDFs)، پرس‌وجوهای برنامه‌نویسی شده Spark SQL، توابع پنجره‌ای (Window Functions) و دستکاری تحلیل‌های سنگین داده.

• یادگیری ماشین و پردازش گراف (۱۰%)

  • موضوعات پوشش داده شده:خطوط لوله یادگیری ماشین توزیع شده از طریق MLlib، تبدیل‌کننده‌های ویژگی و تخمین‌زن‌ها، الگوریتم‌های مقیاس‌پذیر یادگیری ماشین، APIهای پردازش گراف GraphX، توپولوژی‌های گراف ساختاری و سیستم‌های توصیه سازمانی.

• مدیریت کلاستر و استقرار (۸%)

  • موضوعات پوشش داده شده:استقرار عملیاتی در مدیران کلاستر مختلف، استراتژی‌های تخصیص منابع در YARN، ایزولاسیون منابع در Apache Mesos، ارکستراسیون کانتینری در Kubernetes و استقرارهای ابری (AWS EMR, Azure Databricks, Google Cloud Dataproc).

• بهینه‌سازی و عیب‌یابی (۷%)

  • موضوعات پوشش داده شده:شناسایی و رفع مشکلات Data Skew، عیب‌یابی خطاهای OutOfMemoryError (OOM)، بهینه‌سازی عملکرد برنامه، مدیریت تسک‌های کند (Straggler)، تحلیل Spark UI، مانیتورینگ تله‌متری و لاگ‌گیری ساختاریافته.

• کاربردهای واقعی و موردکاوی‌ها (۱۰%)

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

توضیحات دوره

پیمودن مسیر یک مصاحبه فنی پیشرفته برای نقش‌های Big Data نیازمند درک عمیق از زیرساخت‌های سیستم‌های توزیع شده است. دیگر دانستن سینتکس ساده برای فیلتر کردن یک DataFrame کافی نیست. مصاحبه‌کنندگان از شما انتظار دارند برنامه‌های اجرایی (Execution Plans) را توضیح دهید، گلوگاه‌های اجرا را در یک DAG شناسایی کنید، محدودیت‌های حافظه را مدیریت کنید و مشکلاتی مانند Data Skew را که باعث کرش کردن کلاسترهای عملیاتی می‌شود، عیب‌یابی کنید. من این بانک سوالات جامع را توسعه دادم تا تمرینات سخت‌گیرانه و سناریو-محوری را فراهم کنم که برای پاسخگویی با اعتماد به نفس به این سوالات پیچیده طراحی و عیب‌یابی مورد نیاز است.

با ۵۵۰ سوال تمرینی منحصر به فرد و با کیفیت بالا، این دوره دقیقاً عمق فنی و سناریوهای تصمیم‌گیری معماری را شبیه‌سازی می‌کند که در مراحل مصاحبه سازمان‌های تراز اول داده‌محور با آن‌ها مواجه می‌شوید. چه برای جایگاه مهندس ارشد داده، معمار بیگ‌دیتا، مهندس یادگیری ماشین یا دانشمند داده مصاحبه کنید، این ارزیابی‌ها شهود مهندسی عملی شما را می‌سنجند.

هر سوال شامل یک توضیح جامع است که مکانیسم‌های داخلی Apache Spark را کالبدشکافی می‌کند. شما یاد می‌گیرید که برنامه‌های اجرایی فیزیکی را ارزیابی کنید، رفتارهای Shuffle را بهینه کنید، پروفایل‌های منابع کلاستر را به درستی پیکربندی کنید و استراتژی‌های دفاعی حافظه را پیاده‌سازی نمایید. با تبدیل هر تست تمرینی به یک شبیه‌ساز مصاحبه، دایره لغات فنی و رویکرد سیستماتیک حل مسئله را خواهید ساخت تا تسلط کامل خود را در گفتگوهای فنی زنده به نمایش بگذارید.

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

سوال ۱: بهینه‌سازی و عیب‌یابی

یک Job دسته‌ای در مقیاس بزرگ که مجموعه‌ای ۲ ترابایتی از داده‌ها را پردازش می‌کند، به طور مداوم در مرحله Shuffle تبدیل‌های Wide با پیام خطای java.lang.OutOfMemoryError: Java heap space در نودهای اجراکننده خاص شکست می‌خورد. تله‌متری نشان می‌دهد که چند تسک خاص زمان بسیار بیشتری نسبت به بقیه می‌گیرند و سپس اجراکننده‌ها کرش می‌کنند. کدام استراتژی برای حل این مشکل موثرترین روش است؟

• الف)افزایش مقدار spark.executor.cores برای اجازه دادن به تسک‌های همزمان بیشتر در هر کانتینر اجراکننده.

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

• ب)اعمال تبدیل repartition() روی ستون کلید Join بلافاصله قبل از مرحله تبدیل Wide بدون استفاده از Salt.

  • چرا نادرست است:فراخوانی repartition روی کلید موجود به پارتیشن‌بندی هش استاندارد متکی است. اگر داده‌ها به شدت Skew (نامتوازن) باشند، ردیف‌هایی با کلیدهای یکسان همچنان به همان پارتیشن ارسال می‌شوند و مشکل تمرکز حافظه حل نمی‌شود.

• ج)پیاده‌سازی تکنیک Salting با افزودن یک پسوند تصادفی به ستون کلید Join در DataFrame نامتوازن و تکثیر کلیدهای متناظر در جدول مرجع.

  • چرا درست است:این شکست توسط Data Skew ایجاد شده است، جایی که کلیدهای خاص حجم نامتناسبی از ردیف‌ها را دارند و پارتیشن‌های Shuffle را بیش از حد بارگذاری می‌کنند. Salting کلیدهای سنگین را به طور یکنواخت در چندین پارتیشن پخش می‌کند و بار پردازشی را به طور مساوی بین تمام اجراکننده‌ها توزیع کرده و نقطه داغ (Hotspot) حافظه را از بین می‌برد.

• د)تبدیل عملیات به Broadcast Join زیرا DataFrame نامتوازن باید به طور کامل در حافظه پردازش شود.

  • چرا نادرست است:یک Broadcast Join کل مجموعه داده را به هر نود اجراکننده کپی می‌کند. تلاش برای Broadcast کردن یک مجموعه داده عظیم و چند گیگابایتی، فوراً حافظه درایور و اجراکننده را اشغال کرده و منجر به کرش سریع می‌شود.

• ه)انتقال محیط مدیر کلاستر از Apache YARN به تنظیمات مدیریت شده Kubernetes برای تغییر پویا در تخصیص RAM کانتینر در حین تسک.

  • چرا نادرست است:مدیران کلاستر ارکستراسیون و زمان‌بندی اولیه منابع را مدیریت می‌کنند. نه YARN و نه Kubernetes نمی‌توانند ردپای حافظه تخصیص یافته به یک کانتینر JVM فعال را در وسط اجرای یک تسک به طور پویا تغییر دهند تا از شکست یک رشته جلوگیری کنند.

• و)کاهش مقدار ویژگی spark.sql.shuffle.partitions برای کاهش تعداد کل فایل‌های Shuffle میانی تولید شده.

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

سوال ۲: Spark SQL و DataFrameها

شما در حال طراحی یک الگوی بهینه‌سازی برای یک خط لوله دستکاری داده روزانه هستید. این Job یک جدول تاریخی عظیم به نام df_large (حدود ۱.۵ ترابایت) را با یک جدول مرجع استاتیک به نام df_small (حدود ۱۲ مگابایت) Join می‌کند. رابط کاربری Spark UI نشان می‌دهد که برنامه اجرایی فیزیکی از SortMergeJoin استفاده می‌کند که منجر به سربار بالای I/O شبکه می‌شود. چگونه باید این Join را بهینه کنید؟

• الف)اجبار به Shuffle کامل کلاستر با اجرای df_large.repartition(2000) درست قبل از فراخوانی شرط Join.

  • چرا نادرست است:اجبار به repartition صریح روی مجموعه داده ۱.۵ ترابایتی، هزینه‌های عظیم سریال‌سازی شبکه و Shuffle در کل کلاستر ایجاد می‌کند که به جای بهینه‌سازی، عملکرد کلی را کاهش می‌دهد.

• ب)کش کردن هر دو DataFrame ورودی در حافظه اجراکننده با فراخوانی صریح storageLevel.DISK_ONLY برای هر دو جزء.

  • چرا نادرست است:کشینگ فقط-دیسک، داده‌ها را در دیسک‌های محلی ذخیره می‌کند که فاز گران‌قیمت Shuffle شبکه در SortMergeJoin را حذف نمی‌کند. همچنین عملیات I/O خواندن و نوشتن غیرضروری به دیسک اضافه می‌کند.

• ج)قرار دادن DataFrame مرجع در تابع راهنمای broadcast() در عبارت Join برای اجبار به استفاده از Broadcast Hash Join.

  • چرا درست است:از آنجایی که df_small بسیار کمتر از حد معمول حافظه است، Broadcast کردن آن به Spark اجازه می‌دهد کل جدول ۱۲ مگابایتی را به هر نود اجراکننده ارسال کند. این کار الگوی اجرا را به Broadcast Hash Join تغییر می‌دهد که نیاز به Shuffle کردن مجموعه داده ۱.۵ ترابایتی را از بین برده و سربار گلوگاه شبکه را حذف می‌کند.

• د)تبدیل هر دو DataFrame سطح بالا به انتزاع‌های RDD سطح پایین و اجرای تبدیل استاندارد map() برای مدیریت دستی منطق تطبیق کلیدها.

  • چرا نادرست است:پایین آمدن به رابط‌های خام RDD باعث دور زدن بهینه‌ساز Catalyst و موتور اجرایی Tungsten می‌شود. این کار مانع از اعمال تولید کد Whole-stage و بهینه‌سازی پرس‌وجو توسط Spark شده و اجرا را کندتر می‌کند.

• ه)افزایش ویژگی پیکربندی جهانی spark.sql.autoBroadcastJoinThreshold به مقدار ۲ ترابایت برای خودکارسازی رفتار تطبیق در آینده.

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

• و)به‌روزرسانی پیکربندی لایه ذخیره‌سازی زیرین برای نوشتن داده‌های میانی به صورت فایل‌های CSV خام فشرده‌نشده به جای Parquet ساختاریافته.

  • چرا نادرست است:فرمت‌های متن‌محور مانند CSV فاقد ایندکس ستونی، فشرده‌سازی شما و قابلیت‌های Predicate Pushdown هستند. استفاده از آن‌ها فضای ذخیره‌سازی را افزایش داده و عملیات خواندن پایین‌دستی را کند می‌کند.

سوال ۳: پردازش داده‌ها و عملکرد

یک خط لوله داده، فایل‌ها را از یک Cloud Data Lake استخراج کرده، مجموعه‌ای از تبدیل‌های Narrow شامل filter() و select() را اعمال می‌کند و سپس نتایج را در Cold Storage ذخیره می‌کند. مجموعه داده منبع به دلیل رفتارهای ورود فایل در مراحل قبل، شامل ۲۵۰۰ پارتیشن کوچک است. خروجی فیلتر شده کوچک است و توسعه‌دهنده می‌خواهد تعداد فایل‌های نهایی را قبل از نوشتن در ذخیره‌ساز به ۲۰ پارتیشن کاهش دهد تا از مشکل Small Files جلوگیری کند. کدام رویکرد از نظر منابع بهینه‌تر است؟

• الف)فراخوانی df.repartition(20) برای یکپارچه کردن پارتیشن‌ها، زیرا توزیع یکنواخت را بدون تحریک فاز Shuffle شبکه تضمین می‌کند.

  • چرا نادرست است:تبدیل repartition همیشه یک Shuffle کامل شبکه به صورت Round-robin را در کل کلاستر تحریک می‌کند. این کار جریمه‌های قابل توجه I/O شبکه و دیسک ایجاد می‌کند که برای کاهش ساده تعداد پارتیشن‌ها غیرضروری است.

• ب)فراخوانی df.coalesce(20) روی DataFrame قبل از اجرای اکشن نهایی نوشتن برای اجتناب از Shuffle کامل شبکه.

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

• ج)تبدیل DataFrame فعال به ساختار RDD و اجرای تابع rdd.pipe() برای ادغام پارتیشن‌ها با استفاده از یک اسکریپت ابزار bash بومی.

  • چرا نادرست است:انتقال پارتیشن‌های توزیع شده به پردازش‌های shell خارجی، مرزهای JVM را می‌شکند. این کار جریمه‌های عظیم سریال‌سازی و دسریال‌سازی داده‌ها را ایجاد کرده و مانع از بهینه‌سازی توزیع شده می‌شود.

• د)تنظیم پارامتر پیکربندی spark.sql.shuffle.partitions روی مقدار ۲۰ بلافاصله قبل از فراخوانی عملیات نوشتن.

  • چرا نادرست است:ویژگی spark.sql.shuffle.partitions فقط تعداد پارتیشن‌ها را برای مراحل Shuffle تبدیل‌های Wide (مانند groupBy یا join) کنترل می‌کند. چون این خط لوله فقط از تبدیل‌های Narrow استفاده می‌کند، تغییر این تنظیم هیچ تأثیری بر تعداد فایل‌های خروجی ندارد.

• ه)نوشتن DataFrame سازمان‌نیافته روی دیسک، ری‌استارت کردن نمونه فعال SparkSession و بارگذاری مجدد فایل‌ها با استفاده از یک ساختار شمای داده سفارشی.

  • چرا نادرست است:این استراتژی با ذخیره داده‌های نامنظم روی دیسک، سربار I/O خواندن و نوشتن عظیم و غیرضروری ایجاد می‌کند و بدون تغییر در چیدمان پارتیشن‌های زیرین، تبار اجرا (Lineage) را می‌شکند.

• و)اعمال عملیات صریح groupBy() روی یک ستون Dummy استاتیک برای اجبار چارچوب به یکپارچه کردن ردیف‌ها در ۲۰ گروه ساختاری.

  • چرا نادرست است:گروه‌بندی داده‌ها حول یک مقدار Dummy باعث ایجاد یک فاز Shuffle گران‌قیمت و غیرضروری در کل کلاستر می‌شود. همچنین شمای ساختاری مجموعه داده را تغییر می‌دهد و برای پاک‌سازی نیاز به پردازش اضافی دارد.

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

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

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

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

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

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

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