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

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

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

• طراحی خط لوله داده (۲۰٪): استراتژی‌های اصلی برای جذب داده‌ها (Data Ingestion)، مدیریت داده‌های جریانی در لحظه، معماری برای مقیاس‌پذیری، پردازش داده با نرخ انتقال بالا و تنظیمات ذخیره‌سازی بادوام.

• مدل‌سازی داده‌ها (۱۵٪): طراحی سنتی و مدرن انبار داده شامل Star Schemas، Snowflake Schemas، تعریف جداول حقیقت (Fact Tables) دانه‌ریز، ساختاردهی جداول بُعد (Dimension Tables) و حفظ تبار کامل داده‌ها.

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

• ذخیره‌سازی داده‌ها و فرمت‌های فایل (۱۲٪): بررسی عمیق ذخیره‌سازی ستونی مانند Parquet، ساختارهای سطر-محور مانند Avro، مدیریت فایل‌های تخت (CSV)، استراتژی‌های Object Storage و بهینه‌سازی Block Storage.

• سیستم‌های ابری و توزیع‌شده (۱۸٪): معماری اصلی داده در اکوسیستم‌های ابری سازمانی (AWS, GCP, Azure) و چارچوب‌های محاسباتی توزیع‌شده مانند Hadoop و Apache Spark.

• SQL و مدیریت پایگاه داده (۱۰٪): کوئری‌های تحلیلی پیچیده SQL، قوانین اصلی طراحی پایگاه داده، مفاهیم مدرن انبار داده، خط لوله‌های ETL در سطح تولید و چارچوب‌های حاکمیت داده (Data Governance).

• حل مسئله و ارتباطات (۵٪): مدیریت سوالات رفتاری حیاتی، طراحی سیستم روی تخته (Whiteboarding)، ایجاد معماری داده مقیاس‌پذیر، ارتباطات فنی شفاف و همکاری بین تیمی.

• ابزارها و فناوری‌های مهندسی داده (۱۰٪): منطق عملیاتی برای ارکستراتورها و لایه‌های پردازشی مانند Airflow، dbt، Snowflake، Databricks و Apache Kafka.

درباره دوره

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

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

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

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

سوال ۱: شکست‌های تکامل طرح‌واره در خط لوله‌های جریانی داده توزیع‌شده

یک مهندس داده خط لوله‌ای برای استریم داده‌ها در لحظه راه‌اندازی می‌کند که در آن یک Topic در Apache Kafka داده‌های رویداد را که با استفاده از Apache Avro سریالایز شده‌اند، دریافت می‌کند. یک سرویس مصرف‌کننده (Consumer) در پایین‌دست، این رویدادها را خوانده و آن‌ها را به عنوان فایل‌های Apache Parquet در یک Object Store می‌نویسد. وقتی تیمی در بالادست، یک فیلد اختیاری جدید با مقدار پیش‌فرض به طرح‌واره Avro اضافه می‌کند، سرویس مصرف‌کننده بلافاصله با خطای عدم تطابق سریالایزاسیون متوقف می‌شود. علت ریشه‌ای این شکست عملیاتی در خط لوله چیست؟

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

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

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

• د) برنامه بالادست تغییر طرح‌واره را با استفاده از حالت forward-compatibility به جای حالت strict full-compatibility ثبت کرده است.

• ه) برنامه مصرف‌کننده از فضای حافظه بافر اجرای بسیار کوچکی برای نگه داشتن داده‌های اضافی ایجاد شده توسط متغیرهای ستون اضافه شده استفاده می‌کند.

• و) سیستم ذخیره‌سازی زیرساختی فاقد مجوزهای صحیح فایل POSIX برای نوشتن ستون‌های داده تغییر یافته روی دیسک است.

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

• پاسخ صحیح: ب

