Truy nguyên gốc lỗi (root cause): số sai đến từ đâu

Có một câu hỏi xuất hiện trong gần như mọi tổ chức dùng dữ liệu: “con số này trên báo cáo sai rồi — nó tính từ đâu ra?”. Và thường thì không ai trả lời nhanh được, vì dữ liệu đã đi qua chục bước xử lý ở nhiều hệ thống trước khi lên dashboard. Người ta đành mở từng truy vấn, từng bảng, dò tay ngược dòng — mất hàng giờ, đôi khi hàng ngày. Truy nguyên gốc lỗi (root cause analysis) dùng nguồn gốc dữ liệu (data lineage) để rút ngắn việc đó: lần ngược lên thượng nguồn (upstream) từ con số sai, đi tới đúng bước biến đổi hay nguồn đã gây lỗi.

Truy nguyên gốc lỗi là gì

Truy nguyên gốc lỗi = bắt đầu từ một kết quả sai ở hạ nguồn (một con số lệch trên báo cáo, một ô trống đáng lẽ phải có dữ liệu) rồi đi ngược về phía thượng nguồn theo dòng chảy lineage, qua từng bước biến đổi, cho tới khi tìm ra nơi lỗi thật sự phát sinh.

Nhắc lại cách đọc đồ thị lineage: với một node (tài sản dữ liệu), thượng nguồn (upstream) là dữ liệu đến từ đâu, hạ nguồn (downstream) là dữ liệu chảy đi đâu. Truy nguyên gốc lỗi chính là đi về phía thượng nguồn:

Bắt đầu ở cột/báo cáo đang cho ra con số sai.
Lần ngược các edge (dòng chảy/biến đổi) lên trên.
Kiểm tra từng bước: bảng trung gian, phép nối (join), phép tính, bộ lọc, cho tới bảng nguồn.
Dừng lại ở mắt xích đầu tiên mà dữ liệu đã sai — đó là gốc lỗi.

Đây là mặt đối xứng của phân tích tác động:

Phân tích tác động (impact analysis) nhìn hạ nguồn, hỏi “đổi cái này thì cái gì hỏng?” — dùng trước khi thay đổi.
Truy nguyên gốc lỗi nhìn thượng nguồn, hỏi “số sai này từ đâu ra?” — dùng sau khi lỗi xuất hiện.

Cùng một đồ thị lineage, chỉ khác hướng lần theo.

Vì sao lineage truy lỗi nhanh hơn nhiều so với dò tay

Cách làm thủ công thường là: người phân tích mở truy vấn của dashboard, đọc xem nó lấy từ bảng nào, rồi mở truy vấn tạo ra bảng đó, rồi lại mở tiếp… Mỗi lần “nhảy” một bước là một lần phải đọc hiểu SQL, đoán phép biến đổi, hỏi người khác. Qua chục bước và nhiều hệ thống, công sức tăng theo cấp số nhân, và rất dễ bỏ sót đúng nhánh chứa lỗi.

Lineage thay đổi cuộc chơi vì nó đã dựng sẵn cả bản đồ:

Đường đi hiện ngay: toàn bộ chuỗi từ báo cáo về nguồn trải ra trên một đồ thị, không phải tự ghép lại trong đầu.
Thu hẹp vùng nghi ngờ: thay vì soi cả hệ thống, bạn chỉ cần đi theo đúng các nhánh thượng nguồn của cột bị sai.
Tới cấp cột: với lineage cấp cột (column-level), bạn lần đúng từng cột — biết con số sai được tạo từ những cột nguồn nào, qua phép tính nào, nên khoanh vùng cực nhanh.
Không phụ thuộc trí nhớ một người: bản đồ nằm trong hệ thống, ai cũng đọc được, kể cả khi người viết ETL ban đầu đã nghỉ việc.

Kết quả: việc truy lỗi rút từ hàng giờ dò tay xuống vài bước đi theo đồ thị.

Kết hợp với chất lượng dữ liệu: lỗi lan theo dòng

Truy nguyên gốc lỗi mạnh nhất khi đi cùng chất lượng dữ liệu (data quality), vì một sự thật quan trọng: lỗi lan theo lineage. Một bản ghi sai ở bảng nguồn không nằm yên — nó chảy xuôi qua mọi bảng trung gian, mọi phép tính, mọi báo cáo ở hạ nguồn. Một giá trị bẩn ở đầu nguồn có thể làm lệch hàng chục con số phía dưới.

Hai hướng bổ trợ nhau:

Lineage chỉ đường truy ngược: từ chỗ lỗi hiện ra (báo cáo), lần lên chỗ lỗi phát sinh (nguồn hoặc bước biến đổi).
Chất lượng dữ liệu chỉ ra chỗ sai: các luật chất lượng (DQ rules) chấm điểm, gắn cờ bản ghi vi phạm ở từng tài sản, cho biết mắt xích nào đang vi phạm.

