Data Engineering 7 — Data Lake, Warehouse & Lakehouse

Mở đầu: tại sao có nhiều kiểu "kho" dữ liệu?

Khi một tổ chức bắt đầu thu thập dữ liệu, câu hỏi đầu tiên luôn là: "Để dữ liệu ở đâu?". Câu trả lời nghe có vẻ đơn giản, nhưng thực tế đã sinh ra cả một lịch sử kiến trúc kéo dài hơn ba thập kỷ. Từ Data Warehouse (kho dữ liệu) ra đời thập niên 1990, đến Data Lake (hồ dữ liệu) bùng nổ cùng làn sóng Big Data những năm 2010, và gần đây nhất là Lakehouse — kiến trúc lai cố gắng gộp ưu điểm của cả hai.

Mỗi mô hình không phải là "cái sau thay thế cái trước" một cách tuyệt đối. Chúng giải quyết những nhu cầu khác nhau, đánh đổi khác nhau giữa chi phí, tốc độ, độ linh hoạt và độ tin cậy. Hiểu rõ ba mô hình này là nền tảng để bạn không "chọn nhầm công cụ", một sai lầm rất tốn kém vì di chuyển dữ liệu giữa các kiến trúc là việc cực kỳ đau đớn.

Bài này đi từ con số không: ta sẽ làm rõ từng khái niệm, so sánh chúng một cách khách quan, rồi đào sâu vào lớp công nghệ làm cho Lakehouse khả thi (open table format), và cuối cùng là kiến trúc tổ chức dữ liệu thực dụng nhất hiện nay — medallion architecture.

Data Warehouse: schema-on-write, kỷ luật và đắt đỏ

Bản chất

Data Warehouse là một hệ thống lưu trữ dữ liệu đã được làm sạch, chuẩn hóa và mô hình hóa để phục vụ phân tích và báo cáo (BI — Business Intelligence). Ý tưởng cốt lõi do Bill Inmon và Ralph Kimball định hình: gom dữ liệu từ nhiều nguồn vận hành (hệ thống core banking, CRM, ERP...) về một nơi duy nhất, biến đổi nó về một schema thống nhất, rồi để các nhà phân tích truy vấn.

Đặc điểm định danh của warehouse là schema-on-write: bạn phải định nghĩa cấu trúc bảng (kiểu cột, ràng buộc, quan hệ) trước khi ghi dữ liệu vào. Mọi dữ liệu nạp vào đều phải khớp schema đó, nếu không sẽ bị từ chối. Điều này tạo ra kỷ luật rất cao: dữ liệu trong warehouse luôn sạch, nhất quán, đáng tin.

Ưu điểm

• Hiệu năng truy vấn cao: dữ liệu được tối ưu sẵn (cột hóa, đánh chỉ mục, phân vùng), engine SQL chạy nhanh.
• Chất lượng dữ liệu đảm bảo: schema-on-write loại bỏ dữ liệu rác ngay từ cửa.
• Thân thiện với BI: công cụ như Power BI, Tableau cắm thẳng vào, người dùng nghiệp vụ tự phân tích được.
• Hỗ trợ giao dịch ACID: cập nhật, xóa, transaction nhất quán — điều mà data lake truyền thống không có.

Nhược điểm

• Đắt: lưu trữ và tính toán thường gắn chặt (coupled), bạn trả tiền cho cả hai dù chỉ cần một.
• Cứng nhắc: chỉ chứa dữ liệu có cấu trúc (structured). Ảnh, log, văn bản tự do, JSON lồng sâu... rất khó nhét vào.
• Chậm thích nghi: thay đổi schema (thêm cột, đổi kiểu) tốn công, vì mọi pipeline phụ thuộc vào nó.
• Không hợp cho khoa học dữ liệu / ML: dữ liệu thô thường đã bị "nắn" mất chi tiết cần cho mô hình.

Trong bối cảnh ngân hàng, warehouse là trái tim của hệ thống báo cáo quản trị (MIS), báo cáo tuân thủ gửi cơ quan quản lý, và các dashboard điều hành. Đây là nơi cần con số chính xác tuyệt đối.

