# Data lake, warehouse hay lakehouse: đọc đúng kiến trúc dữ liệu của khách trước khi viết pipeline ML đầu tiên

> Câu "dữ liệu có hết trong warehouse rồi" thường chỉ đúng một nửa. FDE nào tin trọn câu đó có thể mất vài tuần mới phát hiện model của mình đang học từ một bảng dashboard.

Bản gốc: https://fdetimes.net/vi/bach-khoa/data-lake-warehouse-lakehouse-o-khach-hang/

Buổi kickoff nào cũng có một khoảnh khắc như thế này. Bạn hỏi dữ liệu nằm ở đâu, và phía khách trả lời rất tự tin: "Có hết trong warehouse rồi, anh cứ lấy."

Câu đó thường chỉ đúng một nửa. Dữ liệu có thật, nhưng có thể ai đó đã định hình nó cho một mục đích khác và cho làm mới theo một lịch bạn chưa biết. Rất có thể nó đã mất đúng phần tín hiệu mà model của bạn cần.

Đọc sai kiến trúc dữ liệu là loại lỗi khó phát hiện, vì nó không làm hỏng gì ngay. Pipeline vẫn chạy, model vẫn ra số, và có khi phải mấy tuần sau bạn mới biết mình đã xây trên nền sai. Phần dưới đây chỉ cách đọc đúng nền móng ngay trong tuần đầu.

## Khác biệt nằm ở thời điểm dữ liệu bị "định hình"

Microsoft Azure định nghĩa data lake là kho tập trung, nơi nhận và lưu khối lượng lớn dữ liệu ở dạng gốc. Cơ chế cho phép điều đó là schema-on-read: mọi loại dữ liệu được ghi vào ở dạng thô, cấu trúc chỉ được áp khi có người đọc.

Data warehouse thì ngược lại. Azure mô tả warehouse là nơi chứa dữ liệu đã được xử lý và biến đổi nhắm tới một mục đích cụ thể. Mục đích đó thường là báo cáo, mà mục đích của báo cáo hiếm khi trùng với mục đích của một model.

Lakehouse là nỗ lực gộp hai thứ này lại. Databricks định nghĩa lakehouse là một kiến trúc quản lý dữ liệu mở. Kiến trúc này kết hợp sự linh hoạt, hiệu quả chi phí và quy mô của data lake với các đặc điểm của warehouse, để BI và ML cùng chạy trên một nguồn dữ liệu.

Mấu chốt kỹ thuật là một lớp metadata theo dõi file nào thuộc phiên bản bảng nào. Nhờ lớp này mà lakehouse có giao dịch ACID, cùng các tính năng như schema enforcement, schema evolution và kiểm tra dữ liệu.

**Điểm mấu chốt:** Câu hỏi đúng không phải "dữ liệu nằm ở đâu" mà là "schema được áp vào lúc nào, và ai đã quyết định dữ liệu này dùng để làm gì".

| Khía cạnh | Data lake | Data warehouse | Lakehouse |
|---|---|---|---|
| Dữ liệu ở dạng | Gốc, thô | Đã biến đổi cho một mục đích | File thô có lớp metadata quản lý |
| Schema áp khi | Đọc | Ghi | Có thể ép khi ghi, cho phép tiến hóa |
| Rủi ro chính cho ML | Schema trôi mà không ai hay | Tín hiệu bị gộp mất | Tưởng dữ liệu đã sạch nhưng tính năng chưa bật |
| Câu hỏi đầu tiên | Ai kiểm tra dữ liệu khi ghi? | Bảng này phục vụ báo cáo nào? | Có giữ phiên bản bảng không? |

## Một ví dụ đi trọn: model dự đoán khách rời bỏ

Thử hình dung bạn được giao xây model dự đoán khách sắp rời bỏ cho một chuỗi bán lẻ, với yêu cầu cảnh báo trước 7 ngày. Khách có một warehouse chứa bảng tổng hợp doanh thu theo tháng cho dashboard và một lake chứa log sự kiện từ app dạng JSON. Mỗi đêm, một job đổ dữ liệu từ lake sang warehouse.

Đây chính là mô hình hai tầng mà Databricks cho là phải bảo trì thường xuyên và hay khiến dữ liệu bị cũ. Đó là góc nhìn của một vendor bán lakehouse, nhưng nó khớp khá sát với những gì FDE thường gặp ở chỗ khách.

Vấn đề đầu tiên lộ ra ngay khi bạn mở bảng warehouse. Bảng đã được gộp theo tháng, nên những hành vi kiểu "tuần này không mở app lần nào" đã bị nén mất. Bạn cần cảnh báo trước 7 ngày nhưng dữ liệu chỉ chi tiết đến từng tháng, và tinh chỉnh model đến đâu cũng không lấy lại được phần tín hiệu đã mất.

Vì thế bạn quay về lake, và gặp ngay vấn đề thứ hai: schema có thể đã trôi mà không ai hay. Schema-on-read nghĩa là lúc ghi không có gì chặn lại, nên việc kiểm tra giờ là của bạn. Một truy vấn PySpark đơn giản là đủ cho lần kiểm tra đầu tiên:

```python
from pyspark.sql import functions as F

df = spark.read.json("s3://lake-cua-khach/app_events/")
(df.groupBy(F.date_trunc("month", "event_time").alias("thang"))
.agg(F.count("*").alias("so_dong"),
F.sum(F.col("customer_id").isNull().cast("int")).alias("thieu_customer_id"))
.orderBy("thang")
.show(36))
```

