Trả lời nhanh: Data catalog (danh mục dữ liệu) là hệ thống lập chỉ mục metadata của các tài sản dữ liệu trong doanh nghiệp: bảng, cột, tệp, báo cáo, mô hình. Nó cho biết dữ liệu nằm ở đâu, ai sở hữu, nghĩa là gì, chất lượng ra sao và ai được dùng. Catalog không lưu bản sao dữ liệu thật.
Điểm chính
- Catalog quản lý “thông tin về dữ liệu”, không thay thế kho dữ liệu hay hệ thống nguồn.
- Một mục trong catalog gồm metadata kỹ thuật, metadata nghiệp vụ, chủ sở hữu, nhãn nhạy cảm, lineage và tín hiệu chất lượng.
- Công cụ chia ba nhóm: catalog gắn với nền tảng, catalog thương mại độc lập và catalog mã nguồn mở.
- Giá trị phụ thuộc vào việc mô tả và chủ sở hữu có được duy trì hay không, không phụ thuộc vào số bảng đã quét.
Mục lục
- Data catalog là gì?
- Một mục trong catalog chứa những gì?
- Data catalog hoạt động như thế nào?
- Kiến trúc và thành phần của một data catalog
- Các loại data catalog và công cụ thường gặp
- Ví dụ minh hoạ: ba bảng “doanh thu” cho ba con số
- Ứng dụng của data catalog trong doanh nghiệp Việt Nam
- Ưu điểm và hạn chế
- Data catalog khác gì các khái niệm gần giống?
- Khi nào nên và không nên triển khai data catalog?
- Checklist đánh giá catalog khi chọn mua hoặc thử nghiệm
- Lỗi thường gặp khi triển khai
- Câu hỏi thường gặp
Data catalog là gì?
Data catalog, hay danh mục dữ liệu, là nơi tra cứu tập trung về các tài sản dữ liệu của tổ chức. Mỗi tài sản (bảng trong kho dữ liệu, tệp trong data lake, dashboard, mô hình học máy) có một “hồ sơ” gồm tên, vị trí, mô tả, chủ sở hữu, mức độ nhạy cảm và nguồn gốc. Cách ví von quen thuộc là thư viện: catalog là phần phiếu mục lục, còn dữ liệu là cuốn sách vẫn nằm trên kệ của nó.
Điều này dẫn tới ba điểm hay bị hiểu nhầm:
- Catalog không chứa dữ liệu nghiệp vụ. Nó chứa metadata, tức siêu dữ liệu về dữ liệu đó. Bảng khách hàng một triệu dòng chỉ xuất hiện trong catalog dưới dạng tên bảng, danh sách cột, vài thống kê và mô tả.
- Catalog không phải cơ sở dữ liệu để chạy ứng dụng. Bạn không ghi đơn hàng vào catalog. Nếu cần nền tảng về lưu trữ, hãy xem bài về cơ sở dữ liệu và DBMS.
- Catalog không phải tài liệu Word hay bảng tính liệt kê bảng. Khác biệt nằm ở khả năng tự thu thập metadata từ nguồn, tìm kiếm toàn văn, phân quyền và cập nhật khi cấu trúc nguồn thay đổi.
Về mặt kỹ thuật, khái niệm này có từ lâu: mọi hệ quản trị cơ sở dữ liệu quan hệ đều có “system catalog” nội bộ, trong chuẩn SQL gọi là information schema, liệt kê bảng, cột, chỉ mục của riêng nó. Data catalog doanh nghiệp là bản mở rộng cho nhiều hệ thống cùng lúc, kèm lớp ngữ cảnh nghiệp vụ do con người bổ sung.
Một mục trong catalog chứa những gì?
Đây là chỗ nhiều bài giới thiệu chỉ nói chung chung “chứa metadata”. Thực tế, hồ sơ của một tài sản thường có sáu nhóm thông tin:
| Nhóm thông tin | Nội dung cụ thể | Thường đến từ đâu |
|---|---|---|
| Metadata kỹ thuật | Tên bảng, tên cột, kiểu dữ liệu, khoá chính, kích thước, thời điểm cập nhật cuối | Tự động quét từ nguồn |
| Metadata nghiệp vụ | Mô tả bằng ngôn ngữ nghiệp vụ, đơn vị đo, công thức, thuật ngữ trong glossary | Người làm nghiệp vụ nhập tay hoặc duyệt |
| Quyền sở hữu | Chủ sở hữu dữ liệu (data owner), người quản lý dữ liệu (data steward), kênh liên hệ | Phân công của tổ chức |
| Phân loại và nhãn | Nhạy cảm, dữ liệu cá nhân, mật, nội bộ; thời hạn lưu trữ | Quy tắc tự động cộng với rà soát tay |
| Nguồn gốc (lineage) | Bảng này sinh ra từ đâu, đi vào báo cáo nào | Phân tích câu truy vấn, log, công cụ pipeline |
| Tín hiệu tin cậy | Kết quả kiểm tra chất lượng, độ mới, lượt dùng, đánh giá của người dùng | Công cụ kiểm tra chất lượng, log truy cập |
Nhóm thứ hai và thứ ba là phần máy không tự làm được. Máy đọc được cột ma_kh kiểu chuỗi 10 ký tự, nhưng không biết đó là mã khách hàng theo quy ước của hệ thống bán hàng cũ hay mã sau khi hợp nhất với CRM. Theo cách trình bày của nhiều nhà cung cấp, catalog tốt là catalog kết hợp được hai loại metadata này.
Data catalog hoạt động như thế nào?
Quy trình chung gồm bốn bước, đi từ nguồn đến người dùng:
- Kết nối và thu thập (harvesting). Catalog dùng connector để đọc metadata từ cơ sở dữ liệu, kho dữ liệu, công cụ BI, công cụ điều phối pipeline. Có hai kiểu: kéo (catalog định kỳ quét nguồn) và đẩy (nguồn hoặc pipeline chủ động gửi sự kiện thay đổi sang catalog). Theo mô tả của Atlan, DataHub dùng kiểu đẩy qua API dịch vụ metadata.
- Lập chỉ mục và làm giàu. Metadata được đưa vào công cụ tìm kiếm. Một số công cụ lấy mẫu dữ liệu để thống kê (tỷ lệ rỗng, số giá trị khác nhau) và gợi ý nhãn như “email” hay “số điện thoại”.
- Quản lý bởi con người. Chủ sở hữu duyệt mô tả, gắn thuật ngữ nghiệp vụ, xác nhận phân loại nhạy cảm, đánh dấu tài sản “đã chứng nhận” hoặc “ngừng dùng”.
- Tìm kiếm, tra cứu và yêu cầu truy cập. Người dùng gõ “doanh thu thuần” và nhận danh sách bảng, báo cáo liên quan, kèm chủ sở hữu và mức tin cậy. Với tài sản bị hạn chế, họ gửi yêu cầu quyền ngay trong catalog.
Ở bước 4, bạn sẽ thấy rõ khác biệt giữa catalog và công cụ quét thuần tuý: người dùng không phải hỏi nhóm kỹ thuật “bảng nào đang đúng”, vì trạng thái “đã chứng nhận” và tên chủ sở hữu hiện ngay trong kết quả tìm kiếm.
Kiến trúc và thành phần của một data catalog
Dù là sản phẩm nào, catalog thường có năm lớp. Hiểu các lớp này giúp bạn biết lỗi nằm ở đâu khi catalog “không có ai dùng”.
- Nguồn dữ liệu gồm cơ sở dữ liệu giao dịch, kho dữ liệu, data lake, tệp Excel dùng chung, công cụ BI.
- Connector quyết định catalog “thấy” được bao nhiêu hệ thống. Số connector có sẵn là tiêu chí chọn mua đầu tiên: nếu hệ thống ERP nội địa của bạn không có connector, bạn phải tự viết hoặc nạp metadata qua tệp.
- Kho metadata lưu cả metadata lẫn quan hệ giữa chúng. Theo một bài tổng hợp trên lakeFS, OpenMetadata lưu quan hệ bằng tính năng của PostgreSQL thay vì dùng cơ sở dữ liệu đồ thị riêng. Mỗi sản phẩm chọn một kiểu kiến trúc khác nhau.
- Ngữ cảnh nghiệp vụ là glossary (từ điển thuật ngữ), quy trình duyệt và chứng nhận.
- Giao diện và API phục vụ cả người lẫn chương trình. Phần API ngày càng quan trọng khi các tác tử AI cần tra metadata, mà bài về giao thức MCP mô tả cách kết nối như vậy.
Các loại data catalog và công cụ thường gặp
Có hai cách phân loại hữu ích. Cách thứ nhất theo đối tượng dùng: catalog kỹ thuật (cho kỹ sư dữ liệu, tập trung vào schema, lineage, pipeline) và catalog nghiệp vụ (cho phân tích viên, kế toán, marketing, tập trung vào định nghĩa và độ tin cậy). Nhiều sản phẩm hiện nay cố gắng phục vụ cả hai, nhưng điểm mạnh thường nghiêng về một phía.
Cách thứ hai theo mô hình cung cấp. Theo bài so sánh của Select Star, có ba nhóm chính: mã nguồn mở, gắn với nền tảng và thương mại độc lập. Bảng dưới tóm tắt theo thông tin trong các bài so sánh gần đây (2025–2026); tính năng và giá thay đổi nhanh, bạn cần kiểm tra lại với nhà cung cấp.
| Nhóm | Ví dụ | Phù hợp khi | Điểm cần cân nhắc |
|---|---|---|---|
| Gắn với nền tảng | Databricks Unity Catalog, Snowflake Horizon, Microsoft Purview, Google Dataplex, AWS Glue Data Catalog | Phần lớn dữ liệu nằm trên một nền tảng | Thường kém bao quát với hệ thống ngoài nền tảng đó. Nhóm thực hiện một bài đánh giá ghi rằng Unity Catalog kém phù hợp nếu làm lớp tìm kiếm duy nhất cho nhiều công cụ ngoài |
| Thương mại độc lập | Collibra, Alation, Atlan, Informatica | Nhiều hệ thống, cần quy trình quản trị và kiểm toán | Chi phí theo báo giá, cần nhân sự quản trị nội dung |
| Mã nguồn mở | DataHub, OpenMetadata, Amundsen | Đội kỹ thuật tự vận hành được hạ tầng | Theo một bài phân tích, DataHub cần nhiều thành phần hạ tầng (như Kafka, Elasticsearch) hơn OpenMetadata |
Một số thông tin đáng chú ý từ các bài so sánh gần đây: theo Atlan, hiện chỉ DataHub và OpenMetadata có máy chủ MCP chính chủ để tác tử AI truy vấn catalog trực tiếp. Còn Marquez mạnh ở lineage nhưng không thay được catalog đầy đủ, nên cần ghép với DataHub, OpenMetadata hoặc nền tảng thương mại. Nhà cung cấp nào cũng có lợi ích thương mại khi so sánh, nên hãy dùng các bảng này làm danh sách rà soát ban đầu, không phải kết luận.
Về quy mô, một bài đánh giá của Atlan nêu ngưỡng tham khảo: công cụ nhẹ đủ cho đội dưới 50 người dùng dữ liệu hoặc chương trình quản trị mới bắt đầu, còn nền tảng đầy đủ cần cho doanh nghiệp lớn chịu quản lý chặt. Đây là quan điểm của nhà cung cấp, không phải chuẩn ngành.
Ví dụ minh hoạ: ba bảng “doanh thu” cho ba con số
Ví dụ minh hoạ (giả định): công ty phân phối hàng tiêu dùng có kho dữ liệu với ba bảng tên gần giống nhau: doanh_thu_thang, doanh_thu_thang_v2, rpt_doanh_thu_final. Kế toán dùng bảng đầu, kinh doanh dùng bảng thứ hai, còn bảng cuối do một nhân viên đã nghỉ việc tạo ra. Cuối tháng, ba con số lệch nhau vì bảng đầu tính cả hàng trả về, bảng hai trừ chiết khấu thương mại, bảng cuối bỏ đơn của kênh đại lý.
Với catalog, ba bảng được quét về cùng một nơi. Người quản lý dữ liệu của phòng tài chính viết định nghĩa “doanh thu thuần” trong glossary, gắn nó vào bảng doanh_thu_thang_v2, chứng nhận bảng này và đánh dấu hai bảng còn lại là “ngừng dùng”. Lineage cho thấy bảng cuối còn đang cấp dữ liệu cho một báo cáo của phòng kinh doanh, nên nhóm biết phải thông báo trước khi tắt. Kết quả không phải là số liệu tự đúng, mà là câu hỏi “bảng nào đúng” có một địa chỉ trả lời duy nhất.
Phần nguồn gốc dữ liệu trong ví dụ trên là chức năng của data lineage. Nhiều catalog tích hợp sẵn lineage, một số chỉ nhận lineage từ công cụ khác.
Ứng dụng của data catalog trong doanh nghiệp Việt Nam
Rút ngắn thời gian tìm dữ liệu cho phân tích và BI
Phân tích viên mới vào làm thường mất nhiều ngày hỏi đồng nghiệp để biết bảng nào dùng cho báo cáo gì. Catalog biến kiến thức truyền miệng thành hồ sơ tra cứu được, nhất là khi công ty có nhiều dashboard trong hệ thống business intelligence trỏ về cùng nguồn.
Biết dữ liệu cá nhân nằm ở đâu
Để xác định phạm vi xử lý hay trả lời yêu cầu của chủ thể dữ liệu, doanh nghiệp trước hết phải biết cột nào chứa họ tên, số điện thoại, số căn cước ở bảng nào. Catalog với nhãn “dữ liệu cá nhân” và lineage là công cụ kiểm kê thực tế cho việc này. Phần khung quản trị và các luật liên quan nằm trong bài về data governance.
Chuẩn bị dữ liệu cho AI
Khi doanh nghiệp xây chatbot hay hệ thống hỏi đáp trên dữ liệu nội bộ, câu hỏi đầu tiên là nguồn nào đủ tin cậy để đưa vào. Mô tả, chủ sở hữu và trạng thái chứng nhận trong catalog giúp loại bảng cũ khỏi phạm vi. Cần lưu ý một điều: một bài đánh giá về Unity Catalog ghi rằng Databricks khuyến nghị con người rà soát mô tả do AI sinh ra, và không dùng văn bản sinh tự động để phân loại dữ liệu cá nhân. Với dữ liệu nhạy cảm, nhãn cuối cùng nên do người xác nhận.
Cắt nhánh dữ liệu thừa khi chuyển hệ thống
Trước khi di chuyển lên đám mây hoặc thay ERP, catalog cho danh sách bảng có người dùng thật và bảng không còn truy vấn nào. Đây là cách lọc để không chuyển cả “bãi” sang môi trường mới.
Ưu điểm và hạn chế
| Ưu điểm | Hạn chế |
|---|---|
| Một nơi tra cứu cho dữ liệu nằm ở nhiều hệ thống | Nội dung nghiệp vụ nhanh lỗi thời nếu không ai duy trì |
| Chủ sở hữu và định nghĩa hiển thị cùng dữ liệu | Cần connector phù hợp, hệ thống tự phát triển trong nước thường phải nạp tay |
| Nền tảng cho phân loại dữ liệu cá nhân và kiểm toán truy cập | Một số công cụ chỉ phủ lineage mức bảng chứ không tới mức cột |
| Giảm hỏi đáp lặp lại giữa nhóm kỹ thuật và nghiệp vụ | Chi phí vận hành (hạ tầng, người quản lý nội dung) thường lớn hơn chi phí giấy phép |
Hạn chế thứ nhất mới là rủi ro lớn nhất. Catalog quét tự động rất nhanh, nhưng một bảng có 400 cột không mô tả chỉ là danh sách tên cột đẹp hơn. Chất lượng dữ liệu bên trong bảng cũng là vấn đề riêng: catalog hiển thị kết quả kiểm tra chứ không tự sửa lỗi, nên bạn cần song song một chương trình chất lượng dữ liệu.
Data catalog khác gì các khái niệm gần giống?
| Khái niệm | Phạm vi | Khác với data catalog ở chỗ |
|---|---|---|
| Data dictionary (từ điển dữ liệu) | Mô tả cột, kiểu dữ liệu của một hệ thống | Thường tĩnh, một hệ thống, ít tìm kiếm và phân quyền |
| Business glossary | Định nghĩa thuật ngữ nghiệp vụ | Là một thành phần nằm trong catalog, không gắn trực tiếp với bảng nếu đứng riêng |
| Data lineage | Dòng đi của dữ liệu | Một tính năng, trả lời “từ đâu đến đâu”; catalog trả lời thêm “là gì, của ai” |
| Master data management | Tạo bản ghi chuẩn cho khách hàng, sản phẩm | Làm sạch và hợp nhất dữ liệu thật; catalog chỉ mô tả. Xem master data management |
| Data fabric | Kiến trúc tích hợp dựa trên metadata chủ động | Catalog thường là một thành phần của kiến trúc này, xem data fabric |
Khi nào nên và không nên triển khai data catalog?
Quyết định nên xét theo hai trục: dữ liệu của bạn nằm trên bao nhiêu nền tảng, và đội kỹ thuật có đủ sức tự vận hành hạ tầng hay không.
Nên cân nhắc khi
- Cùng một chỉ số xuất hiện ở nhiều bảng hoặc nhiều báo cáo với giá trị khác nhau.
- Người mới mất hàng tuần để biết nên dùng bảng nào.
- Bạn phải trả lời được “dữ liệu cá nhân của khách hàng nằm ở những hệ thống nào” cho kiểm toán hoặc cơ quan quản lý.
- Có kế hoạch cho AI dùng dữ liệu nội bộ và cần xác định nguồn được phép dùng.
Chưa cần hoặc chưa hiệu quả khi
- Doanh nghiệp chỉ có một phần mềm kế toán và vài tệp Excel: một bảng mô tả cột và chủ sở hữu trong tài liệu dùng chung là đủ.
- Chưa có ai đứng tên làm chủ sở hữu cho bất kỳ bộ dữ liệu nào, vì khi đó mô tả không có người duyệt.
- Vấn đề thật là dữ liệu nguồn sai chứ không phải khó tìm. Lúc này cần làm sạch dữ liệu và kiểm tra chất lượng trước.
Checklist đánh giá catalog khi chọn mua hoặc thử nghiệm
- Liệt kê 5–10 nguồn quan trọng nhất (ví dụ ERP, CRM, kho dữ liệu, công cụ BI) và kiểm tra connector có sẵn cho từng nguồn.
- Hỏi lineage ở mức bảng hay mức cột, tự động hay phải khai báo. Trong 26 công cụ được lakeFS xem xét, chỉ một phần cung cấp lineage đầu cuối hoặc mức cột.
- Kiểm tra phân quyền: catalog có ẩn được tên cột nhạy cảm với người không có quyền không, và có ghi lại ai đã xem gì không.
- Xem cách gắn nhãn dữ liệu cá nhân: quy tắc theo mẫu (regex), theo tên cột, hay do AI gợi ý, và có bước người duyệt không.
- Hỏi về API và khả năng xuất metadata ra định dạng mở, để không bị khoá nhà cung cấp.
- Thử với dữ liệu thật của bạn, kể cả cột tiếng Việt có dấu và bảng có tên viết tắt nội bộ, xem tìm kiếm có trả đúng không.
- Tính cả chi phí nhân sự duy trì nội dung, không chỉ giấy phép hoặc hạ tầng.
Thông tin về công cụ trong bài lấy từ các bài so sánh công khai 2025–2026 và có thể thay đổi. Giá không được nêu vì phần lớn là báo giá theo yêu cầu. Bài mô tả trung lập, không khuyến nghị sản phẩm cụ thể.
Lỗi thường gặp khi triển khai
- Quét toàn bộ rồi để đó. Hàng chục nghìn bảng xuất hiện, phần lớn là bảng tạm và bảng thử nghiệm. Người dùng tìm ra kết quả rác và bỏ catalog. Cách xử lý: ẩn hoặc gắn nhãn “chưa chứng nhận” cho phần chưa duyệt, chỉ nổi bật tài sản đã có chủ sở hữu.
- Glossary viết một lần. Định nghĩa “khách hàng hoạt động” thay đổi khi chính sách kinh doanh đổi, nhưng mô tả trong catalog giữ nguyên. Cách xử lý: gắn ngày duyệt cuối và chu kỳ rà soát cho các thuật ngữ quan trọng.
- Chỉ có kỹ sư dữ liệu dùng. Giao diện đầy thuật ngữ kỹ thuật làm người nghiệp vụ ngại mở. Cách xử lý: cho phép tìm bằng tên nghiệp vụ và hiển thị chủ sở hữu rõ ràng.
- Nhầm catalog với cơ chế bảo mật. Ẩn tên cột trong catalog không chặn được truy cập vào dữ liệu gốc. Quyền truy cập thật vẫn phải được cấu hình ở hệ thống nguồn hoặc nền tảng dữ liệu.
- Bỏ qua pipeline. Nếu bảng mới được tạo hằng ngày bởi quy trình ETL mà không đẩy metadata sang catalog, danh mục sẽ lệch dần so với thực tế.
Câu hỏi thường gặp
Data catalog khác gì với data warehouse?
Data warehouse lưu dữ liệu đã tích hợp để phân tích. Data catalog chỉ lưu thông tin mô tả về dữ liệu, bao gồm cả dữ liệu trong kho, trong data lake và ở các hệ thống khác. Bạn có thể có catalog mà không có kho dữ liệu, và ngược lại.
Data catalog có phải là metadata không?
Không hẳn. Metadata là chất liệu, còn catalog là hệ thống thu thập, tổ chức, tìm kiếm và quản lý chất liệu đó. Catalog thêm vào các lớp mà metadata thô không có: tìm kiếm, phân quyền, chứng nhận, quy trình duyệt.
Doanh nghiệp vừa và nhỏ có cần data catalog không?
Phụ thuộc vào mức độ phân tán dữ liệu hơn là quy mô nhân sự. Nếu dữ liệu nằm ở một hệ thống và vài tệp, một tài liệu mô tả cột kèm tên người phụ trách có thể đủ. Khi số hệ thống, báo cáo và người dùng tăng lên, các công cụ nhẹ hoặc mã nguồn mở là điểm bắt đầu để thử.
Data catalog có tự động làm hết được không?
Phần kỹ thuật như quét schema, thống kê, lineage từ truy vấn có thể tự động. Phần nghiệp vụ như định nghĩa chỉ số, chọn bảng đáng tin, xác nhận dữ liệu nhạy cảm vẫn cần con người, dù AI có thể gợi ý nháp.
Data catalog có liên quan gì đến data governance?
Quản trị dữ liệu đặt ra quy tắc, vai trò và trách nhiệm. Catalog là nơi các quy tắc đó được ghi lại và thể hiện ra: ai sở hữu, mức nhạy cảm nào, được dùng cho mục đích gì. Không có quy tắc thì catalog chỉ là danh sách; không có catalog thì quy tắc khó áp dụng trên thực tế.
Data catalog dùng cho AI như thế nào?
Catalog giúp xác định nguồn dữ liệu nào đủ tin cậy và được phép đưa vào mô hình hoặc hệ thống truy xuất. Một số công cụ còn mở API hoặc máy chủ MCP để tác tử AI tra metadata trực tiếp. Dù vậy, kết quả tra cứu vẫn cần được kiểm tra bởi người chịu trách nhiệm dữ liệu.