Kiến trúc Medallion (Medallion Architecture)

1. Tổng quan

Định nghĩa: Kiến trúc Medallion (Medallion Architecture) là một mẫu thiết kế dữ liệu tinh chế và cấu trúc hóa dữ liệu bên trong data lakehouse theo từng bước thành các tầng (layer) Bronze, Silver, Gold dựa trên chất lượng và mức độ xử lý — một mô hình tinh chế nhiều chặng (multi-hop) trong đó mỗi tầng kế tiếp làm tăng tính toàn vẹn, ý nghĩa nghiệp vụ và khả năng sử dụng của dữ liệu.

Kiến trúc dữ liệu doanh nghiệp từ lâu đã giằng co giữa hai thái cực: schema-on-write nghiêm ngặt của kho dữ liệu (DW) và schema-on-read linh hoạt của data lake. DW mang lại chất lượng và quản trị cao cho dữ liệu có cấu trúc nhưng yếu với dữ liệu bán cấu trúc/phi cấu trúc cùng xử lý khối lượng lớn, thời gian thực; còn data lake lưu trữ mọi dạng dữ liệu với chi phí thấp nhưng do không quản lý được chất lượng, tính nhất quán nên thường thoái hóa thành đầm lầy dữ liệu (data swamp). Khi dữ liệu không đáng tin chất đống trong lake, nhà phân tích phải kiểm chứng lại nguồn mỗi lần, và tổ chức mất đi một "nguồn chân lý duy nhất (Single Source of Truth)" được chia sẻ, khiến không ai thống nhất cùng một con số.

Lakehouse kết hợp ưu điểm của cả hai, đặt các tính năng độ tin cậy cấp DW như giao dịch ACID, áp đặt lược đồ và quản lý phiên bản lên trên object storage chi phí thấp của lake. Nhưng có nền tảng lưu trữ lakehouse không có nghĩa dữ liệu tự sắp xếp. Điều cần thiết là một kỷ luật dòng chảy chuẩn hóa mà tổ chức cùng thống nhất — "đến đâu là dữ liệu thô như nguồn, từ đâu đã được kiểm chứng, và cái gì là sản phẩm tiêu dùng cuối." Kiến trúc Medallion chính là quy ước thiết kế (convention) cung cấp kỷ luật này, được Databricks phổ biến như mẫu hình chuẩn mực cho lakehouse.

Giá trị cốt lõi của mẫu hình nằm ở tinh chế theo từng bước (progressive refinement). Được đặt tên theo hạng huy chương Olympic (đồng - bạc - vàng), dữ liệu khi được thu thập từ nguồn sẽ vào Bronze ít gia công nhất, được thăng hạng lên Silver qua làm sạch, tích hợp, và cuối cùng hoàn thiện thành Gold ánh vàng qua tổng hợp, mô hình hóa nghiệp vụ. Việc tách bạch minh thị các giai đoạn này cùng lúc đạt được bảo tồn bất biến dữ liệu nguồn (có thể kiểm toán, tái xử lý), tái sử dụng sản phẩm trung gian và tối ưu hiệu năng của tầng tiêu dùng, nâng cao đáng kể độ tin cậy và khả năng bảo trì của pipeline.

2. Cấu trúc tổng thể và nguyên tắc thiết kế

Kiến trúc Medallion có cấu trúc dạng pipeline trong đó dữ liệu thu thập từ hệ thống nguồn (OLTP DB, log, IoT, API, v.v.) tuần tự đi qua ba tầng trong khi giá trị tích lũy dần. Mỗi tầng được lưu vật lý thành bảng (hoặc đường dẫn lưu trữ) riêng biệt, và tầng trên lấy tầng ngay dưới làm đầu vào. Cấu trúc tổng thể như sau.

