Top 30+ câu hỏi phỏng vấn Big Data Engineer phổ biến

Big Data đang trở thành một xu hướng không thể thiếu đối với doanh nghiệp trong kỷ nguyên dữ liệu. Nếu bạn sắp tham gia phỏng vấn cho vị trí Big Data Engineer, bài viết sau đây sẽ tổng hợp bộ câu hỏi phỏng vấn Big Data Engineer nhằm giúp bạn chuẩn bị kỹ lưỡng hơn để tự tin vượt qua buổi phỏng vấn.

Đọc bài viết này để tham khảo cách trả lời các câu hỏi phỏng vấn Big Data Engineer về:

• Kiến thức tổng quan của Big Data
• Hệ sinh thái Hadoop, Apache Spark và hệ thống Streaming
• Quản lý và tối ưu hóa dữ liệu
• Kinh nghiệm thực tế

Đọc chi tiết: Lương Big Data Engineer thực tế tại Việt Nam và quốc tế mới nhất

Các chủ đề câu hỏi phỏng vấn Big Data Engineer phổ biến

Các câu hỏi trong buổi phỏng vấn vị trí Big Data Engineer không chỉ xoay quanh kỹ năng kỹ thuật, mà còn giúp nhà tuyển dụng đánh giá tư duy logic, khả năng xử lý vấn đề và mức độ thích nghi của ứng viên trong môi trường thực tế. 

Dưới đây là các chủ đề phổ biến thường xuất hiện trong các câu hỏi phỏng vấn Big Data Engineer:

Kiến thức tổng quan về Big Data

Kiến thức tổng quan về Big Data bao gồm việc hiểu rõ khái niệm, đặc điểm, vai trò và ứng dụng của Big Data trong thực tế kinh doanh. 

Nhà tuyển dụng sẽ hỏi về các chủ đề này để kiểm tra hiểu biết cơ bản và khả năng nhận thức về tầm quan trọng của dữ liệu lớn trong công việc của ứng viên.

Đọc chi tiết: Big Data là gì: 7 đặc điểm và tính chất quan trọng của Big Data

Hệ sinh thái Hadoop

Hệ sinh thái Hadoop là một tập hợp các công cụ và công nghệ mã nguồn mở hỗ trợ lưu trữ, xử lý và phân tích lượng dữ liệu khổng lồ một cách hiệu quả và linh hoạt. Hadoop rất quan trọng với Big Data Engineer vì nó cung cấp nền tảng để xây dựng và quản lý các giải pháp dữ liệu lớn. 

Khi hỏi về chủ đề này, nhà tuyển dụng muốn đánh giá kinh nghiệm vận hành, hiểu biết về kiến trúc, các thành phần cốt lõi, ưu điểm và nhược điểm của Hadoop.

Apache Spark và hệ thống Streaming

Apache Spark là framework xử lý dữ liệu nhanh, hỗ trợ xử lý dữ liệu hàng loạt và dữ liệu thời gian thực (streaming). Spark đóng vai trò quan trọng trong việc xử lý và phân tích dữ liệu lớn theo thời gian thực. 

Đây là phần kiểm tra kỹ năng xử lý dữ liệu theo luồng và kinh nghiệm thực hành với các công cụ phổ biến hiện nay như Spark và Hadoop MapReduce.

Quản lý và tối ưu hóa dữ liệu

Quản lý và tối ưu hóa dữ liệu liên quan đến việc đảm bảo hiệu suất, khả năng mở rộng, bảo mật và quản lý dữ liệu phân tán trong hệ thống Big Data. 

Với chủ đề này, nhà tuyển dụng sẽ đánh giá kinh nghiệm cải thiện hiệu năng hệ thống, tối ưu hóa chi phí, bảo vệ dữ liệu, và duy trì khả năng mở rộng linh hoạt của hệ thống.

Kinh nghiệm làm việc và thực chiến

Ngoài lý thuyết, nhà tuyển dụng thường sẽ hỏi về những kinh nghiệm thực tế, dự án mà ứng viên đã triển khai và các vấn đề mà họ đã giải quyết. Qua đây, nhà tuyển dụng muốn kiểm tra khả năng áp dụng lý thuyết vào thực tiễn, kỹ năng xử lý vấn đề phát sinh và khả năng phối hợp làm việc theo nhóm của ứng viên.

Đọc chi tiết: Big Data Engineer là gì: Tầm quan trọng của vị trí này trong công ty

Câu hỏi phỏng vấn Big Data Engineer về kiến thức tổng quan

Câu hỏi dành cho Fresher/Junior

Hãy giải thích ba loại dữ liệu: structured, semi-structured và unstructured.

Loại dữ liệu	Định nghĩa	Ví dụ	Công cụ xử lý phổ biến
Structured	Dạng dữ liệu được tổ chức chặt chẽ theo hàng và cột, thường lưu trữ trong các hệ quản trị cơ sở dữ liệu quan hệ. Dữ liệu dễ dàng truy vấn bằng SQL và phù hợp với các hệ thống yêu cầu tính toàn vẹn và rõ ràng về schema	Bảng điểm của học sinh, thông tin khách hàng trong cơ sở dữ liệu	SQL, RDBMS (MySQL, PostgreSQL, Oracle)
Semi-structured	Dữ liệu không tuân theo mô hình bảng cứng nhắc, nhưng vẫn có cấu trúc ngầm định nhờ vào định dạng đánh dấu như JSON, XML hoặc cặp key-value. Thường xuất hiện trong log hệ thống, API response, hoặc file cấu hình.	Dữ liệu JSON từ API, file XML, log server, metadata của hình ảnh.	NoSQL (MongoDB, Cassandra), Hadoop, Spark, Hive
Unstructured	Dữ liệu không có cấu trúc xác định, không thể phân tích trực tiếp bằng các hệ thống truyền thống. Thường yêu cầu xử lý bằng kỹ thuật đặc thù như NLP, Computer Vision hoặc AI.	Văn bản tự do, hình ảnh, video, âm thanh, bình luận mạng xã hội.	Spark, Hadoop, TensorFlow, NLP Toolkit, Computer Vision Tools

Hãy cho biết pipeline dữ liệu là gì?

Pipeline dữ liệu là một chuỗi các bước tự động giúp di chuyển và xử lý dữ liệu từ nguồn đầu vào đến hệ thống đích như data warehouse, data lake hoặc hệ thống phân tích.

Quá trình này thường bao gồm các bước: trích xuất (extract) dữ liệu từ nguồn như database, API, hoặc file log; chuyển đổi (transform) để làm sạch, chuẩn hóa và tích hợp dữ liệu; cuối cùng là tải (load) vào nơi lưu trữ phục vụ phân tích. Pipeline đóng vai trò then chốt trong việc đảm bảo dữ liệu luôn được xử lý đồng nhất, đáng tin cậy và sẵn sàng cho các hệ thống downstream như dashboard, AI/ML hoặc báo cáo kinh doanh.

Overfitting là gì? Nó có thể xảy ra trong các bài toán Big Data như thế nào?

Overfitting là hiện tượng xảy ra khi một mô hình học máy học quá kỹ vào dữ liệu huấn luyện,  đến mức ghi nhớ cả nhiễu và chi tiết không quan trọng. Thay vì học được quy luật tổng quát. Kết quả là mô hình cho hiệu suất rất tốt trên dữ liệu huấn luyện, nhưng hiệu suất kém khi áp dụng lên dữ liệu mới, do thiếu khả năng tổng quát hóa.

Thông thường mọi người thường nghĩ overfitting xảy ra khi không có đủ dữ liệu, tuy nhiên trong các bài toán Big Data, overfitting vẫn có thể xảy ra, dù bạn đang làm việc với lượng dữ liệu rất lớn. Điều này thường xuất hiện khi:

• Mô hình quá phức tạp so với mục tiêu (số lượng tham số lớn hơn mức cần thiết).
• Dữ liệu mất cân bằng hoặc có quá nhiều biến không liên quan.
• Thiếu các kỹ thuật như ràng buộc mô hình (để giới hạn mức độ phức tạp), hoặc đánh giá chéo để kiểm tra khả năng dự đoán trên dữ liệu mới.

