Cloudera Data Catalog & Data Lineage: truy vết nguồn gốc dữ liệu

Khi nền tảng dữ liệu đủ lớn, hai câu hỏi xuất hiện gần như hàng tuần — và cả hai đều đắt tiền nếu không trả lời được. Thứ nhất: “số này từ đâu ra?”, thường được hỏi ngay trước một cuộc họp hoặc một kỳ báo cáo. Thứ hai: “đổi cái này thì vỡ cái gì?”, thường được hỏi khi đã quá muộn.

Data Catalog và Data Lineage là hai dịch vụ trong lớp quản trị dùng chung SDX (Shared Data Experience) của Cloudera, sinh ra để trả lời đúng hai câu đó. Catalog cho bạn biết mình đang có dữ liệu gì và dữ liệu đó thuộc loại nào; Lineage cho bạn biết dữ liệu đi qua đâu để thành con số cuối cùng. Cả hai chạy trên metadata thu thập tự động, xuyên suốt môi trường hybrid — tại chỗ và trên đám mây.

flowchart LR
  SRC["Nguồn<br/>core banking · CRM · nhật ký"] --> RAW["Bảng thô<br/>Iceberg"]
  RAW --> TRF["Biến đổi<br/>Spark · SQL"]
  TRF --> MART["Bảng phục vụ báo cáo"]
  MART --> RPT["Số gửi cơ quan quản lý"]
  CAT["Data Catalog<br/>khám phá · phân loại · lập hồ sơ"] -.-> RAW
  CAT -.-> MART
  LIN["Data Lineage<br/>truy ngược · truy xuôi"] -.-> TRF
  RPT -.->|"số này từ đâu ra"| LIN
  RAW -.->|"đổi cái này thì vỡ cái gì"| LIN

Data Catalog — biết mình đang có dữ liệu gì

Không tổ chức nào cố tình để mất dấu dữ liệu của mình. Nó xảy ra dần: mỗi dự án sinh vài chục bảng, mỗi đội đặt tên theo quy ước riêng, người xây bảng chuyển việc — và sau vài năm, việc tìm đúng bảng để dùng tốn nhiều thời gian hơn việc phân tích trên bảng đó.

Data Catalog thu thập metadata từ toàn bộ nền tảng và biến nó thành thứ tra cứu được.

Khám phá và tìm kiếm

Tìm bảng bằng ngôn ngữ nghiệp vụ thay vì bằng trí nhớ về tên kỹ thuật. Mỗi tập dữ liệu hiển thị kèm ngữ cảnh: thuộc về hệ thống nào, ai tạo, cập nhật lần cuối khi nào, ai đang dùng nhiều nhất. Chi tiết cuối cùng thường hữu ích nhất — bảng được cả trăm truy vấn chạm vào mỗi ngày đáng tin hơn bảng nằm im hai năm.

Lập hồ sơ dữ liệu

Lập hồ sơ dữ liệu (data profiling) là bước quét nội dung thật của bảng để mô tả nó: mỗi cột có bao nhiêu giá trị khác nhau, tỉ lệ rỗng là bao nhiêu, phân bố ra sao, giá trị thường gặp là gì.

Đây là cách phát hiện vấn đề trước khi nó thành sai số trên báo cáo: một cột mã khách hàng có 12% giá trị rỗng, hay một cột ngày tháng có giá trị năm 1900, đều lộ ra ở bước lập hồ sơ chứ không đợi tới lúc ai đó cộng nhầm.

Phân loại và tự nhận diện dữ liệu nhạy cảm

Đây là phần quan trọng nhất về mặt tuân thủ. Catalog tự nhận diện các cột có dấu hiệu chứa dữ liệu nhạy cảm — số căn cước, số thẻ, số điện thoại, địa chỉ, email — và gắn nhãn phân loại lên chúng. Nhãn thường dùng nhất là PII — Personally Identifiable Information, dữ liệu định danh cá nhân.

