Module Kết nối & thu thập metadata: 130+ connector

Mọi giá trị của OpenMetadata — khám phá, lineage mức cột, chất lượng, quan sát, governance — đều dựng trên một tiền đề: nền tảng phải nhìn thấy được dữ liệu của bạn ở mọi nơi nó đang nằm. Một đồ thị metadata chỉ thật sự mạnh khi nó hợp nhất được kho đám mây, data lake, công cụ BI, pipeline biến đổi và cả hệ thống ML — chứ không phải một góc rời rạc. Module Connectors & Ingestion chính là lớp làm việc đó: thu thập metadata từ hàng loạt nguồn rồi nạp vào đồ thị chung. Trang này nói về giá trị và vai trò kiến trúc của lớp kết nối, không lặp lại cách cấu hình từng connector (đã có ở nhóm tài liệu kỹ thuật).

Vì sao “đồ thị metadata” chỉ mạnh khi kết nối được mọi nguồn

Hãy hình dung một doanh nghiệp có dữ liệu trong Snowflake, vài bảng còn ở Postgres on-premise, báo cáo trên Tableau, pipeline chạy bằng Airflow và mô hình biến đổi viết bằng dbt. Nếu danh mục dữ liệu chỉ “nhìn thấy” Snowflake, thì câu hỏi quan trọng nhất — “Báo cáo doanh thu này lấy số từ đâu, ai sở hữu, có sạch không?” — vẫn không trả lời được, vì mắt xích nằm ở Tableau và dbt đã đứt khỏi đồ thị.

Nói cách khác, độ phủ kết nối quyết định độ tin của toàn bộ catalog. Lineage chỉ liền mạch khi cả nguồn lẫn đích đều đã được thu thập; phân tích tác động (impact analysis) chỉ đúng khi không có “vùng tối”. Đây là lý do số lượng và chất lượng connector không phải con số marketing — nó là điều kiện cần để các module khác hoạt động đúng.

OpenMetadata trả lời bài toán này bằng hơn 130 connector dựng sẵn trải khắp các nhóm nguồn của một hệ dữ liệu hiện đại, cộng cơ chế mở để tự viết connector cho nguồn đặc thù.

130+ connector: phủ trọn hệ dữ liệu

Các connector được nhóm theo loại hệ thống, giúp đội kiến trúc dễ rà soát “mình đã phủ hết chưa”:

Nhóm nguồn	Đại diện phổ biến	Vai trò trong bức tranh metadata
Database	Snowflake, BigQuery, Postgres, MySQL, Oracle, MSSQL	Lõi của catalog — schema, bảng, cột, khóa
Data Lake / Warehouse	Redshift, Databricks, S3, GCS, ADLS, Hive	Dữ liệu thô & vùng lưu trữ quy mô lớn
Dashboard / BI	Tableau, Power BI, Looker, Superset, Metabase, Qlik	Đầu ra dữ liệu — nối lineage tới báo cáo người dùng thấy
Pipeline	Airflow, Fivetran, Dagster, Airbyte, NiFi	Dòng chảy & điều phối — ai chuyển dữ liệu đi đâu
ML Model	MLflow, SageMaker	Mô hình & feature dùng dữ liệu nào
Messaging	Kafka, Kinesis	Luồng streaming, topic, schema
Search	Elasticsearch, OpenSearch	Chỉ mục tìm kiếm như một tài sản dữ liệu
Metadata	Atlas, Amundsen	Di trú từ nền tảng catalog cũ

Điểm đáng giá với người ra quyết định: bạn không phải mua thêm tool cho mỗi loại nguồn. Một nền tảng mã nguồn mở duy nhất phủ từ database tới BI tới ML — giảm số “đảo công cụ” và giảm chi phí tích hợp về sau. Danh sách chi tiết và cách cấu hình nằm ở Tổng quan Connectors.

Các workflow: không chỉ “kéo schema về”

Một hiểu lầm thường gặp là connector chỉ để “nhập tên bảng”. Thực tế mỗi nguồn có thể chạy nhiều loại workflow thu thập khác nhau, mỗi loại nuôi một module:

Metadata — cấu trúc nền tảng: schema, bảng, cột, dashboard, topic. Đây là bước đầu tiên, dựng nên bộ khung catalog.
Usage — mức độ sử dụng và truy vấn phổ biến, giúp biết tài sản nào “nóng”, bảng nào gần như không ai dùng (ứng viên để dọn).
Lineage — dòng chảy dữ liệu, dựng từ phân tích SQL và metadata pipeline, cho ra nguồn gốc mức cột.
Profiler — thống kê và mẫu dữ liệu (giá trị null, phân phối, miền giá trị), nền cho kiểm thử chất lượng.
dbt — nhập mô hình, mô tả, tag, owner và lineage thẳng từ dự án dbt — biến tài liệu kỹ thuật trong dbt thành metadata sống trong catalog.
Auto-classification — tự dò và gắn nhãn dữ liệu nhạy cảm (PII) như email, số điện thoại, số định danh, làm nền cho tuân thủ.