• چرا درست است: در معماری‌های استریم توزیع‌شده که از Avro استفاده می‌کنند، طرح‌واره‌ها برای به حداقل رساندن اندازه پیام از بدنه پیام (Payload) جدا می‌شوند. وقتی طرح‌واره تکامل می‌یابد، مصرف‌کنندگان نیاز به روشی دارند تا نسخه طرح‌واره نویسنده را جستجو کنند تا آن را به درستی با طرح‌واره خواننده خود تطبیق دهند. بدون پیکربندی Schema Registry متمرکز، مصرف‌کننده نمی‌تواند متادیتای جدید مورد نیاز برای خواندن بدنه پیام را دریافت کند، که باعث توقف سریالایزاسیون می‌شود، حتی اگر فیلد دارای مقدار پیش‌فرض باشد.

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

  • گزینه الف نادرست است: کافکا نسبت به ساختارهای داده بدنه پیام کاملاً بی‌تفاوت است؛ تمام پیام‌های ورودی را به عنوان آرایه‌های بایت خام می‌بیند.

  • گزینه ج نادرست است: Parquet افزودن‌های اختیاری طرح‌واره را به خوبی مدیریت می‌کند زیرا متادیتای داخلی آن ستون‌ها را بر اساس نام یا ایندکس در سطح فوتر (Footer) نگاشت می‌کند.

  • گزینه د نادرست است: افزودن یک فیلد اختیاری با مقدار پیش‌فرض، یک گام تکامل معتبر در هر دو حالت backward و forward است؛ خطا مربوط به مشکل حل (Resolution) است، نه نقض سازگاری.

  • گزینه ه نادرست است: افزودن یک ستون اختیاری واحد، حجم بایت ناچیزی اضافه می‌کند که باعث خطای کمبود حافظه (OOM) یا کراش بافر نمی‌شود.

  • گزینه و نادرست است: مشکلات مجوز باعث ایجاد خطاهای استاندارد سیستم‌عامل در نوشتن (Access Denied) می‌شود، نه عدم تطابق‌های خاص سریالایزاسیون یا رمزگشایی.

سوال ۲: مدیریت حافظه توزیع‌شده و عملیات Shuffle در Apache Spark

در حین اجرای یک جاب تبدیل داده در مقیاس بزرگ با Apache Spark که شامل عملیات .groupByKey() روی یک مجموعه داده ۵۰۰ گیگابایتی است، عملکرد کلاستر به شدت افت می‌کند و چندین نود Worker با پیام java.lang.OutOfMemoryError: Unable to acquire memory bytes متوقف می‌شوند. کدام استراتژی بهینه‌سازی ساختاری مستقیماً این شکست را برطرف می‌کند؟

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

• ب) جایگزینی عملیات .groupByKey() با متدهای .reduceByKey() یا .aggregateByKey() برای بهره‌گیری از ترکیب‌های سمت-مپ (map-side combinations) قبل از شافل کردن داده‌ها در شبکه.

• ج) تنظیم پارامترهای محیطی Spark برای قرار دادن spark.executor.memoryOverhead روی یک مقدار درصد پایین‌تر برای آزاد کردن فضای اجرای JVM.

• د) تبدیل جداول داده منبع اصلی از فرمت بهینه Parquet به فایل‌های تخت CSV فشرده‌نشده قبل از بارگذاری در حافظه.

• ه) تغییر موتور زمان اجرای کلاستر Spark برای اجرا صرفاً روی یک نود Driver عظیم برای اجتناب از سربار ارتباطات شبکه.

• و) تغییر متغیرهای شرط Join به متغیرهای Broadcast گسترده برای دور زدن کامل مراحل تعادل پارتیشن.

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

• پاسخ صحیح: ب

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

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

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

  • گزینه ج نادرست است: کاهش سربار حافظه (Memory Overhead) کلاستر را در برابر کراش‌های حافظه کانتینر خارج از Heap تحت بارهای کاری سنگین بیشتر آسیب‌پذیر می‌کند.

  • گزینه د نادرست است: ساختارهای CSV فشرده‌نشده نسبت به فرمت‌های ستونی فشرده Parquet به فضای حافظه بیشتری نیاز دارند و مشکل را وخیم‌تر می‌کنند.

  • گزینه ه نادرست است: محدود کردن یک جاب پردازشی ۵۰۰ گیگابایتی به یک نود Driver واحد، مزایای محاسبات توزیع‌شده را از بین می‌برد و بلافاصله باعث کراش نمونه Master می‌شود.

  • گزینه و نادرست است: عملیات Broadcast برای بهینه‌سازی Join جداول نامتقارن طراحی شده‌اند، نه برای حل مشکلات تجمیع (Aggregation) ایجاد شده توسط عملیات داخلی group-by.

