[DE Blog #01] Nền Tảng Kiến Trúc Dữ Liệu: Phân Biệt OLTP vs. OLAP & Nghệ Thuật Data Modeling Cho Data Engineer

1. Bối cảnh thực tế (Context & Problem Statement)

Một câu hỏi kinh điển mà nhiều kỹ sư thường đặt ra khi tiếp cận Data Engineering:
“Tại sao chúng ta không cắm trực tiếp công cụ BI (Tableau, PowerBI, Metabase) vào Database vận hành của ứng dụng (PostgreSQL, MySQL) để chạy báo cáo, mà phải xây dựng cả một hệ thống Data Warehouse / Data Lakehouse phức tạp?”

Câu trả lời nằm ở sự khác biệt bản chất giữa mô hình tải công việc (Workload pattern) và cơ chế tối ưu lưu trữ vật lý trên đĩa.

2. Phân biệt cốt lõi: OLTP vs. OLAP

2.1. OLTP (Online Transaction Processing)

Mục đích: Phục vụ các giao dịch nghiệp vụ thường nhật của ứng dụng (đặt hàng, thanh toán, đăng nhập tài khoản).
Đặc điểm truy vấn: Tần suất đọc/ghi cực lớn, mỗi truy vấn chỉ tác động lên vài dòng dữ liệu (độ trễ siêu thấp tính bằng mili-giây, tính đồng thời cao).
Mô hình dữ liệu: Tuân thủ chuẩn hóa cao (3NF - Third Normal Form) nhằm triệt tiêu dữ liệu trùng lặp và đảm bảo tính toàn vẹn tuyệt đối (ACID).
Định dạng lưu trữ: Lưu theo dòng (Row-oriented storage), thuận lợi cho thao tác thêm/sửa/xóa từng bản ghi trọn vẹn.

2.2. OLAP (Online Analytical Processing)

Mục đích: Phục vụ việc phân tích số liệu lịch sử, báo cáo xu hướng kinh doanh và huấn luyện mô hình học máy.
Đặc điểm truy vấn: Tần suất truy vấn thấp hơn nhưng mỗi truy vấn quét qua hàng triệu đến hàng tỷ dòng để tính toán các phép toán tổng hợp (SUM, AVG, COUNT, GROUP BY).
Mô hình dữ liệu: Khử chuẩn hóa (Denormalization) để giảm thiểu số lượng phép JOIN, tối ưu tốc độ đọc dữ liệu quy mô lớn.
Định dạng lưu trữ: Lưu theo cột (Column-oriented storage như Parquet, ORC, ClickHouse, Snowflake, BigQuery), chỉ đọc đúng các cột được yêu cầu trong câu lệnh SELECT.

📊 Bảng so sánh toàn diện: OLTP vs. OLAP

Tiêu chí	OLTP (Online Transaction Processing)	OLAP (Online Analytical Processing)
Mục đích chính	Vận hành ứng dụng, xử lý giao dịch hàng ngày (CRUD)	Phân tích số liệu, tạo báo cáo BI, Data Science/ML
Bản chất truy vấn	Đọc/ghi từng bản ghi đơn lẻ, độ trễ cực thấp (< vài ms)	Quét hàng triệu đến hàng tỷ dòng, tính toán tổng hợp (`SUM`, `AVG`, `GROUP BY`)
Mô hình thiết kế	Chuẩn hóa cao (3NF) để tránh dư thừa & xung đột dữ liệu	Khử chuẩn hóa (Denormalization - Star/Snowflake Schema)
Định dạng lưu trữ	Row-oriented (lưu theo dòng: Heap, B-Tree Pages)	Column-oriented (lưu theo cột: Parquet, ORC, Columnar blocks)
Tối ưu hóa Index	B-Tree, Hash Index trên Primary Key/Foreign Key	Clustered Index, Partitioning, Min/Max metadata, Sparse Index
Tính toàn vẹn	Tuân thủ nghiêm ngặt ACID	Chấp nhận Eventually Consistent, ưu tiên tốc độ đọc và khả năng mở rộng
Công nghệ tiêu biểu	PostgreSQL, MySQL, Oracle, SQL Server	Google BigQuery, Snowflake, AWS Redshift, ClickHouse, Databricks
Điểm nghẽn (Bottleneck)	Tốc độ Disk I/O khi ghi đồng thời, Khóa dữ liệu (Lock/Deadlock)	Băng thông mạng khi Shuffle dữ liệu giữa các node phân tán, RAM/CPU

3. Dimensional Modeling: Star Schema vs. Snowflake Schema

Trong hệ thống OLAP, phương pháp thiết kế phổ biến nhất là Dimensional Modeling (Mô hình chiều theo trường phái Ralph Kimball), chia bảng thành hai loại:

Fact Table (Bảng sự kiện): Nằm ở trung tâm, lưu trữ các chỉ số định lượng (metrics) như doanh thu, số lượng bán, chiết khấu, kèm theo các Foreign Keys liên kết tới các Dimension.
Dimension Table (Bảng chiều không gian): Chứa thông tin ngữ cảnh định tính (who, what, where, when) như thông tin khách hàng, cửa hàng, sản phẩm, thời gian.

       [Dim: Customer]       [Dim: Date]
              \                 /
               \               /
                [Fact: Sales]
               /               \
              /                 \
       [Dim: Store]         [Dim: Product]

3.1. Star Schema (Sơ đồ hình sao)

Đặc điểm: Bảng Fact kết nối trực tiếp với các bảng Dimension. Các bảng Dimension được khử chuẩn hóa hoàn toàn (denormalized) trong 1 bảng duy nhất (chấp nhận lưu lặp dữ liệu chuỗi).
Ưu điểm: Cú pháp SQL đơn giản, ít phép JOIN, tối ưu hóa hiệu năng tính toán và quét dữ liệu phân tán.

3.2. Snowflake Schema (Sơ đồ bông tuyết)

Đặc điểm: Các bảng Dimension tiếp tục được chuẩn hóa (normalized) thành các bảng phân cấp nhỏ hơn (ví dụ: Dim_Product tách ra Dim_Category và Dim_SubCategory).
Ưu điểm: Loại bỏ dư thừa dữ liệu, tiết kiệm dung lượng lưu trữ đĩa.
Nhược điểm: Tăng độ phức tạp câu lệnh truy vấn và giảm tốc độ do phát sinh nhiều phép JOIN qua nhiều tầng.

📊 Bảng so sánh: Star Schema vs. Snowflake Schema

Tiêu chí	Star Schema (Sơ đồ hình sao)	Snowflake Schema (Sơ đồ bông tuyết)
Mức độ chuẩn hóa	Khử chuẩn hóa hoàn toàn (Denormalized)	Chuẩn hóa nhiều cấp (Normalized)
Cấu trúc bảng Dimension	Mỗi Dimension chỉ gồm 1 bảng duy nhất nối trực tiếp với Fact	Dimension phân nhánh thành nhiều bảng con phân cấp
Số lượng phép JOIN	Rất ít (chỉ JOIN trực tiếp Fact với từng Dimension)	Nhiều (phải JOIN qua chuỗi các bảng Dimension con)
Hiệu năng truy vấn	Nhanh hơn, tốn ít tài nguyên shuffle/network hơn	Chậm hơn do chi phí JOIN nhiều bảng phân cấp
Dung lượng lưu trữ	Tốn dung lượng hơn (chứa các chuỗi text lặp lại)	Tiết kiệm dung lượng hơn do chuẩn hóa
Độ phức tạp SQL	Đơn giản, trực quan cho người làm Data Analyst / BI	Phức tạp hơn, dễ gây sai sót khi kết nối nhiều tầng
Quy trình ETL/ELT	Nạp dữ liệu đơn giản, ít phụ thuộc khóa ngoại phức tạp	Nạp dữ liệu phức tạp hơn do phải tuân thủ thứ tự bảng
Xu hướng hiện đại	Ưu tiên hàng đầu trên Modern Cloud Data Warehouse	Thường chỉ gặp trong các hệ thống DWH truyền thống cũ

4. Quản lý biến động dữ liệu: Slowly Changing Dimensions (SCD)

Trong thực tế, dữ liệu chiều (Dimension) luôn có sự thay đổi theo thời gian (ví dụ: khách hàng đổi địa chỉ, đổi số điện thoại, đổi phân hạng thành viên). Kỹ thuật SCD giúp kiểm soát cách hệ thống lưu trữ các thay đổi này:

Loại SCD	Cơ chế xử lý	Khả năng lưu lịch sử	Cấu trúc bảng thay đổi	Trường hợp sử dụng điển hình
SCD Type 0	Giữ nguyên, không bao giờ thay đổi	Không lưu	Không đổi	Ngày tạo tài khoản, ngày sinh gốc
SCD Type 1	Ghi đè trực tiếp giá trị mới	Không (mất vết dữ liệu cũ)	Không đổi	Sửa lỗi chính tả tên, sửa số điện thoại nhập sai
SCD Type 2	Thêm dòng mới cho mỗi thay đổi	Lưu toàn bộ lịch sử chi tiết	Thêm: `surrogate_key`, `valid_from`, `valid_to`, `is_current`	Thay đổi địa chỉ, chức vụ, hạng hội viên (Cực kỳ hay hỏi khi phỏng vấn)
SCD Type 3	Thêm cột mới lưu trạng thái cũ	Chỉ lưu được 1 trạng thái trước	Thêm: `previous_value`, `effective_date`	Theo dõi chức danh trước đó và hiện tại

5. Best Practices & Cạm Bẫy Thực Chiến (Pro-Tips & Pitfalls)

💡 Pro-Tip cho Modern Cloud Data Warehouse (BigQuery, Snowflake, Databricks):
Chi phí lưu trữ (Storage) hiện nay rất rẻ, trong khi chi phí tính toán (Compute) và thời gian thực thi mới là yếu tố quyết định. Vì vậy, Star Schema (hoặc One Big Table - OBT) luôn là giải pháp được khuyến nghị áp dụng để giảm thiểu tối đa việc Shuffle dữ liệu qua mạng giữa các Worker Nodes.

Sử dụng Surrogate Key thay vì Natural Key: Luôn tự sinh khóa thay thế dạng số nguyên (INT/BIGINT) cho Dimension thay vì dùng mã định danh nghiệp vụ dạng chuỗi (VARCHAR), giúp tăng tốc độ JOIN và dễ dàng quản lý SCD Type 2.
Xử lý Granularity (Độ chi tiết): Xác định rõ một dòng trong Fact Table đại diện cho cái gì (ví dụ: từng món hàng trên hóa đơn hay cả giỏ hàng tổng thể). Tuyệt đối không trộn lẫn các mức độ chi tiết khác nhau trong cùng một Fact Table.

6. Góc Ôn Luyện Phỏng Vấn (Interview Corner)

❓ Câu hỏi 1: Tại sao không nên kết nối trực tiếp công cụ BI/Analytics vào cơ sở dữ liệu OLTP của ứng dụng?

Gợi ý trả lời:
1. Resource Contention & Locking: Truy vấn phân tích thường quét số lượng lớn dữ liệu, chiếm dụng CPU/RAM và gây khóa bảng (Table/Row Lock), làm tê liệt các giao dịch người dùng trực tiếp trên app/web.
2. Không tối ưu về I/O (Row-store vs Columnar-store): Khi tính toán tổng hợp (ví dụ SUM(sales)), Row-store vẫn phải nạp toàn bộ mọi cột của từng dòng vào bộ nhớ, gây lãng phí băng thông I/O đĩa nghiêm trọng.
3. Phân mảnh dữ liệu (Data Silos): Doanh nghiệp có nhiều hệ thống rời rạc (CRM, ERP, Payment, Ads). Data Warehouse cần gom tất cả về một nơi để làm sạch, chuẩn hóa và tạo ra "Single Source of Truth".

❓ Câu hỏi 2: Khi thiết kế Data Warehouse trên Snowflake / BigQuery, bạn sẽ ưu tiên Star Schema hay Snowflake Schema? Vì sao?

Gợi ý trả lời:
- Lựa chọn: Ưu tiên Star Schema (hoặc bảng phẳng Denormalized / OBT).
- Lập luận kỹ thuật:
  - Các hệ thống Cloud DWH tính chi phí dựa trên dung lượng quét và thời gian CPU. Giảm bớt số lượng bảng JOIN giúp loại bỏ chi phí trao đổi dữ liệu qua mạng (Data Shuffling giữa các node phân tán).
  - Các định dạng Columnar hiện đại (kết hợp Run-Length Encoding, Dictionary Encoding) nén các cột có dữ liệu lặp lại cực kỳ hiệu quả, khiến lợi ích tiết kiệm dung lượng của Snowflake Schema không còn bù đắp được chi phí tính toán phát sinh.

❓ Câu hỏi 3: Hãy trình bày chi tiết cách bạn thiết kế và xử lý bảng Dimension theo chuẩn SCD Type 2.

Gợi ý trả lời:
- Cấu trúc bảng cần có: surrogate_key (Primary Key), business_id (Natural Key), các thuộc tính mô tả, valid_from (TIMESTAMP), valid_to (TIMESTAMP, mặc định NULL hoặc 9999-12-31), is_current (BOOLEAN).
- Quy trình khi có bản ghi cập nhật:
  1. Cập nhật bản ghi đang hoạt động (is_current = TRUE): Gán valid_to = CURRENT_TIMESTAMP, is_current = FALSE.
  2. Chèn (Insert) bản ghi mới với surrogate_key mới: Gán valid_from = CURRENT_TIMESTAMP, valid_to = NULL, is_current = TRUE.
- Lợi ích: Đảm bảo tính toàn vẹn lịch sử. Khi Fact Table join với Dimension thông qua surrogate_key, các báo cáo lịch sử vẫn phản ánh chính xác trạng thái tại thời điểm phát sinh giao dịch.

7. Tóm Tắt Ghi Nhớ Nhanh (Key Takeaways)

OLTP = Giao dịch thời gian thực, Row-store, Chuẩn hóa 3NF, Đọc/Ghi từng bản ghi.
OLAP = Phân tích chuyên sâu, Columnar-store, Khử chuẩn hóa, Quét hàng loạt & Aggregation.
Star Schema là kiến trúc chuẩn mực hàng đầu cho Data Warehouse hiện đại.
SCD Type 2 là phương pháp cốt lõi để theo dõi biến động lịch sử dữ liệu chiều không gian.