</>Học Dev
Bài học

Tuần 1 - Ngày 2: Data Lake vs Data Warehouse vs Lakehouse

Tuần 1 – Ngày 2

Mục tiêu học tập

  • Phân biệt data lake, data warehouse và lakehouse — khi nào dùng gì
  • Hiểu vì sao S3 là nền tảng của data lake trên AWS
  • Nắm kiến trúc data lake chuẩn: các zone (raw/curated), catalog, query engine
  • Biết các thành phần lakehouse hiện đại: open table formats (Iceberg), S3 Tables

1. Ba mô hình lưu trữ dữ liệu phân tích

Data Warehouse

Kho dữ liệu có cấu trúc, được thiết kế schema trước khi nạp (schema-on-write), tối ưu cho SQL analytics/BI.

  • Dữ liệu đã được làm sạch, chuẩn hóa (star/snowflake schema)
  • Hiệu năng truy vấn cao, hỗ trợ concurrent users
  • Trên AWS: Amazon Redshift (provisioned hoặc Serverless)
  • Chi phí lưu trữ cao hơn object storage; kém linh hoạt với dữ liệu semi/unstructured

Data Lake

Kho lưu mọi loại dữ liệu (structured, semi-structured, unstructured) ở dạng thô, áp schema khi đọc (schema-on-read).

  • Lưu trữ rẻ, scale gần như vô hạn
  • Trên AWS: Amazon S3 + AWS Glue Data Catalog + query engine (Athena, Redshift Spectrum, EMR)
  • Rủi ro "data swamp" nếu thiếu catalog, quality, governance

Lakehouse

Kết hợp cả hai: dữ liệu nằm trên object storage (như data lake) nhưng có table format cung cấp tính năng warehouse: ACID transactions, schema evolution, time travel, upsert/delete.

  • Open table formats: Apache Iceberg, Apache Hudi, Delta Lake
  • Trên AWS: S3 + Iceberg tables (query qua Athena/Glue/EMR/Redshift), hoặc Amazon S3 Tables (managed Iceberg, ra mắt 12/2024)

Bảng so sánh

Data WarehouseData LakeLakehouse
SchemaSchema-on-writeSchema-on-readSchema-on-read + evolution
Loại dữ liệuStructuredMọi loạiMọi loại
ACID transactionsKhông (table format)
Chi phí lưu trữCaoThấp (S3)Thấp (S3)
Update/Delete rowKhó (rewrite file) (merge-on-read/copy-on-write)
AWS serviceRedshiftS3 + Glue + AthenaS3 + Iceberg / S3 Tables
Use caseBI, dashboard, SQL nặngLưu thô, ML, đa dạng workloadData lake cần ACID + upsert

Exam keyword: "cần UPDATE/DELETE từng bản ghi trên data lake S3" → Apache Iceberg (hoặc Hudi/Delta). "SQL analytics hiệu năng cao, nhiều concurrent BI users" → Redshift.

2. S3 — nền tảng của data lake

Vì sao là S3?

  • Durability 99.999999999% (11 số 9), scale không giới hạn
  • Tách biệt storage và compute: nhiều engine (Athena, Redshift Spectrum, EMR, Glue) cùng đọc một dữ liệu
  • Storage classes đa dạng để tối ưu chi phí theo access pattern
  • Tích hợp sâu với Glue Catalog, Lake Formation (governance), KMS (encryption)

Storage classes quan trọng cho data engineering

ClassUse caseLưu ý
S3 StandardDữ liệu hot, truy cập thường xuyênMặc định
S3 Intelligent-TieringAccess pattern không dự đoán đượcTự chuyển tier, phí monitoring nhỏ
S3 Standard-IATruy cập không thường xuyên, cần lấy ngayPhí retrieval per GB, min 30 ngày
S3 Glacier Instant RetrievalArchive nhưng cần đọc msMin 90 ngày
S3 Glacier Flexible RetrievalArchive, chấp nhận phút-giờMin 90 ngày
S3 Glacier Deep ArchiveArchive dài hạn (compliance)Retrieval 12-48h, min 180 ngày
S3 Express One ZoneLatency ms một chữ số, 1 AZCho workload cực nhanh, không HA

Lifecycle policy: tự động chuyển class theo tuổi object (vd: raw data 90 ngày → IA, 365 ngày → Glacier) — câu hỏi "most cost-effective" kinh điển.

3. Kiến trúc data lake chuẩn trên AWS

DATASOURCESRDBMSSaaSappsStreamingFiles/LogsDMSAppFlowKinesis/DataSync/FirehoseTransferFamilyS3DATALAKErawzonecurated/analytics/(as-is)cleanedpresentation(GlueETL/EMRtransformgiacáczone)schemađăngkýtrongGlueDataCatalogLakeFormation(permissions)metadataAthenaRedshiftEMR/Glue(SQL)Spectrum(Spark)

Các zone (layer) điển hình

  1. Raw (bronze): dữ liệu nguyên bản từ nguồn, immutable — dùng để reprocess khi cần
  2. Curated/Cleaned (silver): đã validate, dedupe, chuẩn hóa, convert sang Parquet
  3. Analytics/Presentation (gold): aggregate, join sẵn theo nhu cầu BI/ML

