title: "Kiến trúc dữ liệu (Data Architecture): Từ Master Data Management (MDM) đến Data Lakehouse"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 3 — Kỹ thuật thiết kế & Mô hình hóa (Modeling & Artifacts)"
order: 25
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• Data Architecture
• Master Data Management
• Data Lakehouse
• Data Warehouse
• Data Governance
• Enterprise Architecture

Kiến trúc dữ liệu (Data Architecture): Từ Master Data Management (MDM) đến Data Lakehouse

Một công ty bán lẻ có ba hệ thống đều nói "khách hàng A" — CRM gọi là "Nguyễn Văn A", hệ thống bán hàng gọi là "NGUYEN VAN A - 0912xxx", hệ thống chăm sóc khách hàng gọi là "A Nguyễn". Team Marketing gửi campaign trùng ba lần cho cùng một người. Team Data Science build model dự đoán churn nhưng độ chính xác thấp bất thường — vì một khách hàng bị đếm thành ba khách hàng khác nhau trong tập huấn luyện. Không ai sai quy trình, không ai vi phạm chuẩn nào cả — vấn đề là không có ai "sở hữu" định nghĩa khách hàng là gì.

Đây là kịch bản quen thuộc với bất kỳ Enterprise Architect nào đã đi qua đủ số dự án: vấn đề dữ liệu hiếm khi nằm ở công nghệ lưu trữ, mà nằm ở chỗ tổ chức không có một "phiên bản sự thật" (single source of truth) cho các thực thể dữ liệu quan trọng nhất — khách hàng, sản phẩm, nhà cung cấp, nhân viên. Nhiều tổ chức phản xạ bằng cách đổ tiền vào công cụ mới — data lake, data warehouse thế hệ mới, nền tảng AI — trong khi gốc rễ vấn đề là quản trị dữ liệu chủ (master data) chưa từng được thiết kế bài bản.

Ở bài 15, chúng ta đã nói về Data Architecture trong Giai đoạn C của ADM (Architecture Development Method) — cấu trúc và luồng dữ liệu tổng thể của doanh nghiệp. Bài này đào sâu hai trụ cột thường bị nhầm lẫn hoặc đánh đồng: Master Data Management (MDM) — kỷ luật quản trị dữ liệu chủ, và Data Lakehouse — kiến trúc lưu trữ/xử lý dữ liệu hiện đại. Hiểu đúng vị trí và ranh giới của từng thứ là năng lực bắt buộc của một Chief EA khi ngồi cùng CDO (Chief Data Officer) bàn chiến lược dữ liệu.

Bản chất

MDM giải quyết câu hỏi "cái gì là sự thật", không phải "lưu ở đâu"

Master Data Management là kỷ luật quản trị nhằm tạo ra và duy trì một bản ghi thống nhất, chính xác, nhất quán cho các thực thể dữ liệu chủ (master data) — những đối tượng cốt lõi được nhiều hệ thống cùng tham chiếu: Customer, Product, Supplier, Employee, Location, Chart of Account. Master data khác với transactional data (đơn hàng, giao dịch, log sự kiện) ở chỗ nó tương đối ổn định, có vòng đời dài, và là "danh từ" mà các "động từ" nghiệp vụ xoay quanh.

MDM không phải là một database hay một sản phẩm phần mềm cụ thể — nó là sự kết hợp của: quy tắc quản trị (governance), quy trình khớp nối và làm sạch (match & merge, deduplication), mô hình dữ liệu chuẩn hóa (canonical data model), và cơ chế phân phối bản ghi vàng (golden record) tới các hệ thống tiêu thụ. Có ba kiến trúc triển khai MDM phổ biến:

• Registry style: MDM chỉ giữ ID tham chiếu và metadata khớp nối, dữ liệu chi tiết vẫn nằm ở hệ thống nguồn — chi phí thấp, triển khai nhanh, nhưng không có bản ghi vàng đầy đủ.
• Consolidation style: MDM tổng hợp dữ liệu từ nhiều nguồn về một kho trung tâm để phân tích/báo cáo, nhưng hệ thống nguồn vẫn là nơi ghi (write) chính — phổ biến cho BI/reporting.
• Coexistence/Centralized style: MDM trở thành hệ thống ghi (system of record) cho master data, các ứng dụng khác đọc/ghi qua MDM — mạnh nhất về tính nhất quán nhưng tốn kém và đòi hỏi thay đổi quy trình sâu.

Data Lakehouse là kiến trúc lưu trữ và xử lý, không phải kỷ luật quản trị

Trong khi MDM trả lời "đâu là bản ghi đúng của một thực thể", kiến trúc dữ liệu tổng thể (Data Warehouse / Data Lake / Data Lakehouse) trả lời câu hỏi khác: "dữ liệu (đã đúng hay chưa đúng) được lưu trữ, xử lý và phục vụ như thế nào ở quy mô doanh nghiệp".

Data Lakehouse là mô hình kiến trúc kết hợp hai truyền thống từng đối lập nhau:

