Đọc đồ thị lineage: thượng nguồn, hạ nguồn và cách lần theo dòng

Khi Ataccama đã dựng xong nguồn gốc dữ liệu (data lineage), bạn nhận được một đồ thị (graph): các ô đại diện cho bảng và cột, nối với nhau bằng mũi tên thể hiện dòng chảy dữ liệu. Nhìn lần đầu, một đồ thị lớn có thể rối như sơ đồ tàu điện ngầm. Nhưng thực ra chỉ cần nắm vài khái niệm và hai hướng đọc là đủ để dùng nó cho việc thật: truy một con số sai về tận gốc, hoặc biết trước “đổi cái này thì cái gì hỏng”. Trang này hướng dẫn cách đọc tấm bản đồ đó cho người mới.

Hai thành phần của đồ thị: node và edge

Mọi đồ thị lineage chỉ gồm hai loại thứ:

Node (nút) = một tài sản dữ liệu: một bảng, một view, một cột, một file, hoặc một bước biến đổi. Đây là các “ô” trên bản đồ.
Edge (cạnh, mũi tên) = dòng chảy hoặc phép biến đổi nối hai node: dữ liệu đi từ node này tới node kia, có thể qua một phép tính ở giữa.

Quy ước hướng rất quan trọng: mũi tên chỉ theo chiều dữ liệu chảy, từ nguồn tới đích. Đọc đồ thị thực chất là đi theo các mũi tên — ngược chiều hay xuôi chiều, tùy bạn đang hỏi câu gì.

Thượng nguồn và hạ nguồn

Đứng ở một node bất kỳ (ví dụ cột doanh_thu trên một dashboard), có hai phía:

Thượng nguồn (upstream) — dữ liệu đến từ đâu

Thượng nguồn là tất cả những gì nằm trước node đang xét, tức nguồn cấp dữ liệu cho nó. Đi ngược các mũi tên về phía thượng nguồn để trả lời câu hỏi “con số này từ đâu ra?”. Cứ như đi ngược dòng sông tìm về đầu nguồn: cột dashboard ← view tổng hợp ← bảng trung gian ← bảng giao dịch gốc ở hệ thống nguồn.

Hạ nguồn (downstream) — dữ liệu chảy đi đâu

Hạ nguồn là tất cả những gì nằm sau node, tức những thứ phụ thuộc vào nó. Đi xuôi theo mũi tên về phía hạ nguồn để trả lời “nếu cái này thay đổi thì ảnh hưởng tới đâu?”. Từ một bảng nguồn, hạ nguồn có thể là nhiều bảng trung gian, vài view, và một loạt dashboard cùng báo cáo.

Mẹo ghi nhớ: thượng nguồn = quá khứ của dữ liệu (nó đã đi qua những đâu để tới đây); hạ nguồn = tương lai của dữ liệu (nó sẽ còn chảy tới những đâu).

Hai hướng đọc cho hai việc khác nhau

Cùng một đồ thị, nhưng tùy mục đích bạn đọc theo hai chiều ngược nhau.

Lần ngược (về thượng nguồn) để truy lỗi

Khi một con số trông sai, bạn bắt đầu từ chỗ phát hiện ra (thường là cột trên báo cáo) rồi lần ngược về thượng nguồn, qua từng bước biến đổi, cho tới khi tìm ra mắt xích đầu tiên bị hỏng — một câu SQL ghép sai, một bảng nguồn thiếu dữ liệu, một phép tính nhầm. Đây là truy nguyên gốc lỗi (root cause): thay vì đoán mò khắp nơi, bạn đi theo đúng đường mà dữ liệu đã đi.

Lần xuôi (xuống hạ nguồn) để xem ảnh hưởng

Khi bạn sắp thay đổi một thứ ở nguồn — đổi tên cột, đổi kiểu dữ liệu, bỏ một bảng — bạn bắt đầu từ node đó và lần xuôi xuống hạ nguồn để liệt kê mọi thứ sẽ bị động tới. Đây là phân tích tác động (impact analysis): biết trước báo cáo nào, dashboard nào, luồng nào sẽ hỏng, để báo cho đúng người và sửa trước khi gây sự cố.

Cùng một mũi tên, đọc ngược là “đến từ đâu”, đọc xuôi là “đi tới đâu” — chính sự đối xứng này khiến lineage hữu dụng cho cả hai bài toán quan trọng nhất.

Mẹo đọc một đồ thị lớn

Đồ thị lineage thật của một doanh nghiệp có thể hàng nghìn node. Vài cách để không bị ngợp:

Bắt đầu từ một node, đừng nhìn cả bản đồ. Chọn đúng cột/bảng đang quan tâm rồi mở rộng dần ra hai phía, thay vì cố đọc toàn cảnh.
Mở rộng từng cấp một. Xem thượng nguồn (hoặc hạ nguồn) một bước, hiểu xong mới đi tiếp một bước nữa — thay vì bung hết mọi nhánh cùng lúc.
Chuyển giữa cấp bảng và cấp cột. Nhìn ở cấp bảng để thấy bức tranh tổng thể; khi cần soi một phép tính cụ thể thì hạ xuống cấp cột (column-level).
Dùng tìm kiếm và lọc. Tìm thẳng tên tài sản cần xét, hoặc lọc theo hệ thống/loại, để cô lập phần đồ thị liên quan.
Đọc nhãn trên mũi tên. Một edge không chỉ nói “có nối”, nó còn có thể cho biết phép biến đổi gì xảy ra ở đó (ghép, tính, lọc) — đây là chỗ ẩn nhiều câu trả lời.
Phân biệt phần tự động và phần khai báo tay. Đoạn lineage do máy parse từ SQL thường đáng tin tới từng cột; đoạn custom lineage nối tay chỉ chính xác bằng những gì người ta đã khai báo — nên cẩn trọng hơn ở đó.

Ví dụ Việt Nam: lần từ cột dashboard ngược về nguồn

Một ngân hàng có dashboard “dư nợ theo chi nhánh”. Phòng kinh doanh báo: con số dư nợ của một chi nhánh cao bất thường. Đội dữ liệu mở đồ thị lineage và bắt đầu lần ngược về thượng nguồn từ chính cột du_no trên dashboard:

Cột du_no (dashboard) ← đến từ một view tổng hợp theo chi nhánh.
View đó ← đọc từ bảng trung gian du_no_ngay, được nạp bằng một job SQL chạy đêm.
Đọc nhãn trên edge ở bước này, họ thấy job SQL cộng gộp dư nợ từ hai bảng: khoản vay cá nhân và khoản vay doanh nghiệp.
Lần thêm một cấp lên thượng nguồn, hóa ra bảng khoản vay doanh nghiệp bị nạp trùng một lô dữ liệu trong ngày — đó là gốc của con số phình lên.

Chỉ trong vài bước đi ngược mũi tên, đội dữ liệu đã chỉ đúng mắt xích hỏng thay vì dò khắp hệ thống. Sau khi sửa, họ lần xuôi xuống hạ nguồn từ bảng đó để kiểm tra: ngoài dashboard “dư nợ theo chi nhánh”, còn báo cáo nào khác cũng đọc từ bảng này và cần chạy lại — đảm bảo không sót chỗ nào bị ảnh hưởng.

Đọc xuôi để đánh giá rủi ro trước khi thay đổi: Phân tích tác động (impact analysis).
Đọc ngược để tìm gốc của số liệu sai: Truy nguyên gốc lỗi (root cause).
Soi tới từng phép tính trong từng cột: Lineage cấp cột (column-level).