Data warehouse lưu dữ liệu đã làm sạch và có cấu trúc chặt để phục vụ báo cáo; data lake lưu dữ liệu thô ở mọi định dạng với chi phí thấp, chỉ áp cấu trúc khi đọc; lakehouse là kiến trúc ghép hai thứ, đặt các tính năng quản lý bảng của kho (giao dịch, kiểm soát lược đồ, phiên bản) lên trên lưu trữ giá rẻ của hồ. Ba khái niệm không loại trừ nhau; nhiều doanh nghiệp dùng cùng lúc hai hoặc cả ba.
Điểm cần nắm là mỗi kiến trúc trả lời một câu hỏi khác nhau về ai dùng dữ liệu và dùng để làm gì. Nếu người dùng chủ yếu là ban điều hành và phòng tài chính cần con số đáng tin, kho là trọng tâm. Nếu có đội khoa học dữ liệu cần nhật ký máy, ảnh, văn bản để huấn luyện mô hình, hồ trở nên cần thiết. Lakehouse đáng cân nhắc khi bạn muốn cả hai mà không phải duy trì hai bản sao dữ liệu.
Lịch sử ngắn của ba khái niệm
Hiểu thứ tự ra đời giúp thấy mỗi kiến trúc sinh ra để vá điểm yếu nào của cái trước:
- Cuối thập niên 1980 – 1990: khái niệm kho dữ liệu hình thành, được Bill Inmon và Ralph Kimball hệ thống hoá. Kho chạy trên phần cứng chuyên dụng đắt tiền, lưu dữ liệu có cấu trúc từ hệ thống giao dịch.
- Giữa thập niên 2000: hệ sinh thái Hadoop cho phép lưu và xử lý khối lượng lớn trên máy chủ phổ thông. Dữ liệu web, nhật ký máy, cảm biến tăng nhanh mà kho truyền thống lưu quá đắt.
- Khoảng 2010: James Dixon, khi đó là CTO của Pentaho, dùng hình ảnh "hồ dữ liệu" để đối lập với "chợ dữ liệu" đóng chai sẵn: nước ở trạng thái tự nhiên, ai cần thì múc và tự xử lý.
- Thập niên 2010: lưu trữ đối tượng trên đám mây trở nên rẻ; kho dữ liệu đám mây tách lưu trữ khỏi tính toán. Cùng lúc, nhiều hồ dữ liệu biến thành "đầm lầy dữ liệu" (data swamp) vì thiếu quản trị.
- Khoảng 2020–2021: các định dạng bảng mở như Delta Lake, Apache Iceberg, Apache Hudi cho phép giao dịch và quản lý phiên bản trên tệp trong hồ. Bài báo "Lakehouse" của nhóm tác giả Databricks (Armbrust và cộng sự, hội nghị CIDR 2021) đặt tên và lập luận cho kiến trúc mới.
Bảng so sánh theo tám tiêu chí
So sánh dưới đây mô tả dạng điển hình; sản phẩm cụ thể có thể lấn sang ô bên cạnh vì các nhà cung cấp đang hội tụ tính năng.
| Tiêu chí | Data warehouse | Data lake | Lakehouse |
|---|---|---|---|
| Loại dữ liệu | Có cấu trúc, đã mô hình hoá | Mọi loại: bảng, JSON, nhật ký, ảnh, âm thanh | Mọi loại, phần bảng được quản lý chặt |
| Lược đồ | Áp khi ghi (schema on write) | Áp khi đọc (schema on read) | Áp khi ghi cho bảng, linh hoạt cho tệp thô |
| Người dùng chính | Phân tích viên, lãnh đạo, tài chính | Kỹ sư và nhà khoa học dữ liệu | Cả hai nhóm trên một nền tảng |
| Chất lượng mặc định | Cao, đã qua kiểm soát | Không đảm bảo | Theo tầng: thô, đã làm sạch, đã tổng hợp |
| Chi phí lưu trữ | Cao hơn trên mỗi đơn vị | Thấp | Thấp, dùng lưu trữ đối tượng |
| Hiệu năng truy vấn BI | Tốt nhất, ổn định | Kém nếu không tối ưu | Tốt, phụ thuộc định dạng và bộ máy truy vấn |
| Giao dịch, cập nhật, xoá | Có sẵn | Khó, thường chỉ ghi thêm | Có nhờ định dạng bảng mở |
| Rủi ro điển hình | Cứng nhắc, đắt khi dữ liệu phình | Thành đầm lầy, khó tìm, khó tin | Phức tạp vận hành, đòi đội ngũ có kỹ năng |
Đọc bảng theo hàng "người dùng chính" trước tiên. Kiến trúc nào cũng có thể làm được gần hết việc của kiến trúc khác nếu bỏ đủ công sức; câu hỏi thật là công sức đó rơi vào ai và có xứng đáng không.
Vì sao hồ dữ liệu hay biến thành đầm lầy
Lời hứa của hồ dữ liệu là "lưu trước, nghĩ sau". Chính lời hứa đó là nguồn rủi ro. Khi không ai buộc phải mô tả dữ liệu lúc ghi, sau một hai năm hồ chứa hàng nghìn thư mục với tên như "export_final_v3", không rõ nguồn, không rõ ngày, không rõ cột nào nghĩa là gì. Người cần dữ liệu không tìm được, hoặc tìm được nhưng không dám dùng, và quay về hỏi trực tiếp phòng ban nguồn. Lúc đó hồ chỉ còn là chi phí lưu trữ.
Ba thứ ngăn hồ thành đầm lầy đều là kỷ luật chứ không phải công nghệ: danh mục dữ liệu (catalog) ghi mỗi bộ dữ liệu từ đâu, ai chịu trách nhiệm, cập nhật khi nào; quy ước vùng phân rõ vùng thô, vùng đã làm sạch, vùng phục vụ, mỗi vùng có quyền ghi khác nhau; và chính sách vòng đời quy định dữ liệu nào xoá sau bao lâu. Lakehouse ra đời phần lớn để đưa kỷ luật kiểu kho vào hồ một cách có hệ thống: bảng có lược đồ, có lịch sử phiên bản, có thể quay lại trạng thái cũ khi nạp nhầm.
Một bẫy khác ít được nói: dữ liệu cá nhân. Hồ nhận mọi thứ, kể cả tệp xuất từ CRM chứa số điện thoại, căn cước của khách. Khi không có danh mục, doanh nghiệp không biết mình đang giữ dữ liệu cá nhân ở đâu, nên không thể đáp ứng yêu cầu xoá hay giới hạn mục đích theo quy định bảo vệ dữ liệu cá nhân.
Lakehouse giải quyết gì và chưa giải quyết gì
Giải quyết: một bản dữ liệu cho nhiều mục đích. Thay vì nạp dữ liệu vào hồ cho khoa học dữ liệu rồi chép thêm một bản vào kho cho BI, lakehouse cho cả hai nhóm đọc cùng các bảng trên lưu trữ đối tượng. Ít bản sao hơn nghĩa là ít chỗ lệch nhau hơn.
Giải quyết: định dạng mở, giảm phụ thuộc nhà cung cấp. Dữ liệu lưu dạng Parquet cùng siêu dữ liệu bảng mở có thể được nhiều bộ máy truy vấn đọc. Nếu đổi nền tảng, bạn mang dữ liệu đi dễ hơn so với định dạng độc quyền của một số kho truyền thống.
Chưa giải quyết: chất lượng và định nghĩa. Lakehouse không tự biết "khách hàng hoạt động" nghĩa là gì. Việc mô hình hoá, thống nhất chỉ số, kiểm tra chất lượng vẫn y nguyên như khi xây kho.
Chưa giải quyết: độ phức tạp vận hành. Bạn phải chọn định dạng bảng, bộ máy truy vấn, danh mục, cơ chế phân quyền, rồi ghép chúng lại. Với đội dữ liệu hai ba người, một kho đám mây trọn gói có thể nhẹ gánh hơn dù trên giấy kém linh hoạt.
Còn tranh luận: hiệu năng và chi phí tổng thể. Các nhà cung cấp công bố kết quả đo hiệu năng có lợi cho mình; kết quả độc lập phụ thuộc mạnh vào khối lượng và kiểu truy vấn. Cách đáng tin duy nhất là chạy thử với dữ liệu và truy vấn thật của bạn.
Năm câu hỏi để chọn kiến trúc
Trước khi nghe trình bày giải pháp, nhóm của bạn nên tự trả lời năm câu sau và ghi ra giấy:
- Ai là người dùng trong 12 tháng tới? Nếu chỉ có phân tích viên và lãnh đạo xem báo cáo, kho dữ liệu là đủ. Hồ chỉ đáng đầu tư khi có người thật sự dùng dữ liệu thô.
- Có dữ liệu phi cấu trúc với mục đích rõ không? Ảnh sản phẩm, ghi âm tổng đài, nhật ký máy móc chỉ có giá trị khi có bài toán cụ thể như phân loại khiếu nại hay bảo trì dự đoán.
- Khối lượng và tốc độ tăng? Hàng chục triệu dòng mỗi năm vẫn nằm thoải mái trong một kho đám mây cỡ nhỏ. Tính toán lại khi lên tới hàng tỷ sự kiện hoặc dữ liệu cảm biến liên tục.
- Đội ngũ có kỹ năng gì? Lakehouse đòi kỹ sư hiểu định dạng tệp, phân vùng, tối ưu truy vấn. Không có người như vậy thì chọn giải pháp quản lý sẵn.
- Ràng buộc về dữ liệu cá nhân và nơi lưu trữ? Một số dữ liệu có yêu cầu riêng về lưu trữ, chuyển ra nước ngoài; cần đối chiếu quy định hiện hành trước khi chọn vùng đám mây.
Phần lớn doanh nghiệp vừa ở Việt Nam sẽ thấy câu trả lời dẫn về một kho dữ liệu đám mây, có thể kèm một vùng lưu tệp thô đơn giản. Kiến trúc lakehouse đầy đủ hợp với doanh nghiệp đã có đội dữ liệu, có bài toán học máy đang chạy thật.
Lộ trình tiến hoá hợp lý thay vì chọn một lần
Kiến trúc dữ liệu không phải quyết định một lần cho mười năm. Một lộ trình phổ biến và ít rủi ro là: giai đoạn đầu dùng kho dữ liệu cho các chỉ số quản trị cốt lõi; song song lưu bản sao thô của dữ liệu nguồn vào lưu trữ đối tượng giá rẻ, đơn giản để có thể tính lại lịch sử; khi xuất hiện bài toán cần dữ liệu thô với khối lượng lớn, nâng vùng lưu trữ đó thành hồ có danh mục và quản trị; khi chi phí duy trì hai bản trở nên đáng kể, cân nhắc hợp nhất theo hướng lakehouse.
Điều quan trọng ở mọi giai đoạn là giữ mô hình dữ liệu và định nghĩa chỉ số tách khỏi công nghệ lưu trữ. Nếu logic "doanh thu thuần" được viết bằng mã có quản lý phiên bản, có kiểm thử, việc chuyển từ kho sang lakehouse chỉ là chuyển chỗ chạy. Nếu logic đó nằm rải rác trong hàng trăm báo cáo, mỗi lần đổi nền tảng là một lần viết lại và một lần số liệu lệch.
Ví dụ giả định: ba doanh nghiệp, ba lựa chọn khác nhau
Chuỗi 40 cửa hàng thời trang. Nguồn gồm phần mềm bán hàng, kế toán, hai sàn thương mại điện tử và nền tảng quảng cáo. Câu hỏi chính là doanh thu, biên lãi, tồn kho theo cửa hàng và kênh. Không có dữ liệu phi cấu trúc nào được dùng thật. Lựa chọn hợp lý: một kho dữ liệu đám mây cỡ nhỏ, lưu thêm bản sao thô các tệp xuất từ sàn để tính lại khi sàn đổi định dạng. Không cần hồ dữ liệu riêng.
Nhà máy linh kiện với hàng trăm cảm biến. Dữ liệu rung, nhiệt độ ghi theo giây, khối lượng lớn, đội kỹ thuật muốn thử mô hình phát hiện bất thường. Ban giám đốc cần báo cáo hiệu suất thiết bị và sản lượng theo ca. Lựa chọn hợp lý: lưu dữ liệu cảm biến thô vào lưu trữ đối tượng dạng tệp cột, tổng hợp theo phút hoặc ca rồi đưa vào kho cho báo cáo. Đây là mô hình hai tầng, có thể tiến hoá lên lakehouse khi bài toán học máy chứng minh được giá trị.
Công ty dịch vụ tài chính có đội khoa học dữ liệu. Họ cần dữ liệu giao dịch chi tiết, nhật ký ứng dụng, ghi âm tổng đài cho cả báo cáo tuân thủ lẫn mô hình chấm điểm. Hai bản dữ liệu song song đã gây lệch số giữa báo cáo và mô hình. Lựa chọn hợp lý: lakehouse với định dạng bảng mở, phân tầng rõ, danh mục và phân quyền chặt vì dữ liệu nhạy cảm.
Điểm chung. Không doanh nghiệp nào chọn vì công nghệ mới; cả ba chọn từ câu hỏi ai dùng dữ liệu, dùng làm gì và đội ngũ vận hành được tới đâu.
Câu hỏi thường gặp
Data lake có thay thế được data warehouse không?
Về lý thuyết có thể chạy BI trên hồ, nhưng nếu không có lớp quản lý bảng, mô hình hoá và kiểm soát chất lượng, hiệu năng và độ tin cậy thường kém. Khi bạn thêm đủ các lớp đó, kết quả gần như chính là lakehouse, tức đã mang tính chất của kho vào hồ.
Schema on read có nghĩa là không cần thiết kế dữ liệu?
Không. Nó chỉ dời việc thiết kế sang thời điểm đọc. Mỗi người đọc lại tự diễn giải cấu trúc, nên nếu không có quy ước chung, năm phân tích viên sẽ hiểu năm kiểu. Việc thiết kế vẫn phải làm, chỉ là linh hoạt hơn về thời điểm.
Parquet là gì và vì sao hay nhắc đến trong hồ dữ liệu?
Parquet là định dạng tệp lưu theo cột, nén tốt và cho phép bộ máy truy vấn chỉ đọc các cột cần thiết. Nó trở thành định dạng mặc định cho dữ liệu phân tích trong hồ, và là nền của các định dạng bảng mở như Delta Lake hay Iceberg.
Doanh nghiệp sản xuất có dữ liệu cảm biến có nên xây hồ ngay không?
Chỉ khi đã có bài toán cụ thể dùng dữ liệu đó, ví dụ phát hiện bất thường hay bảo trì dự đoán, và có người phân tích được. Nếu chưa, lưu dữ liệu cảm biến tổng hợp theo phút hoặc giờ vào kho thường đủ cho báo cáo hiệu suất thiết bị.
Lakehouse có rẻ hơn kho dữ liệu đám mây không?
Chi phí lưu trữ thường thấp hơn, nhưng tổng chi phí còn gồm tính toán, công cụ và nhân sự vận hành. Với khối lượng nhỏ và đội mỏng, kho trọn gói có thể có tổng chi phí thấp hơn. Cần ước tính theo khối lượng truy vấn thật, không chỉ theo dung lượng.