graph LR
  subgraph SRC["Hệ thống nguồn"]
    S1["OLTP DB"]
    S2["Log/Sự kiện"]
    S3["IoT/API"]
  end
  subgraph LH["Lakehouse"]
    B["Bronze<br/>nạp nguyên dạng từ nguồn"]
    SV["Silver<br/>làm sạch/kiểm chứng/tích hợp"]
    G["Gold<br/>tổng hợp/mô hình nghiệp vụ"]
  end
  subgraph CON["Tầng tiêu dùng"]
    C1["Dashboard BI"]
    C2["Huấn luyện/suy luận ML"]
    C3["Phân tích ad-hoc"]
  end
  S1 --> B
  S2 --> B
  S3 --> B
  B -->|"Làm sạch (Cleansing)"| SV
  SV -->|"Tổng hợp (Aggregation)"| G
  G --> C1
  G --> C2
  SV --> C2
  G --> C3

Các nguyên tắc thiết kế chống đỡ cấu trúc này được tóm tắt như sau.

• Bất biến và khả năng phát lại (immutability & replayability). Vì Bronze bảo tồn nguồn mà không gia công, khi phát hiện lỗi trong logic biến đổi của tầng trên hoặc yêu cầu thay đổi, có thể tái dựng toàn bộ chuỗi bằng cách đọc lại Bronze. Nói cách khác, Bronze đóng vai trò "bản sao lưu kiêm log phát lại" của pipeline.
• Tách bạch mối quan tâm (separation of concerns). Bằng cách chia các trách nhiệm khác nhau là thu thập (ingestion), chất lượng (quality) và phục vụ (serving) theo tầng, mỗi giai đoạn có thể được phát triển, kiểm thử và tối ưu độc lập.
• Chất lượng tăng dần. Tầng càng cao, chất lượng và tính cố kết càng cao. Càng xuống dưới càng tổng quát, nguyên thủy; càng lên trên càng chuyên biệt cho mục đích nghiệp vụ cụ thể.
• Nguồn chân lý duy nhất. Vì mọi Gold đều chia sẻ Silver làm nền tảng tinh chế chung, nên tránh được sai lệch con số giữa các bộ phận và bảo đảm chỉ số nhất quán ở cấp tổ chức.

Nhờ các nguyên tắc này, Medallion tự nhiên đáp ứng yêu cầu của kỹ thuật dữ liệu hiện đại là "lưu nhanh nhưng tiêu dùng cẩn trọng." Nguồn được nhận vào Bronze không trì hoãn để ngăn mất dữ liệu, còn việc tiêu dùng bị buộc chỉ diễn ra ở các tầng trên đã kiểm chứng, dung hòa các yêu cầu đối nghịch là sự nhanh nhạy khi thu thập và độ tin cậy khi sử dụng thông qua việc tách tầng.

Cần lưu ý rằng Medallion không nhất thiết có nghĩa là "đúng ba tầng." Cả hướng dẫn của Microsoft lẫn Databricks đều nêu rõ mẫu hình này linh hoạt (flexible) và số lượng cùng tên gọi các tầng có thể điều chỉnh theo nhu cầu tổ chức. Trong thực tế, các nhóm thêm vùng 'Raw/Landing' để nhận tệp thô trước Bronze, hoặc tách lại Gold thành các mart theo mục đích (cho BI, cho ML). Điều cốt lõi không phải là số tầng mà là sự tách bạch minh thị theo mức độ xử lý và sự đồng thuận của tổ chức về điều đó.

3. Vai trò của từng tầng và dòng chảy dữ liệu

Biểu diễn dưới dạng quy trình chi tiết những biến đổi mà dữ liệu thực tế trải qua ở mỗi tầng như sau.

flowchart TB
  R["Dữ liệu nguồn (có cấu trúc/bán/phi cấu trúc)"] --> I["Thu thập tăng dần (Incremental Ingestion)"]
  I --> B["Bronze: nạp append-only<br/>+ gắn metadata nạp (nguồn, thời điểm)"]
  B --> V{"Kiểm chứng chất lượng dữ liệu"}
  V -->|"Đạt"| SV["Silver: khử trùng lặp/khớp kiểu/join/tích hợp"]
  V -->|"Trượt (cách ly)"| Q["Bảng cách ly (Quarantine)"]
  SV --> A["Tổng hợp nghiệp vụ/mô hình chiều (star schema)"]
  A --> G["Gold: chỉ số tổng hợp/đặc trưng/mart"]
  G --> O["Tiêu dùng: BI/ML/báo cáo"]