• Data Warehouse — mạnh về cấu trúc (schema-on-write), hiệu năng truy vấn SQL, quản trị chất lượng chặt chẽ — nhưng cứng nhắc, chi phí lưu trữ cao, khó chứa dữ liệu phi cấu trúc (log, hình ảnh, văn bản), và thường tụt hậu khi nhu cầu phân tích thay đổi nhanh.
• Data Lake — linh hoạt, chi phí lưu trữ thấp (object storage), chứa được mọi định dạng dữ liệu thô (schema-on-read) — nhưng dễ biến thành "data swamp" nếu thiếu quản trị: không ai biết dữ liệu nào đáng tin, không có transaction guarantee, khó phục vụ báo cáo tài chính đòi hỏi độ chính xác cao.

Data Lakehouse dùng các định dạng bảng mở hỗ trợ giao dịch ACID trên nền object storage (kiểu Delta Lake, Apache Iceberg, Apache Hudi) để mang tính năng quản trị/giao dịch của warehouse vào trên nền tảng lưu trữ rẻ và linh hoạt của lake — một hạ tầng dữ liệu duy nhất phục vụ cả BI truyền thống lẫn machine learning/AI, thay vì duy trì hai hệ thống tách biệt và đồng bộ tốn kém giữa chúng.

Điểm mấu chốt EA cần nắm: MDM và Data Lakehouse giải quyết hai vấn đề khác tầng nhau và bổ sung cho nhau, không thay thế nhau. Một Data Lakehouse tuyệt đẹp về công nghệ vẫn có thể chứa ba bản ghi "Nguyễn Văn A" khác nhau nếu không có MDM đứng phía trên quản trị định danh thực thể. Ngược lại, MDM tốt mà không có kiến trúc lưu trữ/xử lý phù hợp thì golden record cũng không đến được tay các ứng dụng phân tích và AI cần nó kịp thời.

Khung & Kỹ thuật áp dụng

So sánh ba mô hình kiến trúc dữ liệu

Vị trí của MDM trong bức tranh tổng thể

MDM không cạnh tranh vị trí với Data Warehouse/Lake/Lakehouse — nó là một lớp quản trị định danh và chất lượng nằm ngang qua toàn bộ kiến trúc dữ liệu, thường được mô hình hóa như sau trong ArchiMate hoặc Data Architecture Catalog (xem lại bài 24):

1. Nguồn (Source systems) — CRM, ERP, hệ thống bán hàng, hệ thống nhân sự — nơi phát sinh dữ liệu chủ.
2. Lớp MDM — thu thập, khớp nối (match/merge), làm sạch, sinh golden record, gắn ID chuẩn hóa, phân phối ngược lại nguồn hoặc xuống các lớp tiêu thụ.
3. Lớp lưu trữ & xử lý phân tích (Warehouse/Lake/Lakehouse) — nhận cả dữ liệu giao dịch và golden record từ MDM, phục vụ báo cáo, phân tích, AI/ML.
4. Lớp tiêu thụ (Consumption) — dashboard BI, mô hình AI, ứng dụng vận hành đọc lại golden record qua API hoặc đồng bộ.

Sai lầm phổ biến nhất mà EA hay gặp: tổ chức triển khai Data Lakehouse xong mới "phát hiện ra" cần MDM, dẫn đến phải làm lại toàn bộ pipeline nhận dữ liệu (ingestion) để chèn bước khớp nối định danh vào giữa. Trình tự đúng theo tư duy TOGAF là xác định các thực thể dữ liệu chủ và nhu cầu MDM ngay từ Phase B/C (Business & Information Systems Architecture), song song với việc chọn mô hình lưu trữ — không phải làm tuần tự trước-sau.

Nguyên tắc chọn mô hình kiến trúc dữ liệu

Một Chief EA khi tư vấn lựa chọn giữa ba mô hình cần đặt câu hỏi theo thứ tự:

1. Tỷ trọng nhu cầu là báo cáo tuân thủ/tài chính ổn định hay phân tích/AI khám phá đang thay đổi nhanh?
2. Dữ liệu chủ yếu có cấu trúc (giao dịch, bảng) hay đa dạng định dạng (log, hình ảnh, văn bản, sự kiện streaming)?
3. Tổ chức có sẵn năng lực vận hành nền tảng dữ liệu mở (data engineering, table format, orchestration) hay phụ thuộc vào nền tảng đóng gói sẵn?
4. Chi phí tổng thể (TCO) tính cả lưu trữ, compute, license, và chi phí duy trì hai hệ thống song song (nếu chọn giữ cả warehouse lẫn lake riêng biệt) là bao nhiêu so với hợp nhất về lakehouse?

Không có câu trả lời đúng tuyệt đối — một ngân hàng với yêu cầu compliance nghiêm ngặt có thể vẫn giữ warehouse lõi cho báo cáo tài chính trong nhiều năm nữa, trong khi song song xây lakehouse cho các use case AI/phân tích hành vi khách hàng. Vai trò của EA là làm rõ ràng đây là quyết định có chủ đích (deliberate trade-off), không phải quán tính công nghệ.

Case thực tế minh hoạ

(Minh hoạ điển hình tổng hợp, không phải case của một công ty cụ thể có thật, không có số liệu chính xác.)

