Data Mesh 6 — Quản trị liên bang tính toán hoá

13 thg 7, 2026 2 lượt xem
#governance
#data-engineering
#data-mesh
#policy-as-code
#interoperability

Data Mesh 6 — Quản trị liên bang tính toán hoá

Ba nguyên tắc đầu của Data Mesh trao quyền mạnh mẽ cho domain: sở hữu dữ liệu theo miền, coi dữ liệu như sản phẩm với contract rõ ràng, và tự vận hành trên nền tảng tự phục vụ. Nhưng phân quyền tối đa sinh ra một nguy cơ đối xứng: hỗn loạn. Nếu mỗi domain tự quyết mọi thứ — mỗi nơi định nghĩa "khách hàng" một kiểu, mỗi nơi định dạng ngày tháng khác nhau, mỗi nơi tự đặt mức bảo mật PII — thì đến lúc cần join dữ liệu Thẻ với dữ liệu Cho vay để tính tổng dư nợ một khách hàng, bạn phát hiện hai domain không nói cùng một ngôn ngữ. Data Mesh biến thành một đống silo mới, chỉ khác là được gọi tên đẹp hơn.

Nguyên tắc thứ tư — federated computational governance (quản trị liên bang, tính toán hoá) — giải bài toán này. Nó trả lời câu hỏi cốt lõi: làm sao để các domain tự chủ nhưng vẫn kết nối được với nhau và vẫn tuân thủ toàn tổ chức? Câu trả lời gồm hai vế. "Federated" (liên bang) nói về ai ra quyết định và ra ở cấp nào. "Computational" (tính toán hoá) nói về chính sách được thực thi như thế nào — bằng code tự động thay vì tài liệu và duyệt tay.

Bài toán cân bằng: tự chủ vs chuẩn chung

Governance trong Data Mesh nằm giữa hai thái cực, cả hai đều sai:

  • Tập trung hoàn toàn (mô hình cũ): một hội đồng dữ liệu trung tâm duyệt mọi thứ — mọi schema, mọi lần publish, mọi quyền truy cập. Kết quả: nút thắt cổ chai. Domain chờ hàng tuần để được duyệt một thay đổi cột. Governance trở thành phanh, không phải tay lái.
  • Phân tán hoàn toàn (vô chính phủ): mỗi domain tự quyết tất cả. Kết quả: không interoperability. Không join được dữ liệu xuyên domain, không đảm bảo tuân thủ, không ai chịu trách nhiệm tổng thể khi thanh tra NHNN hỏi "dữ liệu PII của khách được bảo vệ thế nào trên toàn ngân hàng".

Mô hình liên bang là điểm cân bằng: chuẩn hoá tối thiểu những gì bắt buộc phải chung để hệ thống kết nối và tuân thủ, còn lại để domain tự do. Nguyên tắc thiết kế: đặt càng ít ràng buộc global càng tốt — nhưng những ràng buộc đó phải đủ mạnh để dữ liệu ghép được với nhau và ngân hàng không vi phạm pháp luật.

Hội đồng liên bang: ai ngồi vào bàn

"Federated" ở đây mượn hình ảnh nhà nước liên bang: có luật chung của liên bang, có luật riêng của từng bang. Cơ chế ra quyết định chung không phải một phòng ban trung tâm áp đặt từ trên xuống, mà là một hội đồng governance (governance guild / council) gồm đại diện của chính những bên bị ảnh hưởng:

Thành phầnVai trò trong hội đồng
Data product owner của mỗi domainMang tiếng nói và ràng buộc thực tế của domain vào; đảm bảo chuẩn chung khả thi khi triển khai
Platform teamBiến quyết định thành năng lực tự động trên nền tảng; cho biết cái gì thực thi được bằng code
Chuyên gia SecurityChuẩn mã hoá, phân loại nhạy cảm, kiểm soát truy cập
Chuyên gia Legal / ComplianceRàng buộc pháp lý: Nghị định 13 về bảo vệ dữ liệu cá nhân, quy định NHNN, lưu trữ chứng từ
Data architect / chuyên gia semanticsChuẩn định danh, mô hình khái niệm chung (customer, account, transaction)