Thực tế, Big Data không tự động giúp tránh overfitting. Nếu mô hình không được kiểm soát tốt, bạn vẫn có thể “học nhầm” từ nhiễu trong hàng triệu dòng dữ liệu. Do đó, việc đánh giá mô hình qua tập test độc lập, sử dụng cross-validation, regularization (L1/L2), hoặc đơn giản hóa mô hình là rất quan trọng

Câu hỏi dành cho Middle/Senior

Data Lake là gì, có gì khác biệt so với Data Warehouse?

Data Lake là một hệ thống lưu trữ tập trung, cho phép lưu trữ dữ liệu ở mọi định dạng: từ có cấu trúc (structured), bán cấu trúc (semi-structured) đến phi cấu trúc (unstructured), mà không cần xử lý trước hoặc định nghĩa schema ngay từ đầu (schema-on-read). Dữ liệu thường được lưu ở định dạng thô (raw format), cho phép người dùng linh hoạt xử lý, phân tích và khám phá sau này bằng các công cụ khác nhau.

Trong khi đó, Data Warehouse là một hệ thống lưu trữ dữ liệu có cấu trúc, được xử lý và làm sạch trước khi lưu (schema-on-write). Nó tối ưu cho việc phân tích dữ liệu truyền thống, truy vấn nhanh và tạo báo cáo định kỳ. 

Tóm lại, Data Lake thiên về linh hoạt và khả năng lưu trữ dữ liệu lớn với nhiều định dạng, phù hợp với các use case AI/ML, trong khi Data Warehouse thích hợp với các hoạt động phân tích kinh doanh truyền thống đòi hỏi tốc độ truy vấn nhanh và dữ liệu có cấu trúc rõ ràng.

Bảng so sánh cụ thể:

Tiêu chí	Data Lake	Data Warehouse
Loại dữ liệu lưu trữ	Dữ liệu thô: structured, semi-structured, unstructured	Chủ yếu là structured data đã được xử lý
Schema	Áp dụng khi đọc dữ liệu (schema-on-read)	Áp dụng khi ghi dữ liệu (schema-on-write)
Khả năng mở rộng	Cao, linh hoạt nhờ công nghệ lưu trữ phân tán (HDFS, S3…)	Giới hạn hơn, tốn chi phí để mở rộng
Chi phí lưu trữ	Thường thấp hơn do lưu dữ liệu thô	Cao hơn vì cần xử lý và chuẩn hóa dữ liệu trước
Tốc độ truy vấn/hiệu năng	Chậm hơn do cần xử lý khi truy vấn	Tối ưu cho truy vấn nhanh, đặc biệt là truy vấn phức tạp hoặc BI
Công nghệ phổ biến	Hadoop, Apache Spark, Amazon S3, Azure Data Lake	Amazon Redshift, Google BigQuery, Snowflake, Teradata
Trường hợp sử dụng điển hình	Lưu trữ dữ liệu đa dạng phục vụ Machine Learning, Data Science	Phân tích báo cáo kinh doanh, dashboard, truy vấn OLAP truyền thống

Khi nào thì NoSQL là lựa chọn phù hợp hơn so với SQL?

NoSQL phù hợp khi bạn cần một hệ thống linh hoạt, dễ mở rộng, chịu tải cao và không bị ràng buộc bởi schema cứng nhắc, đặc biệt trong các hệ thống Big Data, ứng dụng web quy mô lớn hoặc hệ sinh thái dữ liệu hiện đại. Tuy nhiên, NoSQL không phải là lựa chọn thay thế hoàn toàn cho SQL. Trong các hệ thống yêu cầu tính toàn vẹn dữ liệu cao, giao dịch phức tạp (ACID) hoặc phân tích dữ liệu logic với các truy vấn phức tạp, SQL vẫn là lựa chọn tối ưu.

Dưới đây là các tình huống cụ thể mà NoSQL là lựa chọn phù hợp hơn so với SQL:

Trường hợp sử dụng	Lý do chọn NoSQL
Ứng dụng cần mở rộng theo chiều ngang	NoSQL như MongoDB, Cassandra hỗ trợ phân mảnh (sharding) và xử lý phân tán tốt hơn so với RDBMS
Dữ liệu có cấu trúc linh hoạt hoặc thay đổi thường xuyên	NoSQL không yêu cầu schema cố định, dễ thích ứng với mô hình dữ liệu thay đổi
Hệ thống lưu trữ log, sự kiện, cảm biến IoT, mạng xã hội	Dữ liệu phi cấu trúc hoặc bán cấu trúc, tốc độ ghi cao – NoSQL xử lý tốt hơn
Ứng dụng có lưu lượng truy cập lớn, yêu cầu phản hồi nhanh	NoSQL tối ưu cho các thao tác đọc/ghi tốc độ cao, đặc biệt trong các ứng dụng real-time như game, chat
Khi mối quan hệ giữa dữ liệu không phức tạp	Không cần JOIN hoặc giao dịch ACID phức tạp – NoSQL đơn giản và hiệu quả hơn
Ứng dụng cần lưu trữ dữ liệu bán cấu trúc như JSON, XML,…	Các NoSQL như MongoDB cho phép lưu trực tiếp JSON, dễ thao tác và truy vấn dạng document

Đọc chi tiết: SQL vs NoSQL: Cách chọn hệ quản trị cơ sở dữ liệu phù hợp

Khi nào nên xử lý dữ liệu theo lô, khi nào nên xử lý dữ liệu luồng? Hãy so sánh 2 phương pháp này.

Batch processing (Xử lý dữ liệu theo lô) phù hợp với các tác vụ không yêu cầu xử lý tức thời, chú trọng đến hiệu suất xử lý dữ liệu lớn trong các khung thời gian cụ thể.

Stream processing (Xử lý dữ liệu luồn) lại là giải pháp lý tưởng khi doanh nghiệp cần phản ứng nhanh với dữ liệu, đặc biệt trong các hệ thống real-time và sự kiện liên tục.

Bảng so sánh chi tiết hai phương pháp này:

Tiêu chí	Batch Processing (Xử lý theo lô)	Stream Processing (Xử lý luồng)
Định nghĩa	Xử lý một khối lượng dữ liệu lớn được thu thập trong khoảng thời gian nhất định.	Xử lý dữ liệu ngay khi nó phát sinh, gần như theo thời gian thực.
Tốc độ phản hồi	Chậm hơn – xử lý sau khi gom đủ dữ liệu.	Gần như tức thì – xử lý liên tục từng bản ghi hoặc sự kiện.
Độ trễ (latency)	Vài phút đến hàng giờ, tùy theo kích thước lô dữ liệu.	Vài mili giây đến vài giây.
Khối lượng dữ liệu	Lớn, phù hợp với xử lý hàng GB đến TB dữ liệu/lần.	Nhỏ hơn từng đơn vị, nhưng liên tục.
Trường hợp sử dụng phổ biến	Tạo báo cáo định kỳ, xử lý ETL hàng ngày, tổng hợp dữ liệu theo khung thời gian.	Phát hiện gian lận thời gian thực, hệ thống khuyến nghị (real-time recommender), IoT.
Công cụ tiêu biểu	Apache Hadoop, Apache Spark (batch mode), AWS EMR.	Apache Kafka, Apache Flink, Apache Storm, Spark Streaming, Google Dataflow.
Độ phức tạp khi triển khai	Đơn giản hơn, dễ kiểm soát lỗi do xử lý toàn bộ sau khi thu thập đủ dữ liệu.	Phức tạp hơn, đòi hỏi khả năng xử lý liên tục, quản lý lỗi và trễ dữ liệu (late events).

Commodity hardware là gì? Giải thích tầm quan trọng của nó trong các hệ thống Big Data.

Commodity hardware là các phần cứng phổ thông, giá rẻ, không yêu cầu cấu hình cao cấp, ví dụ như server thông thường, ổ cứng SATA, CPU phổ thông. 

