Data Mesh 5 — Nền tảng dữ liệu tự phục vụ

Hai nguyên tắc đầu của Data Mesh trao cho domain rất nhiều quyền và trách nhiệm: sở hữu dữ liệu theo miền nghiệp vụ và coi dữ liệu như một sản phẩm có contract, có SLO. Nhưng nếu dừng ở đó, ta sẽ đâm vào một bức tường thực tế: domain team hiểu nghiệp vụ, không phải chuyên gia hạ tầng. Bạn không thể bắt team Thẻ tự dựng cluster Spark, tự cấu hình Kafka, tự viết Terraform cho warehouse, tự đấu nối catalog và tự vận hành orchestration — rồi cả team Cho vay, team Tiền gửi, team Rủi ro cũng làm y hệt như thế. Nếu mỗi domain tự dựng hạ tầng riêng, kết quả là trùng lặp khổng lồ, tốn kém, không đồng nhất và không thể quản trị — chính là bức tranh silo mà Data Mesh muốn xoá.

Nguyên tắc thứ ba — self-serve data platform (nền tảng dữ liệu tự phục vụ) — giải bài toán này. Ý tưởng: có một platform team chuyên trách xây dựng một nền tảng chung, đóng gói mọi năng lực hạ tầng phức tạp thành các dịch vụ và công cụ mà domain team dùng được mà không cần biết bên dưới vận hành ra sao. Domain tập trung vào giá trị nghiệp vụ; hạ tầng trở thành thứ "có sẵn, bấm là ra".

Vì sao cần nền tảng chung: bài toán trùng lặp

Hãy hình dung một ngân hàng có 8 domain dữ liệu, mỗi domain có 3–4 kỹ sư. Nếu không có nền tảng chung, mỗi domain sẽ phải tự giải cùng một tập vấn đề:

• Dựng và bảo trì nơi lưu trữ + tính toán (warehouse/lakehouse).
• Viết pipeline ingestion từ core banking, từ hệ thống thẻ, từ CRM.
• Cấu hình orchestration (Airflow/Dagster) và tự vận hành scheduler.
• Đấu nối catalog, thiết lập lineage, đo chất lượng.
• Cấu hình phân quyền, mã hoá, che dữ liệu PII cho đúng quy định.

Tám domain nhân với chừng ấy việc = tám bản Airflow cấu hình khác nhau, tám cách đặt tên bảng, tám mức độ bảo mật không đồng đều, tám nơi để lỗi. Chi phí không chỉ là tiền hạ tầng mà là năng lực kỹ sư bị đốt vào việc không tạo giá trị nghiệp vụ. Một data engineer giỏi nghiệp vụ thẻ lại đi debug YAML của Airflow — đó là lãng phí.

Nền tảng chung giải quyết bằng cách giải quyết mỗi vấn đề đúng một lần, ở một nơi, bởi những người giỏi nhất về hạ tầng, rồi cho tất cả domain dùng lại. Đây là logic kinh tế quy mô (economies of scale) áp dụng vào năng lực kỹ thuật.

Platform như một SẢN PHẨM NỘI BỘ

Điểm mấu chốt — và cũng là chỗ nhiều tổ chức làm sai — là platform phải được xây như một sản phẩm, với domain team là khách hàng. Đây không phải một đội IT nhận ticket rồi làm; đây là một product team có tư duy sản phẩm hệt như tư duy data-as-product đã bàn, nhưng "sản phẩm" ở đây là developer experience (trải nghiệm của kỹ sư domain).

Thước đo thành công của platform không phải "có bao nhiêu tính năng" mà là:

• Time-to-first-data-product: một domain team mới cần bao lâu để ra được data product đầu tiên? Mục tiêu là kéo từ hàng tháng xuống hàng ngày.
• Cognitive load (tải nhận thức): domain phải học bao nhiêu thứ hạ tầng để làm việc? Càng ít càng tốt.
• Adoption (tỷ lệ dùng): domain có tự nguyện dùng nền tảng, hay lách ra tự làm riêng vì nền tảng khó dùng?

Nếu domain team phải mở ticket chờ platform team làm hộ từng việc, thì đó không phải self-serve — đó là dịch vụ tập trung đội lốt nền tảng, và nó sẽ tái tạo đúng cái nút thắt mà Data Mesh muốn phá.

Các nhóm năng lực nền tảng cung cấp

Một self-serve data platform trưởng thành cung cấp các nhóm năng lực (capability) xếp thành nhiều lớp. Domain "lắp ráp" data product của mình từ các năng lực này.

1. Lưu trữ & tính toán (storage & compute)

