DataHub và Atlan: dùng data catalog để nắm dữ liệu của khách ngay tuần đầu

Tài liệu của Atlan hứa rằng bạn có thể dựng nền tảng, kết nối những nguồn dữ liệu đầu tiên và nắm các khái niệm cơ bản “trong vài phút”. Đó là lời của nhà cung cấp, và có thể đúng với khâu kết nối kỹ thuật.

Nhưng FDE nào từng đến một khách hàng mới đều biết vài phút ấy không trả lời được câu hỏi thật của tuần đầu: bảng nào đáng tin, ai chịu trách nhiệm, cột nào chứa thông tin cá nhân.

Đây chính là chỗ data catalog đáng để học. Khi bạn được giao xây một agent hay một pipeline trên dữ liệu của khách, sai lầm đắt nhất thường không nằm ở model. Nó nằm ở chuyện bạn dùng nhầm bảng, hoặc đưa dữ liệu nhạy cảm vào nơi không được phép.

DataHub và Atlan là hai lựa chọn tiêu biểu cho hai hướng khác nhau: một bên có lõi mã nguồn mở, một bên là SaaS độc quyền. Hiểu chúng làm gì, và quan trọng hơn là dùng chúng theo trình tự nào, giúp bạn nắm được bức tranh dữ liệu của khách ngay trong tuần đầu.

Hai công cụ, hai cách để có cùng một bản đồ

DataHub tự định vị là nền tảng quản lý ngữ cảnh cho AI và dữ liệu, gom discovery, governance và observability trên toàn bộ hệ thống dữ liệu. Atlan mô tả mình là “context layer” cho AI, nối dữ liệu với định nghĩa nghiệp vụ và chính sách truy cập.

Về số connector, tài liệu của Atlan quảng cáo hơn 80 nguồn, và trang so sánh độc lập Modern DataTools xếp hai bên ngang nhau, mỗi bên hơn 80. Khác biệt thật nằm ở mô hình triển khai.

Vì thế câu hỏi đầu tiên ở site khách không phải công cụ nào tốt hơn, mà khách đang đứng ở đâu. Nếu khách có đội hạ tầng và muốn giữ mọi thứ trong mạng nội bộ, DataHub tự host là lựa chọn tự nhiên. Nếu khách đã mua Atlan, việc của bạn là dùng thành thạo thứ họ đã có, không phải thuyết phục họ đổi.

Tuần đầu với catalog trông thế nào?

Thử hình dung bạn đến một công ty bán lẻ cần một agent trả lời câu hỏi về đơn hàng. Họ có một data warehouse, vài dashboard và một thư mục file thô mà không ai nhớ ai tạo ra. Ngày đầu tiên, việc đầu tiên không phải viết prompt mà là kết nối các nguồn này vào catalog.

Với DataHub, bạn có thể nạp metadata qua giao diện cho nhanh, hoặc dùng CLI để cấu hình được lưu lại, review và chạy lại. Tại site khách, cách thứ hai đáng giá hơn vì nó để lại dấu vết cho người sau.

Khi metadata đã vào, công cụ mạnh nhất là ô tìm kiếm. DataHub cho tìm trên toàn hệ sinh thái, gồm dashboard, dataset, ML model và file thô. Bạn gõ “order” và lần đầu tiên thấy được tất cả những nơi khái niệm đơn hàng xuất hiện, thay vì chỉ cái bảng mà người dẫn đường nhắc tới.

Một phép tính nhỏ cho thấy việc thật

Giả sử lượt tìm kiếm đó trả về 40 tài sản liên quan đến đơn hàng. Bạn hỏi xung quanh và chỉ xác định được owner cho 12 cái. Vậy 28 tài sản còn lại, tức 70%, là dữ liệu không ai đứng ra chịu trách nhiệm, và đó là con số bạn mang vào buổi họp cuối tuần.

