Quản trị dữ liệu 2 — Data Catalog, Metadata & Lineage

Trong bài tổng quan governance chúng ta đã dựng khung: ai sở hữu dữ liệu, chính sách nào chi phối nó, và làm sao đo được nó đáng tin. Bài này đi vào hai công cụ nền tảng biến khung đó thành hiện thực hằng ngày: data catalog (để người ta tìm và hiểu dữ liệu) và data lineage (để người ta truy vết dữ liệu đến tận nguồn). Cả hai đều dựng trên một khái niệm chung — metadata.

Tình huống kinh điển ở ngân hàng: NHNN yêu cầu giải trình chỉ tiêu "dư nợ nhóm 2" trên báo cáo phân loại nợ. Cán bộ báo cáo mở dashboard, thấy con số 1.842 tỷ, nhưng không ai biết chắc nó được tính từ bảng nào, lọc điều kiện gì, chạy job nào lúc mấy giờ. Không có lineage, việc giải trình biến thành một cuộc điều tra khảo cổ kéo dài vài ngày, hỏi khắp team. Có lineage, nó là một cú click.

Metadata là gì

Metadata là "dữ liệu về dữ liệu" — mọi thông tin mô tả một tài sản dữ liệu mà không phải là bản thân giá trị trong bảng. Người ta thường chia metadata thành ba nhóm:

1. Technical metadata — mô tả cấu trúc kỹ thuật. Tên bảng, tên cột, kiểu dữ liệu, khoá chính/khoá ngoại, schema, phân vùng (partition), định dạng file (Parquet/ORC), vị trí lưu trữ (đường dẫn S3/HDFS), index. Đây là metadata mà một engine hay driver cần để đọc dữ liệu.

2. Business metadata — mô tả ý nghĩa nghiệp vụ. Định nghĩa "dư nợ nhóm 2" là gì, cột dpd nghĩa là "days past due", đơn vị tính là VND hay nghìn VND, ai là data owner, mức độ nhạy cảm (public/internal/confidential/restricted). Đây là cầu nối giữa dữ liệu và người dùng nghiệp vụ.

3. Operational metadata — mô tả quá trình vận hành. Job nào tạo ra bảng, chạy lúc mấy giờ, mất bao lâu, xử lý bao nhiêu dòng, lần refresh gần nhất, tỷ lệ null, số bản ghi thay đổi. Đây là metadata cho monitoring và SLA.

Một catalog tốt gộp cả ba nhóm này về một chỗ để mỗi tài sản dữ liệu có một "hồ sơ" đầy đủ. Để cụ thể hơn, xét bảng dw.fct_loan_balance — hồ sơ metadata thực tế của nó trông như sau:

Hồ sơ này cho một analyst biết ngay: bảng chứa gì (technical), nghĩa là gì và ai chịu trách nhiệm (business), có mới và đáng tin không (operational) — mà không cần hỏi ai.

Data Catalog — khám phá và hiểu dữ liệu

Data catalog là một hệ thống tập trung liệt kê và mô tả toàn bộ tài sản dữ liệu của tổ chức, giống một "mục lục thư viện" cho dữ liệu. Nó giải quyết vấn đề đau đầu nhất của tổ chức lớn: dữ liệu nằm rải rác ở hàng trăm bảng, không ai biết cái gì tồn tại ở đâu.

Chức năng cốt lõi của catalog:

• Search & discovery: tìm bảng theo tên, tag, cột, hoặc mô tả nghiệp vụ. Ví dụ gõ "số dư tài khoản" ra ngay dw.dim_account.
• Profiling: thống kê tự động về dữ liệu (min/max, null rate, cardinality, sample values) để đánh giá nhanh chất lượng.
• Documentation: mô tả bảng/cột do người dùng bổ sung, kèm ví dụ dùng.
• Ownership & stewardship: gắn owner và data steward cho mỗi tài sản.
• Ratings & usage: bảng nào được query nhiều nhất, ai dùng, độ tin cậy.

Business glossary — chuẩn hoá thuật ngữ

Một cấu phần quan trọng của catalog là business glossary: từ điển các thuật ngữ nghiệp vụ chuẩn hoá của tổ chức. Trong ngân hàng, cùng một khái niệm có thể được gọi và tính khác nhau giữa các phòng: "khách hàng active" với phòng thẻ nghĩa là có giao dịch trong 90 ngày, với phòng tín dụng nghĩa là còn dư nợ. Glossary định nghĩa chính thức mỗi thuật ngữ, gán một owner, rồi liên kết thuật ngữ với các cột/bảng vật lý hiện thực hoá nó.

Nhờ vậy, khi một analyst tìm "NPL ratio", catalog chỉ ra định nghĩa chuẩn (nợ nhóm 3-5 / tổng dư nợ) và đúng cột tính ra nó, thay vì mỗi người tự chế một công thức. Đây là nền tảng để "một con số chỉ có một sự thật".