Data Lake: schema-on-read, rẻ và linh hoạt — nhưng dễ thành đầm lầy

Bản chất

Data Lake ra đời khi dữ liệu phình to về cả khối lượng lẫn đa dạng định dạng. Ý tưởng đảo ngược warehouse: thay vì "làm sạch rồi mới lưu", hãy lưu mọi thứ ở dạng thô trước, lo cấu trúc sau. Dữ liệu được đổ thẳng vào object storage giá rẻ (Amazon S3, Azure Data Lake Storage, Google Cloud Storage) dưới mọi định dạng: CSV, JSON, Parquet, ảnh, video, log...

Đặc điểm định danh là schema-on-read: bạn không áp schema khi ghi, mà chỉ diễn giải cấu trúc khi đọc dữ liệu ra để dùng. Cùng một file có thể được đọc theo nhiều schema khác nhau tùy mục đích.

Ưu điểm

• Rẻ: object storage cực rẻ, và lưu trữ tách rời tính toán (decoupled) — bạn chỉ trả tiền compute khi thực sự chạy job.
• Linh hoạt tối đa: chứa được mọi định dạng, cấu trúc và phi cấu trúc.
• Lý tưởng cho ML/Data Science: giữ nguyên dữ liệu thô, nhà khoa học dữ liệu tự do khai thác.
• Mở rộng gần như vô hạn: object storage scale theo nhu cầu.

Nhược điểm và rủi ro "data swamp"

Đây là điểm chí mạng. Vì không có kỷ luật schema, không có giao dịch ACID, không có quản trị chặt, data lake rất dễ thoái hóa thành "data swamp" (đầm lầy dữ liệu): một mớ file hỗn độn không ai biết file nào đúng, nguồn gốc từ đâu, schema ra sao, dùng được hay không.

• Không ACID: hai job ghi cùng lúc có thể làm hỏng dữ liệu; đọc giữa lúc đang ghi thấy dữ liệu nửa vời.
• Không enforce schema: dữ liệu rác lọt vào tự do.
• Khó quản trị & truy vết: thiếu metadata, thiếu lineage.
• Hiệu năng SQL kém nếu không tổ chức tốt: quét hàng triệu file nhỏ rất chậm.

Lakehouse: hợp nhất hai thế giới

Ý tưởng cốt lõi

Câu hỏi đặt ra: tại sao phải chọn? Tại sao không có sự rẻ và linh hoạt của data lake cộng với độ tin cậy, ACID và hiệu năng của warehouse? Đó chính là Lakehouse.

Lakehouse vẫn lưu dữ liệu trên object storage giá rẻ (giữ tính rẻ và mở của lake), nhưng phủ lên trên một lớp giao dịch (transactional layer) mang lại ACID, enforce schema, time travel và hiệu năng truy vấn cao — những thứ vốn là độc quyền của warehouse. Lớp ma thuật này chính là open table format, sẽ bàn ở phần sau.

Kết quả: một nền tảng duy nhất phục vụ cả BI (báo cáo) lẫn ML (khoa học dữ liệu), trên cùng một bản sao dữ liệu, không cần sao chép qua lại giữa lake và warehouse như kiến trúc hai tầng truyền thống.

Bảng so sánh ba kiến trúc

Tiêu chí	Data Warehouse	Data Lake	Lakehouse
Schema	Schema-on-write	Schema-on-read	Schema-on-read + enforce được
Định dạng dữ liệu	Có cấu trúc	Mọi định dạng	Mọi định dạng
Lưu trữ	Lưu trữ chuyên dụng (đắt)	Object storage (rẻ)	Object storage (rẻ)
Tính toán & lưu trữ	Thường gắn chặt	Tách rời	Tách rời
Giao dịch ACID	Có	Không (truyền thống)	Có (qua table format)
Hiệu năng BI/SQL	Rất cao	Thấp đến trung bình	Cao
Hỗ trợ ML/AI	Hạn chế	Rất tốt	Rất tốt
Time travel	Hạn chế	Không	Có
Rủi ro "data swamp"	Thấp	Cao	Thấp (nhờ quản trị)
Chi phí tổng thể	Cao	Thấp	Trung bình - thấp
Use case điển hình	Báo cáo, BI	Lưu thô, Data Science	Hợp nhất BI + ML

