Data Mesh 3 — Dữ liệu như một sản phẩm

Ở bài tổng quan chúng ta đã nêu bốn nguyên tắc của Data Mesh, và ở bài về domain ownership đã trao quyền sở hữu dữ liệu về cho từng miền nghiệp vụ. Nhưng trao quyền sở hữu mà không kèm chuẩn mực thì rất dễ tạo ra một mớ silo mới: mỗi miền tự làm dữ liệu theo kiểu của mình, không ai dùng được của ai. Nguyên tắc thứ hai — data as a product (dữ liệu như một sản phẩm) — chính là cơ chế kỷ luật để domain ownership không thoái hoá thành hỗn loạn.

Ý tưởng cốt lõi rất đơn giản nhưng đảo ngược tư duy nhiều team: dữ liệu bạn xuất bản ra cho người khác dùng phải được đối xử như một sản phẩm có khách hàng thật, chứ không phải phụ phẩm (by-product) rơi ra từ pipeline của bạn. Khách hàng ở đây là các data analyst, data scientist, team ML, team báo cáo, hay chính một miền nghiệp vụ khác. Và khi đã gọi là sản phẩm, nó phải có chất lượng, có bảo hành (SLA/SLO), có tài liệu, có người chịu trách nhiệm — y như một API hay một microservice mà team bạn cung cấp.

Từ "by-product" sang "product": đổi tư duy

Trong mô hình data warehouse tập trung truyền thống, đội platform trung tâm hút dữ liệu thô từ mọi hệ nguồn rồi cố gắng làm sạch, mô hình hoá và phục vụ. Team nguồn (ví dụ team Core Banking, team Thẻ) coi việc xuất dữ liệu ra chỉ là nghĩa vụ tuân thủ: đổ file ra, xong việc. Họ không biết ai dùng, dùng để làm gì, và cũng không chịu trách nhiệm nếu dữ liệu sai. Kết quả kinh điển: schema đổi mà không báo, cột bị null bất thường, số dư lệch — và người phát hiện lại là analyst ở cuối chuỗi, ba tuần sau, khi báo cáo đã lên bàn lãnh đạo.

Product thinking đảo ngược điều này. Team nguồn phải hỏi: ai là khách hàng của dữ liệu này? Họ cần gì? Trải nghiệm dùng dữ liệu của tôi tốt tới đâu? Một vài phép so sánh:

Chuẩn đánh giá thực dụng nhất là thời gian để một khách hàng mới khám phá, hiểu, tin và bắt đầu dùng dữ liệu — Zhamak Dehghani (người khai sinh Data Mesh) gọi đây là thước đo trải nghiệm của data product. Nếu một analyst mới vào cần ba ngày hỏi khắp team để hiểu bảng "giao dịch thẻ" thì đó là sản phẩm tồi.

Data product là gì — đơn vị kiến trúc đóng gói

Đây là điểm hay bị hiểu nhầm nhất. Data product KHÔNG phải là một bảng, một dataset, hay một file. Nó là một đơn vị kiến trúc (architectural quantum) — đơn vị nhỏ nhất có thể triển khai và vận hành độc lập — đóng gói cùng lúc mọi thứ cần thiết để cung cấp và duy trì một tập dữ liệu có giá trị. Cụ thể một data product đóng gói:

• Dữ liệu (data) — bản thân các bản ghi, dưới một hoặc nhiều dạng lưu trữ.
• Metadata — schema, mô tả nghiệp vụ, đơn vị tính, phân loại nhạy cảm, thông tin lineage, thông tin liên hệ owner.
• Code biến đổi (transformation code) — pipeline ingest, làm sạch, tính toán tạo ra dữ liệu; code phục vụ (serving); code kiểm thử chất lượng.
• Hợp đồng dữ liệu (data contract) — cam kết chính thức về schema, ngữ nghĩa và mức chất lượng với consumer (xem sâu ở bài về data contracts).
• Chính sách (policy) — kiểm soát truy cập, mã hoá, che (masking), lưu trữ/xoá theo vòng đời — được thực thi tự động (policy as code).
• Hạ tầng (infrastructure) — khai báo tài nguyên lưu trữ, compute, endpoint phục vụ; thường là code (Terraform/IaC) chứ không phải cấu hình thủ công.