Data Lineage — truy vết dòng chảy dữ liệu

Data lineage là bản đồ mô tả dữ liệu chảy từ đâu đến đâu qua những phép biến đổi nào. Có hai mức:

• Table-level lineage: bảng A + bảng B → (job X) → bảng C. Cho biết bức tranh tổng thể các phụ thuộc giữa dataset.
• Column-level lineage (field-level): cột C.npl_ratio được tính từ A.nhom_no và B.du_no. Chi tiết hơn nhiều, cho phép truy đúng nguồn của từng chỉ tiêu.

Column-level đắt hơn để thu thập nhưng là thứ audit và giải trình NHNN thực sự cần. Table-level thường đủ cho impact analysis ở mức thô.

Vì sao lineage quan trọng

1. Impact analysis — trước khi đổi một bảng nguồn, ta biết ngay bao nhiêu dashboard/báo cáo/mô hình phụ thuộc vào nó. Ví dụ định drop cột cust_segment ở ods.customer, lineage cho thấy nó nuôi 14 bảng hạ nguồn và 3 báo cáo NHNN → không được xoá bừa.

2. Root cause analysis — khi một con số sai, ta ngược dòng lineage tìm bảng/job nào gây lỗi thay vì mò từng bước.

3. Audit & tuân thủ — kiểm toán viên và NHNN yêu cầu chứng minh nguồn gốc mỗi chỉ tiêu báo cáo. Lineage cung cấp bằng chứng có kiểm chứng, không phải "chúng tôi tin là đúng".

4. Trust — người dùng thấy được dữ liệu đến từ đâu thì mới tin để ra quyết định.

Dưới đây là lineage điển hình từ hệ thống nguồn (core banking, LOS) đi qua ODS, DW, tới báo cáo NHNN:

Khi kiểm toán hỏi "chỉ tiêu dư nợ nhóm 2 lấy từ đâu", ta đọc ngược: R1 ← M1.nhom_2_bal ← F1.balance + F1.dpd (phân loại) ← O1 ← core.loan_master. Toàn bộ chuỗi hiện ra kèm điều kiện lọc và job thực thi.

Ví dụ column-level lineage cụ thể

Hãy lần theo một chỉ tiêu thật ở mức cột, ví dụ "dư nợ" (loan balance) dùng cho báo cáo phân loại nợ và làm đầu vào tính hệ số an toàn vốn (CAR). Mỗi bước là một phép biến đổi cột cụ thể:

Column-level lineage lưu chính xác chuỗi phụ thuộc: ô "Dư nợ nhóm 2" ← mart_loan_classification.nhom_2_bal ← fct_loan_balance.balance (lọc theo nhom_no=2, mà nhom_no lại ← fct_loan_balance.dpd) ← ods.loan.balance ← core.loan_master.PRINC_BAL + INT_ACCR. Nhờ đó, khi ô báo cáo sai, ta biết đích danh cột nào ở tầng nào cần kiểm — không phải cả bảng.

Cách thu thập lineage

Lineage không tự có — phải được trích xuất. Bốn cách chính, thường kết hợp:

1. Parse SQL (query log parsing) — cơ chế: catalog kéo query log/audit log của warehouse (các câu INSERT ... SELECT, CREATE TABLE AS, MERGE) rồi chạy một SQL parser dựng cây cú pháp (AST). Từ AST, nó ánh xạ từng cột trong SELECT về các cột nguồn trong FROM/JOIN, suy ra được column-level. Đây là cách phổ biến nhất vì không đòi hỏi đội dev đổi code. Nhược điểm: SQL động sinh bằng string, hàm UDF, logic trong Python/Spark ngoài SQL khó parse chính xác; parser cũng phải hiểu đúng phương ngữ (Postgres/Snowflake/BigQuery khác nhau).

2. Tích hợp dbt — cơ chế: khi chạy dbt docs generate, dbt biên dịch toàn bộ project và xuất manifest.json + catalog.json. manifest.json chứa DAG phụ thuộc dựng từ các hàm ref() và source() trong model — đây là lineage table-level tường minh và sạch vì lấy thẳng từ khai báo của dev, không phải đoán. dbt bản mới còn suy được column-level lineage. Catalog (OpenMetadata, DataHub...) có connector nạp thẳng hai file này. Vì đội data thường đã dùng dbt để transform, đây là nguồn lineage rẻ và đáng tin nhất. Xem thêm dbt tổng quan.

3. Tích hợp Airflow — cơ chế: orchestrator là nơi biết trình tự thực thi. Với khai báo inlets/outlets trên task (hoặc dataset-aware scheduling), Airflow phát ra lineage ở mức job → dataset: task load_fct_loan đọc ods.loan, ghi fct_loan_balance. Bổ trợ tốt cho parse SQL vì nó gắn lineage vào đơn vị vận hành (DAG/task) và mốc thời gian chạy.