A. Tầng Bronze (tầng bảo tồn nguồn). Bronze là điểm đáp nạp dữ liệu thu thập từ hệ thống nguồn nguyên dạng nhất có thể (as-is). Triết lý thiết kế của tầng này là "không biến đổi." Nó tối thiểu hóa thay đổi lược đồ và làm sạch, thay vào đó gắn metadata như thời điểm nạp, định danh nguồn, đường dẫn tệp dưới dạng cột bổ sung để có thể truy vết nguồn gốc (lineage) của dữ liệu. Phương thức nạp mặc định là chỉ nối thêm (append-only), không ghi đè bản ghi hiện có, nhằm bảo tồn cả lịch sử thay đổi của nguồn và cho phép kiểm toán (audit) cùng tái hiện thời điểm (time travel).

Lý do bảo tồn Bronze ở dạng gốc là tính linh hoạt khi tái xử lý. Ví dụ, nếu logic biến đổi Silver có lỗi khiến chỉ số sáu tháng gần nhất bị tính sai, thì có thể khôi phục bằng cách phát lại chỉ riêng Bronze mà không cần truy cập lại hệ thống nguồn. Nếu đã làm sạch ngay ở bước thu thập, thông tin gốc sẽ mất đi và việc khôi phục như vậy là bất khả thi. Lấy một doanh nghiệp thương mại điện tử làm ví dụ, việc lưu trọn vẹn các phản hồi JSON của API đơn hàng vào Bronze mà không parse hay gia công có nghĩa là ngay cả khi phát sinh yêu cầu mới như "tỷ lệ hoàn tiền theo phương thức thanh toán" về sau, vẫn có thể trích xuất tức thì từ dữ liệu quá khứ.

B. Tầng Silver (tầng làm sạch/tích hợp). Silver là tầng kiểm chứng, làm sạch và tích hợp dữ liệu thô của Bronze để dựng nên 'khung nhìn doanh nghiệp (enterprise view)' đáng tin cậy. Các biến đổi cốt lõi thực hiện ở đây là (1) xử lý giá trị thiếu/ngoại lai và khử trùng lặp, (2) chuẩn hóa kiểu dữ liệu, đơn vị và giá trị mã, (3) join nhiều nguồn trên khóa chung để tích hợp các thực thể (khách hàng, sản phẩm, đơn hàng). Những bản ghi không qua được kiểm chứng chất lượng không bị loại bỏ mà được tách sang bảng cách ly (quarantine) để phân tích nguyên nhân — đây là thông lệ tốt. Làm vậy ngăn dữ liệu xấu lan truyền lên trên trong khi vẫn truy vết được mà không mất mát.

Silver quan trọng vì tầng này trở thành nền tảng chung được đa số người tiêu dùng dữ liệu chia sẻ. Nếu Gold chuyên biệt cho một chỉ số cụ thể của một bộ phận cụ thể, thì Silver là tài sản đa dụng "đã làm sạch nhưng chưa thiên lệch về một mục đích cụ thể." Kỹ sư học máy thường dùng trực tiếp Silver thay vì Gold để tự do khám phá đặc trưng, vì sự tổng hợp của Gold làm mất thông tin chi tiết của bản gốc. Trong ngành tài chính, việc tích hợp dữ liệu tài khoản/giao dịch từ nhiều hệ thống core banking thành một mô hình giao dịch chuẩn ở Silver có nghĩa là các sản phẩm Gold đa dạng cho rủi ro, tiếp thị, báo cáo tuân thủ về sau đều được dựng nhất quán trên nền tảng duy nhất này.

C. Tầng Gold (tầng tiêu dùng nghiệp vụ). Gold là tầng cao nhất chứa dữ liệu 'sẵn sàng cho nghiệp vụ (business-ready)' đã được tổng hợp và mô hình hóa cho một mục đích nghiệp vụ cụ thể từ dữ liệu đã làm sạch của Silver. Điển hình nó gồm các chỉ số được tổng hợp sẵn (doanh thu theo ngày, KPI) để công cụ BI truy vấn nhanh, mô hình chiều (bảng fact và dimension của star schema) thân thiện với phân tích, hoặc bảng đặc trưng mà mô hình ML có thể dùng trực tiếp để huấn luyện. Vì mục tiêu thiết kế của Gold là hiệu năng đọc và sự tiện dụng, nên chiến lược là thực hiện join trước để phi chuẩn hóa (denormalization) và vật chất hóa (materialize) các tổng hợp hay dùng.