Trong các hệ thống Big Data, đặc biệt là Hadoop hoặc Spark, kiến trúc phân tán cho phép dữ liệu và tác vụ được chia nhỏ và chạy song song trên nhiều máy commodity. Điều này giúp doanh nghiệp giảm chi phí đầu tư, mở rộng quy mô dễ dàng theo chiều ngang (horizontal scaling), đồng thời đảm bảo khả năng chịu lỗi cao: nếu một node hỏng, dữ liệu vẫn được sao lưu và xử lý trên các node khác. Chính nhờ sự kết hợp giữa phần mềm phân tán và phần cứng giá rẻ mà Big Data trở thành giải pháp khả thi cho các tổ chức cần xử lý dữ liệu lớn nhưng vẫn tối ưu chi phí.

Câu hỏi phỏng vấn Big Data Engineer về hệ sinh thái Hadoop

Câu hỏi dành cho Fresher/Junior

Mô tả chức năng của NameNode và DataNode trong Hadoop.

NameNode được ví như “bộ não” của HDFS. Nó quản lý toàn bộ thông tin cấu trúc hệ thống tệp, bao gồm tên tệp, thư mục, vị trí lưu trữ từng phần dữ liệu (block), phân quyền truy cập, và trạng thái các node trong hệ thống. Tuy nhiên, NameNode không lưu dữ liệu thực tế, mà chỉ lưu metadata – dữ liệu mô tả dữ liệu.

DataNode là nơi thực tế lưu trữ các khối dữ liệu (data blocks). Mỗi DataNode chịu trách nhiệm lưu, đọc/ghi dữ liệu và gửi thông tin trạng thái định kỳ về cho NameNode. Khi người dùng yêu cầu truy xuất dữ liệu, NameNode sẽ cho biết khối dữ liệu nằm ở đâu, còn DataNode sẽ là nơi thực hiện việc truyền dữ liệu.

Hệ thống HDFS hoạt động theo mô hình tập trung quản lý, phân tán lưu trữ: NameNode duy nhất quản lý metadata, trong khi nhiều DataNode phân tán đảm nhiệm lưu trữ dữ liệu. Mô hình này cho phép Hadoop xử lý dữ liệu lớn với khả năng mở rộng cao, song cũng đòi hỏi NameNode phải luôn sẵn sàng. Nếu NameNode gặp sự cố mà không có bản sao dự phòng, toàn bộ hệ thống có thể bị gián đoạn.

Hãy liệt kê một số tính năng nổi bật của Hadoop.

Một số tính năng nổi bật giúp Hadoop trở thành nền tảng phổ biến trong các hệ thống Big Data:

• Khả năng xử lý phân tán: Hadoop chia nhỏ dữ liệu thành các khối và xử lý song song trên nhiều node trong cụm, giúp tăng tốc độ xử lý và tận dụng tài nguyên tối đa.

• Khả năng mở rộng ngang (horizontal scaling): Có thể dễ dàng mở rộng hệ thống bằng cách thêm nhiều máy rẻ tiền (commodity hardware) mà không cần thay đổi cấu trúc phần mềm.
• Chịu lỗi cao (fault-tolerance): Khi một node bị lỗi, hệ thống sẽ tự động lấy bản sao của dữ liệu từ node khác nhờ cơ chế sao lưu (replication), đảm bảo quá trình xử lý không bị gián đoạn.
• Lưu trữ dữ liệu lớn với chi phí thấp: Nhờ tận dụng phần cứng phổ thông và hệ thống tệp phân tán HDFS, Hadoop cho phép lưu trữ hàng petabyte dữ liệu với chi phí tối ưu.
• Tương thích với nhiều định dạng dữ liệu: Hadoop hỗ trợ dữ liệu có cấu trúc, bán cấu trúc và phi cấu trúc, bao gồm văn bản, hình ảnh, log, video…
• Hệ sinh thái phong phú và mở rộng: Bao quanh Hadoop là các công cụ mạnh mẽ như Hive (truy vấn dữ liệu), Pig (xử lý dữ liệu dạng script), HBase (cơ sở dữ liệu NoSQL), Spark (xử lý in-memory), giúp mở rộng khả năng phân tích dữ liệu đa dạng.
• Tự động phân phối và xử lý dữ liệu: Người dùng không cần lo việc phân chia hay điều phối thủ công. Hadoop tự động chia nhỏ, phân phối và gom kết quả xử lý.

Bạn biết gì về Apache Hive? Hãy giải thích sự khác biệt giữa Hive và RDBMS?

Apache Hive là một công cụ trong hệ sinh thái Hadoop cho phép truy vấn, phân tích và xử lý dữ liệu lớn lưu trữ trên HDFS bằng cú pháp giống SQL, gọi là HiveQL. Thay vì thực thi truy vấn trực tiếp như các hệ quản trị cơ sở dữ liệu quan hệ (RDBMS), Hive biên dịch các truy vấn thành các tác vụ MapReduce (hoặc Spark jobs) để chạy trên nền tảng phân tán.

Mặc dù cú pháp tương tự SQL, Hive không phải là một cơ sở dữ liệu quan hệ, và có một số điểm khác biệt rõ rệt so với RDBMS:

Tiêu chí	Hive	RDBMS (Cơ sở dữ liệu quan hệ)
Cấu trúc lưu trữ	Dữ liệu được lưu trữ trên HDFS (tệp phân tán)	Dữ liệu lưu trữ trong bảng quan hệ với schema cố định
Cơ chế thực thi	Chạy trên MapReduce, Tez hoặc Spark – thường có độ trễ cao	Chạy trực tiếp trong engine cơ sở dữ liệu – tốc độ phản hồi nhanh
Loại dữ liệu xử lý	Dữ liệu lớn, xử lý hàng loạt (batch processing)	Dữ liệu có cấu trúc rõ ràng, thường xử lý theo giao dịch (OLTP)
Hỗ trợ cập nhật dữ liệu	Hạn chế, không tối ưu cho thao tác INSERT/UPDATE/DELETE từng dòng	Hỗ trợ cập nhật dữ liệu theo hàng, đảm bảo tính nhất quán (ACID)
Khả năng mở rộng	Rất cao nhờ nền tảng phân tán Hadoop	Hạn chế hơn, phụ thuộc vào cấu hình phần cứng

Tóm lại, Hive phù hợp với các bài toán phân tích dữ liệu lớn (OLAP), nơi yêu cầu xử lý khối lượng dữ liệu khổng lồ theo lô. Ngược lại, RDBMS được tối ưu cho các ứng dụng giao dịch nhỏ, truy cập thời gian thực, yêu cầu độ chính xác và phản hồi nhanh.

Câu hỏi dành cho Middle/Senior

Tại sao kích thước block trong HDFS lại ảnh hưởng đến hiệu suất hệ thống?

Kích thước block ảnh hưởng trực tiếp đến hiệu suất hệ thống vì nó quyết định số lượng khối cần xử lý và quản lý trong quá trình lưu trữ, truyền tải và xử lý dữ liệu.

• Nếu block quá nhỏ: Một tệp lớn sẽ bị chia thành rất nhiều block nhỏ, dẫn đến quá tải metadata tại NameNode (do phải theo dõi nhiều khối dữ liệu). Điều này làm giảm hiệu suất toàn hệ thống và tăng độ trễ khi truy cập.
• Nếu block quá lớn: Việc xử lý song song bị hạn chế vì có ít block để phân phối cho các DataNode, giảm khả năng tận dụng tính phân tán của Hadoop. Ngoài ra, khi đọc một phần nhỏ của file, hệ thống có thể phải tải nguyên block lớn, gây lãng phí tài nguyên.

Điểm khác biệt chính giữa Hadoop phiên bản 1 và 2 là gì?

Sự khác biệt cốt lõi giữa Hadoop 1 và Hadoop 2 nằm ở kiến trúc quản lý tài nguyên và khả năng mở rộng của hệ thống.

Trong Hadoop phiên bản 1, hệ thống sử dụng JobTracker để vừa quản lý tài nguyên, vừa điều phối các tác vụ xử lý MapReduce. Điều này dẫn đến nút thắt cổ chai (bottleneck) khi có nhiều job chạy đồng thời, khiến hệ thống khó mở rộng và kém linh hoạt.