Nói cách khác, data product là một "hộp" tự chứa (self-contained), có ranh giới rõ, mà bên trong có cả dữ liệu lẫn tất cả logic và hạ tầng để tạo ra và phục vụ nó. Nếu bạn xoá data product, bạn xoá luôn cả pipeline, storage, và metadata của nó — không để lại "mồ côi".

Input ports và Output ports

Ranh giới của data product được định nghĩa qua các port — điểm giao tiếp chuẩn hoá:

• Input port — nơi data product nhận dữ liệu từ bên ngoài: đọc CDC từ Oracle GoldenGate, subscribe một topic Kafka, poll một API, hay đọc output port của một data product khác. Input port che giấu chi tiết nguồn khỏi consumer.
• Output port — nơi data product cung cấp dữ liệu ra ngoài: một schema SQL/view để query, một REST/GraphQL API, một topic sự kiện, hay một tập file Parquet trên object store. Một data product có thể có nhiều output port cùng phục vụ một tập dữ liệu qua nhiều kênh khác nhau (đây chính là tính "natively accessible" bên dưới).

Điểm mấu chốt: consumer chỉ được phép chạm vào output port, không bao giờ đọc thẳng bảng nội bộ (internal storage) của data product. Nhờ đó team chủ có thể tự do đổi cách lưu trữ, tối ưu bên trong, mà không phá vỡ consumer — miễn là output port giữ đúng contract. Đây chính là nguyên tắc encapsulation mượn từ thiết kế phần mềm.

Tám tính chất của một data product tốt — DATSIS

Cộng đồng Data Mesh đúc kết một checklist tám tính chất mà mọi data product tốt phải có. Sáu chữ đầu ghép thành từ khoá dễ nhớ DATSIS, cộng thêm hai tính chất về bảo mật và giá trị:

Một mẹo phân biệt hay dùng: DATSIS là các phẩm chất về trải nghiệm dùng (usability), còn secure và valuable là điều kiện cần để một data product được phép tồn tại. Thiếu bất kỳ tính chất nào, thứ bạn có chỉ là một dataset thô, không phải data product.

"Understandable" và "trustworthy" trong thực tế

Hai tính chất này quan trọng nên đáng nói kỹ. Self-describing/understandable nghĩa là một analyst chưa từng gặp data product này vẫn hiểu được nó chỉ bằng metadata đi kèm: mỗi cột có mô tả, đơn vị tính, ví dụ giá trị, và các trường enum được liệt kê đủ. Điều này liên hệ chặt với data catalog và business glossary — data product tự mô tả chính là "phiếu thông tin" đầy đủ trong catalog.

Trustworthy nghĩa là data product chủ động công bố mức chất lượng nó cam kết và đo nó liên tục, chứ không để consumer tự đoán. Đây là nơi các kỹ thuật kiểm thử chất lượng dữ liệu (null rate, uniqueness, referential integrity, freshness check) được nhúng thẳng vào code của data product và chạy mỗi lần build.

SLO của một data product

Nếu data product là sản phẩm có "bảo hành", thì bảo hành đó được viết bằng SLO (Service Level Objective) — các mục tiêu chất lượng định lượng, và SLA là cam kết chính thức với consumer kèm hệ quả nếu vi phạm. Vài SLO cốt lõi cho một data product dữ liệu:

• Freshness (độ mới) — dữ liệu trễ tối đa bao lâu so với sự kiện thực tế. VD: "Giao dịch thẻ" cam kết freshness ≤ 15 phút; "Khách hàng 360" ≤ 24 giờ.
• Completeness (độ đầy đủ) — tỷ lệ bản ghi đầy đủ, không thiếu. VD: completeness ≥ 99.9% cho các trường bắt buộc.
• Availability (độ sẵn sàng) — output port trả lời được bao nhiêu % thời gian. VD: API availability ≥ 99.5%/tháng.
• Accuracy / consistency — tỷ lệ bản ghi đúng so với nguồn chân lý; ví dụ đối soát tổng số dư khớp Core Banking.
• Schema stability — cam kết không phá vỡ contract; đổi breaking phải có bản version mới và thời gian chuyển tiếp.

