Kết nối nguồn và quét/khám phá dữ liệu vào catalog

Một danh mục dữ liệu (data catalog) chỉ hữu ích khi nó biết tổ chức đang có những dữ liệu gì. Vậy làm sao để hàng trăm bảng nằm rải rác ở nhiều hệ thống tự “xuất hiện” trong catalog? Câu trả lời gồm hai bước cốt lõi: kết nối tới nguồn dữ liệu, rồi quét/khám phá (scan/discovery) để đưa cấu trúc của nguồn vào catalog. Trang này giải thích hai bước đó cho người mới — cách Ataccama ONE nạp catalog mà không cần ai ngồi gõ tay từng bảng, từng cột.

Bước 1 — Kết nối tới nguồn dữ liệu

Kết nối nguồn (source connection) là việc khai báo cho Ataccama ONE biết “dữ liệu của tôi nằm ở đâu và đăng nhập vào đó thế nào”. Nói nôm na, đây là lúc bạn đưa cho hệ thống địa chỉ và chìa khóa để nó tự tìm tới kho dữ liệu của bạn.

Một tổ chức Việt Nam điển hình hiếm khi chỉ có một loại nguồn. Ataccama ONE kết nối tới nhiều dạng khác nhau:

Cơ sở dữ liệu quan hệ (relational database) — như PostgreSQL, MySQL, SQL Server, Oracle. Đây thường là nơi chứa dữ liệu giao dịch lõi: đơn hàng, khách hàng, hóa đơn.
Kho dữ liệu đám mây (cloud data warehouse) — như Snowflake, Google BigQuery, Amazon Redshift, Azure Synapse, Databricks. Nhiều doanh nghiệp đã chuyển dữ liệu phân tích lên đây để chạy báo cáo trên khối lượng lớn.
Object storage (kho lưu trữ đối tượng) — như Amazon S3, Azure Blob/ADLS, Google Cloud Storage. Đây là nơi đổ “data lake” — chứa file thô đủ loại, kể cả dữ liệu chưa được dọn dẹp.
File — như CSV, Parquet, Excel, JSON. Vẫn rất phổ biến: một file Excel danh mục sản phẩm, một file CSV xuất ra từ phần mềm cũ.

Mỗi loại nguồn cần thông tin kết nối khác nhau (máy chủ, cổng, tên kho/bucket, tài khoản, mật khẩu hoặc khóa truy cập). Trong Ataccama ONE, các thông tin nhạy cảm này được lưu an toàn và tách khỏi nội dung tài liệu — bạn xem chi tiết cấu hình ở Kết nối CSDL quan hệ.

Vì sao “kết nối” lại quan trọng cho governance

Việc kết nối không chỉ là chuyện kỹ thuật. Khi mọi nguồn dữ liệu đều được khai báo tập trung trong catalog, tổ chức có ngay một bản đồ “chúng ta đang có những kho dữ liệu nào” — bước đầu tiên của quản trị dữ liệu (data governance). Không thể quản trị thứ mình không biết là mình đang có; kết nối nguồn chính là cách đưa “thứ chưa biết” ra ánh sáng.

Bước 2 — Quét/khám phá (scan/discovery) để đưa cấu trúc vào catalog

Có kết nối rồi, Ataccama ONE thực hiện quét (scan) — còn gọi là khám phá (discovery). Đây là quá trình hệ thống tự “soi” vào nguồn và đọc lấy cấu trúc của nó: trong kho này có những lược đồ (schema) nào, mỗi lược đồ có những bảng nào, mỗi bảng có những cột nào, kiểu dữ liệu của từng cột ra sao.

Kết quả của lần quét là một cây phân cấp được đưa thẳng vào catalog:

Nguồn (source) → ví dụ kho PostgreSQL “ERP bán lẻ”.
Bảng (table) → ví dụ bảng don_hang, bảng khach_hang.
Cột (column) → ví dụ cột ma_kh, ngay_dat, tong_tien.

Toàn bộ cấu trúc nguồn → bảng → cột ấy trở thành các tài sản dữ liệu (catalog item) mà ai trong tổ chức cũng tra cứu được. Đây là điểm thay đổi lớn: thay vì phải mở công cụ quản trị CSDL và biết câu lệnh SQL mới xem được có bảng gì, giờ một người làm nghiệp vụ chỉ cần gõ tìm trong catalog.

Một ví dụ Việt Nam

Hãy hình dung một chuỗi siêu thị có:

Một SQL Server chạy phần mềm bán hàng (POS), chứa hàng chục bảng giao dịch.
Một kho BigQuery nơi đội phân tích đổ dữ liệu doanh thu theo ngày, theo tỉnh.
Một thư mục S3 chứa file CSV nhập kho hằng tuần từ nhà cung cấp.