Việc	Làm thủ công	Với Data Catalog
Tìm mọi cột chứa số căn cước	Rà từng bảng, phụ thuộc trí nhớ	Quét và gắn nhãn tự động
Bảng mới sinh ra tuần sau	Phải nhớ rà lại	Được quét và phân loại theo
Áp chính sách che dữ liệu	Viết chính sách cho từng cột	Một chính sách theo nhãn, áp cho tất cả
Chứng minh với kiểm toán	Tổng hợp thủ công	Danh sách tài sản theo nhãn, xuất được

Từ phân loại tới chính sách tuân thủ

Phân loại chỉ có giá trị khi nó dẫn tới hành động. Điểm mạnh của Cloudera nằm ở chỗ Catalog và phân quyền dùng chung một bộ metadata: nhãn mà Catalog gắn chính là nhãn mà chính sách bảo mật đọc.

Nhờ vậy, bạn viết một chính sách — “vai trò Marketing không đọc cột mang nhãn PII” — và nó tự áp cho mọi cột được gắn nhãn, kể cả bảng tạo ra sau khi chính sách đã viết. Đây là điều kiện để quản trị theo kịp tốc độ sinh bảng mới. Chi tiết ở SDX — quản trị dùng chung.

Nền metadata dùng chung

Catalog và Lineage không phải hai sản phẩm rời rồi ghép lại với nhau. Cả hai đọc cùng một kho metadata trong lớp quản trị dùng chung — nền tảng mã nguồn mở Apache Atlas — và metadata đó được thu thập tự động khi job thật sự chạy, không phải do ai đó nhập tay vào một bảng kê.

Hệ quả thực tế đáng giá: nhãn phân loại mà Catalog gắn lên một cột đi theo cột đó dọc chuỗi lineage. Một cột được đánh dấu nhạy cảm ở bảng thô vẫn được nhận ra khi nó chảy vào bảng báo cáo ba tầng phía sau — kể cả khi đã bị đổi tên trên đường đi. Đây đúng là chỗ mà việc phân loại thủ công hay hụt: cột gốc thì nhớ che, bản sao ở cuối chuỗi thì không ai để ý.

Data Lineage — hai câu hỏi đắt giá

Data Lineage truy vết nguồn gốc dữ liệu, quan hệ giữa các tập dữ liệu và metadata xuyên môi trường hybrid. Nó dựng lại toàn bộ chuỗi: nguồn nào nạp vào bảng nào, phép biến đổi nào chạy, kết quả chảy tiếp đi đâu — ở mức bảng và mức cột.

Chiều truy vết	Câu hỏi	Dùng khi nào
Truy ngược — upstream	Số này từ đâu ra? Đi qua những phép biến đổi nào?	Kiểm toán, giải trình số liệu, điều tra khi số lệch
Truy xuôi — downstream	Nếu đổi bảng này, những gì phía sau bị ảnh hưởng?	Đánh giá tác động trước khi đổi, dọn bảng cũ

Hai chiều này phục vụ hai nhóm người khác nhau. Truy ngược là công cụ của người chịu trách nhiệm về con số. Truy xuôi là công cụ của người chịu trách nhiệm về hệ thống.

Mức bảng và mức cột

Lineage mức bảng trả lời “bảng nào sinh ra bảng nào” — đủ để vẽ bức tranh tổng thể. Mức cột đi sâu hơn một bậc: chỉ tiêu du_no_cuoi_ky trên báo cáo được tính từ những cột nào, qua phép biến đổi nào, ở bước nào.

Khác biệt này quyết định phạm vi công việc khi bạn đổi một trường. Mức bảng nói “bảng A ảnh hưởng bảng B” — bạn buộc phải kiểm thử cả bảng B. Mức cột chỉ đúng ba cột cần kiểm thử. Cùng một thay đổi, hai khối lượng công việc rất khác nhau.

Xuyên môi trường hybrid