4. OpenLineage + Marquez — cơ chế: OpenLineage là chuẩn mở mô tả sự kiện lineage dưới dạng event JSON gồm ba thực thể — job (định nghĩa việc), run (một lần chạy) và dataset (input/output) — kèm các "facet" mở rộng (schema, thống kê, chất lượng). Các integration cho Spark, Airflow, dbt tự động phát event này mỗi lần chạy tới một backend. Marquez là reference backend thu và lưu trữ các event đó, dựng thành đồ thị lineage; DataHub/OpenMetadata cũng nhận được OpenLineage. Vì là chuẩn chung, mọi công cụ nói cùng "ngôn ngữ" → không khoá vào một vendor và ghép được lineage xuyên nhiều hệ thống. Đây là hướng đi bền vững nhất.

Ví dụ minh hoạ (không phải SQL chạy trong sandbox) — một transform mà parser sẽ suy ra column-level lineage:

-- Minh hoạ: parser suy ra mart_loan_classification.nhom_2_bal
--          <- fct_loan_balance.balance (khi dpd 10..90)
INSERT INTO dw.mart_loan_classification
SELECT report_date,
       SUM(CASE WHEN dpd BETWEEN 10 AND 90 THEN balance END) AS nhom_2_bal
FROM dw.fct_loan_balance
GROUP BY report_date;

Để cảm nhận việc lineage lần theo cột, hãy hình dung một truy vấn đọc trên sandbox tổng hợp số dư theo loại tiền — đầu ra phụ thuộc trực tiếp vào cột balance và currency:

-- ▶ Chạy được
SELECT currency, COUNT(*) AS n_acc, SUM(balance) AS tong_du
FROM accounts
GROUP BY currency
ORDER BY tong_du DESC;

Một parser lineage sẽ ghi: output tong_du ← accounts.balance, currency ← accounts.currency. Nhân rộng ý này lên hàng nghìn transform chính là bản đồ lineage của cả kho.

Active vs Passive metadata

Đây là một chuyển dịch tư duy quan trọng của thế hệ catalog hiện đại:

• Passive metadata: catalog thu thập metadata rồi lưu lại thụ động để người ta tra cứu. Nó là một "danh bạ tĩnh" — hữu ích nhưng dễ lỗi thời và không hành động gì.
• Active metadata: metadata được đưa trở lại vào công cụ và quy trình để tự động sinh giá trị. Ví dụ: usage cao → tự đề xuất bảng ưu tiên tối ưu; freshness trễ → tự cảnh báo Slack; một cột bị gắn nhãn PII → tự động lan truyền policy masking xuống mọi bảng hạ nguồn theo lineage. Metadata "chảy" hai chiều và kích hoạt hành động, không chỉ nằm im.

Ngân hàng hưởng lợi rõ ở mảng bảo mật: gắn nhãn PII một lần ở nguồn, active metadata dùng lineage để propagate nhãn và policy xuống toàn bộ chuỗi, giảm rủi ro lộ dữ liệu vì quên gắn nhãn ở bảng trung gian.

So sánh công cụ

Định hướng chung: ngân hàng lớn cần workflow tuân thủ chặt và có ngân sách thường chọn Collibra/Alation; đội data engineering muốn tự chủ, tích hợp dbt/Airflow/OpenLineage và tiết kiệm chi phí thường chọn OpenMetadata hoặc DataHub.

Quy trình vận hành catalog

Catalog không phải dự án "làm một lần rồi thôi" — nó là sản phẩm sống. Quy trình vận hành điển hình:

Vai trò then chốt là data steward — người phụ trách làm giàu và duy trì chất lượng metadata cho một miền dữ liệu (ví dụ steward miền tín dụng). Không có steward, catalog nhanh chóng thành nghĩa địa bảng không mô tả.

Cụ thể hoá quy trình thành các thủ tục vận hành:

Onboarding nguồn dữ liệu: mỗi khi có DB/warehouse/BI mới, quy trình chuẩn gồm: (1) tạo service account chỉ-đọc cho catalog; (2) cấu hình connector và lịch ingest (thường hằng ngày cho metadata, theo phút cho lineage qua OpenLineage); (3) chạy profiling lần đầu; (4) gán owner/steward cho miền; (5) steward duyệt và bổ sung mô tả tối thiểu cho các bảng "vàng" (curated) trước khi công bố cho toàn tổ chức.

