Data Engineer làm gì trong tổ chức dữ liệu?

Sáng thứ Hai, 8:30. CEO của GDev Mart, một chuỗi bán lẻ có 40 cửa hàng, mở dashboard doanh thu tuần trước và thấy con số 1,35 tỷ đồng. Mười phút sau, kế toán trưởng gửi báo cáo chốt sổ: 1,20 tỷ đồng. Hai con số cho cùng một tuần, chênh nhau 150 triệu. Không ai biết con số nào đúng, và cuộc họp 9:00 bị hoãn để "tìm hiểu".

Đây là loại sự cố mà Data Engineer (DE) tồn tại để ngăn chặn. Trước khi đọc tiếp, hãy tự trả lời bằng cách viết ra giấy: theo bạn, 150 triệu chênh lệch có thể đến từ những nguyên nhân nào? Hãy đưa ra ít nhất hai giả thuyết, vì ở phần sau ta sẽ đối chiếu với số liệu thật.

Sau bài này, bạn có thể

• Giải thích vì sao hai con số doanh thu của GDev Mart lệch nhau 150 triệu, bằng số dòng trùng và số đơn hủy.
• Phân biệt Data Engineer, Analytics Engineer, Data Analyst và Data Scientist theo sản phẩm đầu ra.
• Nêu ba câu hỏi về độ tin cậy (đúng, kịp, truy vết được) mà một pipeline phải trả lời mỗi sáng.

Cần biết trước: không cần bài nào trước đó; chỉ cần đọc được câu lệnh SELECT COUNT(*) và COUNT(DISTINCT ...) ở mức cơ bản.

Bằng chứng: điều gì nằm trong bảng đơn hàng?

Một kỹ sư dữ liệu mở bảng orders mà dashboard đọc và chạy ba câu truy vấn đếm:

SELECT COUNT(*) AS total_rows FROM orders WHERE week = '2026-W40';
SELECT COUNT(DISTINCT order_id) AS distinct_orders FROM orders WHERE week = '2026-W40';
SELECT COUNT(DISTINCT order_id) AS cancelled FROM orders WHERE week = '2026-W40' AND status = 'cancelled';

Hãy tự tính trước khi xem lời giải ở mục kế tiếp: bao nhiêu đơn thực sự hợp lệ, và giá trị trung bình mỗi đơn là bao nhiêu nếu kế toán chốt 1,20 tỷ?

Giải đáp: bóc từng lớp chênh lệch

Từ bảng đếm ta suy ra:

• Đơn trùng: 11.250 − 10.550 = 700 dòng bị nạp lặp. Nguyên nhân thường gặp là API nguồn bị timeout, job nạp dữ liệu tự thử lại và ghi thêm lần nữa vì không có cơ chế chống trùng.
• Đơn hủy: 550 đơn có status = 'cancelled' nhưng vẫn bị cộng vào doanh thu.
• Đơn hợp lệ: 10.550 − 550 = 10.000 đơn. Với 1,20 tỷ, giá trị trung bình là 120.000 đồng mỗi đơn.

Kiểm tra lại chênh lệch: (700 + 550) × 120.000 = 150 triệu đồng, đúng bằng khoảng cách giữa hai con số. Hãy lưu ý đây mới là phép kiểm tra nhất quán: 120.000 đồng là giá trị trung bình rút ra từ chính 1,20 tỷ chia cho 10.000 đơn, và 1,35 tỷ chia cho 11.250 dòng cũng ra đúng 120.000, nên phép nhân gần như chắc chắn khớp. Muốn chứng minh thật, bạn phải cộng amount của đúng 700 dòng trùng và 550 đơn hủy (ví dụ SUM(amount) theo từng nhóm) và so với 150 triệu. Không có phép màu nào ở đây: dashboard "sai" vì dữ liệu đi vào nó không được kiểm soát, không phải vì ai đó tính toán sai.

Nếu giả thuyết của bạn là múi giờ hoặc dữ liệu đến muộn, đó cũng là những nguyên nhân hoàn toàn có thật trong thực tế; chúng chỉ không xuất hiện ở số liệu này. Chính việc chứng minh nguyên nhân bằng số đếm, thay vì đoán, là kỹ năng đầu tiên của một DE.

Mô hình tư duy 1: DE xây "đường ống" biến dữ liệu thô thành dữ liệu đáng tin