Mỗi zone thường là prefix hoặc bucket riêng: s3://company-datalake-raw/, s3://company-datalake-curated/...

4. Lakehouse trên AWS: Apache Iceberg

Iceberg giải quyết gì trên S3?

  • ACID transactions: nhiều writer/reader an toàn
  • Row-level update/delete/merge: MERGE INTO qua Athena/Spark
  • Schema evolution: thêm/đổi tên/xóa cột không cần rewrite dữ liệu
  • Time travel: query snapshot quá khứ (FOR TIMESTAMP AS OF)
  • Hidden partitioning: không cần cột partition thủ công trong query

Hỗ trợ trên AWS (2026)

  • Athena: tạo/query/MERGE INTO Iceberg tables (engine v3)
  • Glue: Glue 4.0/5.0 hỗ trợ Iceberg, Hudi, Delta Lake native
  • Redshift: query Iceberg tables trong Glue Catalog
  • Amazon S3 Tables: bucket kiểu mới quản lý Iceberg tự động (compaction, snapshot cleanup) — "least operational overhead" cho Iceberg

5. Chọn mô hình nào? (decision guide)

CnSQLBIhiunăngcao,concurrencyln,dliustructured?Redshift(warehouse)Lưumiloidliu,nhiuengineđc,chiphíthp?S3datalake+GlueCatalog+AthenaDatalakenhưngcnUPDATE/DELETE,ACID,timetravel?IcebergtrênS3(hocS3Tables)Chainhucu?(thưnggpthctế)Kiếntrúckếthp:S3lake(raw/curated)+Redshift(martphcvBI),SpectrumđcthngS3

Câu hỏi ôn tập

  1. Schema-on-read khác schema-on-write thế nào, và mô hình nào dùng cái nào?

    Xem đáp án

    Schema-on-write (data warehouse): định nghĩa schema trước, dữ liệu phải khớp schema mới nạp được — đảm bảo chất lượng nhưng kém linh hoạt. Schema-on-read (data lake): lưu dữ liệu thô, schema chỉ áp khi query (qua Glue Catalog/Athena) — linh hoạt, nạp nhanh, nhưng chất lượng phải kiểm soát bằng quy trình riêng. Lakehouse dùng schema-on-read kèm schema evolution có kiểm soát của table format.

  2. Team cần chạy UPDATE và DELETE trên từng bản ghi trong data lake S3 với chi phí lưu trữ thấp. Giải pháp?

    Xem đáp án

    Dùng open table format — Apache Iceberg (hoặc Hudi/Delta Lake) trên S3. Iceberg cho phép MERGE INTO/UPDATE/DELETE qua Athena hoặc Spark với ACID guarantee, trong khi dữ liệu vẫn nằm trên S3 (rẻ). Chuyển toàn bộ sang Redshift cũng làm được UPDATE/DELETE nhưng chi phí lưu trữ cao hơn — không phải đáp án "most cost-effective" khi đề nhấn mạnh data lake.

  3. Dữ liệu log có access pattern không dự đoán được (một số file đọc thường xuyên, số khác vài tháng không đọc). Storage class nào phù hợp nhất?

    Xem đáp án

    S3 Intelligent-Tiering — tự động di chuyển object giữa các access tier dựa trên pattern thực tế, không phí retrieval, chỉ có phí monitoring nhỏ per object. Standard-IA hay Glacier chỉ phù hợp khi pattern đã biết trước (kết hợp lifecycle policy).

  4. Vì sao kiến trúc data lake tách raw zone và curated zone?

    Xem đáp án

    Raw zone giữ dữ liệu nguyên bản, immutable — là "nguồn sự thật" để reprocess khi logic transform thay đổi hoặc phát hiện bug. Curated zone chứa dữ liệu đã làm sạch, dedupe, convert sang định dạng columnar (Parquet) để query hiệu quả. Tách zone giúp: (1) không mất dữ liệu gốc, (2) phân quyền khác nhau per zone (Lake Formation), (3) tối ưu lifecycle riêng (raw → Glacier sớm hơn).

  5. Redshift Spectrum đóng vai trò gì trong kiến trúc kết hợp lake + warehouse?

    Xem đáp án

    Spectrum cho phép Redshift query trực tiếp dữ liệu trên S3 (qua external table đăng ký trong Glue Data Catalog) mà không cần load vào Redshift. Nhờ đó: dữ liệu hot/aggregate nằm trong Redshift (hiệu năng cao), dữ liệu lịch sử/khối lượng lớn nằm trên S3 (rẻ), và có thể JOIN cả hai trong một câu SQL.

Bài tập thực hành

  • Tạo bucket datalake-<tên>-rawdatalake-<tên>-curated, upload 1 file CSV mẫu vào raw
  • Cấu hình lifecycle rule: chuyển prefix raw/ sang Standard-IA sau 30 ngày
  • Đọc kiến trúc tham khảo Data lakes on AWS
  • Đọc giới thiệu Amazon S3 Tables và note 2 điểm khác Iceberg tự quản

Tài liệu tham khảo chính thức


Tiếp theo: Định dạng dữ liệu: Parquet, ORC, Avro, JSON, CSV