Phê duyệt glossary: thuật ngữ nghiệp vụ mới đi qua workflow phê duyệt để tránh "loạn định nghĩa": đề xuất → steward miền rà soát → owner nghiệp vụ (vd trưởng phòng QLRR) phê duyệt → thuật ngữ chuyển trạng thái Approved và được neo vào cột/bảng. Chỉ term đã Approved mới hiển thị là định nghĩa chính thức; các term draft được gắn nhãn rõ để không gây hiểu nhầm.

SLA cập nhật metadata: đặt cam kết rõ ràng, ví dụ — technical metadata & lineage tự động refresh trong vòng 24h sau khi schema đổi; freshness dataset trọng yếu cập nhật mỗi lần chạy; mô tả nghiệp vụ cho bảng mới phải có trong 5 ngày làm việc; term glossary được rà soát lại mỗi 6 tháng.

Đo lường độ phủ (coverage): catalog trưởng thành cần KPI định lượng, không chỉ "đã cài đặt". Các chỉ số thường theo dõi: tỷ lệ bảng có owner (target ≥ 95% cho bảng curated), tỷ lệ bảng/cột có mô tả, tỷ lệ tài sản có lineage đầy đủ tới nguồn, tỷ lệ term glossary đã Approved, và documentation coverage % = số cột có mô tả / tổng số cột. Ví dụ đặt mục tiêu: lớp DW curated đạt 90% documentation coverage và 100% lineage-to-source trong quý; lớp staging chỉ cần technical metadata.

Việc gắn tag phân loại (public/PII/restricted) nối trực tiếp sang phân loại & PII; còn các luật chất lượng gắn vào catalog thuộc về data quality. Xem thêm góc nhìn nền tảng ở governance & quality.

Use case thực tế

Bối cảnh: NCB nhận công văn NHNN yêu cầu giải trình chênh lệch chỉ tiêu "dư nợ nhóm 2" giữa báo cáo tháng 5 (1.842 tỷ) và tháng 4 (1.610 tỷ), hạn trả lời 3 ngày làm việc.

Trước khi có catalog/lineage (quy trình cũ): team phải hỏi từng người, mở từng script, so từng bảng staging. Trung bình mất 2–3 ngày, dễ sót, và không có bằng chứng chuẩn cho kiểm toán.

Sau khi có OpenMetadata + lineage (quy trình mới):

1. Mở tài sản mart_loan_classification, click "Lineage" → thấy chỉ tiêu nhom_2_bal được tính từ fct_loan_balance.balance với điều kiện dpd BETWEEN 10 AND 90. (15 phút)
2. Ngược lên fct_loan_balance → nguồn ods.loan → core.loan_master, kèm job dbt_run_loan_mart chạy 31/05 lúc 02:15. (10 phút)
3. So sánh operational metadata: tháng 5 job xử lý 3.24M dòng vs tháng 4 là 3.05M dòng → tăng thật, không phải lỗi. (10 phút)
4. Truy vào business glossary xác nhận định nghĩa "nhóm 2" đúng chuẩn phân loại nợ, có owner phòng QLRR ký duyệt. (5 phút)
5. Kết luận: chênh lệch do 187 khoản vay mới rơi vào nhóm 2 tháng 5, xuất báo cáo lineage đính kèm công văn. (20 phút)

Kết quả: từ 2–3 ngày xuống còn ~1 giờ, kèm bằng chứng lineage có thể kiểm chứng — đúng thứ kiểm toán viên chấp nhận. Chi phí vận hành catalog được bù lại nhiều lần chỉ trong một tình huống giải trình.

Ghi nhớ

• Metadata có ba nhóm: technical (cấu trúc), business (ý nghĩa + owner), operational (vận hành). Catalog gộp cả ba thành hồ sơ đầy đủ cho mỗi tài sản.
• Data catalog giải bài toán khám phá dữ liệu; business glossary chuẩn hoá thuật ngữ và neo chúng vào cột/bảng vật lý → "một con số một sự thật".
• Lineage có mức bảng (impact analysis thô) và mức cột (audit, giải trình NHNN). Column-level đắt nhưng cần thiết cho tuân thủ.
• Lineage quan trọng cho impact analysis, root cause, audit/tuân thủ và trust.
• Thu thập lineage bằng: parse SQL, tích hợp dbt (manifest.json), Airflow, và chuẩn mở OpenLineage — thường kết hợp; OpenLineage tránh khoá vendor.
• Active metadata đưa metadata trở lại vào công cụ để hành động (propagate policy PII, cảnh báo freshness), khác với passive metadata chỉ tra cứu.
• Chọn công cụ: OpenMetadata/DataHub/Amundsen (open-source, tự chủ) vs Collibra/Alation (thương mại, workflow tuân thủ mạnh cho tổ chức tài chính lớn).
• Catalog là sản phẩm sống, cần data steward duy trì; tự động ingest metadata + lineage nhưng phần mô tả nghiệp vụ phải do con người làm giàu.