ETL, ELT, data lake & lakehouse

TL;DR: Dữ liệu phải đi từ nguồn giao dịch sang hệ thống phân tích — câu hỏi là biến đổi (transform) lúc nào và lưu dạng gì. ETL (Extract-Transform-Load) biến đổi dữ liệu trước khi nạp vào kho, nên kho chỉ chứa dữ liệu đã làm sạch theo schema cố định. ELT (Extract-Load-Transform) nạp dữ liệu thô trước, rồi biến đổi trong kho bằng chính sức mạnh tính toán của kho — lên ngôi khi kho phân tích đủ mạnh và rẻ. Về nơi lưu: data warehouse ép cấu trúc khi ghi (schema-on-write, chỉ dữ liệu có cấu trúc), data lake lưu thô mọi định dạng và áp cấu trúc khi đọc (schema-on-read), lakehouse ghép hai thế giới. Mỗi lựa chọn là một đánh đổi giữa kiểm soát và linh hoạt.

Suốt module này ta dựng bức tranh: bài 01 tách OLAP sang warehouse, bài 02 lưu theo cột, bài 03 tổ chức thành fact/dimension. Cả ba giả định một điều chưa mổ: làm sao dữ liệu từ database giao dịch đến được warehouse — và ở dạng nào.

Đó là việc của pipeline dữ liệu. Bài này phân biệt hai cách dựng pipeline (ETL vs ELT — khác nhau ở chỗ biến đổi trước hay sau khi nạp) và ba kiểu kho lưu (warehouse, lake, lakehouse — khác nhau ở chỗ ép cấu trúc khi ghi hay khi đọc). Đây là bài khép lại vòng đời dữ liệu mà bài 01 mở ra.

1. Analogy — Bếp ăn sẵn và kho nguyên liệu

Hình dung hai cách một nhà hàng chuỗi xử lý thực phẩm:

• Bếp trung tâm sơ chế trước (ETL): rau được rửa, thái, đóng gói đúng khẩu phần trước khi chuyển tới từng chi nhánh. Chi nhánh nhận về là dùng ngay, gọn gàng, đồng nhất. Nhưng nếu sau này muốn món mới cần phần rau thái kiểu khác, nguyên liệu đã sơ chế theo một kiểu rồi — khó quay lại.
• Kho nguyên liệu thô (ELT): mọi nguyên liệu thô chuyển thẳng về kho lớn của chi nhánh, chế biến tại chỗ khi cần. Linh hoạt — món nào cũng làm được vì còn nguyên liệu gốc; đổi lại chi nhánh phải có bếp đủ mạnh để xử lý khối lượng lớn.

Còn về chỗ lưu:

• Tủ lạnh phân loại sẵn (warehouse): chỉ nhận thực phẩm đã sơ chế, xếp ngăn nắp theo loại — lấy ra nhanh, nhưng thứ gì không vừa khuôn thì không cho vào.
• Kho tổng để thô (lake): chứa mọi thứ ở dạng gốc — rau, thịt, gia vị, cả thứ chưa biết dùng làm gì — phân loại lúc lấy ra dùng. Chứa được tất cả, nhưng tìm và dùng tốn công hơn.

2. ETL — Extract, Transform, Load

ETL là pipeline kinh điển, gồm ba bước theo đúng thứ tự tên:

1. Extract: rút dữ liệu từ các nguồn (database giao dịch OLTP, file log, API).
2. Transform: làm sạch và định hình ngoài kho — chuẩn hoá định dạng, lọc rác, gộp/tách, ánh xạ vào fact/dimension (bài 03), tính sẵn các cột phái sinh.
3. Load: nạp dữ liệu đã biến đổi xong vào warehouse theo schema cố định.

ETL flow:

[Nguon OLTP] --Extract--> [May transform rieng]
                              |
                          Transform (lam sach, dinh hinh)
                              |
                              v
                       [Data warehouse]  <-- chi chua du lieu da sach

Hệ quả của "transform trước load":

• Warehouse luôn sạch và đúng schema. Mọi thứ vào kho đã được kiểm soát — analyst query trên dữ liệu nhất quán, đáng tin.
• Nhưng biến đổi cứng nhắc. Logic transform chốt trước khi nạp; muốn một góc nhìn mới cần dữ liệu thô khác đi thì phải sửa pipeline và nạp lại — chậm. Dữ liệu thô gốc thường không giữ lại trong kho.
• Cần một tầng xử lý riêng để chạy transform trước khi tới kho — thêm hạ tầng để vận hành.

ETL ngự trị thời warehouse còn đắt và yếu: lọc bớt dữ liệu trước khi nạp giúp tiết kiệm dung lượng và sức tính của kho.

3. ELT — Extract, Load, Transform

ELT đảo thứ tự hai bước cuối: nạp trước, biến đổi sau — và biến đổi bên trong kho.

1. Extract: rút dữ liệu từ nguồn (như ETL).
2. Load: nạp dữ liệu thô, chưa biến đổi thẳng vào kho.
3. Transform: biến đổi trong kho, dùng chính sức mạnh tính toán của warehouse/engine để làm sạch và định hình khi cần.

