[DE Blog #08] Kiến Trúc Data Lakehouse & Cuộc Chiến Table Formats: Delta Lake vs. Apache Iceberg vs. Apache Hudi

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

Trong thập kỷ qua, hệ thống dữ liệu doanh nghiệp thường bị chia cắt thành 2 thái cực:

Data Warehouse (Snowflake, BigQuery, Redshift): Hiệu năng truy vấn cực nhanh, hỗ trợ ACID và bảo mật tốt, nhưng chi phí lưu trữ cao và không phù hợp với dữ liệu phi cấu trúc (Unstructured Data: hình ảnh, video, âm thanh).
Data Lake (AWS S3, GCS, HDFS lưu Parquet/ORC): Chi phí lưu trữ cực rẻ, mở và linh hoạt, nhưng lại nhanh chóng biến thành "Đầm lầy dữ liệu" (Data Swamp) vì thiếu giao dịch ACID, không hỗ trợ UPDATE/DELETE bản ghi đơn lẻ, dễ bị đọc dữ liệu bẩn (Dirty Reads) khi có pipeline đang nạp dở.

Kiến trúc Data Lakehouse ra đời nhằm hợp nhất ưu điểm của cả hai: Lưu trữ dữ liệu dạng mở, giá rẻ trên Data Lake nhưng vẫn sở hữu đầy đủ tính năng quản trị, giao dịch ACID và hiệu năng cao như Data Warehouse. Trọng tâm của cuộc cách mạng này chính là tầng Open Table Format.

2. Các Khái Niệm & Cơ Chế Cốt Lõi

2.1. Bản Chất Của Table Format Là Gì?

Trước đây, một "bảng" trên Data Lake chỉ đơn giản là một thư mục chứa các file Parquet (s3://bucket/table/year=2026/*.parquet). Nếu có 1 file bị ghi lỗi giữa chừng, toàn bộ truy vấn đọc sẽ bị sai hoặc crash.

Table Format là một tầng quản lý Metadata thông minh nằm giữa các file dữ liệu (Parquet/ORC) và các Query Engine (Spark, Trino, Flink, Snowflake). Nó định nghĩa: Một bảng tại một thời điểm chính xác bao gồm những file dữ liệu nào.

+-------------------------------------------------------------------+
|               Query Engines: Spark, Trino, Flink, Snowflake       |
+---------------------------------+---------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|        TABLE FORMAT METADATA LAYER (Delta Lake / Iceberg / Hudi)  |
|          (ACID Log, Snapshots, Schema Evolution, Partitioning)   |
+---------------------------------+---------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|               STORAGE FILE LAYER (Parquet / ORC on S3/GCS)        |
|               [data_1.parquet] [data_2.parquet] [data_3.parquet]  |
+-------------------------------------------------------------------+

2.2. Các Tính Năng Đột Phá Của Open Table Formats

ACID Transactions trên Cloud Storage: Áp dụng cơ chế Optimistic Concurrency Control (OCC) và Transaction Log để đảm bảo nếu ghi file thất bại, dữ liệu cũ vẫn nguyên vẹn (All-or-Nothing), không làm ảnh hưởng người đang đọc (Snapshot Isolation).
Time Travel (Du hành thời gian): Truy vấn lại trạng thái chính xác của dữ liệu tại một mốc thời gian hoặc phiên bản trong quá khứ:
```
SELECT * FROM orders VERSION AS OF 15;
SELECT * FROM orders TIMESTAMP AS OF '2026-08-01 00:00:00';
```
Schema Evolution an toàn: Thêm, xóa, đổi tên hoặc thay đổi vị trí cột mà không làm hỏng dữ liệu cũ và không cần viết lại (rewrite) toàn bộ file Parquet hiện có.
Partition Evolution (Đặc quyền của Apache Iceberg): Cho phép thay đổi chiến lược phân vùng (ví dụ từ theo ngày sang theo giờ) mà không cần tạo bảng mới hay di chuyển dữ liệu cũ.

2.3. Cơ Chế Ghi Dữ Liệu: Copy-on-Write (CoW) vs. Merge-on-Read (MoR)

Copy-on-Write (CoW): Mỗi khi có thao tác UPDATE hoặc DELETE, hệ thống sẽ đọc toàn bộ file Parquet chứa bản ghi đó, áp dụng thay đổi và ghi ra một file Parquet mới hoàn chỉnh.
- Ưu điểm: Tốc độ đọc (Read performance) đạt tối đa vì dữ liệu đã được gom sẵn.
- Nhược điểm: Tốc độ ghi (Write latency) chậm vì tốn tài nguyên ghi đè cả file lớn.
Merge-on-Read (MoR): Khi có UPDATE/DELETE, dữ liệu mới hoặc dấu vết xóa (Delete Marker / Delta Log) chỉ được ghi vào các file log nhỏ riêng biệt (Avro/Parquet Delta).
- Ưu điểm: Tốc độ ghi cực nhanh, rất phù hợp cho Streaming Ingestion & CDC.
- Nhược điểm: Tốc độ đọc chậm hơn vì khi truy vấn, Query Engine phải hợp nhất (Merge) file dữ liệu gốc với file log delta.

3. Các Bảng Markdown So Sánh Chi Tiết

📊 Bảng 1: So Sánh Data Warehouse vs. Data Lake vs. Data Lakehouse

Tiêu chí	Data Warehouse	Data Lake truyền thống	Data Lakehouse
Loại dữ liệu	Dữ liệu có cấu trúc (Structured)	Tất cả (Cấu trúc, Bán cấu trúc, Phi cấu trúc)	Tất cả các loại dữ liệu
Chi phí lưu trữ	Đắt (Storage gắn liền hoặc tính phí cao)	Rất rẻ (AWS S3, Google Cloud Storage)	Rất rẻ (Lưu trữ trên Cloud Object Storage)
Định dạng dữ liệu	Đóng / Độc quyền của từng Vendor	Mở (Parquet, ORC, CSV, JSON)	Mở hoàn toàn (Parquet + Open Table Formats)
Tính toàn vẹn (ACID)	Hỗ trợ đầy đủ, kiểm soát chặt chẽ	Không có hoặc rất yếu	Hỗ trợ đầy đủ ACID Transactions
Tốc độ BI / Analytics	Cực nhanh	Chậm (quét thủ công, dễ lỗi)	Nhanh tương đương Data Warehouse
Hỗ trợ Data Science & ML	Hạn chế (khó cắm framework Python/Spark)	Rất tốt (truy cập trực tiếp file thô)	Xuất sắc (Hỗ trợ cả SQL Analytics lẫn Python/ML APIs)

📊 Bảng 2: So Sánh Copy-on-Write (CoW) vs. Merge-on-Read (MoR)

Tiêu chí	Copy-on-Write (CoW)	Merge-on-Read (MoR)
Cơ chế ghi	Viết lại toàn bộ file Parquet bị thay đổi	Chỉ ghi thay đổi vào file Delta Log phụ trợ
Tốc độ ghi (Write / Ingest)	Chậm hơn (Write amplification cao)	Rất nhanh (độ trễ thấp tính bằng giây)
Tốc độ đọc (Read / Query)	Tối ưu nhất (chỉ đọc file Parquet chuẩn)	Chậm hơn (phải tốn CPU để merge dữ liệu on-the-fly)
Dung lượng file trung gian	Ít file nhỏ hơn	Phát sinh nhiều file log nhỏ (cần Compaction định kỳ)
Use-case tối ưu	Batch pipeline nạp dữ liệu định kỳ, ít update	Streaming CDC Pipeline, IoT Ingestion, Near Real-time

📊 Bảng 3: So Sánh Bộ Ba: Delta Lake vs. Apache Iceberg vs. Apache Hudi

Tiêu chí	Delta Lake	Apache Iceberg	Apache Hudi
Nguồn gốc / Khởi xướng	Databricks	Netflix, Apple	Uber
Kiến trúc Metadata	File-based JSON Transaction Log + Checkpoint Parquet	Hierarchical Snapshot Tree (Manifest Files & Lists)	Timeline-based Metadata & Indexing
Partition Evolution	Không hỗ trợ (phải tạo bảng mới nếu đổi partition)	Hỗ trợ xuất sắc (Hidden Partitioning)	Hạn chế
Hỗ trợ Streaming CDC	Tốt (hỗ trợ `MERGE` và Change Data Feed)	Tốt (tập trung cải thiện trên Flink/Spark)	Mạnh nhất lịch sử (Tích hợp sẵn Record-level Indexing)
Hệ sinh thái Query Engines	Cực mạnh với Spark & Databricks, mở rộng sang Trino/Snowflake	Độc lập và đa dạng nhất (Snowflake, BigQuery, Athena, Trino, Spark, Flink)	Chủ yếu mạnh trên Spark, Presto, Flink
Độ phủ công nghệ hiện nay	Rất cao trong hệ sinh thái Spark/Databricks	Tăng trưởng nhanh nhất, trở thành chuẩn của nhiều Cloud Vendor	Rất mạnh tại các hệ thống Streaming CDC quy mô khổng lồ

4. Best Practices & Tối Ưu Lakehouse Thực Chiến (Pro-Tips & Tuning)

💡 Kỹ thuật Tối Ưu Quét Dữ Liệu: `OPTIMIZE` & `Z-ORDER`

Compaction: Gom các file Parquet nhỏ (Small Files) thành các file lớn chuẩn $128\text{ MB} - 512\text{ MB}$ .
Z-Ordering (Đường cong không gian Z-Order Curve): Sắp xếp dữ liệu đa chiều trên nhiều cột không phân vùng (ví dụ customer_id, created_date) để tối đa hóa khả năng Data Skipping (bỏ qua hàng nghìn file không chứa dữ liệu cần tìm).

-- Chạy lệnh Optimize trên Delta Lake / Databricks:
OPTIMIZE fct_sales 
ZORDER BY (customer_id, product_category);

💡 Dọn dẹp dung lượng với lệnh `VACUUM`

Khi cập nhật dữ liệu, các file cũ không bị xóa ngay để phục vụ Time Travel. Theo thời gian, dung lượng lưu trữ trên S3 sẽ tăng vọt.
Sử dụng lệnh VACUUM định kỳ để xóa vĩnh viễn các file dữ liệu cũ vượt quá ngưỡng lưu trữ lịch sử:

-- Xóa các file cũ hơn 7 ngày:
VACUUM fct_sales RETAIN 168 HOURS;

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

❓ Câu hỏi 1: Data Lakehouse giải quyết những nhược điểm cố hữu nào của Data Lake truyền thống? Giải thích cơ chế đảm bảo ACID của Apache Iceberg hoặc Delta Lake trên Cloud Storage (S3).

Gợi ý trả lời:
- Giải quyết nhược điểm:
  1. Cung cấp đầy đủ tính toàn vẹn ACID Transactions, loại bỏ hoàn toàn tình trạng Dirty Reads khi pipeline đang ghi dở.
  2. Hỗ trợ thao tác cập nhật/xóa bản ghi đơn lẻ (UPDATE, DELETE, MERGE) mà không cần phải viết lại toàn bộ thư mục dữ liệu.
  3. Hỗ trợ Time Travel, Audit log và Data Rollback khi có sự cố phát sinh dữ liệu bẩn.
- Cơ chế hoạt động trên S3 (Delta Lake / Iceberg):
  - Dữ liệu được ghi ra các file Parquet mới (không bao giờ sửa trực tiếp file đang có).
  - Sau khi tất cả các file được ghi thành công, một bản ghi Commit mới sẽ được ghi vào Transaction Log / Snapshot Metadata.
  - Query Engine chỉ đọc dữ liệu dựa trên Snapshot mới nhất đã commit thành công. Nếu quá trình ghi bị lỗi giữa chừng, bản ghi commit không được tạo $\rightarrow$ Không có bất kỳ truy vấn nào đọc phải dữ liệu rác.

❓ Câu hỏi 2: Khi xây dựng một Streaming Ingestion Pipeline nhận sự kiện CDC từ database nguồn (MySQL Binlog) nạp vào Lakehouse, bạn sẽ chọn Copy-on-Write (CoW) hay Merge-on-Read (MoR)? Tại sao?

Gợi ý trả lời:
- Lựa chọn: Chọn Merge-on-Read (MoR).
- Lập luận kỹ thuật:
  - Các luồng CDC có tần suất cập nhật/chèn (INSERT/UPDATE/DELETE) liên tục với độ trễ thấp (vài giây đến vài phút).
  - Nếu dùng CoW, mỗi lần có một vài bản ghi bị update, hệ thống sẽ phải đọc và viết lại toàn bộ các file Parquet dung lượng hàng trăm MB (hiện tượng Write Amplification cực lớn), gây lãng phí tài nguyên CPU, I/O đĩa và làm chậm pipeline.
  - Với MoR, các thay đổi chỉ cần ghi nhanh vào các file Delta Log nhỏ. Sau đó, hệ thống sẽ thiết lập một tiến trình nền bất đồng bộ (Background Compaction Job) để gộp các file log này vào file Parquet chính theo định kỳ (ví dụ mỗi 30 phút hoặc 1 giờ), vừa đảm bảo độ trễ nạp dữ liệu thấp vừa duy trì hiệu năng đọc tốt cho các báo cáo sau này.

❓ Câu hỏi 3: Tại sao Apache Iceberg lại đang trở thành chuẩn mực Table Format được nhiều nền tảng lớn (Snowflake, BigQuery, AWS Athena, Trino) đồng loạt hỗ trợ thay vì Delta Lake?

Gợi ý trả lời:
1. Tính độc lập và cởi mở (Vendor-neutral): Iceberg được phát triển hoàn toàn dưới sự quản lý của Apache Software Foundation và không bị chi phối bởi một nhà cung cấp thương mại duy nhất.
2. Cơ chế Hidden Partitioning & Partition Evolution: Người dùng không cần phải ghi nhớ cột phân vùng khi viết SQL (ví dụ không cần phải viết WHERE year = 2026 AND month = 8, chỉ cần lọc theo timestamp gốc WHERE event_time >= '2026-08-01'), Iceberg tự động tối ưu hóa việc tỉa phân vùng (Partition Pruning). Ngoài ra, Iceberg cho phép thay đổi phân vùng mà không làm gián đoạn bảng.
3. Kiến trúc Metadata dạng cây phân cấp (Hierarchical Manifests): Tách biệt rõ ràng giữa Snapshot $\rightarrow$ Manifest List $\rightarrow$ Manifest File $\rightarrow$ Data File, giúp các Query Engine phân tán độc lập (Trino, Snowflake, Spark) dễ dàng tối ưu hóa việc lập kế hoạch truy vấn (Query Planning) mà không phụ thuộc vào Spark runtime.

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

Data Lakehouse = Tính linh hoạt & Chi phí rẻ của Data Lake + Tính toàn vẹn ACID & Hiệu năng của Data Warehouse.
Table Format (Delta Lake, Iceberg, Hudi) là lớp Metadata quản lý trạng thái bảng trên nền file Parquet.
Chọn CoW khi ưu tiên tốc độ đọc (Read-heavy / Batch); chọn MoR khi ưu tiên tốc độ ghi nạp liên tục (Write-heavy / Streaming CDC).
Sử dụng Z-Ordering để tăng tốc độ lọc dữ liệu đa chiều và chạy VACUUM định kỳ để kiểm soát chi phí lưu trữ.