Fundamentals of Data Engineering sau 4 năm: tấm bản đồ FDE nên mang theo khi đến chỗ khách hàng

“Four years ago yesterday.” Joe Reis mở bài nhìn lại cuốn Fundamentals of Data Engineering bằng đúng một câu như vậy: sách ra ngày 26/7/2022, và bài viết của ông đăng ngày 27/7/2026.

Ông tự hỏi nếu được viết lại thì có viết khác đi không. Câu trả lời ngắn gọn: phần lớn vẫn giữ nguyên, chỉ kèm vài điều kiện.

Trong ngành dữ liệu, công cụ thay đổi nhanh, nên một tác giả vẫn đứng sau khung lý thuyết của mình sau bốn năm là chi tiết đáng để bạn chú ý.

Với người muốn làm FDE, điều đó càng quan trọng. Bạn sẽ không được chọn stack ở chỗ khách hàng. Thứ bạn mang theo được là cách nhìn hệ thống, và cuốn sách của Reis cùng Matt Housley dạy đúng cách nhìn ấy.

Năm giai đoạn, một cách truy lỗi

Lõi của sách là vòng đời dữ liệu gồm năm giai đoạn: Generate, Store, Ingest, Transform, Serve. Nghe thì giống sơ đồ trong slide, nhưng giá trị thật của nó lộ ra khi có thứ gì đó hỏng.

Thử hình dung bạn là FDE tại một chuỗi bán lẻ. Giám đốc vận hành than rằng báo cáo doanh thu sáng nay thấp hơn số thu ngân báo lên. Phản xạ của nhiều developer là mở dashboard, tức giai đoạn Serve, rồi soi câu SQL.

Đi theo vòng đời thì bạn hỏi ngược từ đầu. Hệ thống POS ở cửa hàng (Generate) đồng bộ lúc mấy giờ? Job kéo dữ liệu (Ingest) chạy lúc mấy giờ?

Giả sử POS đồng bộ xong lúc 2 giờ sáng còn job Ingest chạy lúc 1 giờ, thì mọi giao dịch phát sinh sau lần đồng bộ trước sẽ vắng mặt trong báo cáo, dù câu SQL của bạn hoàn toàn đúng.

Lỗi ấy không nằm ở Transform hay Serve, nên sửa SQL không giải quyết được gì. Cách sửa hợp lý là ràng buộc thứ tự: Ingest chỉ chạy khi POS đã báo đồng bộ xong, thay vì chạy theo một giờ cố định.

Năm giai đoạn cho bạn một trình tự để loại trừ, và ở chỗ khách hàng, có trình tự loại trừ là đỡ được hàng giờ đoán mò.

Sáu dòng chảy ngầm mới là phần đáng tiền

Ví dụ trên thật ra là một vấn đề Orchestration, một trong sáu “undercurrents” mà sách mô tả. Chúng không phải giai đoạn mà chạy xuyên qua mọi giai đoạn, và chính Reis gọi đây là phần hữu ích nhất của cuốn sách.

Từ góc nhìn của một FDE, sáu undercurrents đáng tiền vì chúng biến thành bộ câu hỏi dùng được ngay tại chỗ khách hàng. Áp vào chuỗi bán lẻ ở trên, mỗi undercurrent có thể thành một câu hỏi discovery cụ thể:

Undercurrent	Câu hỏi gợi ý cho khách hàng bán lẻ
Security	Dữ liệu POS có số điện thoại khách không, và ai được đọc nó?
Data management	“Doanh thu” có cùng một định nghĩa giữa các phòng ban không?
DataOps	Khi pipeline gãy thì ai được báo, sau bao lâu?
Data architecture	Dữ liệu từ cửa hàng đi qua những hệ thống nào trước khi lên báo cáo?
Orchestration	Job nào phải chạy xong trước job nào, và ai kiểm tra thứ tự đó?
Software engineering	Code pipeline có được review, test và quản lý phiên bản không?

Lời khuyên cho buổi discovery đầu tiên: đừng đi với một danh sách tính năng. Hãy đi với sáu câu hỏi như trên và ghi lại chỗ nào khách hàng ngập ngừng, vì đó thường là nơi dự án sẽ vỡ.

Khi lỗi vắt qua hai cloud

Giờ đẩy ví dụ đi xa thêm một bước. Giả sử chuỗi bán lẻ lưu dữ liệu POS ở một cloud còn dashboard chạy ở cloud khác. Google Cloud gọi kiểu kiến trúc này là multicloud, tức kết hợp ít nhất hai nhà cung cấp public cloud, và một lý do họ nêu là tránh bị trói vào một vendor duy nhất.

Lúc đó lỗi lệch giờ ở trên khó thấy hơn nhiều, vì Ingest và Serve nằm ở hai nơi với hai bộ log.

Chỗ cần kiểm tra đầu tiên là điểm dữ liệu rời cloud này sang cloud kia, với ba câu hỏi: job chuyển dữ liệu chạy lúc mấy giờ so với lúc nguồn ghi xong, hai bên có ghi thời gian theo cùng múi giờ không, và nếu lần chuyển thất bại thì ai, ở phía cloud nào, nhận cảnh báo.

Nếu có người đề xuất dời job chuyển dữ liệu ấy sang serverless cho gọn, nhớ rằng Corey Quinn từng viết lời hứa của serverless đáng tiếc vẫn chưa thành hiện thực. Trước khi gật đầu, hãy hỏi nó có giải quyết đúng chuyện thứ tự chạy và cảnh báo ở ranh giới này không.

Về AI/ML, Reis còn do dự việc thêm nó làm undercurrent thứ bảy, nhưng khẳng định AI/ML sẽ hiện diện đậm nét trong data engineering dù thế nào đi nữa. Với FDE đang triển khai agent hay mô hình cho khách hàng, đó là lời nhắc rằng chất lượng đầu ra vẫn phụ thuộc vào năm giai đoạn phía trước.

Ai nên đọc, và đọc theo thứ tự nào

Johnny Winter, viết trên Greyskull Analytics, khuyên bất kỳ ai làm trong mảng dữ liệu, không riêng data engineer, nên có một cuốn. Với developer backend hay full-stack đang nhắm tới FDE, đây là cuốn nên đọc trước các tài liệu hướng dẫn công cụ cụ thể.

Winter cũng chỉ ra điểm yếu: một số phần về lưu trữ đi hơi sâu vào chi tiết. Vì thế, nên đọc kỹ phần vòng đời và phần undercurrents trước, áp ngay vào một pipeline bạn đang làm, rồi mới quay lại các đoạn lưu trữ khi dự án thực sự cần.

Khi viết CV, hãy mượn ngôn ngữ của sách. Thay vì “tối ưu ETL”, hãy viết bạn đã tìm ra lỗi ở giai đoạn Ingest khiến báo cáo ở giai đoạn Serve sai lệch, và bạn sửa bằng cách nào. Khi đọc JD, để ý các cụm như “data pipeline end-to-end” hay “work with customer data infrastructure”: đó là những vị trí cần đúng cách tư duy này.

Công cụ sẽ còn đổi nhiều lần nữa. Một khung tư duy mà chính tác giả vẫn muốn giữ sau bốn năm là thứ đáng mang theo vào mọi dự án dữ liệu bạn nhận tiếp theo.