Với nhiều tổ chức Việt Nam, dữ liệu không nằm trọn một chỗ: dữ liệu lõi ở trung tâm dữ liệu riêng vì yêu cầu chủ quyền, một phần khối lượng xử lý tràn lên đám mây lúc cao điểm. Nếu mỗi môi trường có một catalog riêng, lineage đứt ở đúng chỗ ranh giới — nơi khó giải trình nhất.

Vì Catalog và Lineage nằm trong lớp quản trị dùng chung, chuỗi truy vết nối liền qua ranh giới đó. Bạn nhìn thấy một dòng chảy, không phải hai mảnh rời. Xem thêm Triển khai hybrid & Cloud Bursting.

Ví dụ: chứng minh nguồn gốc số báo cáo gửi cơ quan quản lý

Một ngân hàng gửi báo cáo định kỳ cho Ngân hàng Nhà nước Việt Nam (State Bank of Vietnam). Cơ quan quản lý hỏi lại về một chỉ tiêu: con số này được tính thế nào?

Không có lineage, việc trả lời là một cuộc điều tra: hỏi người viết job, đọc lại mã nguồn, dựng lại logic của một pipeline có thể đã đổi chủ hai lần. Thường mất vài ngày, và kết quả là lời giải thích của con người — thứ mà kiểm toán viên có quyền chưa tin ngay.

Với lineage, câu trả lời là bản ghi của hệ thống: chỉ tiêu lấy từ bảng báo cáo nào, bảng đó sinh ra từ phép biến đổi nào, đọc từ bảng thô nào, nạp từ hệ thống nguồn nào, vào lúc nào. Ghép cùng nhật ký truy cập của SDX, bạn có cả số đến từ đâu lẫn ai đã chạm vào nó.

Ví dụ: đánh giá tác động trước khi đổi schema

Đội kỹ thuật cần đổi kiểu dữ liệu một cột trong bảng khách hàng. Câu hỏi trước khi bấm nút: cái gì đang phụ thuộc vào cột này?

Truy xuôi từ cột đó cho ra danh sách cụ thể — các job biến đổi đọc nó, các bảng phái sinh, các dashboard hiển thị kết quả. Danh sách đó biến một quyết định cảm tính thành một kế hoạch: sửa gì trước, báo cho đội nào, kiểm thử ở đâu.

Cùng công cụ đó trả lời một câu hỏi tiết kiệm tiền: bảng nào không có ai ở phía sau — không job nào đọc, không dashboard nào dùng. Đó là ứng viên dọn dẹp, và là chi phí lưu trữ cùng chi phí xử lý bạn đang trả mà không thu lại gì.

Catalog của nền tảng nằm ở tầng nào

Hai dịch vụ trong bài này trả lời rất tốt một nhóm câu hỏi: dữ liệu gì đang có, nằm ở đâu, từ đâu ra, ai đã chạm vào. Trong phạm vi nền tảng Cloudera, chúng trả lời tự động, liên tục, và bằng bản ghi của hệ thống.

Có một nhóm câu hỏi khác mà chúng không sinh ra để trả lời:

Câu hỏi	Tầng trả lời
Dữ liệu gì đang có, nằm ở đâu?	Data Catalog của nền tảng
Con số này từ đâu ra, đi qua bước nào?	Data Lineage của nền tảng
Ai được xem, ai đã xem?	SDX — phân quyền và nhật ký truy cập
Dữ liệu này có dùng được không?	Tầng chất lượng dữ liệu — DQ (Data Quality)
Khách hàng này xuất hiện ở năm hệ thống — bản nào là bản đúng?	Tầng dữ liệu chủ — MDM (Master Data Management)
Bộ mã dùng chung toàn tổ chức lấy ở đâu, ai duyệt khi đổi?	Tầng dữ liệu tham chiếu — RDM (Reference Data Management)

Ba dòng in đậm là ba câu hỏi nằm ngoài phạm vi của lớp quản trị nền tảng. Chúng không phải phần bị thiếu của Cloudera — chúng thuộc một tầng khác trong kiến trúc dữ liệu, và tầng đó có công cụ riêng.

Ranh giới thứ hai: phạm vi