Open table format: lớp công nghệ làm Lakehouse khả thi

Một data lake bản chất chỉ là một đống file (thường là Parquet) trên object storage. Để biến đống file đó thành những "bảng" hành xử như trong cơ sở dữ liệu, ta cần một lớp metadata thông minh đứng giữa file vật lý và engine truy vấn. Đó là open table format. Có ba cái tên nổi bật.

Delta Lake

Khởi xướng bởi Databricks, nay là dự án mã nguồn mở (Linux Foundation). Delta Lake bổ sung một transaction log (thư mục _delta_log chứa các file JSON ghi lại mọi thay đổi) bên cạnh các file Parquet dữ liệu. Nhờ log này, Delta cung cấp:

• ACID transactions: nhiều job ghi đồng thời được kiểm soát; đọc luôn thấy trạng thái nhất quán.
• Time travel: truy vấn dữ liệu tại một phiên bản hoặc thời điểm trong quá khứ (VERSION AS OF, TIMESTAMP AS OF).
• Schema evolution: thêm cột, đổi cấu trúc một cách có kiểm soát mà không phá pipeline cũ.
• MERGE / UPSERT / DELETE: cập nhật và xóa cấp dòng — điều mà Parquet thuần không làm được, rất quan trọng cho yêu cầu như GDPR "quyền được lãng quên".

Apache Iceberg

Khởi nguồn từ Netflix, nay là dự án Apache hàng đầu, được xem là chuẩn mở trung lập nhất hiện nay. Iceberg dùng kiến trúc metadata phân tầng (metadata file → manifest list → manifest → data files) cho phép quản lý bảng cực lớn (hàng petabyte, hàng triệu partition) hiệu quả. Điểm mạnh nổi bật:

• Partition evolution: đổi cách phân vùng mà không cần viết lại toàn bộ dữ liệu cũ.
• Hidden partitioning: người dùng truy vấn không cần biết bảng phân vùng thế nào.
• Trung lập về engine: được Spark, Trino, Flink, Snowflake, BigQuery... hỗ trợ rộng, tránh khóa nhà cung cấp (vendor lock-in).

Apache Hudi

Khởi nguồn từ Uber, tập trung mạnh vào các workload ghi gia tăng (incremental) và cập nhật streaming. Hudi cung cấp hai chế độ bảng (Copy-on-Write và Merge-on-Read) để cân bằng giữa hiệu năng đọc và độ trễ ghi, rất phù hợp khi dữ liệu liên tục thay đổi theo dòng sự kiện.

Tóm lại, cả ba đều mang đến ACID, time travel và schema evolution cho dữ liệu trên object storage. Chúng khác nhau ở trọng tâm thiết kế và hệ sinh thái. Đây là phần giới thiệu — việc chọn cái nào phụ thuộc engine bạn dùng và mức độ cần trung lập nhà cung cấp.

Medallion Architecture: tổ chức dữ liệu trong Lakehouse

Có công nghệ rồi, ta cần một nguyên tắc tổ chức để dữ liệu không lại biến thành đầm lầy. Mẫu hình phổ biến nhất là medallion architecture (kiến trúc huy chương), chia dữ liệu thành ba lớp chất lượng tăng dần: Bronze → Silver → Gold.

Bronze (lớp đồng) — dữ liệu thô

Đây là điểm tiếp nhận dữ liệu nguyên trạng từ nguồn, gần như không biến đổi. Mục tiêu là giữ lại bản gốc đầy đủ để có thể tái xử lý lại bất cứ lúc nào nếu logic ở các lớp sau thay đổi. Bronze thường lưu cả metadata kỹ thuật (thời điểm nạp, nguồn, file gốc). Quan điểm cốt lõi: đừng bao giờ làm mất dữ liệu thô, vì bạn không thể tái tạo lại nó.

