Rất nhiều ứng viên ghi "thành thạo Spark, Airflow" trong CV nhưng không giải thích được vấn đề cụ thể đã giải quyết — nhà tuyển dụng luôn hỏi sâu để phân biệt người thực sự vận hành hệ thống với người chỉ chạy theo tutorial.
"Tại sao Spark nhanh hơn MapReduce truyền thống?" — Spark xử lý dữ liệu trong bộ nhớ (in-memory processing) thay vì ghi kết quả trung gian xuống disk sau mỗi bước như MapReduce — đặc biệt lợi thế với các thuật toán lặp (iterative, vd. machine learning) cần đọc lại dữ liệu nhiều lần.
"Partition trong Spark là gì, tại sao quan trọng?" — Dữ liệu được chia thành các partition xử lý song song trên nhiều executor — quá ít partition không tận dụng hết tài nguyên cluster, quá nhiều gây overhead quản lý task. Câu hỏi tiếp theo thường là "làm sao biết số partition hợp lý" — câu trả lời tốt nhắc tới việc cân bằng giữa kích thước dữ liệu và số core khả dụng.
"Data skew là gì và xử lý thế nào?" — Khi dữ liệu phân bố không đều giữa các partition (vd. 1 key chiếm phần lớn dữ liệu do JOIN/groupBy), khiến 1 vài task chạy lâu hơn hẳn các task khác — xử lý bằng salting (thêm key ngẫu nhiên để phân tán) hoặc broadcast join khi 1 bảng đủ nhỏ.
"DAG là gì, tại sao Airflow dùng khái niệm này?" — Directed Acyclic Graph — đồ thị có hướng không có chu trình, biểu diễn thứ tự phụ thuộc giữa các task. Không có chu trình đảm bảo pipeline luôn có điểm kết thúc, không bị lặp vô hạn.
"Task bị fail giữa chừng trong pipeline dài, bạn xử lý thế nào?" — Airflow hỗ trợ retry tự động (cấu hình số lần thử lại + thời gian chờ giữa các lần), và quan trọng hơn là thiết kế task idempotent (chạy lại nhiều lần cho kết quả giống nhau) để retry an toàn không gây trùng lặp dữ liệu.
Kể 1 pipeline cụ thể: nguồn dữ liệu đầu vào, các bước transform, tần suất chạy, và vấn đề thực tế gặp phải (job chạy quá lâu, dữ liệu bị trễ, cần backfill dữ liệu lịch sử) cùng cách giải quyết — con số cụ thể (giảm thời gian chạy từ X xuống Y) luôn thuyết phục hơn mô tả chung chung.