Dự án cuối khóa: từ đề bài đến kiến trúc end-to-end
Xem thửHai học viên cùng nộp dự án cuối khóa. Bạn A có một repository gồm 14 notebook chạy tay theo thứ tự, một bảng điều khiển đẹp và một tệp README ba dòng. Bạn B có ít tính năng hơn, nhưng docker compose up dựng toàn bộ nền tảng, CI chạy xanh, pipeline có kiểm thử chất lượng và cảnh báo, và một sơ đồ kiến trúc giải thích vì sao chọn từng công cụ. Người phỏng vấn mở repository của B và nói chuyện về thiết kế trong 20 phút; với A, họ hỏi "chạy cái này thế nào?" và không ai trả lời nhanh được.
Hãy dự đoán: một dự án end-to-end có giá trị khi tuyển dụng cần chứng minh được những khả năng nào, ngoài việc "dữ liệu chảy từ đầu tới cuối"? Nêu ít nhất ba.
Sau bài này, bạn có thể
- Chọn một trong ba đề tài và giới hạn phạm vi vào một câu hỏi nghiệp vụ trung tâm cùng hai đến ba nguồn dữ liệu.
- Vẽ kiến trúc end-to-end đủ sáu tầng và gắn với lộ trình ba mốc.
- Viết một ADR ngắn gồm bối cảnh, phương án, quyết định và hệ quả.
Cần biết trước: các chương 1 đến 16, đặc biệt medallion (chương 12), chất lượng dữ liệu (chương 13), quan sát (chương 14), CI/CD (chương 15) và Power BI (chương 16).
Mô hình tư duy 1: dự án là bằng chứng của quyết định, không phải của công cụ
Bạn đã dùng hơn mười công cụ qua các chương trước. Dự án cuối khóa không kiểm tra bạn biết bao nhiêu công cụ, mà kiểm tra bạn chọn, nối và vận hành chúng có lý do ra sao. Một dự án tốt thể hiện:
| Khả năng | Bằng chứng trong repository |
|---|---|
| Thiết kế | Sơ đồ kiến trúc, tài liệu quyết định (ADR) giải thích vì sao chọn và vì sao không chọn phương án khác |
| Tin cậy | Pipeline idempotent, kiểm thử dữ liệu, xử lý lỗi, backfill được |
| Vận hành | CI/CD, hạ tầng dưới dạng mã, quan sát, cảnh báo |
| An toàn | Không bí mật trong mã, che PII, quyền tối thiểu |
| Giao tiếp | README, hướng dẫn chạy, bản demo, báo cáo trả lời câu hỏi nghiệp vụ |
Hai đề tài mẫu và đề tài tự chọn
Bạn chọn một trong ba hướng, với phạm vi được giảng viên duyệt ở tuần 16.
| Đề tài | Mô tả | Công nghệ gợi ý |
|---|---|---|
| A. Nền tảng bán lẻ (batch) | Thu thập đơn hàng, khách hàng, sản phẩm từ CSV và API giả lập; mô hình sao; báo cáo doanh thu | Airflow, dbt, PostgreSQL hoặc cloud warehouse, Power BI |
| B. Phân tích hành vi (streaming) | Luồng sự kiện click và đặt hàng qua Kafka; xử lý gần thời gian thực; kho lakehouse; bảng điều khiển | Kafka, Spark Structured Streaming, Delta hoặc Iceberg, Power BI hoặc Grafana |
| C. Tự chọn | Dữ liệu thật của bạn (thời tiết, giao thông, thể thao, tài chính cá nhân) | Cần duyệt phạm vi và nguồn dữ liệu hợp pháp |
Dù chọn đề nào, nền tảng cần có đủ sáu tầng: thu thập, lưu trữ, biến đổi, kiểm thử chất lượng, phục vụ (báo cáo), vận hành (CI/CD, IaC, quan sát).
Đang tải sơ đồ…
Cách đọc hình: luồng dữ liệu đi từ nguồn qua thu thập, lưu trữ, biến đổi và kiểm thử, rồi phục vụ báo cáo. Lớp vận hành (mũi tên đứt) bao phủ các tầng: CI/CD cho mã, IaC cho hạ tầng, quan sát cho chất lượng và độ tươi. Thiếu lớp này, dự án chỉ là một tập lệnh chạy một lần.
Mô hình tư duy 2: làm hẹp phạm vi, đào sâu chất lượng
Sai lầm phổ biến nhất là ôm quá nhiều: 10 nguồn dữ liệu, 5 công cụ, nhưng không cái nào hoàn chỉnh. Quy tắc phạm vi cho 3 tuần:
- Một câu hỏi nghiệp vụ trung tâm (ví dụ "doanh thu thuần theo cửa hàng và theo ngày, kèm cảnh báo khi dữ liệu cũ").
- Hai đến ba nguồn dữ liệu có quan hệ với nhau.
- Một đường đi chính chạy trơn tru trước, rồi mới mở rộng.
- Cắt tính năng, không cắt chất lượng: bỏ một nguồn thứ ba tốt hơn bỏ kiểm thử.
Lộ trình ba mốc: tuần 1 là bản "đi xuyên" (walking skeleton) chạy từ nguồn tới báo cáo với dữ liệu mẫu; tuần 2 thêm kiểm thử chất lượng, CI/CD và hạ tầng; tuần 3 thêm quan sát, tài liệu, bản demo và rà soát chi phí.
Mô hình tư duy 3: tài liệu quyết định (ADR) ngắn nhưng có giá trị
Một ADR (Architecture Decision Record) là một trang ngắn ghi: bối cảnh, các phương án, quyết định, hệ quả. Ví dụ:
# ADR-003: Dùng Parquet trên S3 cho tầng silver
Context: silver cần đọc nhanh theo cột, chi phí thấp, nhiều công cụ truy vấn.
Options: (1) PostgreSQL bảng; (2) Parquet trên S3 với Athena; (3) Delta Lake.
Decision: (2) Parquet phân vùng theo ngày. Delta hoãn vì dự án chưa cần MERGE và time travel.
Consequences: không có giao dịch ACID trên nhiều tệp; compaction làm thủ công; ghi lại trong runbook.
Điểm đáng giá không phải là quyết định "đúng" mà là bạn biết rõ đánh đổi. Ba đến năm ADR là đủ cho dự án cuối khóa.
Đang tải sơ đồ…
Cách đọc hình: ba mốc theo thứ tự: bản đi xuyên, rồi độ tin cậy và tự động hóa, rồi quan sát và tài liệu. Mũi tên đứt nhắc rằng nếu trễ hãy cắt phạm vi ở mốc đầu (bớt nguồn dữ liệu) thay vì bỏ kiểm thử hay tài liệu ở mốc sau.
Những hiểu lầm thường gặp
- "Dự án càng nhiều công cụ càng ấn tượng." Người đánh giá nhìn vào sự phù hợp và chất lượng; công cụ thừa chỉ thêm điểm lỗi và câu hỏi khó trả lời.
- "Dùng dữ liệu thật quy mô lớn mới đáng giá." Quy mô không phải mục tiêu; chất lượng thiết kế và khả năng chạy lại mới là mục tiêu. Dữ liệu mẫu nhỏ nhưng đầy đủ các lỗi thực tế (trùng, thiếu, trễ) còn tốt hơn.
- "Làm tính năng trước, kiểm thử và tài liệu sau." Hai thứ này thường bị cắt khi hết giờ; hãy đặt chúng vào mốc, không phải phần "nếu còn thời gian".
- "Tài liệu chỉ để chấm điểm." README tốt là sản phẩm: người khác (và bạn sau 3 tháng) có thể chạy lại.
Tự kiểm tra (có đáp án)
Câu 1. Vì sao nên làm bản "đi xuyên" ở tuần đầu? Đáp án: để sớm có đường đi từ nguồn tới báo cáo, phát hiện vấn đề tích hợp giữa các công cụ khi còn thời gian, và các tuần sau chỉ cải thiện chứ không phải dựng lại.
Câu 2. Nếu trễ tiến độ, nên cắt gì và giữ gì? Đáp án: cắt phạm vi tính năng (bớt nguồn dữ liệu, bớt báo cáo); giữ kiểm thử chất lượng, CI/CD cơ bản, README và bản demo vì chúng là bằng chứng của kỹ năng vận hành.
Câu 3. ADR có giá trị ở điểm nào? Đáp án: ghi lại bối cảnh, phương án và đánh đổi của quyết định, cho người đọc thấy bạn chọn có lý do và biết hệ quả, thay vì chỉ liệt kê công cụ.
Nếu chỉ nhớ 3 điều
- Dự án là bằng chứng của quyết định (thiết kế, tin cậy, vận hành, an toàn, giao tiếp), không phải danh sách công cụ.
- Làm hẹp phạm vi, đào sâu chất lượng: một câu hỏi trung tâm, 2 đến 3 nguồn, đường đi chính chạy trơn tru trước.
- Ba mốc: bản đi xuyên, kiểm thử cùng CI/CD và IaC, rồi quan sát cùng tài liệu và demo; viết ADR cho các quyết định chính.