Điểm mấu chốt: domain có ghế trong hội đồng. Chuẩn chung không phải thứ áp từ ngoài vào mà là thứ chính các domain cùng thoả thuận. Nhờ vậy chuẩn vừa khả thi (vì người phải thực thi tham gia soạn), vừa được tôn trọng (vì có tính chính danh). Hội đồng họp định kỳ, ra quyết định về những vấn đề global, và những quyết định đó ràng buộc mọi domain.

Global vs Local: phân định thẩm quyền

Trái tim của governance liên bang là biết quyết định nào thuộc cấp global (bắt buộc chung) và quyết định nào thuộc cấp local (domain tự quyết). Ranh giới chung: nếu một lựa chọn chỉ ảnh hưởng nội bộ domain thì để domain quyết; nếu nó ảnh hưởng đến khả năng kết nối, bảo mật hay tuân thủ của toàn tổ chức thì phải là global.

Quyết định GLOBAL (bắt buộc mọi domain tuân theo)

  • Định danh chung (global identifiers): customer_id phải là cùng một định danh khách hàng trên toàn ngân hàng. Đây là điều kiện tiên quyết để join dữ liệu xuyên domain.
  • Định dạng chuẩn (interoperability formats): kiểu ngày DATE theo ISO 8601, mã tiền tệ theo ISO 4217 (VND, USD), timezone chuẩn, mã hoá ký tự UTF-8.
  • Chuẩn metadata: mọi data product phải khai báo owner, mô tả, schema, phân loại nhạy cảm, SLO — theo một khuôn metadata thống nhất để catalog và lineage hoạt động.
  • Chính sách bảo mật & PII: dữ liệu cá nhân (CMND/CCCD, số điện thoại, địa chỉ) phải được gán tag, mã hoá và kiểm soát truy cập theo quy định chung — không domain nào được nới lỏng.
  • SLO tối thiểu: mọi data product hạng "được chia sẻ" phải đạt sàn tối thiểu về tươi mới (freshness), độ đầy đủ và tính sẵn sàng.

Quyết định LOCAL (domain tự chủ)

  • Mô hình dữ liệu nội bộ: domain Thẻ tự quyết cách phân rã bảng, cách đặt tên cột nội bộ, kỹ thuật partition, cách tính chỉ số riêng.
  • Công nghệ triển khai bên trong: dùng dbt hay Spark, layout Bronze/Silver/Gold cụ thể ra sao.
  • Ngữ nghĩa nghiệp vụ riêng: định nghĩa "thẻ hoạt động" của domain Thẻ là chuyện của domain Thẻ, miễn khai báo rõ trong contract.

Nói ngắn gọn: global chuẩn hoá các "đường ghép" giữa các domain; local để domain tự do bên trong "hộp" của mình. Domain chỉ phải phơi ra thế giới bên ngoài một customer_id chuẩn và một schema có tag PII đúng — bên trong nó tổ chức dữ liệu thế nào là quyền của nó.

Computational: nhúng chính sách thành CODE

Đây là chữ khiến governance của Data Mesh khác biệt căn bản với governance truyền thống. "Computational" nghĩa là chính sách được biểu diễn thành code và được nền tảng tự động thực thi, thay vì nằm trong tài liệu Word và phụ thuộc con người duyệt tay.

Governance kiểu cũ ở nhiều ngân hàng: có một bộ "Chính sách quản trị dữ liệu" dài 80 trang, ai vi phạm thì... phát hiện sau qua audit thủ công, thường là sau khi sự cố đã xảy ra. Chính sách là tài liệu thụ động — nó mô tả điều nên làm nhưng không tự ngăn điều sai.

Governance tính toán hoá biến chính sách thành policy as code — luật lệ thực thi tự động ngay tại thời điểm tạo, publish và truy cập data product:

Những gì nền tảng tự động thực thi, thay cho duyệt tay:

  • Kiểm tra khi tạo/publish: khi domain đẩy một data product, pipeline CI chạy các check tự động — schema có khai đủ metadata bắt buộc? định danh có dùng customer_id chuẩn? SLO có được khai báo? Không đạt thì chặn publish, không cần ai review thủ công.
  • Quét PII tự động (PII scanning): nền tảng quét dữ liệu và schema, nhận diện cột chứa dữ liệu cá nhân (theo pattern CCCD, số thẻ, số điện thoại) rồi tự gán tag nhạy cảm. Đây là quét giám sát tự động, không phải chỉ ghi trong tài liệu.
  • Access control tự động: dựa trên tag nhạy cảm, nền tảng tự áp masking/mã hoá và luật phân quyền theo vai trò — liên quan trực tiếp tới kiểm soát truy cập đã bàn.
  • Kiểm tra định kỳ (continuous): chính sách không chỉ chạy một lần lúc publish mà chạy liên tục — nếu một data product tụt xuống dưới SLO hoặc xuất hiện cột PII chưa tag, hệ thống cảnh báo.

Sức mạnh nằm ở chỗ: chính sách được viết một lần bởi hội đồng, rồi thực thi hàng nghìn lần tự động cho mọi domain, đồng đều và không mệt mỏi. Đây cũng là lý do platform team ngồi trong hội đồng — họ là người biến quyết định chính sách thành cơ chế thực thi trên nền tảng.

Interoperability: định danh chung để join xuyên domain

Mục tiêu cuối cùng của mọi chuẩn global là interoperability — khả năng dữ liệu của các domain khác nhau ghép lại thành một bức tranh thống nhất. Chìa khoá là các global entity (thực thể toàn cục) và định danh chung.

customer_id là ví dụ điển hình. Nếu domain Thẻ gọi khách là card_holder_id, domain Cho vay gọi là borrower_ref, domain Tiền gửi gọi là depositor_no, và cả ba dùng giá trị khác nhau cho cùng một người, thì không tài nào tính được tổng quan hệ của một khách hàng với ngân hàng. Chuẩn global bắt buộc: mọi domain khi nhắc đến khách hàng đều phải phơi ra customer_id chuẩn của Master Data Management, dù bên trong domain đó gọi tên nội bộ là gì.

Trong mô hình dữ liệu ngân hàng của sandbox, customer_id chính là chiếc khoá ghép này — muốn có tên khách phải join qua nó (chú ý bảng accountstransactions không mang sẵn tên khách):

-- ▶ Chạy được
SELECT c.city,
       COUNT(DISTINCT c.id)   AS so_khach,
       COUNT(a.id)            AS so_tai_khoan,
       SUM(a.balance)         AS tong_so_du
FROM customers c
JOIN accounts a ON a.customer_id = c.id
GROUP BY c.city
ORDER BY tong_so_du DESC;

Câu này minh hoạ điều mà governance liên bang bảo vệ ở quy mô toàn ngân hàng: chỉ khi customer_id (ở đây là customers.id) là chuẩn chung thì việc gộp tài khoản, số dư, giao dịch của cùng một khách xuyên nhiều domain mới cho kết quả đúng. Ngoài định danh, các chuẩn interoperability khác gồm: mã tiền tệ (currency theo ISO 4217), định dạng thời gian, và một bộ metadata thống nhất để catalog và lineage tự động kết nối các data product thành một đồ thị dữ liệu toàn tổ chức.

Liên hệ tuân thủ ngân hàng Việt Nam

Với ngân hàng, governance liên bang không phải lựa chọn "hay thì làm" mà là điều kiện sống còn để vừa nhanh vừa tuân thủ. Bối cảnh pháp lý Việt Nam đặt ra ràng buộc cứng:

  • Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân: yêu cầu phân loại, bảo vệ, kiểm soát xử lý dữ liệu cá nhân — chính là loại chính sách phải nhúng thành policy as code (quét PII, gán tag, mã hoá, kiểm soát truy cập tự động).
  • Quy định NHNN về an toàn hệ thống thông tin, lưu trữ chứng từ, báo cáo giám sát: đòi hỏi SLO tối thiểu, lineage đầy đủ và khả năng truy vết.

Nếu ngân hàng để mỗi domain tự lo tuân thủ theo cách riêng, thanh tra sẽ thấy tám mức độ bảo vệ PII khác nhau và không ai đảm bảo được tính đồng nhất. Governance liên bang tính toán hoá cho phép hội đồng đặt chuẩn tuân thủ một lần (global) rồi nền tảng ép mọi domain tuân theo tự động — không domain nào có thể publish một data product chứa CCCD chưa mã hoá, vì cổng policy as code sẽ chặn. Đây là cách dung hoà tốc độ (domain vẫn tự chủ, không chờ duyệt) với tuân thủ (chuẩn được ép cứng bằng code).