Việc có nhiều Gold theo mục đích cũng là điều quan trọng và phổ biến. 'Mart lãi lỗ theo tháng' của phòng tài chính, 'mart hiệu quả chiến dịch' của phòng tiếp thị, 'tập đặc trưng dự báo rời bỏ' của phòng khoa học dữ liệu đều là những Gold khác nhau phái sinh từ cùng một Silver. Cách này đáp ứng độc lập nhu cầu của từng bộ phận trong khi, vì dữ liệu gốc chia sẻ nền tảng duy nhất là Silver, nên tránh được sai lệch con số. Bảng dưới đây so sánh đặc tính của ba tầng.

Hạng mục	Bronze	Silver	Gold
Trạng thái dữ liệu	thô (raw)	đã làm sạch (cleansed)	đã tuyển chọn (curated)
Biến đổi chính	nạp/gắn metadata	khử trùng lặp/chuẩn hóa/join	tổng hợp/mô hình chiều/phi chuẩn hóa
Lược đồ	lược đồ nguồn/lỏng	có cấu trúc/áp đặt	hướng nghiệp vụ
Người tiêu dùng chính	kỹ sư dữ liệu	kỹ sư ML/nhà phân tích	BI/lãnh đạo/nghiệp vụ
Phương thức nạp	append-only	upsert/merge	overwrite/tổng hợp
Mức chất lượng	thấp (ưu tiên bảo tồn)	trung bình (nền tin cậy)	cao (hoàn chỉnh)

4. Công nghệ triển khai và mẫu vận hành

Vì Kiến trúc Medallion là một mẫu hình khái niệm nên không ràng buộc vào một sản phẩm cụ thể, nhưng định dạng bảng mở (open table format) đóng vai trò cốt lõi trong triển khai thực tế. Các định dạng như Delta Lake, Apache Iceberg, Apache Hudi cung cấp giao dịch ACID, tiến hóa lược đồ (schema evolution), truy vấn thời điểm (time travel) và upsert (MERGE) trên object storage, giúp cập nhật bảng của mỗi tầng một cách đáng tin cậy. Ví dụ, phép toán MERGE INTO (upsert) chỉ phản ánh dữ liệu thay đổi ở tầng Silver khó thực hiện an toàn nếu thiếu bảo đảm ACID của Delta Lake. Một stack triển khai điển hình gồm các thành phần sau.

• Tầng lưu trữ/định dạng: object storage (S3, ADLS, GCS) + định dạng bảng mở (Delta, Iceberg, Hudi).
• Engine xử lý: các engine xử lý phân tán như Spark, Flink, Trino và công cụ biến đổi SQL (dbt).
• Thu thập/tăng dần: connector CDC, nạp streaming (Auto Loader, Kafka), pipeline khai báo (Delta Live Tables).
• Chất lượng/kiểm chứng: triển khai cổng chuyển tầng bằng Great Expectations, DLT expectations và tương tự.
• Quản trị/catalog: quản lý tập trung nguồn gốc, quyền và kiểm toán bằng Unity Catalog, OneLake hoặc catalog mở.

Để dòng chảy dữ liệu hiệu quả, xử lý tăng dần (incremental processing) là thiết yếu. Tái xử lý toàn bộ dữ liệu mỗi lần làm chi phí và độ trễ bùng nổ, nên CDC (Change Data Capture) vốn chỉ đẩy phần thay đổi xuống các tầng dưới được kết hợp với nạp streaming (ví dụ Auto Loader của Spark Structured Streaming). Khi nối các tầng bằng streaming, có thể dựng một pipeline hợp nhất vượt Lambda xử lý batch và thời gian thực trong một codebase duy nhất. Để áp đặt kỷ luật chất lượng dưới dạng mã, kỳ vọng (expectation) của khung chất lượng dữ liệu như test của Delta Live Tables/dbt và Great Expectations được áp dụng tại điểm chuyển tầng nhằm chặn dữ liệu xấu khỏi được thăng hạng.