Nếu số dòng thiếu customer_id gần bằng 0 suốt nhiều tháng rồi bỗng tăng vọt, rất có thể team app đã đổi tên field trong một bản phát hành. Lake vẫn nhận dữ liệu như thường, và dashboard vẫn chạy vì ai đó đã lặng lẽ sửa job đêm. Còn feature của bạn thì âm thầm biến thành null.

Vấn đề cuối cùng là độ tươi của dữ liệu. Xử lý theo lô lớn (batch) hay theo thời gian thực (stream) là một trong những phân biệt cốt lõi của data engineering. Nếu khách muốn chấm điểm rủi ro ngay khi khách hàng mở app thì job đêm không đáp ứng được, và bạn cần biết điều đó trước khi hứa bất kỳ mốc tiến độ nào.

## ETL hay ELT quyết định bạn còn giữ được gì

IBM định nghĩa data pipeline là hệ thống nhận dữ liệu thô từ nhiều nguồn rồi biến đổi nó. Biến đổi trước hay nạp trước sẽ quyết định bạn còn giữ được dữ liệu thô hay không.

Với ETL, dữ liệu được trích xuất và biến đổi rồi mới nạp vào kho. Cách này hợp với kiến trúc lấy warehouse làm trung tâm, nhưng bản thô có thể không còn sau khi biến đổi. Với ELT, dữ liệu được nạp trước rồi mới biến đổi trong warehouse trên cloud, nên bản thô vẫn còn để bạn tự dựng lại feature theo cách model cần.

Trong ví dụ chuỗi bán lẻ, lựa chọn hợp lý là lấy dữ liệu huấn luyện từ lake theo kiểu ELT, tự viết phần biến đổi cho feature và quản lý nó như code của mình. Nếu khách đã có lakehouse, hãy dùng phiên bản bảng để dựng lại đúng tập huấn luyện của một ngày cụ thể. Bật schema enforcement để chặn lỗi đổi tên field ngay lúc ghi.

## Năm câu hỏi cho tuần đầu tiên

Bắt đầu từ nguồn gốc. Với mỗi bảng khách đưa cho bạn, hãy hỏi nó được tạo từ đâu và phục vụ báo cáo nào. Bảng làm ra cho dashboard của phòng tài chính thì được gộp và lọc theo cách phòng tài chính cần, chưa chắc theo cách model của bạn cần.

Tiếp theo, hỏi schema được kiểm tra lúc ghi hay chỉ khi đọc, và ai được báo khi có field đổi tên. Sau đó là lịch làm mới: batch hằng đêm, hằng giờ hay stream, và độ trễ thực tế so với nhu cầu của use case.

Hai câu cuối là về khả năng tái lập và quyền sở hữu. Khách có lưu phiên bản bảng để dựng lại dữ liệu trong quá khứ không? Ai sở hữu các job biến đổi? Biết người đó thì khi họ sửa job, bạn sẽ được báo trước chứ không phải phát hiện sau.

## Những lỗi hay gặp nhất

Lỗi phổ biến nhất là tin vào tên bảng. Một bảng tên "customer_features" vẫn có thể là bảng tổng hợp cho báo cáo, đã gộp mất đúng chiều thời gian bạn cần.

Lỗi thứ hai là huấn luyện trên bảng warehouse đã biến đổi nhưng lại phục vụ model bằng dữ liệu thô từ lake, hoặc ngược lại. Hai luồng này đi qua hai bộ logic biến đổi khác nhau, nên thứ model thấy ở production sẽ khác thứ nó đã học.

Lỗi thứ ba là nghe "lakehouse" rồi mặc định dữ liệu đã sạch. Schema enforcement và kiểm tra dữ liệu là tính năng có sẵn, không có nghĩa là bảng nào cũng đã bật. Hãy kiểm tra cấu hình thay vì tin vào slide.

## Cách thể hiện kỹ năng này khi đi xin việc

Khi đọc JD cho vị trí FDE, hãy để ý các cụm như lakehouse, ELT, batch và streaming: chúng cho bạn biết mình sẽ làm việc với dữ liệu ở tầng nào. Trong CV, một dòng cụ thể như "phát hiện bảng nguồn đã gộp theo tháng, chuyển sang dữ liệu thô và dựng lại feature theo ngày" thuyết phục hơn nhiều so với một danh sách công cụ.

Định nghĩa của ba kiến trúc thì lúc nào cũng tra được. Thứ đáng luyện hơn là phản xạ: nghe câu "có hết trong warehouse rồi", bạn biết ngay phải hỏi tiếp câu gì.

**Thử ngay tuần này:**

- Chọn một bảng bạn hay dùng ở công ty và truy ngược xem nó được tạo từ nguồn thô nào, qua ETL hay ELT, lần làm mới gần nhất là khi nào.
- Trên một nguồn dữ liệu thô bạn có quyền đọc, chạy truy vấn đếm tỷ lệ thiếu của một cột khóa theo từng tháng, rồi ghi lại những tháng bất thường.
- Gom năm câu hỏi về kiến trúc dữ liệu vào một trang checklist để mang theo buổi kickoff tiếp theo.

## Nguồn

- [What is a Data Lake? Data Lake vs. Warehouse | Microsoft Azure](https://azure.microsoft.com/en-gb/resources/cloud-computing-dictionary/what-is-a-data-lake)

- [What is a Lakehouse? Databricks Blog](https://www.databricks.com/glossary/data-lakehouse)

- [What Is a Data Pipeline? | IBM](https://www.ibm.com/topics/data-pipeline)

- [Data engineering 101: lifecycle, best practices, and emerging trends](https://www.redpanda.com/guides/fundamentals-of-data-engineering)