Modeling nâng cao 1 — Chọn phương pháp mô hình hoá

Mô hình tinh thần: không có "mô hình đúng", chỉ có "mô hình hợp bối cảnh"

Câu hỏi hay gặp nhất khi thiết kế kho dữ liệu là "nên dùng Kimball hay Data Vault?" — và câu trả lời trung thực luôn là "còn tuỳ". Mỗi trường phái mô hình hoá là một cách đánh đổi giữa bốn thứ: tốc độ đọc, chi phí bảo trì khi nguồn thay đổi, khả năng kiểm toán/truy vết, và độ dễ hiểu cho người dùng nghiệp vụ. Không phương pháp nào thắng cả bốn — chọn sai trục ưu tiên mới là lỗi, chứ không phải chọn sai "trường phái".

Series Data Modeling & Kho dữ liệu chuyên sâu (các bài dm-01 → dm-07) đã đặt nền: OLTP vs OLAP, chuẩn hoá, mô hình chiều Kimball, Data Vault. Series nâng cao này không lặp lại cơ bản — nó đào sâu vào những chỗ mà thực tế hay vỡ: SCD phức tạp và bi-temporal, Data Vault ở quy mô, OBT/wide cho ML, semantic/metrics layer, activity schema, và mô hình hoá riêng cho nghiệp vụ ngân hàng. Bài mở màn này làm một việc: cho bạn bản đồ chọn phương pháp — ôn nhanh năm trường phái, khi nào chọn cái nào, cách xếp chúng thành tầng, và semantic layer đứng ở đâu.

Toàn bộ SQL/DDL trong series là (minh hoạ) cho cấu trúc và ý tưởng, không nhằm chạy trực tiếp trong sandbox. Trọng tâm là quyết định thiết kế, không phải cú pháp một engine cụ thể.

Năm trường phái trong một bảng

Trước khi so sánh, cần thấy rõ mỗi trường phái tối ưu cho điều gì. Đây là điểm mấu chốt: chúng không cạnh tranh trực tiếp mà thường bổ sung nhau ở các tầng khác nhau.

Điểm dễ nhầm nhất: medallion không thay thế Kimball hay Data Vault. Bronze/silver/gold chỉ nói dữ liệu sạch tới đâu và đã tích hợp chưa; còn hình dạng bảng ở gold vẫn có thể là star (Kimball) hoặc OBT tuỳ nhu cầu. Tương tự, Data Vault thường sống ở tầng integration còn Kimball ở tầng presentation — chúng xếp chồng, không loại trừ nhau.

Cây quyết định: chọn phương pháp theo bối cảnh

Thay vì học thuộc "trường phái nào tốt", hãy đi theo các trục quyết định: số lượng nguồn và tần suất chúng thay đổi, yêu cầu kiểm toán, đặc tính engine (MPP columnar vs OLTP row-store), và năng lực đội ngũ. Sơ đồ dưới gói các trục đó thành một cây chọn cho tầng lõi của kho (integration + presentation).

Vài quy tắc thực chiến rút ra từ cây này:

• Nhiều nguồn + đổi liên tục + audit → Data Vault ở giữa. Hub/Link/Satellite hấp thụ nguồn mới bằng cách thêm satellite/link, không đập bảng cũ — cực hợp ngân hàng phải giữ vết dữ liệu cho thanh tra. Chi tiết ở dma-04.
• Đầu ra cho người dùng nghiệp vụ → gần như luôn là Kimball ở tầng presentation, vì analyst và công cụ BI "nghĩ" theo fact/dimension. Nâng cao ở dma-02 và xử lý lịch sử ở dma-03.
• Engine MPP columnar + use case đọc-nặng (feature ML, dashboard nóng) → cân nhắc OBT/wide, vì join lớn vẫn đắt ngay cả trên kho cột. Xem dma-05.
• Đội nhỏ, nguồn ít → đừng vẽ Data Vault. Chi phí bảo trì hàng chục bảng hub/link/satellite không đáng; đi thẳng staging → Kimball star là đủ.
• Đội lớn, nhiều nguồn chồng chéo định nghĩa → đầu tư semantic layer để một metric được định nghĩa một lần (dma-06).

Mô hình hoá theo tầng: staging → integration → presentation

Trong thực tế bạn hiếm khi dùng một trường phái cho toàn bộ kho. Kiến trúc bền vững là nhiều tầng, mỗi tầng một mục đích và có thể một trường phái khác nhau. Đây cũng là lý do các "chiến tranh Kimball vs Vault" phần lớn là hiểu lầm — chúng sống ở tầng khác nhau.