Use case thực tế

Bối cảnh. Ngân hàng có 8 domain dữ liệu. Trước khi áp governance liên bang, mỗi lần muốn tạo một data product mới, domain phải gửi email cho phòng Quản trị dữ liệu trung tâm chờ duyệt schema và quyền — trung bình 9 ngày làm việc một lần duyệt. Đồng thời, một đợt kiểm tra nội bộ phát hiện 3/8 domain đang lưu số CCCD ở dạng plaintext, vi phạm Nghị định 13.

Triển khai. Hội đồng liên bang (8 data product owner + platform + security + compliance) được lập, ra 5 quyết định global: (1) định danh khách hàng bắt buộc dùng customer_id từ MDM; (2) khuôn metadata bắt buộc (owner, mô tả, phân loại, SLO); (3) mọi cột PII phải có tag và mã hoá; (4) SLO tối thiểu cho data product chia sẻ; (5) định dạng ngày/tiền tệ chuẩn. Platform team biến 5 quyết định này thành các check trong pipeline publish.

Kết quả sau 4 tháng (số liệu minh hoạ):

Chỉ sốTrướcSau
Thời gian duyệt tạo data product~9 ngày (duyệt tay)Vài phút (check tự động, không cần duyệt tay)
Domain lưu CCCD plaintext3/80/8 (cổng chặn publish)
Data product join được xuyên domain qua customer_id~40%100% (bắt buộc global)
Cột PII được gán tag tự độngthủ công, không đầy đủquét & tag tự động toàn bộ

Điểm cốt lõi: nút thắt duyệt tay biến mất nhưng mức tuân thủ tăng lên — vì chính sách chuyển từ "con người kiểm sau" sang "code chặn trước".

Ghi nhớ

  • Federated computational governance cân bằng giữa tự chủ domainchuẩn chung: chuẩn hoá tối thiểu những gì bắt buộc phải chung, còn lại để domain tự do.
  • Hai thái cực đều sai: tập trung hết → nút thắt; phân tán hết → hỗn loạn không kết nối được.
  • Federated: hội đồng gồm đại diện các domain + platform + security + legal/compliance cùng ra quyết định chuẩn chung; domain có ghế trong bàn nên chuẩn vừa khả thi vừa chính danh.
  • Global (bắt buộc chung): định danh chung, định dạng interoperability, chuẩn metadata, chính sách PII/bảo mật, SLO tối thiểu. Local (domain tự quyết): mô hình dữ liệu nội bộ, công nghệ, ngữ nghĩa riêng.
  • Ranh giới: cái gì ảnh hưởng kết nối/bảo mật/tuân thủ toàn tổ chức thì global; cái gì chỉ ảnh hưởng nội bộ domain thì local.
  • Computational: nhúng chính sách thành code tự động thực thi (policy as code) — kiểm tra khi publish, quét PII, gán tag, access control tự động — thay cho tài liệu và duyệt tay.
  • Interoperability dựa trên global entity như customer_id: chỉ khi định danh là chuẩn chung mới join được dữ liệu xuyên domain.
  • Với ngân hàng VN: chuẩn chung + tự động thực thi là cách vừa nhanh (domain không chờ duyệt) vừa tuân thủ (Nghị định 13, NHNN được ép cứng bằng code).

Bài viết liên quan

CSV/JSON/Parquet/Avro, lưu trữ theo hàng vs cột, nén, và OLTP vs OLAP.

13 thg 7, 2026 8

Data Engineering là gì, vai trò trong vòng đời dữ liệu, và bức tranh hệ sinh thái công cụ.

13 thg 7, 2026 5

Vì sao xử lý phân tán, mô hình Spark (RDD/DataFrame), lazy evaluation, shuffle và tối ưu.

13 thg 7, 2026 5

Đảm bảo chất lượng & minh bạch dữ liệu bằng dbt: data tests dựng sẵn (unique, not_null, relationships, accepted_values), singular test, unit test, và tài liệu tự sinh kèm lineage graph.

13 thg 7, 2026 5