SLO phải đo được và hiển thị — thường trên chính trang của data product trong catalog, dạng bảng điều khiển (dashboard) có màu xanh/đỏ. Consumer nhìn vào biết ngay hôm nay dữ liệu có "khoẻ" không trước khi dùng.

Data product khác gì "dataset" thuần?

Đây là ranh giới cần khắc rõ, vì rất nhiều team gắn nhãn "data product" cho thứ thực ra vẫn chỉ là bảng.

Một cách nói súc tích: dataset là danh từ, data product là danh từ + trách nhiệm + hợp đồng.

Vai trò Data Product Owner

Product thinking chỉ thành thật khi có một người chịu trách nhiệm cuối cùng — Data Product Owner (DPO), tương tự Product Owner trong Agile nhưng cho một tài sản dữ liệu. Trách nhiệm điển hình:

• Hiểu khách hàng: xác định consumer, thu thập nhu cầu, ưu tiên roadmap của data product.
• Định nghĩa và bảo vệ contract & SLO: quyết định schema, ngữ nghĩa, mức chất lượng cam kết.
• Đo lường thành công: theo dõi số lượng consumer, mức độ sử dụng, mức độ hài lòng, thời gian onboard của consumer mới.
• Quản lý vòng đời: quyết định khi nào ra version mới, khi nào deprecate.
• Chịu trách nhiệm chất lượng: là người "trực" khi SLO bị vi phạm.

DPO thường là người thuộc miền nghiệp vụ (ví dụ chuyên viên nghiệp vụ Thẻ) làm việc cùng data engineer trong đội cross-functional của miền — đúng tinh thần domain ownership.

Vòng đời và versioning của data product

Vì là sản phẩm, data product có vòng đời (lifecycle) rõ ràng, không tồn tại vô thời hạn một cách mù mờ:

Versioning tuân nguyên tắc giống semantic versioning của API:

• Thay đổi tương thích ngược (thêm cột mới, thêm output port): tăng minor, consumer cũ không bị ảnh hưởng.
• Thay đổi phá vỡ (đổi kiểu cột, xoá cột, đổi ngữ nghĩa): phải ra version mới (v2) chạy song song với v1 một khoảng thời gian chuyển tiếp (VD 30–90 ngày), báo cho mọi consumer, rồi mới deprecate và retire v1.

Chạy song song hai version là chi phí thật, nhưng đó chính là cái giá của việc coi consumer là khách hàng — bạn không được phép "rút thảm" dưới chân họ.

Output port minh hoạ: tổng hợp giao dịch theo khách hàng

Để hình dung một output port dạng SQL view, hãy xét data product "Khách hàng 360" cần một view tổng hợp hoạt động giao dịch của mỗi khách hàng. Truy vấn dưới đây minh hoạ logic của output port đó (chạy được trên sandbox PostgreSQL của Knowledge Base — join xuyên transactions → accounts → customers):

-- ▶ Chạy được
SELECT c.id,
       c.full_name,
       c.city,
       COUNT(DISTINCT a.id)            AS so_tai_khoan,
       COUNT(t.id)                     AS so_giao_dich,
       COALESCE(SUM(t.amount), 0)      AS tong_gia_tri_gd,
       MAX(t.created_at)               AS gd_gan_nhat
FROM customers c
JOIN accounts a          ON a.customer_id = c.id
LEFT JOIN transactions t ON t.account_id = a.id
GROUP BY c.id, c.full_name, c.city
ORDER BY tong_gia_tri_gd DESC;