Hadoop 2 đã cải tiến điều này bằng cách giới thiệu YARN (Yet Another Resource Negotiator) – một kiến trúc quản lý tài nguyên tách biệt với xử lý tác vụ. Với YARN:

• ResourceManager quản lý tài nguyên chung cho toàn cụm.
• ApplicationMaster điều phối từng ứng dụng riêng biệt.

Nhờ đó, Hadoop 2 hỗ trợ không chỉ MapReduce mà còn các mô hình xử lý khác như Spark, Tez, Storm… Điều này giúp hệ thống linh hoạt hơn, sử dụng tài nguyên hiệu quả hơn và dễ mở rộng quy mô xử lý.

Hadoop có những cơ chế bảo mật nào giúp hạn chế các truy cập không được phép?

Một số cơ chế bảo mật chính trong Hadoop:

• Xác thực người dùng (Authentication): Hadoop hỗ trợ xác thực người dùng thông qua Kerberos – một giao thức xác thực mạnh mẽ dựa trên vé (ticket). Điều này giúp đảm bảo chỉ những người dùng hợp lệ mới được truy cập vào hệ thống.
• Phân quyền truy cập (Authorization): HDFS sử dụng cơ chế phân quyền theo người dùng/ nhóm/ quyền truy cập (chạy theo mô hình giống UNIX), bao gồm quyền đọc, ghi và thực thi trên file hoặc thư mục. Ngoài ra, một số công cụ như Apache Ranger hay Sentry cho phép thiết lập chính sách phân quyền chi tiết ở mức bảng, cột hoặc hành động.
• Mã hóa dữ liệu (Encryption): Hadoop hỗ trợ mã hóa dữ liệu khi lưu trữ (at rest) và trong quá trình truyền tải (in transit). Điều này giúp bảo vệ dữ liệu khỏi bị đánh cắp, ngay cả khi ổ đĩa hoặc kết nối bị rò rỉ.
• Kiểm soát truy cập mạng (Network-level security): Có thể cấu hình Hadoop chỉ cho phép truy cập từ các IP hoặc subnet nhất định, đồng thời sử dụng giao thức SSL để bảo mật kênh truyền thông giữa các node trong cụm.
• Ghi log và giám sát truy cập (Auditing & Monitoring): Các công cụ như Apache Ranger hoặc các giải pháp giám sát ngoài (Splunk, ELK) cho phép theo dõi và ghi lại toàn bộ hành vi truy cập hệ thống, giúp dễ dàng phát hiện hành vi đáng ngờ hoặc truy vết khi xảy ra sự cố.

Câu hỏi phỏng vấn Big Data Engineer về Apache Spark

Câu hỏi dành cho Fresher/Junior

Spark khác gì so với Hadoop MapReduce?

Cả Apache Spark và Hadoop MapReduce đều là các nền tảng xử lý dữ liệu phân tán. Spark ra đời sau với mục tiêu khắc phục những hạn chế về hiệu suất và tính linh hoạt của MapReduce. Dưới đây là những điểm khác biệt chính:

• Hiệu suất xử lý nhanh hơn nhiều lần: Spark xử lý dữ liệu trong bộ nhớ (in-memory), giúp giảm đáng kể thời gian đọc/ghi dữ liệu từ đĩa, vốn là điểm yếu của MapReduce. Điều này giúp Spark nhanh gấp 10 đến 100 lần so với MapReduce trong nhiều bài toán phân tích.
• Hỗ trợ xử lý linh hoạt hơn: MapReduce chỉ hỗ trợ xử lý theo mô hình batch (theo lô), còn Spark hỗ trợ nhiều mô hình xử lý khác nhau: batch, streaming (luồng), xử lý đồ thị (GraphX) và học máy (MLlib), tất cả trong cùng một nền tảng.
• Lập trình dễ hơn, ít mã hơn: Spark cung cấp các API phong phú và thân thiện với lập trình viên (hỗ trợ Scala, Python, Java, R), cho phép viết các pipeline xử lý dữ liệu phức tạp chỉ với vài dòng code – điều mà MapReduce cần rất nhiều đoạn mã boilerplate để thực hiện.
• Quản lý job hiệu quả hơn: Spark có cơ chế tối ưu hóa DAG (Directed Acyclic Graph) giúp lập kế hoạch thực thi linh hoạt và hiệu quả hơn so với cơ chế cứng nhắc theo từng bước (map → shuffle → reduce) của MapReduce.

Spark Streaming hoạt động như thế nào?

Spark Streaming cho phép xử lý dữ liệu luồng (streaming data) gần như theo thời gian thực bằng cách tận dụng sức mạnh của Spark Core. Thay vì xử lý từng bản ghi một như các hệ thống stream truyền thống (ví dụ: Storm), Spark Streaming sử dụng mô hình micro-batch, tức là chia dòng dữ liệu liên tục thành các “lô nhỏ” (mini-batch) theo chu kỳ thời gian định trước (ví dụ: mỗi 1 hoặc 2 giây). Mỗi batch được xử lý như một tập dữ liệu tĩnh bằng engine Spark thông thường.

Quy trình hoạt động của Spark Streaming:

• Ingest (Thu nhận dữ liệu): Nhận dữ liệu từ các nguồn như Kafka, Flume, socket, HDFS…
• Chia nhỏ theo thời gian (micro-batch): Dữ liệu được chia thành các batch nhỏ.
• Xử lý song song: Mỗi batch được xử lý giống như một RDD hoặc DataFrame, sử dụng các thao tác như map, reduce, join…
• Xuất kết quả: Dữ liệu đầu ra có thể ghi xuống HDFS, cơ sở dữ liệu, hoặc hiển thị lên dashboard theo thời gian thực.

RDD và DataFrame trong Spark có gì khác nhau?

Tiêu chí	RDD	DataFrame
Cấp độ trừu tượng	Thấp, cho phép thao tác dữ liệu dưới dạng các đối tượng phân tán không có schema. Lập trình viên cần định nghĩa logic xử lý chi tiết, tương tự như làm việc với danh sách trong ngôn ngữ lập trình.	Cao, tổ chức dữ liệu theo dạng bảng có tên cột, tương tự như bảng trong cơ sở dữ liệu. Nó ẩn bớt các chi tiết kỹ thuật và cho phép viết mã ngắn gọn hơn.
Hiệu suất xử lý	Không tự động	Có, nhờ Catalyst Optimizer
Khả năng thao tác và tích hợp	Linh hoạt hơn khi xử lý các thao tác phức tạp, đặc biệt với dữ liệu không có cấu trúc hoặc thao tác không phù hợp với biểu thức SQL.	Dễ tích hợp với Spark SQL, rất hữu ích trong các bài toán phân tích dữ liệu, báo cáo, hoặc khi thao tác dữ liệu có cấu trúc rõ ràng.

Câu hỏi phỏng vấn Big Data Engineer về hệ thống Streaming

Câu hỏi dành cho Fresher/Junior

Hãy giải thích kiến trúc Lambda và trường hợp sử dụng của nó.

Kiến trúc Lambda là một mô hình thiết kế hệ thống xử lý dữ liệu lớn được phát triển để xử lý dữ liệu theo thời gian thực (real-time) đồng thời vẫn đảm bảo độ chính xác và tính toàn vẹn nhờ kết hợp giữa xử lý theo lô (batch processing) và xử lý luồng (stream processing) trong cùng một hệ thống. Cấu trúc cơ bản của kiến trúc Lambda gồm ba tầng chính: Batch Layer, Speed Layer, Serving Layer.

Các trường hợp điển hình sử dụng kiến trúc Lambda:

• Hệ thống phân tích hành vi người dùng theo thời gian thực (ví dụ: theo dõi hành vi trên website hoặc ứng dụng).
• Phát hiện gian lận trong giao dịch tài chính, nơi cần phản ứng nhanh nhưng cũng cần xác nhận dữ liệu chuẩn xác sau khi xử lý đầy đủ.
• Hệ thống khuyến nghị hoặc phân tích log máy chủ, kết hợp dữ liệu hiện tại và dữ liệu lịch sử.

