Big Data Processing là môn có khoảng cách lớn giữa cái tên và trải nghiệm thật: nghe rất "kỹ sư dữ liệu", còn thực tế tuần thứ tư là bạn ngồi nhìn một cái job chạy 15 phút chỉ để phát hiện mình viết sai một dòng. Môn này thưởng người có phương pháp và phạt rất nặng người quen nước rút.
COSC2637 là môn gì?
Big Data Processing dạy cách xử lý khối dữ liệu vượt sức một máy đơn bằng hệ thống phân tán, với hệ sinh thái kiểu Hadoop và Spark làm xương sống các kỳ trước: lưu trữ phân tán, mô hình map/reduce và các lớp xử lý xây bên trên. Assignment quen thuộc là bài xử lý dữ liệu: nhận một tập dữ liệu lớn, viết chương trình xử lý chạy trên cụm và nộp kèm báo cáo kết quả cộng hiệu năng.
Cấu trúc assessment, trọng số và word count thay đổi theo kỳ; mọi mô tả trong bài là mặt bằng các kỳ trước. Course guide trên Canvas của đúng kỳ bạn học là nguồn duy nhất đáng tin.
Cấu trúc đánh giá (tính tới 2026): các kỳ gần đây môn thường trộn ba nhóm điểm: bài kiểm tra hoặc quiz theo tuần (nắm lý thuyết), assignment/task cá nhân hoặc nhóm (phần nặng điểm nhất, chính là thứ bài này hướng dẫn), và bài đánh giá cuối kỳ. Kỳ 2026 của bạn dùng đúng cấu hình nào, trọng số bao nhiêu: mở course guide trên Canvas để đối chiếu trước khi phân bổ thời gian.
Assignment xử lý dữ liệu lớn: tư duy trước, cụm sau
- Trả lời được câu hỏi: bài này có thật sự cần distributed không. Dữ liệu vài trăm megabyte xử lý một máy còn nhanh hơn dựng cả cụm. Hiểu ngưỡng nào thì phân tán mới đáng (dữ liệu không vừa một máy, xử lý một máy quá lâu) là câu lý thuyết kinh điển của môn, và là tư duy giúp bạn không tự làm khổ mình.
- Tư duy map/reduce ở mức khái niệm, đừng học thuộc API. Mọi bài toán của mô hình này quy về hai câu hỏi: với từng phần tử dữ liệu, mình biến nó thành cặp khóa-giá trị gì (map), và với các giá trị cùng khóa, mình gộp chúng thế nào (reduce). Nghĩ xong hai câu này trên giấy rồi mới mở editor; code chỉ là bản dịch.
- Chạy trên mẫu nhỏ ở máy mình trước. Cắt vài nghìn dòng dữ liệu, chạy local cho đúng logic đã, rồi mới đưa lên cụm chạy bản đầy đủ. Vòng sửa lỗi trên cụm tính bằng chục phút mỗi lần; trên mẫu nhỏ tính bằng giây.
- Ghi lại mỗi lần chạy như ghi thí nghiệm. Cấu hình gì, dữ liệu bao nhiêu, chạy hết bao lâu, kết quả ra sao. Log này là nguyên liệu thô của phần báo cáo hiệu năng.
Báo cáo hiệu năng trung thực: chỗ ăn điểm ít ai làm tử tế
Phần báo cáo hay bị xem là thủ tục, trong khi nó là nơi phân hóa band rõ nhất. Ba nguyên tắc:
- So sánh phải công bằng. Muốn nói bản phân tán nhanh hơn: cùng dữ liệu, cùng điều kiện, nêu rõ cấu hình từng bên. So bản chạy cụm với laptop yếu hơn rồi kết luận "nhanh gấp 10 lần" là tự đánh rơi uy tín cả bài.
- Kết quả xấu vẫn báo cáo, kèm phân tích. Bản phân tán chậm hơn mong đợi vì chi phí khởi động và trộn dữ liệu lấn át khối lượng tính toán? Viết đúng như vậy kèm lý giải là ăn điểm, vì nó chứng minh bạn hiểu hệ thống. Sửa số cho đẹp là con đường ngắn nhất tới hội đồng học thuật.
- Số nào cũng có nguồn gốc. Thời gian đo bằng gì, lấy trung bình mấy lần chạy, có loại lần chạy khởi động đầu tiên không. Người chấm môn này đọc số bằng con mắt kỹ sư; số trơn không nguồn gốc là số chết.
Code và report của môn này cũng qua so trùng như essay; mượn pipeline của nhóm khác rồi đổi tên biến bị bắt y hệt văn xuôi. Ranh giới an toàn giữa tham khảo và chép tụi mình viết kỹ trong bài Turnitin bao nhiêu phần trăm là đạt, tinh thần áp dụng cho code không khác gì. Còn nếu bạn đã có bài chạy được và muốn người ngoài soi lại phần báo cáo (so sánh đã công bằng chưa, kết luận có vượt quá số liệu không), tụi mình nhận review trước khi nộp theo đúng rubric, chi tiết ở bảng báo giá của 7 Writing Service.
Câu hỏi thường gặp
Máy yếu có học được COSC2637 không?
Được. Các kỳ trước môn thường cấp môi trường cụm qua lab hoặc hướng dẫn chạy giả lập trên một máy; phần phát triển logic hoàn toàn làm được trên mẫu dữ liệu nhỏ với máy phổ thông.
Môn dùng Java hay Python?
Tùy kỳ và tùy công cụ được chọn: hệ Hadoop truyền thống nghiêng về Java, còn Spark viết được bằng Python. Đừng đặt cược vào ngôn ngữ mà vào tư duy map/reduce: nó không đổi dù kỳ bạn dùng công cụ nào.
Job chạy quá lâu, có nên ngồi đợi không?
Không. Thời gian đợi là thời gian làm việc khác: soát lại logic trên mẫu nhỏ, viết dần báo cáo, ghi log lần chạy. Job vượt xa thời gian dự kiến thì khả năng cao logic sai hoặc dữ liệu lệch; dừng sớm kiểm tra rẻ hơn đợi tới cùng.
Cần hỗ trợ 1-1 cho môn này? Xem bảng giá và quy trình nhận hỗ trợ của 7 Writing Service.