سوال ۳: بهینه‌سازی انبار داده و هرس پارتیشن (Partition Pruning) در Snowflake

یک مهندس داده متوجه می‌شود که یک کوئری داشبورد هوش تجاری (BI) یک جدول تراکنشات تاریخی عظیم در Snowflake را هدف قرار می‌دهد، اما اجرای آن بیش از پنج دقیقه زمان می‌برد. کوئری داده‌ها را دقیقاً بر اساس ستون TRANSACTION_TIMESTAMP از هفت روز گذشته فیلتر می‌کند. مؤثرترین راه برای بهینه‌سازی عملکرد این کوئری بدون تغییر فیزیکی در اندازه کلاستر سخت‌افزاری چیست؟

• الف) مرتب‌سازی مجدد فیزیکی جدول تراکنشات تاریخی با ایجاد یک Cluster Key متمرکز بر ستون TRANSACTION_TIMESTAMP برای فعال کردن هرس موثر میکرو-پارتیشن‌ها.

• ب) تبدیل ساختار جدول موجود به یک مدل Star Schema چند لایه با استفاده از چیدمان‌های مجزای Fact و Dimension برای هر متغیر Timestamp.

• ج) مجبور کردن موتور اجرای کوئری برای دور زدن سیستم کش جهانی با افزودن یک کنترل Hint صریح به ابتدای بلوک دستور SQL.

• د) حذف تمام محدودیت‌های رابطه‌ای کلید اصلی و کلید خارجی در جدول Snowflake برای حذف سربار بررسی محدودیت‌ها.

• ه) بازنویسی کل کوئری پردازش تراکنشات برای استفاده از چندین زیر-کوئری تودرتو به جای اجرای Joinهای فیلتر SQL استاندارد.

• و) انتقال پایگاه داده تراکنشات از لایه‌های استاندارد Object Storage به تنظیمات محلی Block Storage سازمانی.

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

• پاسخ صحیح: الف

• چرا درست است: اسنو-فلیک چیدمان داده‌ها را به طور خودکار با استفاده از میکرو-پارتیشن‌ها مدیریت می‌کند. اگر یک جدول بزرگ به صورت تصادفی بارگذاری شود، مقادیر TRANSACTION_TIMESTAMP در هزاران میکرو-پارتیشن مجزا پراکنده می‌شوند. با تعریف صریح یک Clustering Key روی آن ستون Timestamp، اسنو-فلیک ردیف‌های داده را به صورت متوالی سازماندهی می‌کند. این امر به موتور کوئری اجازه می‌دهد تا پارتیشن‌های نامرتبط را کاملاً نادیده بگیرد (Partition Pruning) و فقط زیرمجموعه کوچکی را که شامل داده‌های هفت روز گذشته است اسکن کند، که سرعت کوئری را به طور قابل توجهی افزایش می‌دهد.

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

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

  • گزینه ج نادرست است: دور زدن کش متادیتا سرعت کوئری‌ها را کاهش می‌دهد زیرا موتور مجبور است داده‌های خام را به جای نتایج سریع کش شده، مجدداً از object storage دریافت کند.

  • گزینه د نادرست است: اسنو-فلیک محدودیت‌های کلید اصلی یا خارجی را در حین جذب داده‌ها اعمال نمی‌کند، بنابراین حذف آن‌ها هیچ سودی در عملکرد اجرا ندارد.

  • گزینه ه نادرست است: جایگزینی فیلترهای استاندارد با زیر-کوئری‌های پیچیده تودرتو، پیچیدگی تجزیه (Parsing) را افزایش داده و معمولاً منجر به برنامه‌های اجرای کوئری بدتری می‌شود.

  • گزینه و نادرست است: اسنو-فلیک به عنوان یک سرویس مدیریت شده روی زیرساخت ابری اجرا می‌شود که لایه ذخیره‌سازی آن به صورت داخلی کنترل می‌شود؛ کاربران نمی‌توانند به صورت دستی درایوهای سخت‌افزاری فیزیکی زیربنایی را بازنگاشت کنند.

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

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

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

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

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

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

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

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