Đọc chi tiết: AWS Lambda là gì? Cẩm nang sử dụng AWS Lambda

Khi nào thì Kappa Architecture là lựa chọn tối ưu hơn Lambda Architecture?

Kappa Architecture là lựa chọn tối ưu hơn Lambda Architecture trong các trường hợp sau:

• Khi hệ thống cần đơn giản, dễ bảo trì: Lambda yêu cầu triển khai song song hai hệ thống (batch + stream), khiến việc phát triển và đồng bộ logic xử lý trở nên phức tạp. Với Kappa, bạn chỉ cần duy trì một pipeline xử lý duy nhất, giúp giảm chi phí vận hành và rủi ro sai lệch logic.
• Khi dữ liệu chủ yếu được xử lý theo thời gian thực: Nếu hệ thống không cần xử lý lại toàn bộ dữ liệu lịch sử thường xuyên (reprocessing), hoặc dữ liệu không thay đổi sau khi được ghi nhận, thì việc dùng một luồng xử lý liên tục là đủ.
• Khi có thể phát lại dữ liệu (replayable stream): Kappa tận dụng các nền tảng như Apache Kafka để lưu trữ dữ liệu dòng một cách bền vững, cho phép phát lại dữ liệu nếu cần xử lý lại, thay thế vai trò của batch layer trong Lambda.
• Ứng dụng yêu cầu độ trễ thấp và cập nhật liên tục: Các hệ thống như giám sát an ninh, cảnh báo giao dịch gian lận, phân tích cảm xúc mạng xã hội,… thường ưu tiên phản hồi nhanh hơn là tổng hợp dữ liệu lớn định kỳ, do đó rất phù hợp với kiến trúc Kappa.

Câu hỏi dành cho Middle/Senior

Làm thế nào bạn xử lý tình trạng trễ (late events) trong hệ thống xử lý stream?

Có thể áp dụng các kỹ thuật sau:

• Sử dụng watermark: Watermark là cơ chế giúp hệ thống xác định điểm cắt thời gian, sau đó coi mọi sự kiện đến muộn hơn mốc này là “trễ”. Công cụ như Apache Flink hoặc Spark Structured Streaming đều hỗ trợ watermark để kiểm soát độ trễ cho phép và đảm bảo dữ liệu đến chậm vẫn được xử lý nếu trong khoảng thời gian cho phép.
• Thiết lập “grace period” hoặc “allowed lateness”: Có thể cấu hình một khoảng thời gian chờ (ví dụ: 5 phút) sau thời gian thực tế để tiếp nhận các sự kiện trễ. Trong khoảng đó, hệ thống vẫn cập nhật kết quả đầu ra khi có dữ liệu đến muộn.
• Buffer dữ liệu tạm thời: Trong một số hệ thống, có thể chọn buffer (đệm) dữ liệu thêm vài giây hoặc phút trước khi xử lý, nhằm chờ dữ liệu trễ. Điều này phù hợp khi ưu tiên độ chính xác hơn là tốc độ phản hồi tức thì.
• Tách xử lý chính và xử lý bổ sung: Thay vì làm chậm toàn bộ pipeline, bạn có thể xử lý dữ liệu đúng hạn trước, sau đó xử lý dữ liệu trễ ở một nhánh riêng (Ví dụ: lưu vào side table hoặc gửi cảnh báo điều chỉnh sau).

Bạn đã từng gặp vấn đề về back-pressure trong các hệ thống xử lý stream chưa? Bạn xử lý nó như thế nào?

Bạn có thể đưa ra một tình huống thực tế mà bạn đã xử lý thành công.

Gợi ý cách trả lời:

Tôi đã từng gặp vấn đề back-pressure khi làm việc với một hệ thống phân tích log theo thời gian thực sử dụng Apache Kafka và Apache Spark Structured Streaming. Trong giai đoạn cao điểm, khi lượng truy cập tăng đột biến, hệ thống không xử lý kịp luồng dữ liệu đẩy về từ Kafka, dẫn đến độ trễ đầu ra tăng dần, bộ nhớ Spark bị chiếm đầy và một số batch bị treo, phải retry nhiều lần. Sau khi kiểm tra log và giám sát bằng Spark UI + Kafka Lag Monitor, tôi xác định rõ ràng nguyên nhân đến từ việc tốc độ xử lý downstream không theo kịp tốc độ đọc dữ liệu từ Kafka, khiến hàng đợi ngày càng đầy. Đây là biểu hiện điển hình của back-pressure.

Hướng giải quyết mà tôi đã thực hiện:

• Kích hoạt cơ chế xử lý back-pressure tự động trong Spark: Tôi thêm cấu hình spark.streaming.backpressure.enabled = true để Spark tự điều chỉnh tốc độ lấy dữ liệu từ Kafka dựa trên năng lực xử lý thực tế.
• Tối ưu logic xử lý trong pipeline: Một phần độ trễ đến từ việc groupBy và aggregation theo session rất tốn tài nguyên. Tôi đã tách xử lý thành hai giai đoạn, giảm số lượng shuffle và kết hợp thêm reduceByKey thay vì groupByKey, giúp giảm áp lực lên driver và executor.
• Mở rộng tài nguyên hệ thống: Tôi tăng số lượng executor và batch interval từ 1 giây lên 5 giây, cho Spark có thêm thời gian xử lý từng batch và giảm áp lực liên tục.
• Tạm thời scale-in Kafka consumer: Trong lúc khẩn cấp, tôi chủ động giảm số lượng thread đọc Kafka để làm chậm tốc độ ingest đầu vào, tránh đẩy quá tải cho Spark trong thời gian ngắn.

Câu hỏi phỏng vấn Big Data Engineer về quản lý và tối ưu hóa dữ liệu

Câu hỏi dành cho Fresher/Junior

Vì sao fault tolerance và data replication lại cần thiết trong hệ thống Big Data?

Fault tolerance và data replication cần thiết trong hệ thống Big Data vì:

• Fault tolerance (khả năng chịu lỗi) giúp hệ thống Big Data vẫn tiếp tục hoạt động ngay cả khi một hoặc nhiều node gặp sự cố. Dữ liệu và tiến trình xử lý sẽ không bị mất, giúp đảm bảo tính liên tục của dịch vụ và độ tin cậy cho người dùng cũng như doanh nghiệp.
• Data replication (sao lưu dữ liệu) là việc lưu trữ nhiều bản sao dữ liệu trên các node khác nhau trong cluster. Khi một node bị hỏng hoặc mất kết nối, hệ thống có thể truy cập dữ liệu từ bản sao dự phòng, tránh mất mát dữ liệu và giảm rủi ro downtime.

Theo bạn, scalability trong lĩnh vực Big Data được hiểu như thế nào?

Scalability (khả năng mở rộng) trong lĩnh vực Big Data là khả năng của hệ thống dữ liệu trong việc xử lý hiệu quả khi khối lượng, tốc độ hoặc độ đa dạng của dữ liệu tăng lên, mà không làm giảm hiệu năng hoặc làm gián đoạn dịch vụ. 

Có thể hiểu scalability không chỉ là “mở rộng để xử lý được nhiều dữ liệu hơn”, mà còn là làm sao để hệ thống duy trì được độ ổn định, tiết kiệm tài nguyên và đảm bảo latency chấp nhận được khi lượng dữ liệu tăng đột biến hoặc người dùng tăng theo thời gian.

Scalability trong Big Data không chỉ là một tính năng hệ thống, mà là nguyên tắc cốt lõi để đảm bảo hệ thống dữ liệu luôn sẵn sàng phục vụ khi dữ liệu phát triển theo quy mô hoặc tốc độ không lường trước được. Một hệ thống có khả năng scale tốt là tiền đề để tổ chức chuyển đổi số và ra quyết định theo thời gian thực một cách hiệu quả.

Sự khác biệt giữa mở rộng ngang (horizontal scaling) và mở rộng dọc (vertical scaling) là gì?