Lưu ý thực chiến: consumer chỉ gọi view/output port này với đúng khoá join transactions.account_id → accounts.id và accounts.customer_id → customers.id; họ không phải tự hiểu và join lại các bảng thô. Trong data product thật, view này được đóng gói cùng contract (khai báo tên cột, kiểu, ý nghĩa tong_gia_tri_gd là VND) và SLO freshness ≤ 24h.

Điểm quan trọng về mặt kiến trúc: consumer chỉ gọi view/output port này, không đọc thẳng bảng thô bên dưới. Team chủ có thể thay đổi cách tính, đổi storage, thêm cache — mà consumer không hề hay biết, miễn hình dạng output giữ nguyên theo contract.

Use case thực tế

Bối cảnh. Khối Ngân hàng bán lẻ của NCB muốn xây data product "Khách hàng 360" làm nền cho ba consumer: (1) đội giám sát giao dịch AML, (2) mô hình chấm điểm tín dụng, (3) dashboard chăm sóc khách hàng. Trước đây mỗi đội tự join lại 12 bảng thô từ Core Banking + Thẻ + Tiết kiệm, cho ra ba con số "tổng tài sản khách hàng" khác nhau — một cơn ác mộng đối soát.

Cách làm theo product thinking.

1. Xác định khách hàng & contract. DPO (một chuyên viên khối bán lẻ) họp với ba consumer, chốt schema output: customer_id, full_name, segment, tong_tai_san, so_san_pham, active_flag, updated_at — mỗi trường có định nghĩa và đơn vị rõ (tong_tai_san = VND, cuối ngày T-1).
2. Đóng gói data product. Input ports đọc CDC từ Core Banking + event thẻ; transformation code chuẩn hoá và ghép về một khoá customer_id toàn hàng (tính interoperable); hai output ports: một SQL view cho analyst/ML, một REST API cho app CSKH.
3. Cam kết SLO. Freshness ≤ 24h, completeness ≥ 99.5% (đo mỗi sáng), availability API ≥ 99%. SLO hiển thị trên trang catalog của data product.
4. Bảo mật tại port. CMND/CCCD và số dư bị masking; chỉ role được cấp mới thấy trường nhạy cảm (secure).

Kết quả sau 3 tháng (số minh hoạ). Thời gian onboard một consumer mới giảm từ ~3 ngày (đọc code, hỏi han) xuống ~2 giờ (đọc contract trên catalog, gọi API). Ba con số "tổng tài sản" hội tụ về một nguồn duy nhất, chấm dứt tranh cãi đối soát. Khi hệ Thẻ đổi schema nguồn, contract v1 vẫn giữ nguyên với consumer (team chủ hấp thụ thay đổi bên trong input port); một breaking change bổ sung phân khúc mới được phát hành thành v2 chạy song song 60 ngày trước khi retire v1 — không consumer nào bị gãy.

Ghi nhớ

• Data as a product là nguyên tắc biến domain ownership thành kỷ luật: dữ liệu xuất bản ra phải được đối xử như sản phẩm có khách hàng thật, không phải phụ phẩm của pipeline.
• Data product KHÔNG phải một bảng/dataset. Nó là đơn vị kiến trúc đóng gói: dữ liệu + metadata + code biến đổi + data contract + policy + hạ tầng — tự chứa, triển khai độc lập.
• Consumer chỉ chạm output port (SQL/API/file), không đọc storage nội bộ; nhờ đó team chủ tự do thay đổi bên trong mà không phá consumer.
• Tám tính chất DATSIS + secure + valuable: Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure, natively-accessible, valuable-on-its-own.
• SLO là "bảo hành" định lượng: freshness, completeness, availability, schema stability — phải đo được và công bố trên catalog.
• Data Product Owner chịu trách nhiệm cuối: hiểu khách hàng, giữ contract & SLO, quản vòng đời.
• Versioning như API: đổi tương thích → minor; đổi phá vỡ → version mới chạy song song rồi mới deprecate/retire.
• Trong ngân hàng, "Khách hàng 360" và "Giao dịch thẻ" là ví dụ điển hình của data product có SLA — thống nhất một nguồn chân lý, rút ngắn thời gian onboard consumer từ ngày xuống giờ.