Cách dùng khôn ngoan: bật dần dần. Khởi đầu chỉ metadata cho một nguồn, ổn rồi mới mở thêm usage / lineage / profiler / auto-classification. Cách này giúp đội vận hành kiểm soát tải hệ thống và làm chủ từng lớp giá trị.

dbt: vì sao đáng tách riêng

Trong nhiều đội dữ liệu hiện đại, dbt là nơi tập trung nhiều metadata quý nhất mà lại hay bị bỏ quên: mô tả cột, quy ước đặt tên, tag phân loại, owner mô hình, và cả quan hệ phụ thuộc giữa các bảng. OpenMetadata có workflow dbt riêng để hút toàn bộ những thứ này vào đồ thị — thay vì để chúng “chết” trong file YAML của repo.

Giá trị thực tế: tài liệu mà kỹ sư dữ liệu đã bỏ công viết trong dbt sẽ tự xuất hiện trong danh mục cho cả người dùng nghiệp vụ, kèm lineage đáng tin từ chính định nghĩa mô hình. Chi tiết tích hợp ở dbt workflow.

Custom connector: cho nguồn “không có sẵn”

Doanh nghiệp Việt Nam thường có hệ thống đặc thù — phần mềm kế toán nội bộ, ERP tùy biến, cơ sở dữ liệu cũ, hay một API riêng — mà danh sách 130+ chưa phủ. Đây là lúc bản chất mã nguồn mở của OpenMetadata phát huy: bạn có thể viết custom connector để thu thập metadata từ bất kỳ nguồn nào, theo cùng chuẩn metadata mở (JSON Schema) như connector chính hãng.

Điều này khác hẳn các nền tảng đóng: ở đó, nếu nhà cung cấp chưa hỗ trợ nguồn của bạn, bạn phải chờ — hoặc trả phí lớn để họ làm. Với OpenMetadata, không bị khóa nhà cung cấp: nguồn nào cũng có thể đưa vào đồ thị nếu bạn (hoặc đối tác như BSD) bỏ công viết. Hướng dẫn khung ở Custom connector.

Giá trị nghiệp vụ: một nơi thấy toàn bộ, tự động cập nhật

Khi lớp kết nối được dựng đúng, doanh nghiệp nhận ba giá trị cốt lõi:

Một nơi thấy toàn bộ — thay vì hỏi từng đội “dữ liệu này ở đâu”, mọi tài sản từ mọi nguồn đều tra cứu được tại một chỗ.
Tự động cập nhật — ingestion chạy theo lịch, nên khi schema đổi, bảng mới sinh ra, hay mô hình dbt thay đổi, catalog không bị lỗi thời. Đây là khác biệt sống còn so với các “tài liệu dữ liệu” thủ công luôn lạc hậu sau vài tuần.
Nền cho mọi module khác — discovery, lineage, quality, governance đều ăn dữ liệu từ lớp này; phủ kết nối tốt thì các module sau mới đáng tin.

Khi nào dùng — và dùng tới đâu

Bắt đầu ngay khi triển khai: tối thiểu một workflow metadata cho nguồn quan trọng nhất (thường là kho dữ liệu chính).
Mở rộng sang BI và pipeline sớm — vì lineage tới báo cáo là thứ lãnh đạo cảm nhận giá trị rõ nhất.
Thêm profiler và auto-classification khi bước vào giai đoạn chất lượng và tuân thủ.
Đầu tư custom connector khi có hệ thống lõi đặc thù không thể bỏ ngoài bức tranh.

Lưu ý về chi phí sở hữu: connector “miễn phí license” không có nghĩa “miễn phí vận hành”. Cần người cấu hình, lên lịch, theo dõi, xử lý khi nguồn đổi cấu trúc. Đây đúng là phần BSD đồng hành.

Ví dụ Việt Nam

Một công ty thương mại điện tử dùng Snowflake làm kho trung tâm, biến đổi dữ liệu bằng dbt, điều phối bằng Airflow, và báo cáo trên Tableau. Trước khi có OpenMetadata, mỗi khi một dashboard doanh thu “ra số lạ”, đội phân tích phải lần ngược thủ công qua dbt và Snowflake mất cả buổi.

Sau khi BSD thiết lập lớp kết nối: workflow metadata + lineage cho Snowflake, workflow dbt cho mô hình biến đổi, connector Airflow cho pipeline, và connector Tableau cho báo cáo — tất cả nối thành một đồ thị liền mạch. Giờ chỉ cần mở dashboard trong OpenMetadata là thấy ngay đường đi từ bảng nguồn → mô hình dbt → bảng đích → biểu đồ Tableau, ai sở hữu khâu nào, và kết quả kiểm thử chất lượng ở từng chặng. Việc truy lỗi rút từ vài giờ xuống vài phút.

Tổng quan Connectors & Ingestion Danh sách 130+ connector, các loại workflow và mẫu cấu hình chung.

dbt Workflow Nhập lineage, mô tả, tag, owner và glossary thẳng từ dự án dbt.

Custom connector Viết connector riêng cho nguồn đặc thù — không bị khóa nhà cung cấp.