Lineage, Data Quality, Glossary & Governance
Dành cho ai: bạn đã nạp được nguồn dữ liệu đầu tiên (Bài 4) và catalog đã có bảng thật. Bài này là phần tạo ra giá trị thật sự — thứ khiến sếp thấy đáng đầu tư.
Bốn năng lực, đi từ dễ tới khó: Lineage → Data Quality → Glossary → Governance.
Phần 1 — Lineage: biết dữ liệu chảy từ đâu tới đâu
Phần tiêu đề “Phần 1 — Lineage: biết dữ liệu chảy từ đâu tới đâu”1.1. Lineage giải quyết hai câu hỏi đắt giá
Phần tiêu đề “1.1. Lineage giải quyết hai câu hỏi đắt giá”Mọi đội dữ liệu đều gặp hai tình huống này:
- Truy nguyên (root cause): “Báo cáo doanh thu sáng nay sai. Hỏng ở khâu nào?” → nhìn ngược lên nguồn.
- Phân tích tác động (impact analysis): “Tôi sắp đổi cấu trúc bảng
orders. Đổi xong thì hỏng những gì?” → nhìn xuôi xuống các báo cáo phụ thuộc.
Không có lineage, hai câu này tốn hàng giờ hỏi han. Có lineage, chúng là một cú click.
1.2. Column-level lineage — điểm mạnh của OpenMetadata
Phần tiêu đề “1.2. Column-level lineage — điểm mạnh của OpenMetadata”OpenMetadata không chỉ vẽ bảng A → bảng B, mà đi tới từng cột: cột doanh_thu_thuan trên dashboard được tính từ orders.amount trừ discounts.value, qua view nào, phép biến đổi gì.
Ví dụ ngân hàng: một mô hình chấm điểm rủi ro dùng cột
thu_nhap_khach_hang. Column-level lineage cho biết cột đó bắt nguồn từ hệ thống nào, đã qua bước làm sạch nào — thứ mà kiểm toán viên chắc chắn sẽ hỏi.
1.3. OpenMetadata lấy lineage ở đâu ra?
Phần tiêu đề “1.3. OpenMetadata lấy lineage ở đâu ra?”Đây là chỗ người mới hay kỳ vọng sai. Lineage không tự có ngay sau Metadata ingestion. Nó đến từ bốn nguồn:
| Nguồn | Cách hoạt động | Ghi chú |
|---|---|---|
| Query log / Usage | Đọc lịch sử truy vấn của database, phân tích SQL để suy ra quan hệ | Nguồn tự động mạnh nhất; cần bật Usage ingestion |
| View definition | Phân tích câu SQL định nghĩa view | Có ngay khi nạp view |
| dbt | Nạp manifest của dbt | Rất chính xác nếu bạn dùng dbt |
| Thủ công / API | Tự vẽ cạnh lineage trên UI, hoặc đẩy qua API | Dùng cho hệ thống mà OpenMetadata chưa đọc tự động được |
Việc cần làm: sau Bài 4, hãy thêm một Usage ingestion (hoặc Lineage ingestion) trên chính service bạn vừa tạo, rồi mở tab Lineage của một bảng để xem sơ đồ.
⚠️ Kỳ vọng thực tế: lineage hiếm khi đầy đủ 100% ngay. Chỗ nào tự động không bắt được (ví dụ dữ liệu chạy qua script Python rời), bạn bổ sung thủ công. Đừng để “chưa hoàn hảo” ngăn bạn dùng phần đã có.
Phần 2 — Data Quality: phát hiện lỗi trước khi sếp phát hiện
Phần tiêu đề “Phần 2 — Data Quality: phát hiện lỗi trước khi sếp phát hiện”2.1. Profiler — hiểu “sức khỏe” dữ liệu trước đã
Phần tiêu đề “2.1. Profiler — hiểu “sức khỏe” dữ liệu trước đã”Trước khi đặt luật, phải biết hiện trạng. Profiler (đã nhắc ở Bài 4) chạy định kỳ và tính:
- Số dòng, số cột.
- Với mỗi cột: tỷ lệ giá trị rỗng (null), số giá trị duy nhất, min/max/trung bình, độ dài chuỗi…
Nhìn vào đây bạn thường phát hiện ngay điều bất ngờ: “À, cột email rỗng 37%?”
Nhắc lại về bảo mật: Profiler có chạm dữ liệu (lấy mẫu + thống kê). Đây là tùy chọn — xin phép và giới hạn số dòng mẫu trước khi bật trên hệ thống thật.
2.2. Test Case — đặt luật cho dữ liệu
Phần tiêu đề “2.2. Test Case — đặt luật cho dữ liệu”Test case là một luật bạn muốn dữ liệu luôn thỏa mãn. Hai cấp:
Test ở cấp bảng (Table tests):
- Số dòng phải nằm trong khoảng kỳ vọng (ví dụ 1.000–100.000) → bắt được lỗi pipeline nạp thiếu/thừa.
- Danh sách cột phải đúng như mong đợi → bắt được việc ai đó lặng lẽ xóa cột.
Test ở cấp cột (Column tests):
emailkhông được rỗng (not null).revenuephải ≥ 0.order_idphải là duy nhất (unique).trang_thaichỉ được nhận các giá trị trong tập cho phép.- Giá trị phải khớp một biểu thức chính quy (regex), ví dụ định dạng số điện thoại.
2.3. Test Suite & lịch chạy
Phần tiêu đề “2.3. Test Suite & lịch chạy”Gom nhiều test lại thành Test Suite, đặt lịch chạy (ví dụ mỗi sáng sau khi pipeline nạp xong). OpenMetadata lưu lại lịch sử kết quả, nên bạn thấy được xu hướng: “tỷ lệ null của cột này đang tăng dần”.
2.4. Cảnh báo & xử lý sự cố
Phần tiêu đề “2.4. Cảnh báo & xử lý sự cố”- Alerts / Notifications: khi test
Failed, gửi thông báo qua email, Slack, Microsoft Teams, hoặc webhook. - Incident Manager: OpenMetadata cho phép ghi nhận sự cố dữ liệu, gán người xử lý, theo dõi tới khi đóng — giống hệ thống ticket, nhưng gắn thẳng vào tài sản dữ liệu.
Bắt đầu ở đâu? Đừng viết 200 test. Chọn 3–5 bảng quan trọng nhất, mỗi bảng 2–3 test đánh vào lỗi đã từng xảy ra thật. Test mà không ai sửa khi nó đỏ thì tệ hơn không có test.
Ví dụ theo ngành:
| Ngành | Test đáng đặt đầu tiên |
|---|---|
| Bán lẻ | Doanh thu ngày không âm; số đơn hàng hôm nay không bằng 0 |
| Ngân hàng | Số tài khoản là duy nhất; số dư không rỗng |
| Y tế | Mã bệnh nhân duy nhất; ngày sinh không ở tương lai |
| Sản xuất | Giá trị cảm biến nằm trong dải vật lý hợp lệ |
| Xây dựng | Mã dự án tồn tại trong danh mục; ngày kết thúc sau ngày bắt đầu |
Phần 3 — Glossary: để cả công ty nói chung một ngôn ngữ
Phần tiêu đề “Phần 3 — Glossary: để cả công ty nói chung một ngôn ngữ”3.1. Vấn đề
Phần tiêu đề “3.1. Vấn đề”Phòng Kinh doanh nói “doanh thu” là tiền đã ký hợp đồng. Phòng Kế toán nói “doanh thu” là tiền đã ghi nhận. Hai báo cáo lệch nhau, họp cãi nhau cả buổi. Đây không phải lỗi kỹ thuật — đây là lỗi thiếu định nghĩa chung.
3.2. Glossary hoạt động thế nào
Phần tiêu đề “3.2. Glossary hoạt động thế nào”- Glossary là một tập từ điển (ví dụ “Từ điển Tài chính”).
- Trong đó có các Glossary Term (thuật ngữ): Doanh thu thuần, Khách hàng hoạt động, Tỷ lệ hủy đơn…
- Mỗi thuật ngữ có: định nghĩa, từ đồng nghĩa, thuật ngữ liên quan, người phê duyệt, và có thể xếp phân cấp cha–con.
- Quan trọng nhất: gắn thuật ngữ vào tài sản dữ liệu thật (bảng, cột). Từ đó ai mở cột
net_revenuecũng thấy ngay định nghĩa chính thức.
3.3. Quy trình phê duyệt
Phần tiêu đề “3.3. Quy trình phê duyệt”OpenMetadata hỗ trợ workflow duyệt thuật ngữ: người đề xuất → người có thẩm quyền duyệt → thuật ngữ chuyển trạng thái Approved. Điều này biến glossary từ “file Excel không ai tin” thành nguồn định nghĩa có thẩm quyền.
Mẹo: đây thường là tính năng dễ “bán” cho lãnh đạo nghiệp vụ nhất, vì nó giải quyết nỗi đau họ cảm nhận được hằng ngày — mà lại không đòi hỏi kiến thức kỹ thuật.
Phần 4 — Governance: ai chịu trách nhiệm, dữ liệu nào nhạy cảm
Phần tiêu đề “Phần 4 — Governance: ai chịu trách nhiệm, dữ liệu nào nhạy cảm”4.1. Bốn trụ thực tế của quản trị dữ liệu trong OpenMetadata
Phần tiêu đề “4.1. Bốn trụ thực tế của quản trị dữ liệu trong OpenMetadata”a) Ownership (chủ sở hữu) Gán người/team làm chủ mỗi tài sản. Đây là việc đầu tiên nên làm, vì mọi thứ khác đều cần “có người chịu trách nhiệm”.
b) Classification & Tags (phân loại)
- Gắn thẻ PII.Sensitive cho cột chứa CCCD, số điện thoại, email, hồ sơ bệnh án.
- Gắn Tier (mức độ quan trọng: Tier 1 = tối quan trọng) để biết tài sản nào cần chăm sóc kỹ nhất.
- Auto-classification: OpenMetadata tự đề xuất thẻ PII dựa trên tên cột và dữ liệu mẫu — vẫn nên rà bằng mắt.
c) Domain & Data Product
- Domain = mảng nghiệp vụ (Bán hàng, Nhân sự, Vận hành). Chia tài sản theo domain giúp catalog không thành một đống hỗn độn.
- Data Product = một “sản phẩm dữ liệu” được đóng gói để người khác dùng (ví dụ “Bộ dữ liệu Khách hàng 360”). Đây là tư duy data mesh, nhưng bạn không cần theo trọn triết lý mới dùng được.
d) Policies & Roles (chính sách & vai trò)
Quy định ai được xem/sửa gì. Ví dụ: chỉ thành viên nhóm Compliance mới xem được tài sản gắn thẻ PII.Sensitive.
4.2. Đo lường: catalog của bạn “khỏe” tới đâu?
Phần tiêu đề “4.2. Đo lường: catalog của bạn “khỏe” tới đâu?”OpenMetadata có mục Insights / Data Insights cho biết:
- Bao nhiêu % tài sản đã có mô tả?
- Bao nhiêu % đã có chủ sở hữu?
- Tài sản nào được xem nhiều nhất? Ai đóng góp nhiều nhất?
Đây chính là bộ KPI để báo cáo sếp. Ví dụ mục tiêu quý: “80% tài sản Tier 1 có owner và mô tả.” Con số này biến một dự án mơ hồ thành thứ đo đếm được.
5. Nên làm theo thứ tự nào?
Phần tiêu đề “5. Nên làm theo thứ tự nào?”Người mới hay ôm cả bốn cùng lúc rồi đuối. Thứ tự khuyến nghị:
- Ownership + Description (Bài 4) — nền móng, không có thì mọi thứ khác vô nghĩa.
- Tag PII — giá trị tuân thủ, thấy ngay, lãnh đạo dễ hiểu.
- Lineage — bật Usage ingestion, chấp nhận chưa đầy đủ.
- Data Quality — vài test trên vài bảng quan trọng, có người trực khi test đỏ.
- Glossary — cần sự tham gia của bộ phận nghiệp vụ, nên làm khi đã có đà.
- Domain / Policies — khi quy mô đã lớn và cần trật tự.
6. Tổng kết
Phần tiêu đề “6. Tổng kết”- Lineage trả lời “hỏng ở đâu” và “đổi cái này thì hỏng cái gì”; tới cấp cột; nhưng cần bật Usage/dbt và chấp nhận bổ sung thủ công.
- Data Quality = Profiler (hiểu hiện trạng) + Test Case (đặt luật) + Alert/Incident (xử lý). Ít test nhưng có người sửa, hơn nhiều test bị bỏ qua.
- Glossary giải quyết tranh cãi định nghĩa nghiệp vụ, có workflow phê duyệt — thường là tính năng dễ thuyết phục lãnh đạo nhất.
- Governance = Owner + Tag/Tier + Domain + Policy, và Data Insights là bộ KPI để chứng minh tiến độ.
Bước tiếp theo: Bài 6 — triển khai thật theo ngành, kiến trúc production, và lộ trình 90 ngày.
💬 Thảo luận cùng cộng đồng BSD
Phần tiêu đề “💬 Thảo luận cùng cộng đồng BSD”Bạn định đặt test chất lượng đầu tiên cho bảng nào? Lineage của bạn có bị “đứt đoạn” ở khâu nào không (script rời, file Excel)? Glossary bên bạn ai là người duyệt?
👉 Chia sẻ và hỏi tại Forum BSD Insights. Đây là những bài toán ai triển khai cũng gặp — kinh nghiệm của bạn rất đáng giá với người đi sau.
(Bài viết thuộc loạt “Bắt đầu với OpenMetadata” trên tài liệu BSD.)