• Staging (bronze): ảnh chụp thô của nguồn, ánh xạ gần 1-1, chỉ chuẩn hoá kiểu dữ liệu và đóng dấu thời gian tải. Không đặt logic nghiệp vụ ở đây. Đây là nơi batch ingestion và CDC đổ dữ liệu vào.
• Integration (silver): nơi gộp nhiều nguồn thành một sự thật. Nếu nguồn nhiều và đổi liên tục → Data Vault; nếu ít và ổn định → 3NF chuẩn hoá kiểu Inmon là đủ. Tầng này giữ lịch sử và là nơi khó nhất về mặt mô hình hoá.
• Presentation (gold): định hình cho tiêu thụ — Kimball star cho BI, thêm OBT khi có use case đọc-nặng. Từ cùng một integration layer, bạn có thể sinh nhiều mart trình bày khác nhau mà không đụng vào lõi.
• Semantic layer: ở trên cùng, không lưu dữ liệu mà lưu định nghĩa metric — biến "doanh thu", "NPL", "khách hàng active" thành công thức duy nhất.

Ánh xạ với công cụ: dbt tổ chức các tầng này qua sources → staging → intermediate → marts, và điều phối bằng Airflow hay scheduler của kho. Y hệt medallion, chỉ khác tên gọi.

Semantic layer hiện đại: tầng ngữ nghĩa tách khỏi công cụ

Một thay đổi lớn của thập niên qua là semantic/metrics layer trở thành thành phần chính thức, không còn nằm rải rác trong từng dashboard. Ý tưởng: định nghĩa metric một lần ở dạng khai báo, rồi mọi công cụ (BI, notebook, agent hỏi tự nhiên) đọc cùng định nghĩa đó — gọi là headless BI. Nhờ vậy "tỷ lệ nợ xấu" không còn ba cách tính ở ba phòng ban.

# (minh hoạ) định nghĩa metric ở semantic layer — khai báo một lần, dùng khắp nơi
semantic_model:
  name: loan_portfolio
  entity: loan
  measures:
    - name: outstanding_principal
      agg: sum
      expr: principal_balance
    - name: npl_balance
      agg: sum
      expr: "case when dpd_bucket in ('group_3','group_4','group_5') then principal_balance else 0 end"
  metrics:
    - name: npl_ratio            # tử số / mẫu số cố định — hết cãi nhau "số của ai đúng"
      type: ratio
      numerator: npl_balance
      denominator: outstanding_principal
      dimensions: [branch, product, report_date]

Chi tiết cách xây dựng và các công cụ (dbt Semantic Layer/MetricFlow, LookML, Cube) ở bài dma-06. Điểm cần nhớ ở đây: semantic layer không thay thế mô hình vật lý bên dưới — nó dựa trên star/OBT đã có, chỉ thêm một tầng ý nghĩa thống nhất.

Bản đồ series: 8 bài đi từ đâu tới đâu

Series này đào sâu từng nhánh mà bài mở màn vừa phác. Thứ tự thiết kế để đọc tuần tự, nhưng mỗi bài đứng độc lập được.

• dma-02 — Dimensional nâng cao: chọn grain đúng, bus matrix, conformed dimension, các loại fact (transaction/periodic snapshot/accumulating), degenerate & junk dimension.
• dma-03 — SCD nâng cao: type 0 tới 7, bi-temporal (valid time vs system time), xử lý late-arriving dimension.
• dma-04 — Data Vault 2.0: hub/link/satellite ở quy mô, hashed key, PIT & bridge table, tải song song.
• dma-05 — One Big Table / wide: khi denormalize thắng, feature store cho ML, nested/repeated.
• dma-06 — Semantic / metrics layer: định nghĩa metric tập trung, headless BI, SSoT chỉ số.
• dma-07 — Activity schema: mô hình một-bảng-sự-kiện cho phân tích hành vi/hành trình khách hàng.
• dma-08 — Modeling ngân hàng: ghép tất cả cho bài toán NCB thực: danh mục tín dụng, sao kê, phân loại nợ, chống gian lận.

Use case thực tế