Một doanh nghiệp bán lẻ đa kênh vận hành một Data Warehouse truyền thống được xây dựng gần một thập kỷ, phục vụ tốt các báo cáo tài chính, báo cáo tồn kho và dashboard vận hành hàng ngày. Khi ban lãnh đạo muốn đẩy mạnh cá nhân hóa marketing và dự đoán nhu cầu bằng AI, đội Data Science liên tục vướng ba rào cản: (1) warehouse không lưu được dữ liệu hành vi thô như clickstream và log tương tác app; (2) mọi thay đổi schema để thêm nguồn dữ liệu mới phải qua quy trình phê duyệt kéo dài vì ảnh hưởng đến báo cáo đang chạy; (3) đội Data Science phải trích xuất dữ liệu ra một môi trường riêng để huấn luyện mô hình, tạo ra bản sao dữ liệu không đồng bộ với nguồn.

Kiến trúc sư doanh nghiệp phụ trách Data Architecture xác định đây không phải bài toán "thay thế" mà là "mở rộng có kiểm soát" — đúng tinh thần Gap Analysis giữa Baseline Architecture (warehouse hiện tại) và Target Architecture (nền tảng phục vụ cả BI lẫn AI). Hướng đi được chọn là chuyển dần sang kiến trúc Lakehouse theo từng lớp (medallion layers — thô/đã làm sạch/đã tổng hợp), giữ nguyên các bảng phục vụ báo cáo tài chính đã ổn định trong lớp đã tổng hợp để không phá vỡ báo cáo hiện có, đồng thời mở lớp dữ liệu thô cho phép Data Science truy cập trực tiếp clickstream, log tương tác mà không cần trích xuất thủ công.

Song song, đội phát hiện ra gốc rễ của nhiều lỗi báo cáo không nằm ở nền tảng lưu trữ mà ở việc ba hệ thống nguồn (CRM, POS, ứng dụng di động) định danh khách hàng khác nhau — đúng vấn đề MDM đã nêu ở đầu bài. Một sáng kiến MDM theo mô hình Registry style được triển khai song song: không di dời toàn bộ dữ liệu khách hàng về một hệ thống trung tâm ngay (chi phí và rủi ro quá lớn trong giai đoạn chuyển đổi), mà xây lớp khớp nối định danh tạo ID khách hàng thống nhất, các hệ thống nguồn giữ nguyên vai trò ghi dữ liệu nhưng đều tham chiếu ID chuẩn hóa này khi đẩy dữ liệu vào Lakehouse.

Kết quả kiến trúc: báo cáo tài chính tiếp tục chạy ổn định trên lớp dữ liệu đã tổng hợp và quản trị chặt; đội AI/phân tích có toàn quyền truy cập dữ liệu thô đa dạng để thử nghiệm mà không ảnh hưởng đến hệ thống báo cáo; và số lượng khách hàng trùng lặp trong các mô hình phân tích giảm đáng kể nhờ ID khách hàng thống nhất từ lớp MDM — dù chi phí vận hành song song trong giai đoạn chuyển đổi (duy trì cả warehouse cũ và lakehouse mới) là đánh đổi được lường trước và có lộ trình rút gọn theo từng quý.

📐 Template/Artifact áp dụng ngay

Data Architecture Decision Matrix — Lựa chọn mô hình kiến trúc dữ liệu theo domain

Cách dùng: liệt kê từng domain dữ liệu trọng yếu của tổ chức theo hàng, điền các cột đánh giá, rồi thống nhất với CDO/CIO mô hình kiến trúc đề xuất trước khi đưa vào Target Architecture ở Phase C. Ma trận này nên được đính kèm làm Artifact hỗ trợ cho Data Dissemination Diagram và Data Entity/Business Function Matrix đã có trong TOGAF Content Framework.

🎯 Góc nhìn Chief EA

• Nếu ngày mai một khách hàng yêu cầu xóa toàn bộ dữ liệu cá nhân (quyền được quên), tổ chức có thể truy vết và xóa đồng bộ ở bao nhiêu hệ thống — và ai là người biết chắc con số đó là đầy đủ?
• Golden record từ MDM có thực sự "thắng" trong mọi hệ thống tiêu thụ, hay mỗi ứng dụng vẫn âm thầm giữ một bản sao cục bộ và tự ý sửa?
• Nếu chọn Lakehouse, tổ chức có đủ năng lực vận hành nội bộ (data engineering, quản trị table format) hay đang đặt cược vào một hệ sinh thái còn non và phụ thuộc vào vài chuyên gia hiếm?
• Chi phí duy trì song song Warehouse cũ và Lakehouse mới trong giai đoạn chuyển đổi được ai phê duyệt, và mốc "tắt hệ cũ" có nằm trong roadmap được ký hay chỉ là ý định?

🔗 Bài viết liên quan

• Giai đoạn C (Information Systems Architecture) — Kiến trúc dữ liệu tập trung
• Catalog, Matrix, Diagram

Bài trước: Catalog, Matrix, Diagram · Bài tiếp theo: Kiến trúc ứng dụng (Application Architecture)