Silver (lớp bạc) — dữ liệu đã làm sạch

Từ Bronze, dữ liệu được làm sạch: ép kiểu, xử lý null, khử trùng lặp, chuẩn hóa định dạng (ngày tháng, đơn vị tiền tệ), join các bảng liên quan, áp các quy tắc chất lượng. Kết quả là một mô hình dữ liệu nhất quán, đáng tin, ở mức chi tiết cấp giao dịch — đủ tốt để phân tích sâu và làm đầu vào cho ML.

Gold (lớp vàng) — dữ liệu sẵn sàng dùng

Lớp cao nhất: dữ liệu được tổng hợp (aggregate) và mô hình hóa theo nhu cầu nghiệp vụ cụ thể — ví dụ bảng dư nợ theo chi nhánh theo tháng, bảng hành vi khách hàng, feature table cho mô hình rủi ro tín dụng. Đây là dữ liệu mà người dùng cuối (analyst, dashboard, mô hình) trực tiếp tiêu thụ. Mỗi use case có thể có bảng Gold riêng.

Lợi ích của mô hình này là tách trách nhiệm rõ ràng: lỗi ở đâu dễ truy, mỗi lớp có thể tái xử lý độc lập, và dữ liệu cấp cao luôn truy ngược được về nguồn thô.

ELT trong Lakehouse

Ở chương trước về pipeline, ta đã phân biệt ETL và ELT. Lakehouse đặc biệt thiên về ELT (Extract — Load — Transform). Vì sao?

Trong ETL truyền thống, ta biến đổi dữ liệu trước khi nạp vào warehouse, do warehouse đắt nên không muốn chứa dữ liệu thô. Nhưng trong Lakehouse, lưu trữ rẻ và tính toán mạnh, nên trình tự đảo lại:

1. Extract: rút dữ liệu từ nguồn.
2. Load: nạp thẳng dữ liệu thô vào Bronze (gần như không biến đổi).
3. Transform: dùng chính sức mạnh tính toán của nền tảng (Spark SQL, dbt...) để biến đổi dữ liệu từ Bronze → Silver → Gold bên trong lakehouse.

Điều này khớp hoàn hảo với medallion: việc Transform chính là quá trình "tinh luyện" dữ liệu qua từng lớp huy chương. Ưu điểm: giữ được dữ liệu thô (tái xử lý được), tách rời compute/storage giúp tiết kiệm, và logic biến đổi nằm tập trung dưới dạng SQL dễ kiểm soát phiên bản.

Các nền tảng đám mây phổ biến

Thị trường có nhiều nền tảng triển khai các kiến trúc trên. Nêu khách quan vài cái tên thường gặp:

• Google BigQuery: kho dữ liệu serverless, tách compute/storage, mạnh về SQL phân tích quy mô lớn; hỗ trợ truy vấn dữ liệu trên object storage và đọc Iceberg.
• Snowflake: nền tảng dữ liệu đám mây tách compute/storage triệt để, dễ vận hành, hỗ trợ chia sẻ dữ liệu và Iceberg.
• Amazon Redshift: kho dữ liệu của AWS, tích hợp chặt hệ sinh thái AWS, truy vấn được dữ liệu trên S3 (Spectrum).
• Databricks: nền tảng lakehouse dựa trên Spark và Delta Lake, mạnh cho cả kỹ thuật dữ liệu lẫn ML/AI trên cùng một nơi.

Lưu ý: ranh giới giữa "warehouse" và "lakehouse" ở các nền tảng này ngày càng mờ — phần lớn đều đang hội tụ về khả năng đọc/ghi open table format và tách compute khỏi storage. Việc chọn nền tảng nên dựa trên hệ sinh thái đám mây hiện có, kỹ năng đội ngũ và chi phí, hơn là nhãn marketing.

Chọn kiến trúc theo nhu cầu

Không có lựa chọn "tốt nhất" tuyệt đối. Hãy chọn theo bài toán:

• Chỉ cần báo cáo BI từ dữ liệu có cấu trúc, ưu tiên độ chính xác và đơn giản → Data Warehouse vẫn rất hợp lý.
• Cần lưu khối lượng lớn dữ liệu đa dạng, phục vụ Data Science, chấp nhận tự xây quản trị → Data Lake.
• Cần phục vụ cả BI lẫn ML trên một bản dữ liệu, muốn ACID nhưng vẫn rẻ và mở → Lakehouse.

Một thực tế hữu ích: nhiều tổ chức không chọn một, mà tiến hóa dần. Bắt đầu với warehouse cho báo cáo, dựng lake khi dữ liệu phình to, rồi hợp nhất thành lakehouse khi muốn xóa bỏ sự trùng lặp giữa hai hệ thống.

Bối cảnh ngân hàng

Với một ngân hàng, kiến trúc dữ liệu thường có dáng dấp như sau. Dữ liệu giao dịch từ core banking, dữ liệu khách hàng từ CRM, log ứng dụng số, dữ liệu thị trường... đổ vào lớp Bronze. Lớp Silver chuẩn hóa thành mô hình khách hàng/tài khoản/giao dịch nhất quán, khử trùng lặp, đối soát. Lớp Gold sản sinh các bảng nghiệp vụ: báo cáo dư nợ và huy động phục vụ MIS, dữ liệu cho báo cáo tuân thủ gửi cơ quan quản lý, feature table cho mô hình chấm điểm tín dụng và phát hiện gian lận.

Điểm nhấn trong ngành ngân hàng: tính chính xác, truy vết nguồn gốc (lineage) và bảo mật là tối quan trọng. Vì vậy, dù chọn kiến trúc nào, lakehouse với ACID và time travel rất hấp dẫn — nó cho phép truy vết "con số báo cáo ngày X dựa trên dữ liệu phiên bản nào", một yêu cầu kiểm toán điển hình. Đây cũng là lý do quản trị dữ liệu (governance) trở thành mảnh ghép không thể thiếu, là chủ đề của chương tiếp theo.

Tóm tắt

Data Warehouse dùng schema-on-write, chứa dữ liệu có cấu trúc đã làm sạch, mạnh cho BI nhưng đắt và cứng nhắc. Data Lake dùng schema-on-read trên object storage giá rẻ, chứa mọi định dạng và lý tưởng cho ML, nhưng dễ thoái hóa thành "data swamp" vì thiếu kỷ luật và ACID. Lakehouse hợp nhất hai thế giới: lưu dữ liệu trên object storage rẻ nhưng phủ thêm lớp giao dịch ACID nhờ open table format (Delta Lake, Apache Iceberg, Apache Hudi) mang lại time travel và schema evolution. Medallion architecture (Bronze → Silver → Gold) là cách tổ chức dữ liệu thực dụng trong lakehouse, kết hợp tự nhiên với mô hình ELT. Các nền tảng như BigQuery, Snowflake, Redshift, Databricks đang hội tụ về cùng năng lực này. Lựa chọn kiến trúc nên dựa trên nhu cầu thực tế chứ không theo trào lưu.

Tự kiểm tra

1. Sự khác biệt cốt lõi giữa schema-on-write và schema-on-read là gì, và nó dẫn đến ưu/nhược điểm nào cho warehouse so với lake?
2. "Data swamp" là gì, nó phát sinh từ thiếu sót nào của data lake truyền thống?
3. Open table format (như Delta, Iceberg, Hudi) mang lại những khả năng gì để biến một data lake thành lakehouse?
4. Mô tả vai trò của ba lớp Bronze, Silver, Gold trong medallion architecture và tại sao phải giữ lại lớp Bronze thô.
5. Vì sao Lakehouse thiên về ELT thay vì ETL, và điều này khớp với medallion ra sao?
6. Trong bối cảnh ngân hàng, time travel và lineage của lakehouse giúp ích gì cho yêu cầu kiểm toán?

Đọc tiếp

Data Engineering 8 — Governance & Chất lượng