Về vận hành, tối ưu vật lý của mỗi tầng cũng quan trọng. Bronze có xu hướng sinh nhiều tệp nhỏ làm giảm hiệu năng truy vấn, nên áp dụng compaction gộp định kỳ các tệp nhỏ và phân vùng/phân cụm (ví dụ Z-Order, Liquid Clustering) khớp với mẫu truy vấn. Ngoài ra, trong khi Bronze đặt chu kỳ lưu giữ và dọn dẹp (vacuum) các phiên bản cũ để tối ưu chi phí lưu trữ, thì Gold được truy vấn thường xuyên nên tăng tốc phản hồi bằng cache và view vật chất hóa. Việc mỗi tầng có mục tiêu tối ưu đối nghịch (Bronze = bảo tồn/chi phí, Gold = hiệu năng) chính là điểm thiết kế cốt lõi khi vận hành Medallion.

So sánh: khác biệt với ETL/DW truyền thống. DW truyền thống là schema-on-write, cố định lược đồ trước khi thu thập và làm sạch bằng ETL rồi mới nạp. Vì cách này vứt bỏ bản gốc nên khó tái xử lý khi yêu cầu thay đổi và không thể chứa dữ liệu phi cấu trúc. Ngược lại, Medallion theo triết lý ELT (nạp trước, biến đổi sau), bảo tồn bản gốc (Bronze) trước rồi trì hoãn và phân tán việc biến đổi theo từng tầng. Kết quả là nó chiếm ưu thế về tính linh hoạt (tái xử lý, tiếp nhận yêu cầu mới) và khả năng mở rộng (lưu trữ chi phí thấp). Tuy nhiên có đánh đổi: nhiều tầng gây trùng lặp lưu trữ và độ trễ.

So sánh: quan hệ với Data Mesh. Nếu Medallion là mẫu hình kỹ thuật quy định dòng tinh chế theo chiều dọc 'bên trong' một lakehouse duy nhất, thì Data Mesh là mô thức tổ chức/quản trị trong đó các nhóm theo miền sở hữu và cung cấp dữ liệu như 'sản phẩm dữ liệu (data product)'. Hai thứ không cạnh tranh mà bổ sung cho nhau. Trong thực tế chúng thường được kết hợp bằng cách mỗi nhóm miền triển khai sản phẩm dữ liệu của mình theo cấu trúc Medallion (Bronze → Silver → Gold) ở nội bộ.

So sánh: khác biệt với kiến trúc Lambda. Phân tích thời gian thực từng được triển khai bằng kiến trúc Lambda vận hành tầng batch và tầng tốc độ riêng rẽ rồi hợp nhất ở bước phục vụ, điều này mang gánh nặng phải bảo trì trùng lặp cùng một logic trong hai codebase batch và streaming. Medallion, bằng cách tận dụng ACID của định dạng bảng mở và các bảng streaming, hợp nhất batch và streaming tăng dần vào một pipeline phân tầng duy nhất, loại bỏ sự trùng lặp mã và áp dụng cùng quy tắc tinh chế một cách nhất quán cho cả hai. Điều này gần với triết lý pipeline đơn 'hướng Kappa'.