ELT flow:

[Nguon OLTP] --Extract--> --Load--> [Data warehouse / lake]
                                        |
                                    Transform tai cho (trong kho)
                                        |
                                        v
                                   [Bang da dinh hinh cho BI]

Vì sao ELT lên ngôi:

• Warehouse hiện đại đủ mạnh và rẻ. Khi kho có thể quét và biến đổi khối lượng lớn nhanh (nhờ column store + vectorized ở bài 02, hạ tầng co giãn), không cần tầng transform riêng nữa — làm transform ngay trong kho tiện hơn.
• Giữ được dữ liệu thô. Vì nạp thô trước, dữ liệu gốc còn nguyên trong kho. Cần một góc nhìn mới? Chỉ viết transform mới chạy lại trên dữ liệu thô đã có — không phải nạp lại từ nguồn. Linh hoạt hơn ETL nhiều.
• Pipeline đơn giản hơn. Bớt một tầng hạ tầng (máy transform riêng); nạp nhanh vì không chờ transform trước.

Đổi lại, ELT đẩy gánh nặng tính toán transform vào trong kho — cần kho đủ khoẻ, và dữ liệu thô chưa sạch nằm trong kho đòi kỷ luật quản trị để analyst không query nhầm dữ liệu chưa làm sạch.

flowchart LR
  SRC["Nguon OLTP"]
  subgraph ETL_FLOW["ETL"]
    E1["Extract"] --> T1["Transform<br/>(ngoai kho)"] --> L1["Load<br/>(du lieu sach)"]
  end
  subgraph ELT_FLOW["ELT"]
    E2["Extract"] --> L2["Load<br/>(du lieu tho)"] --> T2["Transform<br/>(trong kho)"]
  end
  SRC --> E1
  SRC --> E2

4. Data warehouse — schema-on-write

Data warehouse là kho phân tích "cổ điển": dữ liệu phải có cấu trúc và đúng schema ngay khi ghi vào — gọi là schema-on-write. Bạn định nghĩa fact/dimension (bài 03) trước, rồi mọi dữ liệu nạp vào phải khớp khuôn đó. Thứ không khớp bị từ chối hoặc phải biến đổi cho khớp trước.

• Lợi: dữ liệu trong kho luôn sạch, nhất quán, đúng kiểu — query nhanh và đáng tin, hợp BI và báo cáo chính thức.
• Hạn chế: chỉ chứa được dữ liệu có cấu trúc; dữ liệu phi cấu trúc (ảnh, log thô, văn bản tự do) khó nhét vào. Đổi schema tốn công vì dữ liệu đã ghi theo khuôn cũ.

Warehouse là nơi star schema và column store của các bài trước phát huy — môi trường có kỷ luật, tối ưu cho đọc.

5. Data lake — schema-on-read

Data lake lật ngược: lưu dữ liệu thô ở mọi định dạng (có cấu trúc, bán cấu trúc, phi cấu trúc — bảng, JSON, log, ảnh) y như khi nhận, chưa áp schema lúc ghi. Cấu trúc chỉ được áp khi đọc — gọi là schema-on-read: lúc query, bạn mới quyết định diễn giải dữ liệu thô thành bảng/cột thế nào.

• Lợi: chứa được mọi thứ, kể cả dữ liệu chưa biết sẽ dùng làm gì; nạp rẻ và nhanh vì không cần biến đổi trước; linh hoạt — cùng dữ liệu thô diễn giải nhiều cách cho nhiều mục đích.
• Hạn chế: không kỷ luật khi ghi nên dễ thành "đầm lầy dữ liệu" (data swamp) — đầy dữ liệu không ai biết nghĩa, chất lượng không kiểm soát; query phức tạp hơn vì phải tự áp cấu trúc mỗi lần; quản trị (chất lượng, quyền truy cập) khó hơn warehouse.

Lake hợp khi cần giữ mọi dữ liệu thô đa dạng cho khám phá linh hoạt, chấp nhận đánh đổi kỷ luật.

flowchart TB
  subgraph WH["Data warehouse -- schema-on-write"]
    W_IN["Du lieu co cau truc"] -->|"ep schema khi GHI"| W_STORE["Kho da chuan hoa"]
  end
  subgraph LK["Data lake -- schema-on-read"]
    L_IN["Du lieu tho moi dinh dang"] -->|"luu y nguyen"| L_STORE["Kho tho"]
    L_STORE -->|"ap schema khi DOC"| L_Q["Query dien giai"]
  end

6. Lakehouse — ghép hai thế giới

Warehouse kỷ luật nhưng cứng; lake linh hoạt nhưng dễ loạn. Lakehouse ra đời để lấy ưu của cả hai: lưu dữ liệu thô đa dạng chi phí thấp như lake, nhưng thêm một tầng quản trị mang lại cấu trúc, kiểu dữ liệu và đảm bảo nhất quán như warehouse lên trên dữ liệu thô đó.