Ghép lại: khi một báo cáo sai, bạn đi ngược theo lineage và kiểm tra điểm chất lượng ở mỗi node trên đường đi — mắt xích đầu tiên có dữ liệu vi phạm thường chính là gốc lỗi. Nhờ vậy bạn không chỉ tìm ra báo cáo nào sai, mà tìm ra nguồn nào cần sửa để các báo cáo hạ nguồn cùng đúng trở lại.

Ataccama làm thế nào

Ataccama ONE dựng lineage tự động bằng cách quét nguồn và phân tích (parse) câu lệnh SQL, view, script ETL cùng các kế hoạch biến đổi (transformation plan), bổ sung lineage thủ công cho phần không tự đọc được. Để truy nguyên gốc lỗi, người dùng:

Bắt đầu ở tài sản sai (cột, bảng, hoặc báo cáo).
Xem thượng nguồn: đồ thị trải ngược về tận các nguồn, kèm các bước biến đổi giữa đường.
Đối chiếu với chất lượng: vì lineage gắn với catalog và DQ, mỗi tài sản trên đường đi đều có thể xem điểm/luật chất lượng để khoanh vùng mắt xích hỏng.

Vì lineage cập nhật khi quét lại, đường truy lỗi luôn khớp với hệ thống thật — không phải tài liệu vẽ tay đã cũ.

Ví dụ Việt Nam: doanh thu trên dashboard bị lệch

Cuối tháng, dashboard “doanh thu theo vùng” của một doanh nghiệp cho thấy vùng miền Trung tụt bất thường so với thực tế bán hàng. Không ai tin con số, nhưng cũng không ai biết sai ở đâu.

Bắt đầu ở con số sai. Đội dữ liệu mở cột DOANH_THU_VUNG trên dashboard trong Ataccama ONE.
Xem thượng nguồn (upstream). Đồ thị lineage trải ngược: dashboard lấy từ kho phân tích, kho lấy từ bảng trung gian DOANH_THU_NGAY, bảng này được tạo bằng cách nối (join) dữ liệu bán hàng với bảng DANH_MUC_CUA_HANG (ánh xạ mỗi cửa hàng về một vùng).
Đi theo từng mắt xích, đối chiếu chất lượng. Ở mỗi node, đội kiểm tra điểm chất lượng. Tới DANH_MUC_CUA_HANG, luật chất lượng gắn cờ: một số cửa hàng mới mở ở miền Trung chưa được gán vùng (cột vùng bị trống) — bảng này thiếu cập nhật.
Xác định gốc lỗi. Vì các cửa hàng đó không có vùng, doanh số của chúng rơi ra ngoài khi tổng hợp theo vùng — khiến miền Trung bị thiếu. Gốc lỗi không nằm ở dashboard hay phép tính, mà ở bảng nguồn danh mục cửa hàng chưa được cập nhật.
Sửa tại gốc. Cập nhật vùng cho các cửa hàng mới ở bảng nguồn. Nhờ lỗi (và phần sửa) lan theo dòng, mọi báo cáo hạ nguồn dùng cùng bảng đó cũng tự đúng trở lại sau lần chạy kế tiếp.

Không có lineage, đội dữ liệu sẽ phải mở từng truy vấn của dashboard, dò ngược qua kho và các bảng trung gian bằng tay, dễ mất cả ngày và vẫn có thể đổ lỗi nhầm cho “công thức dashboard”. Với lineage cộng chất lượng dữ liệu, họ đi đúng đường về nguồn và tìm ra gốc lỗi trong vài bước.

Lỗi hay gặp

Sửa ở chỗ lỗi hiện ra, không sửa ở gốc: vá con số ngay trên báo cáo mà bỏ qua nguồn — hôm sau lỗi quay lại, và mọi báo cáo khác dùng chung nguồn vẫn sai.
Bỏ qua chất lượng dữ liệu khi truy ngược: lineage chỉ đường, nhưng luật chất lượng mới chỉ mắt xích vi phạm — thiếu nó thì vẫn phải đoán.
Quên các nhánh thượng nguồn phụ: một con số thường được nối từ nhiều nguồn; đừng dừng ở nhánh đầu tiên, hãy soi hết các nhánh đổ vào.
Lineage cũ: nếu lâu không quét lại, đường truy lỗi có thể lệch với hệ thống thật — hãy giữ lineage cập nhật.

Đọc đồ thị lineage: thượng nguồn và hạ nguồn Nắm vững hướng đi của dòng chảy — nền tảng để lần ngược tìm gốc lỗi cho đúng.

Đánh giá mẫu lỗi (data quality) Cách phát hiện và đọc các mẫu lỗi ở từng tài sản — mảnh ghép giúp khoanh đúng mắt xích hỏng.

Phân tích tác động (impact analysis) Mặt còn lại của tấm huy chương: nhìn hạ nguồn để biết trước cái gì sẽ ảnh hưởng.