Tiêu chí	Mở rộng dọc (Vertical Scaling)	Mở rộng ngang (Horizontal Scaling)
Khái niệm	Nâng cấp cấu hình máy chủ hiện tại (CPU, RAM, SSD…)	Thêm nhiều máy chủ (node) để chia tải công việc
Cách triển khai	Tăng sức mạnh phần cứng trên một server duy nhất	Phân tán xử lý qua nhiều server hoặc instance
Chi phí ban đầu	Thường rẻ hơn (nếu chỉ nâng cấp nhỏ)	Cao hơn do phải thiết lập kiến trúc phân tán
Giới hạn	Bị giới hạn bởi phần cứng vật lý của máy	Gần như không giới hạn – chỉ cần thêm node
Độ phức tạp hệ thống	Thấp – dễ triển khai và bảo trì	Cao hơn – cần xử lý phân phối dữ liệu, đồng bộ, cân bằng tải
Tính sẵn sàng (High Availability)	Khó đạt – khi máy chính gặp sự cố sẽ ảnh hưởng toàn hệ thống	Dễ đạt – có thể thiết lập cluster, failover, replication
Downtime khi nâng cấp	Có thể cao (phải dừng hệ thống để nâng phần cứng)	Gần như không có – có thể thêm node động trên cloud
Khả năng mở rộng theo thời gian	Hạn chế – đến một ngưỡng nhất định sẽ không thể nâng tiếp	Rất linh hoạt – phù hợp với hệ thống Big Data & Cloud
Ứng dụng phù hợp	App đơn giản, monolithic, OLAP nhỏ, thử nghiệm	Big Data platform, hệ thống real-time, cloud-native apps

Vai trò của quản lý siêu dữ liệu (metadate) và catalog dữ liệu trong môi trường Big Data là gì?

Vai trò của hai thành phần này như sau:

• Tăng khả năng tìm kiếm và tái sử dụng dữ liệu: Khi làm việc với hàng trăm bảng dữ liệu trong data lake hoặc data warehouse, việc có một data catalog chuẩn hóa (như Apache Atlas, AWS Glue Data Catalog, hoặc Amundsen) giúp người dùng có thể nhanh chóng tìm thấy bảng phù hợp với nhu cầu, hiểu được định nghĩa cột, lineage và các thuộc tính liên quan. Điều này đặc biệt hữu ích khi làm việc đa nhóm hoặc onboarding thành viên mới.
• Cung cấp ngữ cảnh và chất lượng cho dữ liệu: Metadata – đặc biệt là business metadata và technical metadata, giúp người dùng hiểu rõ dữ liệu đang phản ánh điều gì, được tạo ra từ đâu, thay đổi như thế nào, và còn dùng được hay không. Với metadata đầy đủ, tôi có thể xác định được dữ liệu nào đã được chuẩn hóa, dữ liệu nào cần kiểm tra thêm, từ đó đưa ra phân tích chính xác hơn.
• Hỗ trợ quản trị và tuân thủ (governance & compliance): Khi làm việc trong các dự án liên quan đến dữ liệu nhạy cảm (như tài chính, y tế), việc quản lý metadata giúp xác định thông tin nào là PII, ai có quyền truy cập, hoặc các bảng nào cần audit định kỳ. Đây là nền tảng để tổ chức tuân thủ các tiêu chuẩn như GDPR, HIPAA,…
• Tăng hiệu quả vận hành và debug hệ thống: Nhờ việc lưu trữ lineage (nguồn gốc và dòng chảy của dữ liệu), tôi có thể dễ dàng truy ngược lại các bước xử lý khi có vấn đề xảy ra với dữ liệu (ví dụ như sai số, trễ batch, hoặc lỗi phân tích) mà không cần dò lại toàn bộ pipeline thủ công.
• Tối ưu hóa chi phí và tài nguyên xử lý dữ liệu: Trong các hệ thống dữ liệu lớn, không phải lúc nào cũng cần xử lý toàn bộ dataset. Nhờ metadata như kích thước bảng, số lượng bản ghi, tần suất truy cập, tôi có thể xác định bảng nào nên archive, cache, hoặc tối ưu lại mô hình lưu trữ, giúp giảm chi phí cloud và cải thiện hiệu suất pipeline.

Câu hỏi dành cho Middle/Senior

Khi làm việc với hệ thống phân tán, bạn quản lý partitioning và shuffling dữ liệu ra sao để tối ưu hiệu suất?

Đối với Partitioning:

• Chọn số lượng partition phù hợp với tài nguyên hệ thống để tận dụng tối đa khả năng xử lý.
• Partition dữ liệu theo key (hash hoặc range) giúp các phép toán như join, groupBy chạy nhanh hơn do giảm di chuyển dữ liệu giữa các node.
• Luôn kiểm tra và xử lý data skew (partition quá lớn), tránh bottleneck.

Đối với Shuffling:

• Hạn chế tối đa các phép toán gây shuffle như groupByKey, join với bảng lớn. Ưu tiên reduceByKey hoặc broadcast join khi có thể.
• Profile và giám sát các job để phát hiện điểm nghẽn do shuffle, từ đó tối ưu lại logic hoặc partitioning.

Khi schema thay đổi hoặc cần quản lý version dữ liệu trong kho dữ liệu, bạn sẽ xử lý thế nào?

Khi đối mặt với các thay đổi schema hoặc yêu cầu quản lý version dữ liệu trong kho dữ liệu, tôi thường ưu tiên tiếp cận theo hướng ổn định, dễ mở rộng, dễ truy vết. Cụ thể, tôi áp dụng một số nguyên tắc và kỹ thuật sau:

• Thiết kế schema linh hoạt & có khả năng version hóa: Sử dụng các mô hình như SCD Type 2 hoặc Data Vault để đảm bảo khả năng lưu lịch sử thay đổi. Với mỗi bản ghi, tôi thêm các cột như valid_from, valid_to, is_current, hoặc record_version để truy vết version và tái hiện trạng thái dữ liệu theo từng thời điểm.
• Quản lý schema bằng Git & CI/CD: Toàn bộ định nghĩa schema và pipeline ETL đưa vào Git, kết hợp với CI/CD để tự động kiểm tra tính tương thích (schema compatibility) trước khi triển khai. Điều này giúp hạn chế lỗi schema breaking và dễ rollback khi cần.
• Tách version dữ liệu bằng snapshot hoặc partition: Với những bảng lớn hoặc dữ liệu cần audit, lưu thêm các snapshot theo ngày (snapshot_date) hoặc theo logic nghiệp vụ (version_id) để có thể thực hiện truy vấn theo thời gian hoặc so sánh các bản ghi giữa các version.
• Áp dụng schema evolution khi cần thiết: Trong các hệ thống sử dụng Spark hoặc Delta Lake, bật tính năng schema evolution để hệ thống có thể tự cập nhật schema khi dữ liệu mới được ingest. Tuy nhiên, luôn kèm theo bước kiểm tra schema diff để đảm bảo an toàn.
• Đảm bảo backward compatibility: Trước khi thay đổi schema, kiểm tra tác động đến các pipeline downstream. Nếu có sự phụ thuộc, sử dụng các lớp view trung gian để duy trì khả năng tương thích trong thời gian chuyển đổi.

Bạn thường áp dụng những cách nào để tăng tốc độ truy vấn SQL?

Một số kỹ thuật thường sử dụng để tối ưu hóa hiệu năng truy vấn:

• Sử dụng chỉ mục (Index) hợp lý: Tạo index cho các cột thường xuyên dùng trong WHERE, JOIN hoặc ORDER BY giúp truy vấn nhanh hơn rất nhiều. Tuy nhiên, cần tránh lạm dụng index vì sẽ làm chậm quá trình INSERT, UPDATE.
• Hạn chế sử dụng SELECT *: Thay vì dùng SELECT *, chỉ định rõ các cột cần thiết. Điều này giúp giảm lượng dữ liệu truyền tải không cần thiết và tiết kiệm tài nguyên xử lý.
• Tránh truy vấn lồng nhau không cần thiết: Các subquery không tối ưu (đặc biệt là những subquery lặp lại trong SELECT hoặc WHERE) có thể làm chậm toàn bộ truy vấn. Tôi thường thay thế bằng JOIN hoặc sử dụng WITH (CTE) để cải thiện hiệu năng.
• Tối ưu hóa JOIN: Sắp xếp thứ tự bảng từ nhỏ đến lớn theo chiều JOIN, tránh JOIN không cần thiết và luôn đảm bảo có điều kiện ON rõ ràng, sử dụng INNER JOIN thay vì LEFT JOIN nếu không cần dữ liệu bên trái bắt buộc.
• Sử dụng phân vùng (Partition): khi làm việc với các bảng lớn, tận dụng partitioning để chia nhỏ bảng theo ngày hoặc danh mục, từ đó giúp truy vấn chỉ tìm trong phân vùng liên quan thay vì toàn bộ dữ liệu.

Đây cũng chính là một trong những câu hỏi thường gặp trong bộ Câu hỏi phỏng vấn Data Analyst và Câu hỏi phỏng vấn Data Engineer mà bạn nên tham khảo.

Câu hỏi phỏng vấn Big Data Engineer về kinh nghiệm làm việc và thực chiến

Câu hỏi dành cho Fresher/Junior

Theo bạn, điều gì quan trọng hơn: dữ liệu chất lượng hay mô hình tốt? Giải thích lý do.

Nhà tuyển dụng muốn đánh giá:

• Tư duy ưu tiên và ra quyết định của bạn trong bối cảnh thực tế.
• Mức độ am hiểu của bạn về quy trình làm việc với dữ liệu: bạn có đang chạy theo thuật toán hay hiểu vai trò của chất lượng đầu vào?
• Cách bạn lý giải và bảo vệ quan điểm của mình.

Câu trả lời gợi ý:

Theo tôi, dữ liệu chất lượng quan trọng hơn mô hình tốt. Lý do là vì ngay cả mô hình phức tạp nhất cũng không thể tạo ra kết quả đáng tin cậy nếu dữ liệu đầu vào sai lệch, nhiễu loạn hoặc thiếu thông tin.

Một nguyên tắc quen thuộc trong lĩnh vực dữ liệu là: ‘Garbage in, garbage out’ – nếu đầu vào là dữ liệu không chính xác, thì đầu ra cũng sẽ không thể đáng tin cậy, dù mô hình có tối ưu đến đâu.

Tôi từng làm một dự án phân tích hành vi người dùng cho một nền tảng thương mại điện tử. Ban đầu, nhóm của tôi thử nhiều mô hình từ đơn giản đến phức tạp như Random Forest, XGBoost, nhưng kết quả vẫn chưa cải thiện. Sau đó, chúng tôi tập trung rà soát lại toàn bộ dữ liệu: xử lý dữ liệu trùng, chuẩn hóa định dạng, và đặc biệt là xây dựng lại feature về hành vi người dùng theo thời gian. Kết quả là mô hình Logistic Regression đơn giản nhưng chạy trên tập dữ liệu “sạch” lại mang về độ chính xác và F1-score tốt hơn cả XGBoost trước đó.

Tất nhiên, mô hình vẫn rất quan trọng, đặc biệt trong các bài toán phức tạp như xử lý ảnh hoặc NLP. Nhưng nếu bắt buộc phải chọn, tôi ưu tiên dữ liệu chất lượng trước. Vì với dữ liệu tốt, bạn luôn có thể cải tiến dần mô hình theo thời gian; còn nếu dữ liệu kém, mô hình tốt đến đâu cũng khó cứu vãn.”

Trong trường hợp khó xác định bug, bạn thường áp dụng phương pháp nào để tìm ra nguyên nhân?

Nhà tuyển dụng muốn đánh giá:

• Tư duy phân tích và quy trình suy luận lỗi của bạn: Bạn có làm việc logic, có hệ thống, hay chỉ xử lý theo cảm tính?
• Khả năng debug và mindset giải quyết vấn đề thực tế: Bạn xử lý bug kiểu “đoán mò” hay biết cách kiểm soát phạm vi kiểm tra?

Gợi ý câu trả lời:

Khi gặp bug khó xác định, tôi thường áp dụng phương pháp ‘khoanh vùng + kiểm chứng’ từng giả thuyết một cách có hệ thống. Quy trình cụ thể như sau:

• Reproduce bug: Trước tiên, tôi luôn cố gắng tái hiện lại bug một cách ổn định, bằng cách ghi lại input, môi trường, hành vi người dùng nếu có.
• Đọc lại log và theo dõi các error trace: Tôi dùng log ở các mốc logic để xác định bug xảy ra ở giai đoạn nào: input → xử lý → lưu trữ → hiển thị. Nhiều bug không do code sai mà do dữ liệu đầu vào bất thường hoặc khác kỳ vọng.
• Kiểm tra từng ‘hypothesis’ một: Tôi liệt kê các nguyên nhân có thể xảy ra (ví dụ: sai logic xử lý, dữ liệu null, lỗi type cast, race condition…) và loại trừ từng cái bằng cách viết test nhỏ hoặc log rõ hơn.
• So sánh với phiên bản trước (nếu có): Nếu bug mới xuất hiện, tôi kiểm tra git diff để xem commit nào có thể liên quan. Điều này giúp tôi rút ngắn thời gian phân tích đáng kể.
• Tìm kiếm các vấn đề tương tự: Với các lỗi phức tạp hoặc liên quan thư viện ngoài, tôi tra cứu trên GitHub Issues, Stack Overflow hoặc changelog của thư viện để xem có ai gặp lỗi tương tự chưa.

Câu hỏi dành cho Middle/Senior

Nếu được giao thiết kế hệ thống xử lý dữ liệu phân tán, bạn sẽ tiếp cận ra sao?

Nhà tuyển dụng muốn đánh giá:

• Tư duy hệ thống và cách bạn tiếp cận vấn đề từ tổng thể đến chi tiết.
• Hiểu biết thực tế của bạn về các thành phần chính trong hệ sinh thái dữ liệu lớn (big data).
• Khả năng cân nhắc giữa tính đúng đắn – hiệu năng – khả năng mở rộng – độ tin cậy.

Gợi ý câu trả lời:

Nếu được giao thiết kế một hệ thống xử lý dữ liệu phân tán, tôi sẽ bắt đầu bằng cách làm rõ bài toán từ góc độ kinh doanh và dữ liệu. Tôi sẽ đặt câu hỏi: hệ thống cần xử lý dữ liệu batch hay streaming? Dữ liệu đến từ đâu, có cần xử lý thời gian thực không, khối lượng dữ liệu mỗi ngày là bao nhiêu? Độ trễ chấp nhận được là bao lâu? Và ai sẽ sử dụng kết quả đầu ra – data analyst, hệ thống recommendation, hay dashboard BI?

Sau khi hiểu rõ yêu cầu, tôi sẽ chia hệ thống thành các lớp chính:

• Ingestion layer: Nếu dữ liệu đến liên tục từ nhiều nguồn (log, sensor, event tracking…), tôi sẽ dùng Kafka để thu nhận theo cơ chế pub/sub, đảm bảo mở rộng tốt và chống mất dữ liệu.
• Storage layer: Với batch data, tôi có thể chọn S3 hoặc HDFS. Nếu xử lý streaming hoặc cần phản hồi nhanh, tôi ưu tiên Redis hoặc một cơ sở dữ liệu NoSQL như Cassandra.
• Processing layer:
  • Nếu là xử lý hàng loạt, tôi dùng Spark vì nó có khả năng xử lý phân tán mạnh, hỗ trợ cả batch và streaming.
  • Nếu yêu cầu thời gian thực và low-latency hơn, tôi sẽ xem xét Flink hoặc Kafka Streams – đặc biệt khi có nhiều trạng thái cần duy trì (stateful stream).
• Serving layer: Tuỳ mục tiêu đầu ra, dữ liệu sau xử lý sẽ được đẩy vào BigQuery, Snowflake hoặc tạo API để hệ thống khác tiêu thụ.