Ý tưởng cốt lõi: không phải copy dữ liệu sang hai hệ thống riêng (một lake để thô, một warehouse để sạch), mà giữ một chỗ lưu thô rồi áp một tầng siêu dữ liệu (metadata) + đảm bảo giao dịch lên trên, để cùng dữ liệu đó vừa truy vấn kiểu warehouse (có schema, nhất quán) vừa giữ được sự đa dạng và chi phí thấp của lake.

• Lợi: một nguồn dữ liệu duy nhất phục vụ cả khám phá thô lẫn BI có kỷ luật; bớt trùng lặp giữa lake và warehouse.
• Đánh đổi: là kiến trúc trẻ và phức tạp hơn — đòi công cụ/quy trình trưởng thành để tầng quản trị thực sự giữ được kỷ luật mà không mất linh hoạt.

7. Khép vòng — pipeline OLTP đến phân tích

Ghép lại toàn module: dữ liệu sinh ra ở database giao dịch OLTP (bài 01, row store — bài 02), một pipeline (ETL hoặc ELT) đưa nó sang hệ thống phân tích (warehouse/lake/lakehouse), nơi nó được tổ chức (dimensional modeling — bài 03) và lưu tối ưu cho đọc (column store — bài 02) để phục vụ BI.

flowchart LR
  APP["App OLTP"] --> OLTPDB[("DB giao dich<br/>row store")]
  OLTPDB -->|"ETL / ELT"| ANALYTIC[("Warehouse / Lake / Lakehouse<br/>column store, fact+dimension")]
  ANALYTIC --> BI["BI / Dashboard"]

Không có lựa chọn nào "đúng tuyệt đối" — mỗi quyết định (ETL hay ELT, warehouse hay lake hay lakehouse) là một đánh đổi giữa kiểm soát (sạch, nhất quán, dễ tin) và linh hoạt (giữ thô, đa định dạng, dễ đổi góc nhìn). Chọn theo nhu cầu: dữ liệu ổn định + báo cáo chính thức nghiêng về warehouse/ETL; dữ liệu đa dạng + khám phá nghiêng về lake/ELT; muốn cả hai thì lakehouse.

8. Pitfall — chọn kiến trúc theo trào lưu

SAI: du lieu deu co cau truc, bao cao co dinh -> dung dung data lake "cho hien dai"
     -> them rui ro data swamp, quan tri nang, loi it

SAI: "lake = vut moi thu vao, tinh sau" (bo metadata/kiem soat)
     -> data swamp: day du lieu khong ai biet nghia

DUNG: chon theo nhu cau (kiem soat vs linh hoat), khong theo trao luu;
      lake/lakehouse van can ky luat quan tri

9. 📚 Deep Dive

10. Liên hệ các bài khác

• Bài 01 — OLTP vs OLAP: pipeline ETL/ELT trong bài này chính là bước "đồng bộ định kỳ từ OLTP sang warehouse" mà bài 01 nhắc tới — đây là chỗ mổ chi tiết.
• Bài 02 — Row store vs column store: warehouse/lake/lakehouse lưu theo cột để quét nhanh — mô hình lưu trữ mà pipeline này nạp dữ liệu vào.
• Bài 03 — Dimensional modeling & star schema: bước Transform (trong ETL/ELT) chính là nơi dữ liệu thô được định hình thành fact/dimension.
• Module 5 — Normalization 1NF–3NF: schema-on-write của warehouse áp cấu trúc chặt khi ghi, đối lập với schema-on-read linh hoạt của lake — cùng câu hỏi "ép cấu trúc lúc nào".
• Module 6 — Vì sao cần index: tối ưu đọc trong database giao dịch — đối chiếu với cách warehouse tối ưu đọc bằng mô hình lưu trữ và tổ chức bảng riêng.

11. Tóm tắt

• Đưa dữ liệu từ OLTP sang phân tích đặt hai câu hỏi: biến đổi lúc nào (ETL vs ELT) và lưu dạng gì (warehouse vs lake vs lakehouse).
• ETL transform trước load → kho luôn sạch, đúng schema; đổi lại cứng nhắc, thường không giữ dữ liệu thô.
• ELT load thô trước, transform trong kho → linh hoạt (giữ thô, đổi góc nhìn dễ), pipeline gọn; cần kho đủ mạnh — lên ngôi vì warehouse hiện đại mạnh và rẻ.
• Data warehouse: schema-on-write, chỉ dữ liệu có cấu trúc — sạch, nhất quán, hợp BI; nhưng cứng.
• Data lake: schema-on-read, lưu thô mọi định dạng — linh hoạt, nạp rẻ; nhưng dễ thành data swamp, khó quản trị.
• Lakehouse: ghép cả hai — lưu thô chi phí thấp như lake + tầng quản trị cho cấu trúc/nhất quán như warehouse; đổi lại phức tạp và còn non.
• Mọi lựa chọn là đánh đổi giữa kiểm soát và linh hoạt — chọn theo nhu cầu, không theo trào lưu.

12. Tự kiểm tra

Bài tiếp theo: Capstone — thiết kế một data system