Nếu coi dữ liệu như nước, thì hệ thống nguồn (ứng dụng bán hàng, máy POS, website) là các con suối đục và không đều. Người dùng cuối, từ CEO đến analyst, cần nước sạch ở vòi. Công việc của DE là thiết kế, xây dựng và vận hành đường ống: lấy nước từ nhiều nguồn, lọc, kiểm tra chất lượng, dự trữ và đưa tới đúng vòi vào đúng lúc.

Cách đọc hình: mũi tên đi từ trên xuống. Ba nguồn bên trên có định dạng và tần suất khác nhau; DE là người đứng ở giữa để mọi người dùng bên dưới đọc cùng một nguồn sự thật. Khi hai con số lệch nhau như ở GDev Mart, lỗi gần như luôn nằm ở khối giữa, không phải ở người dùng cuối.

Mô hình tư duy 2: phân biệt vai trò theo "ai tiêu thụ cái gì"

Các vai trò dữ liệu hay bị nhầm vì tên gọi gần nhau. Cách phân biệt dễ nhớ nhất là nhìn vào sản phẩm đầu ra của từng vai trò.

Ranh giới giữa các vai trò mờ đi tùy công ty. Ở công ty nhỏ, một người có thể làm cả DE lẫn Analytics Engineer. Điều không đổi là phụ thuộc: analyst và scientist chỉ làm tốt khi dữ liệu họ nhận đáng tin, nên DE là nền móng của cả đội.

Mô hình tư duy 3: DE được đo bằng độ tin cậy, không phải bằng số dòng code

Một pipeline "chạy được" chưa đủ. Với GDev Mart, pipeline đáng tin phải trả lời được ba câu hỏi mỗi sáng:

1. Đúng không? Có trùng, thiếu, sai định dạng không?
2. Kịp không? Dữ liệu của hôm qua đã sẵn sàng trước 8:00 chưa?
3. Có truy vết được không? Khi con số lệch, ta lần ngược được tới nguồn nào, bước nào?

Đây là lý do khóa học này không chỉ dạy viết code biến đổi. Các tuần sau sẽ dạy cách làm pipeline idempotent (chạy lại không gây trùng), có kiểm thử chất lượng, có giám sát và triển khai tự động.

Những hiểu lầm thường gặp

• "DE chỉ là người viết ETL." ETL chỉ là một phần. Thiết kế mô hình dữ liệu, vận hành, chi phí, bảo mật và chất lượng chiếm phần lớn thời gian của DE giỏi.
• "DE là quản trị cơ sở dữ liệu (DBA)." DBA tập trung vận hành một hệ quản trị; DE tập trung vào luồng dữ liệu xuyên nhiều hệ thống.
• "Cứ có công cụ mới nhất là xong." Công cụ thay đổi theo từng năm, nguyên lý (idempotent, mô hình dimensional, độ trễ, chi phí) thì bền hơn nhiều. Khóa học dạy nguyên lý trước, công cụ sau.

Tự kiểm tra (có đáp án)

Câu 1. Vì sao dashboard của GDev Mart cao hơn số của kế toán, và cần ít nhất những phép đếm nào để chứng minh? Đáp án: vì có 700 dòng trùng và 550 đơn hủy vẫn được cộng. Cần COUNT(*), COUNT(DISTINCT order_id) và đếm đơn có status = 'cancelled'; sau đó đối chiếu lại bằng phép nhân với giá trị trung bình đơn.

Câu 2. Một analyst phàn nàn "doanh thu của tôi khác của bạn kia". Đây thường là việc của vai trò nào xử lý nhất? Đáp án: Analytics Engineer hoặc DE, vì cốt lõi là định nghĩa metric chưa thống nhất, được giải quyết ở tầng mô hình dữ liệu chứ không phải ở từng dashboard.

Câu 3. Vì sao "pipeline chạy xong không báo lỗi" chưa chứng minh dữ liệu đúng? Đáp án: vì một job có thể thành công về mặt kỹ thuật nhưng vẫn ghi dữ liệu trùng hoặc thiếu (như trường hợp 700 dòng lặp). Độ tin cậy phải được kiểm tra bằng kiểm thử dữ liệu, không chỉ bằng mã thoát của job.

Nếu chỉ nhớ 3 điều

1. DE xây và vận hành đường ống đưa dữ liệu thô thành dữ liệu đáng tin cho mọi người dùng.
2. Phân biệt vai trò bằng sản phẩm đầu ra; analyst và scientist phụ thuộc vào chất lượng công việc của DE.
3. Khi hai con số lệch, đừng đoán: đếm, đối chiếu và chứng minh nguyên nhân bằng dữ liệu.