Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Technical PM tại một sàn thương mại điện tử. Sáng thứ Hai, ba người tìm đến bàn của bạn cùng một lúc: bộ phận Tài chính cần báo cáo doanh thu theo từng ngành hàng để chốt sổ quý; nhóm Data Science muốn lấy toàn bộ log hành vi click của người dùng trong 18 tháng để huấn luyện mô hình gợi ý; còn đội Marketing hỏi "tại sao dashboard load mất 40 giây mỗi sáng và hóa đơn cloud tháng này tăng gấp đôi?". Ba yêu cầu này nghe có vẻ chỉ là "lấy dữ liệu", nhưng thực ra chúng đụng vào ba kiến trúc lưu trữ hoàn toàn khác nhau — và nếu bạn chọn sai chỗ chứa dữ liệu, bạn sẽ trả giá bằng tiền, tốc độ, và cả niềm tin của các phòng ban.
Đây chính là lý do bài này quan trọng với một Technical PM. Bạn không cần tự tay viết câu lệnh tạo bảng phân vùng, nhưng bạn phải hiểu sự khác biệt căn bản giữa Data Warehouse, Data Lake và Lakehouse để: ước lượng chi phí hạ tầng, đánh giá đề xuất của đội data engineering, và quan trọng nhất là biết một tính năng dữ liệu nào đó khả thi đến mức nào trước khi cam kết với ban lãnh đạo. Rất nhiều PM cam kết "tuần sau có dashboard real-time" mà không biết dữ liệu đang nằm trong một data lake không có schema, và để query được nó cần ba tuần dọn dẹp. Bài này giúp bạn tránh đúng cái bẫy đó.
Trong cả khóa, bài 26 đã nói về cách dữ liệu di chuyển (ETL vs ELT — pipeline). Bài 27 này tập trung vào nơi dữ liệu nằm lại — kiến trúc lưu trữ. Bài 28 sau đó sẽ bàn về dữ liệu đang chảy theo thời gian thực (streaming với Kafka). Hãy giữ ranh giới đó trong đầu để không nhầm lẫn.
Khái niệm cốt lõi
Data Warehouse — kho có ngăn nắp, dán nhãn sẵn
Data Warehouse (kho dữ liệu) là nơi chứa dữ liệu đã được làm sạch, cấu trúc hóa thành bảng — hàng và cột rõ ràng — và tối ưu cho việc truy vấn phân tích. Đặc trưng quan trọng nhất là schema-on-write: bạn phải định nghĩa cấu trúc (kiểu dữ liệu, tên cột, ràng buộc) trước khi nạp dữ liệu vào. Giống như một nhà kho mà mọi thùng hàng phải được dán nhãn, phân loại, xếp đúng kệ trước khi cho vào cửa.
Hệ quả của schema-on-write:
- SQL là ngôn ngữ gốc. Bất kỳ ai biết SQL (kể cả analyst không phải lập trình viên) đều truy vấn được.
- Truy vấn cực nhanh cho các báo cáo dạng tổng hợp (doanh thu theo tháng, số đơn theo vùng), vì dữ liệu đã được sắp xếp, đánh chỉ mục, lưu theo cột (columnar).
- Chất lượng dữ liệu cao, đáng tin cho báo cáo tài chính, kế toán, KPI lãnh đạo.
- Đổi lại: kém linh hoạt. Muốn thêm một loại dữ liệu mới (ví dụ log JSON lồng nhiều tầng) thì phải sửa schema, đôi khi đập đi làm lại pipeline.
Data Lake — cái hồ chứa tất cả, phân loại sau
Data Lake (hồ dữ liệu) đi theo triết lý ngược lại: cứ đổ mọi thứ vào trước, bất kể định dạng — file CSV, ảnh, video, log JSON, file Parquet, dữ liệu cảm biến IoT — rồi khi nào cần dùng mới áp cấu trúc. Đây gọi là schema-on-read: schema được áp lúc đọc, không phải lúc ghi.
Data Lake về bản chất là object storage giá rẻ — như Amazon S3, Google Cloud Storage, hay Azure Data Lake Storage. Bạn trả tiền theo dung lượng lưu trữ, và dung lượng đó rẻ hơn rất nhiều so với warehouse.
- Cực kỳ linh hoạt: chứa được cả dữ liệu phi cấu trúc (ảnh, audio) lẫn bán cấu trúc (JSON).
- Rẻ để lưu trữ ở quy mô lớn — hợp với việc giữ dữ liệu thô lâu dài cho machine learning.
- Đổi lại: dễ biến thành "đầm lầy dữ liệu" (data swamp). Không ai biết file nào là gì, chất lượng ra sao, ai đang dùng. Query trực tiếp thường chậm và tốn công, vì không có chỉ mục, không có ràng buộc.
Lakehouse — cố gắng hợp nhất hai thế giới
Trong nhiều năm, các công ty buộc phải nuôi cả hai: một data lake cho ML và một data warehouse cho BI, kéo theo việc sao chép dữ liệu qua lại, chi phí gấp đôi, và dữ liệu ở hai nơi không khớp nhau. Lakehouse ra đời để giải bài toán này: xây một lớp quản lý dữ liệu có cấu trúc, có giao dịch (transaction), có schema ngay trên nền object storage giá rẻ của data lake.
Bí quyết kỹ thuật nằm ở các định dạng bảng mở (open table format) như Delta Lake, Apache Iceberg, Apache Hudi. Chúng thêm vào data lake những thứ trước đây chỉ warehouse mới có:
- Tính ACID (giao dịch đáng tin — không bị đọc dữ liệu nửa vời khi đang ghi).
- Schema enforcement & evolution (vừa áp được cấu trúc, vừa cho phép cấu trúc thay đổi dần).
- Time travel (truy vấn dữ liệu ở trạng thái của một thời điểm trong quá khứ).
Bảng so sánh nhanh để bạn ghi nhớ
| Tiêu chí | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Schema | schema-on-write | schema-on-read | linh hoạt, có enforcement |
| Loại dữ liệu | có cấu trúc | mọi loại | mọi loại |
| Chi phí lưu trữ | cao | thấp | thấp (nền object storage) |
| Người dùng chính | Analyst, BI, Tài chính | Data Scientist, ML | Cả hai |
| Tốc độ query phân tích | rất nhanh | chậm | nhanh |
| Rủi ro lớn nhất | kém linh hoạt, đắt | thành "đầm lầy" | còn mới, độ phức tạp vận hành |
Tình huống thực tế
Tình huống 1 — Sàn TMĐT "ChợViệt": warehouse quá tải vì cố nhồi log thô
ChợViệt (giả định) là một sàn thương mại điện tử cỡ trung tại Việt Nam, khoảng 2 triệu người dùng hoạt động hàng tháng. Ban đầu họ chỉ có một data warehouse trên BigQuery, dùng cho báo cáo doanh thu và tồn kho — hoàn toàn hợp lý. Nhưng khi đội Growth muốn phân tích hành vi click, họ bắt đầu đổ toàn bộ log sự kiện (mỗi ngày khoảng 400 GB JSON) thẳng vào warehouse.
Hệ quả sau ba tháng: hóa đơn BigQuery tăng từ 8.000 USD lên 23.000 USD mỗi tháng, vì warehouse tính tiền theo lượng dữ liệu quét trong mỗi query, mà log thô thì khổng lồ và bị quét đi quét lại. Tệ hơn, mỗi lần đội data muốn thử một cách phân tích log mới, họ phải nhờ sửa schema, chờ cả tuần.
PM phụ trách data nhận ra vấn đề: log hành vi thô, đa dạng, ít cần báo cáo tức thời — đây là việc của data lake, không phải warehouse. Họ tách kiến trúc: log thô đổ vào data lake trên Google Cloud Storage (rẻ hơn ~5 lần), chỉ những bảng tổng hợp đã làm sạch (ví dụ "lượt xem sản phẩm theo ngày theo danh mục") mới được nạp vào warehouse cho báo cáo. Hóa đơn giảm còn 11.000 USD/tháng và đội data tự do thử nghiệm trên lake.
Bài học: Đừng dùng warehouse như thùng rác chứa mọi dữ liệu thô. Warehouse đắt vì nó tối ưu cho query, không phải để lưu trữ khối lượng lớn. Nhận diện đâu là "dữ liệu báo cáo" và đâu là "dữ liệu thô để khám phá" là một quyết định kiến trúc mà PM cần tham gia.
Tình huống 2 — Fintech "ViPay": data lake biến thành đầm lầy
ViPay (giả định), một ví điện tử Đông Nam Á, đầu tư mạnh vào data lake trên S3 từ sớm để chuẩn bị cho các mô hình chống gian lận. Sau hai năm, lake chứa hơn 4 PB dữ liệu. Vấn đề: không ai có "bản đồ". Cùng một khái niệm "giao dịch thất bại" được ghi theo ba định dạng khác nhau bởi ba team khác nhau, ở ba thư mục không ai biết. Khi đội rủi ro cần dữ liệu để báo cáo cho ngân hàng nhà nước, họ mất sáu tuần chỉ để tìm và đối chiếu — vì lake không có schema enforcement, không có catalog, không đảm bảo dữ liệu nhất quán.
Đây chính là data swamp kinh điển. PM cùng đội data engineering quyết định không quay về warehouse (vì vẫn cần ML), mà chuyển lake sang kiến trúc lakehouse dùng Apache Iceberg: áp schema enforcement, dựng data catalog (mỗi bảng có chủ sở hữu, mô tả, định nghĩa cột), bật ACID để các bản ghi giao dịch đáng tin. Sau đó, đội rủi ro chạy được SQL trực tiếp, còn đội ML vẫn dùng chung dữ liệu cho mô hình.
Bài học: Data lake rẻ và linh hoạt, nhưng "rẻ để đổ vào" không đồng nghĩa "rẻ để dùng lại". Nếu thiếu quản trị (governance, catalog, schema), bạn sẽ trả giá bằng thời gian và rủi ro tuân thủ. Lakehouse là lời giải cho những tổ chức đã có lake nhưng cần độ tin cậy của warehouse.
Tình huống 3 — Startup "EduNow": chưa cần lakehouse, đừng đu trend
EduNow (giả định) là một startup edtech 15 người, mới có 50.000 người dùng. Một engineer mới về từ công ty lớn đề xuất dựng ngay lakehouse với Databricks vì "đó là kiến trúc hiện đại". PM ngồi lại tính: dữ liệu của họ hiện chỉ là vài bảng giao dịch và log đơn giản, tổng cộng dưới 200 GB. Toàn bộ nhu cầu phân tích đều là báo cáo SQL chuẩn.
PM ra quyết định: dùng một warehouse nhỏ gọn (BigQuery với chi phí gần như bằng 0 ở quy mô đó) cho báo cáo, và giữ vài file thô trên cloud storage thông thường. Không lakehouse, không Databricks, không chi phí vận hành cho một nền tảng họ chưa cần. Tiết kiệm được cả tiền lẫn độ phức tạp, và đội ngũ nhỏ không phải học vận hành một hệ thống nặng nề.
Bài học: Kiến trúc "xịn nhất" không phải kiến trúc "đúng nhất". Lakehouse có lý do tồn tại khi bạn vừa cần BI vừa cần ML ở quy mô lớn với nhiều loại dữ liệu. Ở giai đoạn sớm, một warehouse đơn giản gần như luôn là lựa chọn đúng. PM giỏi là người biết khi nào chưa cần một công nghệ.
Hướng dẫn từng bước
Khi đứng trước một quyết định hay một đề xuất liên quan đến lưu trữ dữ liệu, đây là cách một Technical PM nên tư duy:
- Xác định người tiêu thụ dữ liệu (consumer) là ai. Tài chính, BI, lãnh đạo cần báo cáo SQL ổn định, sạch → nghiêng về warehouse. Data Scientist, ML cần dữ liệu thô, đa dạng → cần lake. Cả hai → cân nhắc lakehouse.
- Phân loại bản chất dữ liệu. Hỏi: dữ liệu này có cấu trúc rõ ràng không (bảng) hay phi cấu trúc (ảnh, log JSON lồng nhau)? Khối lượng bao nhiêu? Tần suất cần truy vấn? Dữ liệu có cấu trúc, query thường xuyên → warehouse. Thô, khổng lồ, ít query → lake.
- Ước lượng chi phí theo đúng mô hình tính tiền. Warehouse thường tính theo lượng dữ liệu quét khi query và/hoặc compute. Lake tính theo dung lượng lưu trữ (rẻ) cộng compute khi xử lý. Hỏi đội engineering con số dự phóng — đừng để bất ngờ ở hóa đơn cuối tháng.
- Đặt câu hỏi về quản trị, không chỉ công nghệ. Ai sở hữu mỗi tập dữ liệu? Có data catalog không? Schema được kiểm soát thế nào? Một lake không có governance là quả bom hẹn giờ. Đây là câu hỏi PM phải hỏi sớm.
- Cân nhắc độ trưởng thành của tổ chức. Lakehouse mạnh nhưng phức tạp để vận hành. Nếu đội data còn nhỏ, đừng vội. Chọn kiến trúc khớp với năng lực vận hành hiện tại, có lộ trình nâng cấp.
- Diễn đạt trade-off bằng ngôn ngữ business cho lãnh đạo. Thay vì "ta nên dùng Iceberg", hãy nói "phương án này tăng chi phí lưu trữ 20% nhưng cho phép cả đội ML và đội báo cáo dùng chung một nguồn dữ liệu, giảm 6 tuần dọn dữ liệu mỗi quý".
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm "lưu trữ" với "di chuyển" dữ liệu. Nhiều PM lẫn lộn kiến trúc lưu trữ (bài này) với pipeline ETL/ELT (bài 26). Hãy nhớ: warehouse/lake/lakehouse là nơi dữ liệu nằm; ETL/ELT là cách dữ liệu đến đó. Hai chuyện khác nhau.
Lỗi 2: Coi data lake là "warehouse rẻ tiền". Lake rẻ để lưu, nhưng query trực tiếp trên lake thô thì chậm và tốn công. Nếu nhu cầu chính là báo cáo SQL nhanh, lake không thay thế được warehouse.
Lỗi 3: Đu theo công nghệ mới nhất. "Lakehouse" và "Databricks" nghe sang, nhưng với startup nhỏ, chúng thường là sự phức tạp thừa. Chọn theo nhu cầu thực, không theo trào lưu.
Lỗi 4: Bỏ qua governance từ đầu. Đổ dữ liệu vào lake mà không có catalog, không chủ sở hữu, không schema — bạn đang xây một đầm lầy. Sửa sau tốn gấp mười lần làm đúng từ đầu.
Mẹo 1: Một kiến trúc phổ biến và lành mạnh là lake cho dữ liệu thô, warehouse cho lớp tổng hợp đã làm sạch. Đây gọi là kiến trúc phân tầng (medallion/bronze-silver-gold) và rất đáng để PM biết tên gọi.
Mẹo 2: Khi đội engineering đề xuất "chuyển sang lakehouse", hãy hỏi: "Vấn đề cụ thể nào của warehouse/lake hiện tại mà lakehouse giải quyết, và cái giá vận hành là gì?". Câu trả lời tốt sẽ nói về dữ liệu bị nhân đôi, chi phí đồng bộ, hoặc nhu cầu ML — không phải "vì nó hiện đại".
Mẹo 3: Học một chút SQL cơ bản (sẽ có ở bài 29). Khả năng tự chạy một query đơn giản giúp bạn hiểu dữ liệu thật sự nằm ở đâu và sạch đến đâu, thay vì chỉ nghe lại.
Bài tập thực hành
- Phân loại tình huống. Với mỗi nhu cầu sau, hãy chọn warehouse, lake hay lakehouse và giải thích trong 2–3 câu: (a) Báo cáo doanh thu hằng tháng cho CFO; (b) Lưu 24 tháng video xác minh KYC để sau này huấn luyện mô hình nhận diện khuôn mặt; (c) Một tổ chức vừa cần báo cáo BI vừa cần dùng chính dữ liệu đó cho ML, không muốn nhân đôi dữ liệu.
- Phỏng vấn ngược. Viết ra 5 câu hỏi bạn sẽ hỏi đội data engineering khi họ trình một đề xuất "xây data lake mới". Ít nhất 2 câu phải về governance/chi phí, không phải công nghệ.
- Tính chi phí ngược. Giả sử công ty bạn đang đổ 300 GB log JSON/ngày thẳng vào warehouse, và mỗi GB quét tốn 5 USD, với 4 lần query/ngày trên toàn bộ dữ liệu 90 ngày gần nhất. Hãy ước lượng chi phí quét hằng tháng, rồi lập luận tại sao chuyển log thô sang lake lại tiết kiệm. (Mục tiêu là rèn phản xạ tính nhẩm trade-off, không cần con số tuyệt đối chính xác.)
- Vẽ kiến trúc phân tầng. Vẽ sơ đồ đơn giản: dữ liệu thô vào đâu, lớp đã làm sạch nằm ở đâu, ai đọc từ tầng nào. Dùng đúng tên bronze/silver/gold nếu được.
Tóm tắt
- Data Warehouse: schema-on-write, dữ liệu có cấu trúc, SQL gốc, query phân tích cực nhanh, tối ưu cho BI và báo cáo tài chính — nhưng đắt và kém linh hoạt. Ví dụ: BigQuery, Snowflake, Redshift.
- Data Lake: schema-on-read, chứa mọi loại dữ liệu, lưu trữ rẻ trên object storage, lý tưởng cho ML và dữ liệu thô khối lượng lớn — nhưng dễ thành "đầm lầy" nếu thiếu quản trị. Ví dụ: S3, GCS, Azure Data Lake.
- Lakehouse: hợp nhất hai thế giới bằng open table format (Delta, Iceberg, Hudi) — đem tính ACID, schema enforcement, time travel lên nền lake giá rẻ, cho cả BI lẫn ML dùng chung một bản dữ liệu. Ví dụ: Databricks, Snowflake, hệ sinh thái Iceberg.
- Với Technical PM, kỹ năng cốt lõi không phải tự dựng hệ thống, mà là chọn đúng nơi cho đúng dữ liệu, biết hỏi về chi phí và governance, và biết khi nào chưa cần một công nghệ. Kiến trúc đúng nhất là kiến trúc khớp với consumer, dữ liệu, ngân sách và độ trưởng thành của tổ chức — không phải kiến trúc nghe sang nhất.