Vòng đời dữ liệu năm chặng: FDE cần hiểu data engineering đến đâu

Thử hình dung tuần thứ hai ở site khách hàng, một công ty giao hàng. Agent bạn dựng khẳng định chi nhánh Đà Nẵng không có đơn trễ nào trong tháng 9. Quản lý vận hành nhìn màn hình và nói ngay: sai, tuần trước họ vừa bị khiếu nại vì giao trễ.

Phản xạ đầu tiên của nhiều kỹ sư là sửa prompt hoặc đổi model. Nhưng con số sai đó có thể đã sai từ trước khi model đọc được nó. Nó đi qua một chuỗi hệ thống, và mỗi chặng đều có thể làm rơi dữ liệu.

Việc cần làm lúc này là lần ngược chuỗi đó. Kỹ năng ấy không biến bạn thành data engineer, nhưng nó là ranh giới giữa FDE đứng đoán mò trước mặt khách hàng và FDE nói được “lỗi nằm ở đây, sửa trong hôm nay”.

Data engineering là gì, và FDE đứng ở đâu?

IBM định nghĩa data engineering là việc thiết kế và xây dựng hệ thống để gom, lưu trữ và phân tích dữ liệu ở quy mô lớn. Data engineer, theo IBM, là những kỹ sư phần mềm xây và vận hành hạ tầng dữ liệu của doanh nghiệp.

FDE Academy coi data engineering là phần trung tâm trong công việc FDE, nhưng chỉ ra khác biệt then chốt: data engineer thường làm việc nội bộ, còn FDE làm việc trực tiếp với khách hàng. Cũng theo họ, tư duy debug của data engineer mang sang được, nhưng độ rộng về các loại hệ thống phải mở thêm.

Trên thực tế, data engineer quen sâu một stack mà chính đội mình dựng. FDE thì mỗi khách hàng gặp một stack khác, do người khác dựng, và phải hiểu nó đủ nhanh để không làm chậm deployment.

Năm chặng, mỗi chặng một câu hỏi

Cuốn Fundamentals of Data Engineering, theo bài review của Johnny Winter, chia vòng đời dữ liệu thành năm chặng: generation, storage, ingestion, transformation và serving. Năm chặng này cũng chính là tấm bản đồ để bạn lần ngược lỗi.

Vì storage là nền của mọi chặng khác, bảng dưới đây không xếp theo thứ tự trong sách mà theo đường dữ liệu chạy thật khi bạn debug: generation, ingestion, storage, transformation, serving.

Generation là chuyện của hệ thống nguồn: ERP, app di động, phần mềm kho. Đây là nơi FDE chạm vào dữ liệu khách hàng đầu tiên, và hầu như luôn do người khác sở hữu.

Ingestion, như IBM mô tả, là đưa dữ liệu từ nhiều nguồn về một hệ sinh thái chung; ETL pipeline tự động hóa việc lấy dữ liệu ra, chuẩn hóa định dạng rồi nạp vào database.

Storage là phần cứng và phần mềm ghi, tổ chức và bảo vệ dữ liệu, theo IBM, gồm ba loại file, block và object. Transformation dựa nặng vào SQL, còn serving là lúc dữ liệu tới tay người dùng: dashboard, API, hay agent của bạn.

Chặng	Câu FDE nên hỏi ở site
Generation	Hệ thống nào tạo ra dữ liệu này, ai sở hữu, gần đây có đổi gì không?
Ingestion	Dữ liệu về bằng cách nào, bao lâu một lần, lần chạy cuối có thành công?
Storage	Dữ liệu nằm ở đâu: bảng trong database, file export hay object storage?
Transformation	Câu SQL hay job nào biến dữ liệu thô thành con số đang hiển thị?
Serving	Người dùng hoặc agent đọc từ bảng, view hay API nào?

Lần ngược con số “không có đơn trễ”

Quay lại chi nhánh Đà Nẵng. Bạn bắt đầu từ chặng cuối, serving: agent đang đọc từ một view tên late_orders_by_branch. Mở định nghĩa view ra, bạn thấy nó join bảng orders với bảng branches qua branch_code, rồi lọc đơn có delivered_at > promised_at.

Hai nghi phạm hiện ra ngay. Một là phép join làm rơi đơn nếu mã chi nhánh không khớp. Hai là đơn chưa giao xong có delivered_at rỗng, và phép so sánh với giá trị rỗng sẽ loại chúng khỏi kết quả, dù đó chính là những đơn trễ nặng nhất.

Câu kiểm tra đầu tiên nhắm vào nghi phạm thứ nhất:

SELECT o.branch_code,
       COUNT(*)              AS so_don,
       COUNT(b.branch_code)  AS so_don_khop_chi_nhanh
FROM orders o
LEFT JOIN branches b ON o.branch_code = b.branch_code
WHERE o.created_at >= '2026-09-01'
GROUP BY o.branch_code
ORDER BY so_don DESC;

Giả sử kết quả cho thấy một mã lạ xuất hiện với vài trăm đơn mà cột khớp bằng 0. Đó là dấu hiệu hệ thống nguồn đã đổi cách ghi mã chi nhánh, còn bảng branches vẫn giữ mã cũ. Lỗi không nằm ở agent, cũng không nằm ở SQL của view, mà ở chặng generation.