Tình huống cụ thể (định lượng). Lấy pipeline dự báo nhu cầu của một nhà bán lẻ toàn cầu làm ví dụ, log giao dịch POS từ hàng trăm cửa hàng (hàng trăm triệu sự kiện mỗi ngày) cùng dữ liệu thời tiết/khuyến mãi được nạp nguyên dạng vào Bronze. Ở Silver, các giao dịch hủy và hoàn tiền được bù trừ, mã sản phẩm được ánh xạ sang hệ phân loại chuẩn, và join với master cửa hàng để dựng 'sự kiện bán hàng theo ngày đã chuẩn hóa'. Ở Gold, các dữ liệu này được tổng hợp theo cấp SKU × cửa hàng × tuần thành bảng đặc trưng cấp cho mô hình dự báo nhu cầu. Các tổ chức áp dụng cấu trúc này báo cáo rằng việc loại bỏ trùng lặp mã tiền xử lý và dùng xử lý tăng dần đã giảm vài chục phần trăm thời gian chạy pipeline hằng ngày và chi phí tái xử lý, và nhờ nền tảng duy nhất là Silver, các phòng tài chính và logistics đã cùng chia sẻ một con số bán hàng (các con số cụ thể thay đổi theo tổ chức và môi trường nên cần hiểu như một xu hướng tổng quát).

5. Chuyên sâu: Xu hướng mới nhất và các anti-pattern

Gần đây Kiến trúc Medallion đang tiến hóa theo ba trục: quản trị, tự động hóa và thời gian thực. Thứ nhất, các tầng catalog/quản trị tích hợp như Unity Catalog của Databricks và OneLake của Microsoft Fabric được kết hợp để nguồn gốc dữ liệu (lineage), kiểm soát truy cập và kiểm toán giữa các tầng được quản lý tập trung. Trong khi trước đây Bronze/Silver/Gold chỉ là quy ước thư mục, thì nay catalog truy vết chủ sở hữu, chất lượng và việc sử dụng của bảng mỗi tầng dưới dạng metadata. Thứ hai, hướng đi là các pipeline khai báo như Delta Live Tables (DLT) định nghĩa biến đổi giữa các tầng bằng khai báo thay vì mã, với khung tự động quản lý kỳ vọng chất lượng, phụ thuộc và xử lý tăng dần. Thứ ba, 'streaming Medallion' nối các bảng streaming ở mọi tầng để dòng chảy gần thời gian thực (near real-time) từ thu thập đến Gold đang trở nên phổ biến.

Ngược lại, cũng phải nhận diện rõ các anti-pattern thường xảy ra trong thực tế. Dưới đây là các kiểu thất bại tiêu biểu được quan sát lặp đi lặp lại ở hiện trường.

• Gia công Bronze quá mức. Nếu làm sạch/biến đổi ngay ở bước thu thập và làm mất bản gốc thì khi thay đổi logic sẽ không thể tái xử lý, đánh mất khả năng phát lại — lợi ích cốt lõi của Medallion.
• Bỏ qua Silver (Bronze → Gold trực tiếp). Bỏ qua tầng làm sạch/tích hợp khiến cổng chất lượng biến mất, và mỗi Gold tự diễn giải dữ liệu thô nên sai lệch con số tái diễn.
• Phân tầng chỉ trên danh nghĩa. Nếu không tài liệu hóa và áp đặt trách nhiệm, tiêu chuẩn chất lượng (SLA) và chủ sở hữu của từng tầng thì nó trở thành một đầm lầy dữ liệu khác chỉ chia làm ba thư mục.
• Ba tầng giáo điều bỏ qua quy mô. Áp dụng máy móc ba tầng ngay cả với dữ liệu nhỏ/đơn giản chỉ làm tăng sự sao chép, độ trễ và chi phí không cần thiết. Nên điều chỉnh số tầng theo quy mô dữ liệu và độ trưởng thành của tổ chức.
• Vứt bỏ tùy tiện dữ liệu trượt chất lượng. Vứt bỏ các bản ghi trượt kiểm chứng mà không cách ly làm cho việc truy vết nguyên nhân và hiệu chỉnh trở nên bất khả thi, nên luôn phải tách và bảo tồn vào bảng cách ly.

6. Điểm cần cân nhắc và hàm ý

Kiến trúc Medallion không phải là một sự phân vùng thư mục đơn thuần mà là chiến lược thể chế hóa chất lượng và quản trị dữ liệu thành một kỷ luật dòng chảy. Khi xem xét áp dụng từ góc nhìn Kỹ sư chuyên nghiệp, cần phán đoán toàn diện những điều sau.