Bối cảnh (minh hoạ): NCB xây kho dữ liệu tín dụng gộp từ ~8 nguồn — core banking, thẻ, LOS (khởi tạo khoản vay), CRM, nhắc nợ, bảng phân loại nợ, tỷ giá, danh mục sản phẩm. Schema các nguồn thay đổi vài lần mỗi quý và thanh tra yêu cầu truy vết được từng con số về nguồn gốc.

Quyết định theo cây ở trên:

1. Integration = Data Vault 2.0. Vì nhiều nguồn + đổi liên tục + audit chặt. Khoá nghiệp vụ customer_id, loan_id thành hub; quan hệ khách hàng–khoản vay thành link; thuộc tính (số dư, nhóm nợ, DPD) vào satellite có dấu thời gian → mỗi thay đổi được lưu lịch sử, thêm nguồn mới chỉ là thêm satellite.
2. Presentation = Kimball star. Fact fact_loan_daily_snapshot (grain: 1 khoản vay × 1 ngày) nối các dimension dim_customer, dim_product, dim_branch, dim_date. Analyst dựng báo cáo dư nợ, cơ cấu nhóm nợ dễ dàng.
3. OBT bổ sung. feature_customer_credit — mỗi khách một dòng với ~120 đặc trưng (dư nợ 30/90 ngày, số lần trễ hạn, phân khúc...) phục vụ mô hình chấm điểm rủi ro, tránh join lúc infer.
4. Semantic layer. npl_ratio định nghĩa một lần (nhóm 3-4-5 / tổng dư nợ) → phòng rủi ro, ban giám đốc và báo cáo NHNN dùng cùng một con số.

Kết quả minh hoạ: khi nguồn LOS đổi schema, chỉ thêm một satellite mới ở integration mà không phải sửa star hay OBT phía trên; báo cáo NPL hết tình trạng "ba phòng ba số".

Ghi nhớ

• Không có mô hình đúng tuyệt đối — mỗi trường phái là một đánh đổi giữa tốc độ đọc, chi phí bảo trì, khả năng audit và độ dễ hiểu. Chọn theo trục ưu tiên của bối cảnh.
• Các trường phái xếp chồng, không loại trừ: Data Vault ở integration, Kimball ở presentation, OBT cho use case đọc-nặng, semantic layer trên cùng.
• Medallion ≠ cách mô hình hoá bảng — bronze/silver/gold nói độ tin cậy/tích hợp, còn hình dạng bảng vẫn là star/Vault/OBT tuỳ tầng.
• Nhiều nguồn + đổi liên tục + audit → nghiêng Data Vault; đội nhỏ, nguồn ổn định → đừng vẽ Vault, đi thẳng staging → Kimball.
• Engine MPP columnar làm OBT/wide hấp dẫn vì join lớn vẫn đắt; trên OLTP row-store thì star/chuẩn hoá hợp hơn.
• Tầng hoá staging → integration → presentation giúp cô lập thay đổi: đổi nguồn không lan tới lớp trình bày.
• Semantic layer = định nghĩa metric một lần (headless BI) → single source of truth cho chỉ số, đặc biệt quan trọng với NPL/dư nợ trong ngân hàng.
• Series này không lặp cơ bản — nắm nền tảng ở dm-01, dm-02, dm-05 trước khi đào sâu.

Nguồn tham khảo

• Ralph Kimball & Margy Ross, The Data Warehouse Toolkit (3rd ed., Kimball Group) — mô hình chiều, star/snowflake, bus matrix, conformed dimension.
• Daniel Linstedt & Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0 — hub/link/satellite, kiến trúc tầng.
• Joe Reis & Matt Housley, Fundamentals of Data Engineering (O'Reilly) — vòng đời kỹ thuật dữ liệu, chọn kiến trúc theo bối cảnh.
• Bill Inmon, Building the Data Warehouse — kho doanh nghiệp chuẩn hoá (CIF), quan điểm top-down.
• Medallion architecture — Databricks Documentation — bronze/silver/gold trong lakehouse.
• dbt Semantic Layer & MetricFlow — dbt Documentation — định nghĩa metric tập trung, headless BI.
• How we structure our dbt projects — dbt Documentation — tầng staging/intermediate/marts.
• Kimball Group — Dimensional Modeling Techniques — danh mục kỹ thuật mô hình chiều.

Series Data Modeling nâng cao — bài tiếp: Dimensional nâng cao. Tiền đề nền tảng: Data Modeling cơ bản, Kimball & mô hình chiều, Data Vault. Liên quan: dbt tổng quan, Airflow tổng quan, Batch ETL/ELT.