Lớp quản trị của nền tảng quản trị dữ liệu nằm trên nền tảng. Đó là thiết kế đúng, và cũng là giới hạn cần biết trước khi lập kiến trúc.

Dữ liệu của một tổ chức lớn thì hiếm khi nằm trọn một chỗ: hệ thống lõi, hệ thống nhân sự, hệ thống bán hàng, các ứng dụng chuyên ngành mua ngoài. Khi câu hỏi quản trị là câu hỏi toàn doanh nghiệp — “toàn bộ dữ liệu định danh cá nhân của tổ chức đang nằm ở những đâu”, không chỉ trên lakehouse — thì cần một lớp quản trị đứng trên nhiều nguồn.

Nói thẳng: khi nào bạn không cần gì thêm

Nếu tổ chức của bạn có một estate Cloudera, và nhu cầu quản trị dừng ở khám phá dữ liệu, phân loại dữ liệu nhạy cảm, truy vết nguồn gốc và phân quyền — Catalog cùng Lineage của nền tảng là đủ. Thêm một lớp quản trị nữa lúc này chỉ là thêm một thứ phải vận hành.

Lớp quản trị dữ liệu doanh nghiệp bắt đầu tạo ra giá trị khi xuất hiện một trong bốn nhu cầu sau:

Luật chất lượng dữ liệu có chấm điểm và có xử lý. Không chỉ biết một cột có 12% giá trị rỗng, mà đặt ngưỡng chấp nhận, chấm điểm theo thời gian, chặn dữ liệu không đạt, và giao việc sửa cho người chịu trách nhiệm.
Bản ghi vàng. Cùng một khách hàng ở năm hệ thống với năm cách viết tên — cần so khớp, hợp nhất và công bố một bản đúng để mọi hệ thống dùng chung.
Dữ liệu tham chiếu có quy trình duyệt. Bộ mã dùng chung toàn tổ chức, có phiên bản, có hiệu lực theo thời gian.
Phủ cả nguồn ngoài nền tảng. Cần một bức tranh quản trị bao gồm cả những hệ thống không nằm trên lakehouse.

Bốn nhu cầu này là địa hạt của Ataccama trong bộ giải pháp của BSD:

Chất lượng dữ liệu (DQ) — luật, chấm điểm, giám sát, xử lý lỗi
Dữ liệu chủ (MDM) và bản ghi vàng
Dữ liệu tham chiếu (RDM)
Data Catalog và Lineage ở phạm vi toàn doanh nghiệp

Vị trí của từng lớp trong kiến trúc dữ liệu của BSD: nền dữ liệu giữ và xử lý dữ liệu, tầng quản trị đảm bảo dữ liệu đáng tin, lớp phân tích đưa nó tới người dùng. Xem định vị Cloudera và định vị Ataccama.

Các sai lầm dễ mắc phải

Coi catalog là việc của một dự án. Catalog cập nhật liên tục thì hữu ích; catalog đóng băng sau ngày nghiệm thu thì chỉ là một danh sách cũ.
Phân loại xong rồi để đó. Nhãn không nối vào chính sách thì mới là dán nhãn, chưa phải quản trị.
Chỉ dùng lineage khi có sự cố. Giá trị lớn nhất nằm ở lúc trước khi đổi, không phải lúc điều tra vì sao vỡ.
Bỏ qua lineage ở mức cột. Mức bảng nói “bảng A ảnh hưởng bảng B”; mức cột nói đúng cột nào — khác nhau giữa việc kiểm thử một trường và kiểm thử cả bảng.
Duy trì sơ đồ luồng dữ liệu song song bằng tay. Sớm muộn nó lệch với thực tế, và không ai biết nên tin bản nào.

Đọc tiếp

SDX — quản trị dùng chung Nhãn phân loại nối thẳng vào chính sách phân quyền, che dữ liệu và nhật ký kiểm toán.

Observability & Data Visualization Giám sát tài nguyên, hiệu năng, chi phí — và đưa dữ liệu đã quản trị tới người dùng nghiệp vụ.