Trong một dự án, bạn đã từng tối ưu pipeline ra sao để đạt hiệu quả tốt hơn?

Nhà tuyển dụng muốn đánh giá:

• Khả năng nhận diện bottleneck và cải tiến quy trình làm việc với dữ liệu.
• Tư duy tối ưu hóa có hệ thống, không chỉ “chạy được là xong”.
• Kỹ năng kỹ thuật thực chiến: bạn biết dùng công cụ gì, tối ưu ở đâu – ingestion, transform, hay load?
• Tư duy đánh đổi (trade-off): tốc độ – chi phí – độ chính xác.

Gợi ý câu trả lời:

Trong một dự án gần đây, tôi được giao tối ưu hóa pipeline ETL xử lý dữ liệu hành vi người dùng cho hệ thống recommendation. Pipeline ban đầu được viết bằng Python thuần, chạy hằng ngày trên một cron job đơn lẻ, xử lý dữ liệu từ 3 nguồn khác nhau, lưu vào PostgreSQL. Tuy nhiên, thời gian chạy kéo dài đến hơn 2 tiếng và thường xuyên bị lỗi timeout hoặc duplicate ghi vào DB.

Tôi bắt đầu bằng cách chia nhỏ quy trình xử lý và đo thời gian từng bước để xác định bottleneck. Kết quả cho thấy phần lớn thời gian bị tiêu tốn ở khâu xử lý dữ liệu dạng JSON và ghi lần lượt từng bản ghi vào cơ sở dữ liệu.

Tôi đã áp dụng một số thay đổi như sau:

• Dùng Pandas để batch process dữ liệu thay vì for-loop từng dòng.
• Chuyển từ ghi tuần tự sang batch insert bằng SQLAlchemy hoặc COPY command để giảm số lượng transaction.
• Tách pipeline thành từng task nhỏ và orchestration lại bằng Airflow, giúp dễ kiểm soát lỗi và retry theo từng bước riêng lẻ.
• Thêm checkpoint và logging chuẩn hóa, giúp monitor hiệu suất và debug dễ hơn khi phát sinh sự cố.

Sau tối ưu, thời gian xử lý giảm từ hơn 2 tiếng xuống còn khoảng 25 phút. Đồng thời, tỷ lệ job thất bại giảm đáng kể nhờ khả năng retry thông minh của Airflow. Về lâu dài, tôi còn đề xuất chuyển sang lưu trữ tạm bằng S3 và sử dụng Athena để truy vấn nhanh – giúp giảm tải PostgreSQL khi data scale lớn hơn.

Bài học tôi rút ra là: thay vì tập trung tối ưu từng dòng code nhỏ, cần nhìn tổng thể pipeline và xác định đúng điểm nghẽn, đồng thời chọn đúng công cụ cho từng nhiệm vụ.

Theo bạn, ba bước quan trọng nhất khi xây dựng giải pháp Big Data là gì?

Nhà tuyển dụng muốn đánh giá:

• Cách bạn tư duy hệ thống dữ liệu ở cấp độ lớn, không chỉ vài bảng hoặc file.
• Mức độ hiểu biết của bạn về quy trình, từ ingestion đến phân tích trong môi trường Big Data.
• Khả năng xác định đúng ưu tiên

Gợi ý câu trả lời:

Theo tôi, khi xây dựng một giải pháp Big Data, có rất nhiều bước cần triển khai, nhưng nếu chọn 3 bước quan trọng nhất, tôi sẽ ưu tiên như sau:

• Thiết kế kiến trúc ingest và lưu trữ phù hợp ngay từ đầu: Đây là bước nền móng. Chọn sai cách ingest (batch/stream), hoặc lưu trữ không tối ưu (file format, partitioning) có thể khiến hệ thống scale lên sẽ gặp bottleneck.
• Lựa chọn công cụ xử lý dữ liệu phân tán phù hợp với mục tiêu: Không phải lúc nào Spark cũng là câu trả lời. Nếu cần low-latency streaming, tôi sẽ xem xét Flink hoặc Kafka Streams. Nếu xử lý batch lớn mà không cần real-time, Spark là lựa chọn mạnh mẽ.
• Đảm bảo khả năng mở rộng và quan sát hệ thống: Một hệ thống Big Data tốt không chỉ “chạy được” mà phải dễ mở rộng, dễ debug và giám sát. Vì vậy tôi luôn ưu tiên tích hợp logging tập trung, alerting, và dashboard theo dõi các chỉ số hiệu suất – đặc biệt khi xử lý dữ liệu real-time.

Theo kinh nghiệm của bạn, các rủi ro bảo mật thường gặp khi triển khai Big Data là gì?

Nhà tuyển dụng muốn đánh giá:

• Nhận thức của bạn về khía cạnh bảo mật – một phần thường bị xem nhẹ trong hệ thống dữ liệu.
• Kinh nghiệm thực tế khi triển khai hoặc quản lý pipeline dữ liệu lớn.
• Khả năng lường trước và phòng tránh sự cố về dữ liệu

Gợi ý câu trả lời:

Theo kinh nghiệm cá nhân, khi triển khai hệ thống Big Data, tôi nhận thấy có một số rủi ro bảo mật phổ biến sau mà nếu không kiểm soát tốt sẽ gây hậu quả nghiêm trọng về cả pháp lý lẫn uy tín doanh nghiệp:

• Rò rỉ dữ liệu nhạy cảm do thiếu phân quyền hoặc mã hóa: Rất nhiều hệ thống Big Data ingest trực tiếp từ nhiều nguồn như log người dùng, thiết bị IoT, hoặc dữ liệu tài chính. Nếu không có cơ chế phân quyền truy cập theo vai trò (RBAC), rất dễ xảy ra tình trạng nhân viên truy cập được cả thông tin họ không nên thấy. Ngoài ra, việc không mã hóa dữ liệu khi lưu trữ (at-rest) hoặc khi truyền (in-transit) cũng là một lỗ hổng lớn – đặc biệt với các hệ thống xử lý PII hoặc dữ liệu nhạy cảm.
• Không giám sát và audit đầy đủ các hành vi truy cập dữ liệu: Một lỗ hổng thường bị bỏ qua là thiếu hệ thống logging, monitoring và audit trail cho các hoạt động trên dữ liệu.
• Quá phụ thuộc vào công cụ, bỏ qua nguyên tắc bảo mật cơ bản: Nhiều nhóm kỹ thuật quá tin vào hệ thống như Spark, Kafka, Hadoop đã được “cài sẵn” mà quên kiểm tra lại cấu hình bảo mật. Ví dụ, Kafka cluster không bật SSL, hoặc Hadoop mở port mặc định không giới hạn IP có thể bị khai thác từ bên ngoài.

Tổng kết câu hỏi phỏng vấn Big Data Engineer

Big Data Engineer là một trong những vị trí then chốt trong thời đại dữ liệu ngày nay. Để vượt qua vòng phỏng vấn thành công, ứng viên không chỉ cần nắm vững kiến thức kỹ thuật về hệ sinh thái Hadoop, Apache Spark, các hệ thống xử lý dữ liệu streaming, mà còn phải có tư duy hệ thống, khả năng tối ưu hóa, và kinh nghiệm thực tế trong xử lý dữ liệu quy mô lớn.

Bộ câu hỏi phỏng vấn Big Data Engineer trong bài viết này không chỉ giúp bạn ôn luyện kiến thức cốt lõi, mà còn hỗ trợ bạn rèn luyện tư duy phản biện, giải quyết vấn đề và thể hiện kinh nghiệm làm việc một cách thuyết phục. Hãy dành thời gian luyện tập, chuẩn bị ví dụ cụ thể từ các dự án bạn từng tham gia, và tự tin chia sẻ cách bạn tiếp cận, giải quyết các thách thức trong thực tế.

Chúc bạn thành công và sớm chinh phục vị trí Big Data Engineer mà bạn mong muốn!

Đọc chi tiết: Big Data Engineer Roadmap: Lộ trình học tập và phát triển từ A-Z