Kiến trúc & cách hoạt động của OpenMetadata

Dành cho ai: người đã đọc Bài 1 — OpenMetadata là gì và muốn hiểu “bên trong nó gồm những gì, metadata chảy ra sao”. Bài này không yêu cầu biết lập trình — mọi thứ giải thích bằng ẩn dụ, phần kỹ thuật chỉ để bạn nói chuyện được với đội IT.

1. Nhìn tổng thể trong một bức tranh

Bạn có thể hình dung OpenMetadata như một tòa nhà thư viện 4 tầng:

        ┌───────────────────────────────────────────┐
        │  4. Giao diện Web (UI - React)            │  ← nơi con người tra cứu
        ├───────────────────────────────────────────┤
        │  3. Máy chủ API (Server - Java/Dropwizard)│  ← "bộ não", xử lý mọi yêu cầu
        ├──────────────────────┬────────────────────┤
        │  2a. Kho metadata    │  2b. Bộ tìm kiếm    │
        │  (MySQL/PostgreSQL)  │  (Elasticsearch/    │
        │                      │   OpenSearch)       │
        └──────────────────────┴────────────────────┘
                        ▲
                        │  đẩy metadata lên qua API
        ┌───────────────┴───────────────────────────┐
        │  1. Khung thu nạp (Ingestion - Python)    │  ← đi "gom" metadata về
        │     chạy định kỳ bằng Airflow             │
        └───────────────────────────────────────────┘
                        ▲
              quét metadata từ các hệ thống của bạn
        ┌───────────────────────────────────────────┐
        │  MySQL · Snowflake · Power BI · Kafka ...  │  ← nguồn dữ liệu (130+ loại)
        └───────────────────────────────────────────┘

Từ dưới lên: ingestion đi gom → server nhận và lưu → search đánh chỉ mục → UI hiển thị cho người dùng. Ta đi qua từng thành phần.

2. Năm thành phần cốt lõi

2.1. Máy chủ (Server) — “bộ não”

Viết bằng Java (khung Dropwizard). Đây là trung tâm: nhận mọi yêu cầu qua API, kiểm tra đăng nhập/phân quyền, áp các quy tắc nghiệp vụ, đọc–ghi vào database và bộ tìm kiếm. UI và ingestion đều nói chuyện với server, không bao giờ đụng thẳng vào database.

2.2. Kho metadata (Metadata Store) — “kho sách”

Một cơ sở dữ liệu quan hệ: MySQL hoặc PostgreSQL. Đây là “nguồn sự thật” (source of truth) lưu toàn bộ metadata: bảng, cột, mô tả, chủ sở hữu, thẻ, glossary, lineage… Người mới cứ chọn MySQL (mặc định).

2.3. Bộ tìm kiếm (Search) — “thủ thư siêu nhanh”

Elasticsearch hoặc OpenSearch. Nó giữ một bản sao đã đánh chỉ mục của metadata để khi bạn gõ từ khóa, kết quả trả về trong tích tắc. Nói cách khác: dữ liệu gốc nằm ở MySQL, nhưng khả năng tìm kiếm nhanh đến từ Elasticsearch. Server chịu trách nhiệm giữ hai bên đồng bộ.

2.4. Khung thu nạp (Ingestion Framework) — “người đi gom sách”

Viết bằng Python. Đây là phần chủ động đi ra ngoài, kết nối tới các hệ thống của bạn, đọc metadata (KHÔNG copy dữ liệu thật — xem mục 5), rồi đẩy về server qua API. Nó có thể chạy theo lịch nhờ Apache Airflow (một công cụ lập lịch chạy tác vụ).

2.5. Giao diện Web (UI) — “quầy tra cứu”

Viết bằng React. Đây là nơi con người tương tác: tìm kiếm, xem chi tiết bảng, vẽ lineage, gắn thẻ, thảo luận. UI chỉ gọi API của server, không tự xử lý logic.

Ghi nhớ 1 câu: Ingestion gom về → Server lưu vào MySQL và đánh chỉ mục lên Elasticsearch → UI hiển thị.

3. Metadata “chảy” như thế nào? (luồng end-to-end)

Lấy ví dụ bạn muốn OpenMetadata biết về kho dữ liệu bán hàng đặt trên PostgreSQL:

Cấu hình connector: trong UI, bạn khai báo một kết nối tới PostgreSQL (host, user chỉ-đọc, database).
Chạy ingestion: Airflow kích hoạt tác vụ Python. Nó đăng nhập PostgreSQL, đọc danh sách schema, bảng, cột, kiểu dữ liệu, khóa…
Đẩy về server: ingestion gửi metadata đó tới API của server.
Lưu & đánh chỉ mục: server ghi vào MySQL (kho gốc) và đồng bộ sang Elasticsearch (để tìm kiếm).
Hiển thị: bạn mở UI, gõ “sales”, thấy ngay bảng vừa được nạp, kèm schema và (nếu bật) mẫu dữ liệu, thống kê.
Chạy lại định kỳ: đặt lịch (ví dụ mỗi đêm) để metadata luôn cập nhật khi cấu trúc dữ liệu thay đổi.

Đây gọi là mô hình “pull” (kéo): OpenMetadata chủ động đi kéo metadata về theo lịch, thay vì chờ hệ thống khác gửi tới.

4. Connector là gì và có những loại nào?

Connector (đầu nối) là đoạn tích hợp giúp ingestion “biết cách đọc” một loại hệ thống cụ thể. OpenMetadata có hơn 130 connector, chia thành các nhóm chính:

Nhóm	Ví dụ hệ thống
Database	MySQL, PostgreSQL, Oracle, SQL Server, MongoDB
Kho dữ liệu (Warehouse)	Snowflake, BigQuery, Redshift, Databricks
Công cụ BI / Dashboard	Power BI, Tableau, Looker, Metabase, Superset
Pipeline / ETL	Airflow, dbt, Dagster, NiFi
Messaging (luồng)	Kafka, Redpanda, Kinesis
ML / AI	MLflow, SageMaker
Lưu trữ / Data Lake	S3, GCS, ADLS

Nhiều khả năng phần lớn hệ thống công ty bạn đã nằm trong danh sách này. Nếu có hệ thống lạ, OpenMetadata còn cho phép nạp metadata thủ công qua API/CSV.

5. Một hiểu lầm quan trọng cần gỡ: OpenMetadata KHÔNG copy dữ liệu của bạn

Đây là câu hỏi bảo mật mà sếp/IT chắc chắn sẽ hỏi.

OpenMetadata chỉ đọc metadata (cấu trúc: tên bảng, tên cột, kiểu dữ liệu, thống kê) — không sao chép nội dung dữ liệu thật về kho của nó.
Có hai tính năng tùy chọn có chạm tới dữ liệu, nhưng bạn toàn quyền bật/tắt:
- Profiler & Sampling: lấy mẫu nhỏ và số liệu thống kê (min/max, tỷ lệ rỗng…) để đánh giá chất lượng. Có thể tắt, hoặc giới hạn số dòng mẫu.
- Data Quality tests: chạy truy vấn kiểm tra trên nguồn.
Nên cấp cho ingestion tài khoản chỉ-đọc (read-only) trên nguồn — nguyên tắc “quyền tối thiểu”.

Thông điệp cho IT: “Nó là cuốn mục lục thư viện, không phải bản photo toàn bộ sách.”

6. “Metadata Graph” — vì sao OpenMetadata mạnh

Thay vì lưu các bảng rời rạc, OpenMetadata mô hình hóa mọi thứ thành một đồ thị (graph): các “thực thể” (bảng, cột, dashboard, người dùng, glossary term, thẻ…) được nối với nhau bằng các quan hệ.

Nhờ đồ thị này, OpenMetadata trả lời được những câu mà database thường không:

“Cột doanh thu trên dashboard này lấy từ cột nào của bảng nào?” → đi theo cạnh lineage.
“Ai chịu trách nhiệm mọi tài sản chứa dữ liệu khách hàng?” → đi theo cạnh owner + tag PII.
“Đổi bảng nguồn X thì hỏng những báo cáo nào?” → duyệt xuôi đồ thị (phân tích tác động).

Toàn bộ thực thể được định nghĩa bằng một chuẩn mở dựa trên JSON Schema — nghĩa là “hình dạng” của mỗi loại metadata được đặc tả rõ ràng, giúp OpenMetadata nhất quán và dễ mở rộng. Đây cũng là nền tảng cho hướng “Context Layer cho AI” (5 trụ: Context, Semantics, Knowledge Graph, Memory, Activation) đã nói ở Bài 1.

7. API & MCP — cách “bên ngoài” nói chuyện với OpenMetadata

Mọi thứ trong OpenMetadata đều truy cập được qua:

REST API — cho lập trình viên tự động hóa (nạp metadata, tạo glossary hàng loạt…).
Python SDK — thư viện tiện dụng để viết script.
MCP Server — cổng cho AI agent hỏi metadata bằng ngôn ngữ tự nhiên (ví dụ: “bảng nào chứa doanh thu cửa hàng và ai làm chủ?”).

Điều này nghĩa là OpenMetadata không phải “ốc đảo”: nó có thể là trung tâm mà cả con người, script tự động và trợ lý AI cùng khai thác.

8. Bản thử (Docker) khác bản thật (Production) ở đâu?

	Bản thử — Docker (Bài 3)	Bản thật — Production
Các thành phần	Gộp chung trong Docker Compose trên 1 máy	Tách riêng, chạy trên Kubernetes hoặc nhiều máy
Database & Search	Container tạm	MySQL/PG và Elasticsearch quản trị riêng, có sao lưu
Đăng nhập	admin mặc định	SSO doanh nghiệp (Google, Okta, Azure AD)
Ingestion	Airflow kèm sẵn	Airflow riêng, lịch chạy ổn định
Mục đích	Học, nghịch thử	Vận hành thật, nhiều người dùng, phân quyền

Chi tiết triển khai production và lộ trình sẽ ở Bài 6.

9. Tổng kết

OpenMetadata gồm 5 mảnh: Server (Java) · Kho metadata (MySQL/PG) · Search (Elasticsearch/OpenSearch) · Ingestion (Python + Airflow) · UI (React).
Metadata chảy theo mô hình pull: ingestion đi gom → server lưu + đánh chỉ mục → UI hiển thị.
Connector (130+) là cách kết nối tới từng loại hệ thống; nó đọc metadata, không copy dữ liệu thật.
Sức mạnh đến từ metadata graph + chuẩn JSON Schema, và mở ra ngoài qua API / SDK / MCP.

Bước tiếp theo: đã hiểu bộ máy, hãy cài thử bằng Docker (Bài 3) rồi kết nối nguồn đầu tiên ở Bài 4.

💬 Thảo luận cùng cộng đồng BSD

Bạn định kết nối OpenMetadata với hệ thống nào trước (kho dữ liệu, BI, hay database nghiệp vụ)? Có lo ngại gì về bảo mật/tài nguyên khi triển khai?

👉 Đặt câu hỏi và chia sẻ tại Forum BSD Insights. Mỗi kiến trúc thực tế bạn chia sẻ sẽ giúp người sau bớt mò mẫm.

(Bài viết thuộc loạt “Bắt đầu với OpenMetadata” trên tài liệu BSD.)