Nền tảng cung cấp một lakehouse hoặc warehouse chung: nơi domain lưu và truy vấn dữ liệu mà không cần tự quản lý cluster. Domain xin một "không gian" (schema/database, bucket, warehouse ảo) và có tài nguyên tính toán co giãn theo nhu cầu, có kiểm soát chi phí. Bên dưới là chuyện của platform team; domain chỉ thấy một endpoint để ghi và đọc.

2. Ingestion / ELT

Bộ connector chuẩn để đưa dữ liệu từ hệ nguồn vào: từ core banking (thường qua CDC), từ Kafka, từ file, từ API. Domain khai báo nguồn và đích thay vì tự viết lại logic ingestion từ đầu. Change Data Capture (CDC — bắt thay đổi dữ liệu) là năng lực đặc biệt đáng đóng gói vì rất khó làm đúng.

3. Orchestration

Năng lực lập lịch và quản lý phụ thuộc giữa các bước xử lý (Airflow, Dagster...). Domain định nghĩa pipeline của mình (chạy gì, khi nào, phụ thuộc gì) nhưng không phải tự vận hành scheduler, không phải lo scaling worker, không phải bảo trì hạ tầng orchestration. Platform cung cấp orchestration "as a service".

4. Transformation

Khung để build, test và triển khai các model biến đổi dữ liệu (thường là dbt hoặc tương đương), tích hợp CI/CD. Domain viết logic SQL/transform, nền tảng lo môi trường chạy, kiểm thử tự động và triển khai an toàn.

5. Catalog & discovery

Nơi data product được đăng ký, mô tả, tìm kiếm và tra cứu lineage (dòng chảy dữ liệu). Đây là năng lực biến các data product rời rạc thành một "mesh" thật sự có thể tìm ra và dùng lại nhau. Domain xuất bản data product và nó tự động hiện trên catalog cho cả tổ chức.

6. Observability & DQ (data quality)

Giám sát pipeline (chạy đúng giờ, không lỗi), và kiểm thử chất lượng dữ liệu (freshness, completeness, tính hợp lệ). Domain khai báo các luật chất lượng và ngưỡng SLO; nền tảng đo, cảnh báo và hiển thị. Điều này giúp cam kết SLO của data product không chỉ là lời hứa suông.

7. Quản lý truy cập & bảo mật (access & security)

Phân quyền theo vai trò, mã hoá, và che/ẩn dữ liệu nhạy cảm (masking PII). Với ngân hàng đây là năng lực bắt buộc và không thể để mỗi domain tự chế. Nền tảng cung cấp cơ chế chuẩn để mọi data product tuân thủ quy định (bảo mật thông tin khách hàng, phân loại dữ liệu) một cách nhất quán.

8. Tạo & đăng ký data product (self-serve provisioning)

Đây là lớp "keo dán" ở trên cùng: template, Infrastructure-as-Code (IaC), CLI hoặc portal để domain khởi tạo một data product mới chỉ bằng vài lệnh hoặc vài cú click. Ví dụ minh hoạ (không phải lệnh thật của một công cụ cụ thể):

# minh hoạ: khởi tạo data product mới từ template chuẩn
dpctl init --domain the --name card_transactions_360 \
  --template output-port \
  --storage lakehouse --sla-freshness 30m

Một lệnh như vậy sẽ tự động cấp không gian lưu trữ, tạo repo với cấu trúc chuẩn, đấu sẵn orchestration, đăng ký lên catalog và bật giám sát DQ mặc định. Đây chính là chỗ "time-to-first-data-product" rút từ tháng xuống ngày.

Paved road / golden path — con đường mặc định tốt

Một khái niệm cốt lõi của platform hiện đại là paved road (con đường trải nhựa) hay golden path (con đường vàng): cách làm mặc định mà nền tảng khuyến khích, đã được tối ưu sẵn về bảo mật, chất lượng và vận hành.

Ý tưởng: domain đi theo con đường mặc định thì mọi thứ "tự đúng" — bảo mật đã cấu hình chuẩn, catalog tự đăng ký, DQ tự bật, tuân thủ có sẵn. Đi lệch khỏi paved road vẫn được phép (đây là nền tảng, không phải nhà tù), nhưng khi đó domain phải tự chịu trách nhiệm nhiều hơn.

Paved road khác với "một con đường duy nhất bắt buộc" ở chỗ nó dùng cây gậy và củ cà rốt: củ cà rốt là đi theo đường mặc định thì nhanh và dễ; cây gậy là đi lệch thì tự lo. Phần lớn team sẽ tự nguyện chọn con đường dễ. Đây là cách nền tảng đạt tính nhất quán mà không cần ép buộc cứng nhắc — rất hợp với tinh thần federated governance sẽ bàn ở bài sau.

Ranh giới trách nhiệm: platform vs domain

Đây là ranh giới quan trọng nhất phải vẽ rõ để tránh nhầm lẫn quyền và trách nhiệm:

Nguyên tắc một câu: platform team cung cấp năng lực nhưng KHÔNG sở hữu dữ liệu; domain team dùng năng lực và SỞ HỮU dữ liệu. Platform không được biến thành nơi "làm hộ pipeline cho domain" — vì như thế trách nhiệm dữ liệu lại rơi về trung tâm, đúng cái Data Mesh muốn tránh. Platform cũng có SLA của riêng nó (uptime, độ trễ cấp phát), y như một data product — vì với domain, platform chính là một sản phẩm.

Tránh biến nền tảng thành nút thắt mới

Rủi ro lớn nhất của mô hình này là nền tảng tự nó trở thành nút thắt (bottleneck) mới. Nếu platform team phải xử lý mọi yêu cầu qua ticket, thì bạn chỉ chuyển nút thắt từ "đội warehouse trung tâm" sang "đội platform trung tâm" — không giải quyết được gì.

Dấu hiệu nền tảng đang thành nút thắt:

• Domain phải mở ticket và chờ platform team làm hộ.
• Mọi thay đổi nhỏ đều cần platform team can thiệp.
• Domain bắt đầu lách ra ngoài tự dựng hạ tầng riêng vì nền tảng quá chậm hoặc quá khó — đây là tín hiệu tử vong.

Cách phòng tránh: mọi năng lực phải truy cập được qua API/CLI/portal, tự phục vụ, không cần người can thiệp; ưu tiên tự động hoá và template hơn là làm thủ công; đo adoption và developer experience như KPI thật sự của platform team; và giữ platform team nhỏ nhưng chất — họ xây công cụ, không phải chạy việc thay domain.

Use case thực tế

Bối cảnh: NCB có 8 domain dữ liệu (Thẻ, Cho vay, Tiền gửi, Thanh toán, CRM, Rủi ro, Chống rửa tiền, Báo cáo tuân thủ). Trước đây, mỗi domain muốn ra một data product mới mất trung bình 6–10 tuần: 2 tuần xin cấp môi trường và tài nguyên tính toán qua ticket, 2 tuần dựng pipeline ingestion + orchestration, 1–2 tuần đấu catalog và lineage, 2 tuần làm phân quyền và masking PII cho đúng quy định. Mỗi domain làm mỗi kiểu; kiểm toán nội bộ phát hiện 3 domain cấu hình masking không đồng nhất — rủi ro tuân thủ.

Giải pháp — dựng self-serve platform với paved road. Platform team (6 người) đóng gói:

• Lakehouse chung + compute co giãn, cấp phát bằng IaC.
• Template output-port chuẩn: khởi tạo repo, orchestration, catalog và DQ mặc định.
• Masking PII và phân quyền có sẵn trong paved road — data product đi theo đường mặc định là tự động tuân thủ.

Kết quả (minh hoạ):

Domain Thẻ tạo data product card_transactions_360 bằng một lệnh khởi tạo từ template: trong 3 ngày đã có pipeline chạy, đăng ký catalog, giám sát DQ và masking số thẻ tự động — thay vì 8 tuần như trước. Platform team không sở hữu dữ liệu thẻ; họ chỉ đảm bảo nền tảng chạy. Domain Thẻ vẫn chịu trách nhiệm về contract và tính đúng của dữ liệu.

Ghi nhớ

• Nguyên tắc 3 = self-serve data platform: giúp domain tự chủ tạo và vận hành data product mà không cần chuyên gia hạ tầng riêng.
• Nếu mỗi domain tự dựng hạ tầng thì trùng lặp, tốn kém, không nhất quán, khó quản trị — giải mỗi vấn đề đúng một lần ở nền tảng chung.
• Platform là sản phẩm nội bộ, khách hàng là domain team; thước đo là developer experience và time-to-first-data-product (tháng → ngày).
• Các nhóm năng lực: storage/compute, ingestion/ELT, orchestration, transformation, catalog & discovery, observability & DQ, access & security, và self-serve provisioning (template/IaC/CLI).
• Paved road / golden path: con đường mặc định đã tối ưu sẵn bảo mật + chất lượng + tuân thủ; đi theo thì nhanh và tự đúng, đi lệch được phép nhưng tự chịu trách nhiệm.
• Ranh giới then chốt: platform cung cấp năng lực nhưng không sở hữu dữ liệu; domain dùng năng lực và sở hữu dữ liệu.
• Rủi ro lớn nhất: nền tảng thành nút thắt mới. Tránh bằng self-serve qua API/CLI/portal, tự động hoá, đo adoption, giữ platform team nhỏ mà chất — xây công cụ, không làm hộ.
• Bối cảnh ngân hàng: nền tảng chung giúp mọi domain ra data product nhanh và tuân thủ có sẵn (masking PII, phân quyền chuẩn trong paved road).