• Chiến lược áp dụng (tính linh hoạt của thiết kế tầng). Thay vì áp đặt ba tầng một cách giáo điều, nên điều chỉnh số lượng và tên gọi các tầng theo đặc tính dữ liệu và mục đích sử dụng. Thiết kế tùy biến phản ánh nhu cầu tổ chức — như thêm Landing để đáp tệp thô hoặc tách Gold cho BI và ML — là điều cốt lõi. Với dữ liệu nhỏ/đơn giản cũng cần phán đoán thu gọn còn hai tầng.

• Đánh đổi (chất lượng vs chi phí/độ trễ). Càng đặt nhiều tầng thì tính linh hoạt tái xử lý và khả năng kiểm soát chất lượng càng cao, nhưng cùng một dữ liệu bị sao chép qua từng tầng, làm tăng chi phí lưu trữ và độ trễ đầu-cuối (latency). Phải song hành thiết kế vận hành: giảm độ trễ bằng xử lý tăng dần/streaming và quản lý chi phí bằng chu kỳ lưu giữ (retention), nén (compaction) và tối ưu tệp của Bronze.

• Triển vọng (tích hợp với quản trị). Trong tương lai Medallion sẽ định hình không phải như một mẫu hình độc lập mà như một phần của hệ quản trị kết hợp catalog dữ liệu, nguồn gốc, kiểm soát truy cập và tự động hóa chất lượng dữ liệu. Khi catalog tích hợp chứng thực mức độ tin cậy của mỗi tầng dưới dạng metadata, người tiêu dùng có thể lấy "bảng này đã qua kiểm chứng nào của tầng nào" làm căn cứ cho sự tin tưởng.

• Công nghệ liên đới (định dạng bảng, CDC, khung chất lượng). Hiệu lực của Medallion được phát huy khi hội đủ các định dạng bảng mở bảo đảm ACID (Delta, Iceberg, Hudi), CDC/streaming cho phép xử lý tăng dần, và một khung chất lượng dữ liệu đóng vai cổng chuyển tầng. Nếu chỉ chia tầng mà thiếu những thứ này thì lợi ích cốt lõi của mẫu hình sẽ mất đi.

• Vận hành/quan trắc (Observability). Cần có hệ thống giám sát liên tục thành công/thất bại của việc chuyển tầng, các chỉ số chất lượng (tỷ lệ thiếu, tỷ lệ trùng lặp), độ trễ đầu-cuối và độ tươi của dữ liệu (freshness), và cảnh báo khi vi phạm SLA. Xu hướng khối lượng nạp của bảng cách ly có thể được dùng làm tín hiệu phát hiện sớm sự suy giảm chất lượng nguồn.

• Góc nhìn tổ chức/quản trị. Phải văn bản hóa chủ thể chịu trách nhiệm và tiêu chuẩn chất lượng (SLA) của mỗi tầng, và bằng cách kết hợp với khái niệm sở hữu theo miền của Data Mesh, định nghĩa chủ sở hữu, chất lượng và quy tắc sử dụng của sản phẩm dữ liệu từng tầng. Chỉ riêng mẫu hình kỹ thuật không thể ngăn được đầm lầy dữ liệu; sự đồng thuận của tổ chức và kỷ luật vận hành quyết định thành bại.

Tài liệu tham khảo

• OneLake medallion lakehouse architecture (Microsoft Learn): https://learn.microsoft.com/fabric/onelake/onelake-medallion-lakehouse-architecture
• Describe medallion architecture (Microsoft Learn): https://learn.microsoft.com/training/modules/describe-medallion-architecture/2-describe-medallion-architecture
• Demystifying the Medallion: Practical Insights into the Layers (O'Reilly): https://www.oreilly.com/library/view/building-medallion-architectures/9781098178826/ch02.html

---

Tóm tắt một câu: Kiến trúc Medallion là một mẫu thiết kế dữ liệu nhiều chặng tinh chế dữ liệu lakehouse theo từng bước thành các tầng Bronze (bảo tồn nguồn), Silver (làm sạch/tích hợp) và Gold (tổng hợp/tiêu dùng), bảo đảm đồng thời tính linh hoạt tái xử lý của bản gốc và độ tin cậy của dữ liệu tiêu dùng.