Sau khi kết nối ba nguồn này và chạy quét, catalog tự liệt kê hết các bảng và cột của cả ba — kèm tên, kiểu dữ liệu, thuộc nguồn nào. Một nhân viên mới ở phòng kế hoạch muốn tìm “dữ liệu doanh thu theo tỉnh” chỉ cần tìm trong catalog là thấy bảng nằm ở BigQuery, thay vì đi hỏi vòng quanh xem ai biết bảng đó nằm đâu.

Quét định kỳ — giữ catalog luôn khớp với thực tế

Dữ liệu không đứng yên. Lập trình viên thêm bảng mới, đổi tên cột, bỏ cột cũ; đội phân tích tạo thêm view mới mỗi quý. Nếu catalog chỉ quét một lần rồi thôi, chẳng bao lâu nó sẽ lệch với thực tế — và một catalog lệch còn nguy hiểm hơn không có, vì người ta tin nhầm.

Vì vậy Ataccama ONE cho phép quét định kỳ (scheduled scan): chạy lại việc khám phá theo lịch (ví dụ mỗi đêm, mỗi tuần). Mỗi lần quét lại, hệ thống đối chiếu cấu trúc hiện tại với những gì đã có trong catalog và cập nhật khác biệt:

Bảng/cột mới → được thêm vào catalog.
Bảng/cột bị xóa ở nguồn → được đánh dấu để người quản trị xử lý.
Thay đổi về kiểu dữ liệu → được ghi nhận.

Nhờ vậy catalog luôn là tấm gương phản chiếu trung thực của hệ thống nguồn, chứ không phải một danh sách cũ kỹ chụp tại một thời điểm.

Quét chạy gần nguồn (DPE) — chỉ lấy metadata, không “bê” dữ liệu

Đây là một điểm rất quan trọng mà người mới hay hiểu lầm: quét KHÔNG sao chép toàn bộ dữ liệu của bạn về Ataccama. Việc khám phá chủ yếu thu thập metadata (siêu dữ liệu) — tức thông tin mô tả dữ liệu: tên bảng, tên cột, kiểu dữ liệu, cấu trúc lược đồ. Bản thân hàng triệu dòng dữ liệu giao dịch vẫn nằm yên ở nguồn.

Để làm việc này an toàn và hiệu quả, Ataccama ONE dùng một thành phần xử lý chạy gần nguồn dữ liệu gọi là DPE (Data Processing Engine). Thay vì kéo dữ liệu đi xa rồi mới xử lý, DPE được đặt sát nguồn và:

Đẩy phép tính xuống gần nơi dữ liệu nằm — giảm việc di chuyển dữ liệu qua mạng.
Khi cần thống kê (profiling), DPE tính ngay tại chỗ và chỉ gửi về kết quả tóm tắt (ví dụ “cột này có bao nhiêu giá trị rỗng”), chứ không gửi về từng dòng thô.
Giữ dữ liệu nhạy cảm ở lại trong phạm vi của tổ chức/nguồn — rất hợp với yêu cầu bảo mật và tuân thủ tại Việt Nam.

Nói gọn: phần “bộ não” điều phối catalog (DPM) ra lệnh “hãy quét nguồn này”, còn phần “cánh tay” gần nguồn (DPE) thực thi và mang kết quả metadata về. Bạn xem cách hai thành phần này phối hợp ở DPM và DPE.

Vì sao cách làm này quan trọng cho governance

Bảo mật: dữ liệu thật không phải rời khỏi nơi nó đang được kiểm soát, nên rủi ro lộ lọt giảm hẳn.
Hiệu năng & chi phí: không phải nhân bản kho dữ liệu lớn chỉ để lập danh mục.
Đúng bản chất của catalog: catalog là danh bạ về dữ liệu, không phải thêm một bản sao dữ liệu. Nó cho bạn biết dữ liệu ở đâu, nghĩa là gì, có sạch không — chứ không trở thành một kho dữ liệu thứ hai phải đồng bộ.

Tóm lại

Catalog được nạp qua một mạch rõ ràng: kết nối nguồn (CSDL quan hệ, kho đám mây, object storage, file…) → quét/khám phá đưa cấu trúc nguồn → bảng → cột thành các tài sản dữ liệu → quét định kỳ để luôn khớp với thực tế. Toàn bộ chạy qua DPE gần nguồn, chỉ lấy metadata chứ không bê dữ liệu đi. Đây là phần “móng” để mọi thứ phía sau — mô tả, thuật ngữ, phân loại, điểm chất lượng — có chỗ bám vào.

Tìm hiểu các tài sản sau khi quét được làm giàu tự động ra sao: Tài sản dữ liệu và tự động làm giàu metadata.
Xem chi tiết cấu hình nối tới CSDL: Kết nối CSDL quan hệ.
Hiểu kiến trúc điều phối – xử lý gần nguồn: DPM và DPE.