DataHub cho phép định nghĩa ownership và theo dõi PII ngay trong catalog. Vì thế bước tiếp theo là gắn owner cho 12 tài sản đã rõ, rồi đánh dấu những cột chứa thông tin cá nhân như tên, số điện thoại, địa chỉ giao hàng.

Sau đó là phân loại. Palo Alto Networks định nghĩa data classification là sắp xếp dữ liệu theo mức nhạy cảm, tầm quan trọng và các tiêu chí định sẵn. Các mức phổ biến là public, internal use, restricted và confidential.

Áp vào ví dụ trên: bảng danh mục sản phẩm có thể là internal use, còn bảng khách hàng chứa số điện thoại rõ ràng thuộc nhóm restricted hoặc confidential.

Hai lỗi khiến tuần đầu đi chệch

Lỗi phổ biến nhất là kết nối mọi nguồn trước khi thống nhất phạm vi với khách. Hơn 80 connector khiến việc này rất dễ, nhưng catalog đầy metadata không liên quan đến bài toán đơn hàng chỉ làm kết quả tìm kiếm nhiễu hơn, và bạn có thể chạm vào hệ thống khách chưa cho phép xem.

Hãy chốt danh sách nguồn bằng văn bản trước lần ingestion đầu tiên.

Lỗi kế tiếp là đánh dấu PII mà không gắn một owner có tên cụ thể. Một cột được gắn nhãn số điện thoại nhưng không có người chịu trách nhiệm thì khi agent cần quyền đọc, không ai đủ thẩm quyền để đồng ý hay từ chối. Đó là lý do trong ví dụ trên, gắn owner đi trước đánh dấu PII.

Catalog không làm thay bạn phần khó

Giới hạn đầu tiên là lời hứa tốc độ. “Vài phút” của Atlan là tuyên bố của nhà cung cấp về bước kết nối. Gắn owner thì cần con người trả lời, và không công cụ nào tự biết ai chịu trách nhiệm cho một file thô vô danh.

Giới hạn thứ hai liên quan đến cách nghĩ về ngữ cảnh cho AI. Trong một bài blog tháng 4/2026, chính DataHub lập luận rằng semantic layer là cần nhưng chưa đủ; agent còn cần lineage, ownership, độ tươi của dữ liệu và quyền truy cập. Bài viết cũng cho rằng governance không phải tính năng để thêm vào sau.

Đây là quan điểm của một bên bán catalog, nên nó có động cơ, nhưng thứ tự công việc mà nó gợi ý khớp với thực tế triển khai.

Hệ quả cho FDE khá rõ. Nếu bạn dựng agent trước rồi mới hỏi về phân quyền, bạn sẽ phải làm lại đúng phần mà khách quan tâm nhất.

Nên học gì trước, và thể hiện nó ra sao

Hãy bắt đầu với DataHub Core vì nó mã nguồn mở và tự chạy được, không cần hợp đồng. Học theo thứ tự công việc thật: ingest bằng UI rồi bằng CLI, tìm kiếm, gắn ownership, đánh dấu PII. Atlan khó tiếp cận hơn khi chưa có khách dùng nó, nên đọc tài liệu để quen các khái niệm glossary và lineage là đủ cho giai đoạn đầu.

Khi phỏng vấn cho vị trí FDE, hãy hỏi một câu: “Ở khách hàng gần nhất, ai quyết định bảng nào agent được đọc, và quyết định đó được ghi lại ở đâu?” Câu trả lời cho bạn biết công ty coi governance là việc của FDE hay việc của người khác.

Trong CV, đừng viết “có kinh nghiệm với data catalog”. Viết điều bạn đã làm được bằng con số: số nguồn đã kết nối, tỷ lệ tài sản có owner trước và sau, số cột PII đã đánh dấu.

Model thì khách có thể thuê ai cũng dựng được. Thứ khiến họ tin bạn là việc đến cuối tuần đầu, bạn đưa ra được một danh sách nói rõ dữ liệu nào an toàn để agent đọc.