Trước khi kết luận, bạn loại trừ chặng ingestion bằng cách đếm số dòng theo ngày nạp, để chắc rằng job export đêm qua thực sự chạy (giả sử bảng có cột loaded_at):

SELECT CAST(loaded_at AS DATE) AS ngay_nap,
       COUNT(*)                AS so_dong
FROM orders
GROUP BY CAST(loaded_at AS DATE)
ORDER BY ngay_nap DESC;

Câu thứ ba xử lý nghi phạm còn lại: đơn chưa giao mà đã quá hạn cũng phải được tính là trễ, bằng cách so promised_at với thời điểm hiện tại.

SELECT o.branch_code,
       COUNT(*) AS so_don_tre
FROM orders o
WHERE o.created_at >= '2026-09-01'
  AND (
        o.delivered_at > o.promised_at
     OR (o.delivered_at IS NULL AND o.promised_at < CURRENT_TIMESTAMP)
  )
GROUP BY o.branch_code
ORDER BY so_don_tre DESC;

Nếu con số Đà Nẵng ở câu này lớn hơn hẳn con số trong view, bạn có thêm một lỗi thứ hai, lần này ở chặng transformation. Ba câu SQL, chưa tới một giờ, và bạn có câu trả lời cụ thể cho quản lý vận hành kèm tên người cần liên hệ bên đội IT sở hữu ERP.

Sâu đến đâu là đủ?

Simplilearn gọi SQL là kỹ năng nền tảng của data engineer. Với FDE, SQL còn quan trọng hơn, vì đó là ngôn ngữ chung để bạn đọc logic biến đổi của bất kỳ khách hàng nào. Bạn cần viết trôi chảy JOIN, GROUP BY, window function và đọc hiểu một view dài trăm dòng do người khác viết.

Phần bạn không cần làm sâu là tự dựng và vận hành hạ tầng: tối ưu cluster, thiết kế kho dữ liệu cho cả doanh nghiệp. Việc đó thuộc về data engineer của khách hàng. Việc của bạn là nói chuyện được với họ bằng đúng thuật ngữ và chỉ đúng chỗ hỏng.

Cuốn sách còn liệt kê sáu “dòng chảy ngầm” chạy xuyên qua cả vòng đời: security, data management, DataOps, data architecture, orchestration và software engineering. Hãy dùng chúng như checklist khi scoping: ai được xem dữ liệu này, job nào điều phối pipeline, khi pipeline hỏng thì ai được báo.

Làm thế nào khi bạn mới tới site

Ngay tuần đầu, hãy vẽ sơ đồ năm chặng cho đúng luồng dữ liệu mà use case của bạn phụ thuộc, không phải cho cả công ty. Ghi tên người sở hữu cạnh từng chặng, vì ở site khách hàng, biết hỏi ai quan trọng ngang biết hỏi gì.

Tiếp theo, xin quyền đọc ở chặng transformation và serving trước, vì đó là nơi bạn kiểm tra được nhanh nhất. Viết sẵn bộ câu SQL kiểm tra: đếm dòng theo ngày nạp, đếm bản ghi không khớp khóa, đếm giá trị rỗng ở các cột quan trọng. Chạy chúng mỗi lần dữ liệu có vẻ lạ.

Khi tìm thấy lỗi ở chặng của người khác, đừng tự vá ngầm trong code của bạn. Báo lại cho chủ sở hữu kèm câu SQL chứng minh, rồi mới thống nhất cách xử lý tạm thời.

Những lỗi hay gặp

Lỗi phổ biến nhất là coi dữ liệu trong bảng cuối là sự thật, rồi dồn sức sửa phần AI. Lỗi thứ hai là vá dữ liệu bẩn ngay trong code agent, khiến mỗi lần hệ thống nguồn đổi bạn lại phải sửa một chỗ không ai biết.

Lỗi thứ ba ít người để ý: chỉ hiểu một loại storage. Nếu bạn chỉ quen database quan hệ, bạn sẽ lúng túng khi dữ liệu khách hàng nằm thành hàng nghìn file trong object storage. Đó đúng là kiểu “độ rộng hệ thống” mà người chuyển từ data engineer sang FDE phải bù.

Với developer Việt Nam đang nhắm vai trò FDE, khi đọc JD hãy để ý các cụm như “integration”, “data pipeline”, “SQL” đi cùng “customer-facing”. Trong CV, một dòng kể lại việc bạn lần ngược một lỗi từ dashboard về tận hệ thống nguồn sẽ thuyết phục hơn cả danh sách công cụ.

Bài tập trong tuần

Lấy một báo cáo bạn hay dùng ở công ty, chọn một con số trên đó, và lần ngược nó qua đủ năm chặng cho tới hệ thống đã tạo ra nó. Nếu có chặng nào bạn không giải thích được, đó chính là chỗ bạn cần học tiếp.

Model rồi sẽ ngày càng giỏi hơn. Còn dữ liệu của khách hàng thì vẫn sẽ đi qua năm chặng do nhiều người khác nhau sở hữu, và FDE nào đi hết được con đường đó sẽ luôn là người được gọi đầu tiên.