CDC với Debezium: đưa dữ liệu core lên lakehouse
Change Data Capture cho phép đồng bộ dữ liệu gần thời gian thực mà không chạy truy vấn nặng lên hệ thống nghiệp vụ. Nhưng nó cũng có những cạm bẫy riêng.
Trong hầu hết buổi khảo sát, câu hỏi đầu tiên doanh nghiệp đặt ra không phải “chúng tôi cần kiến trúc nào” mà là “tại sao báo cáo của chúng tôi vẫn chậm dù đã đầu tư kho dữ liệu”. Câu trả lời thường nằm ở chỗ kiến trúc được chọn không khớp với loại dữ liệu và cách khai thác thực tế.
1. Data Warehouse — tối ưu cho câu hỏi đã biết trước {#data-warehouse}
Kho dữ liệu truyền thống yêu cầu định nghĩa schema trước khi nạp dữ liệu. Cách tiếp cận này cho hiệu năng truy vấn rất tốt và số liệu nhất quán, phù hợp với báo cáo tài chính và các chỉ tiêu ổn định theo thời gian.
Giới hạn xuất hiện khi doanh nghiệp cần xử lý dữ liệu phi cấu trúc — hình ảnh, âm thanh, văn bản tự do, log — hoặc khi khối lượng dữ liệu tăng nhanh khiến chi phí license và lưu trữ tăng theo cấp số nhân.
2. Data Lake — linh hoạt nhưng dễ trở thành đầm lầy {#data-lake}
Data lake lưu mọi thứ ở dạng thô, định nghĩa cấu trúc khi đọc. Chi phí lưu trữ rẻ và không giới hạn loại dữ liệu. Vấn đề là nếu thiếu quản trị, sau 18–24 tháng không ai còn biết dữ liệu nào đúng, dữ liệu nào đã lỗi thời.
Trong các dự án BigAI tiếp nhận từ hệ thống có sẵn, nguyên nhân phổ biến nhất khiến data lake thất bại không phải công nghệ, mà là thiếu catalog và thiếu người chịu trách nhiệm về từng tập dữ liệu.
3. Data Lakehouse — kết hợp hai thế mạnh {#data-lakehouse}
Lakehouse giữ chi phí lưu trữ rẻ và tính linh hoạt của data lake, đồng thời bổ sung các đặc tính vốn chỉ có ở warehouse: giao dịch ACID, quản lý phiên bản dữ liệu, tiến hoá schema và tối ưu truy vấn. Nền tảng kỹ thuật là các định dạng bảng mở như Apache Iceberg, Delta Lake hoặc Apache Hudi.
4. So sánh theo sáu tiêu chí {#so-sanh}
| Tiêu chí | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| 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 |
| Hiệu năng truy vấn BI | Rất tốt | Kém | Tốt |
| Hỗ trợ Machine Learning | Hạn chế | Tốt | Tốt |
| Quản trị và chất lượng | Mạnh | Yếu nếu không đầu tư | Mạnh |
| Nguy cơ khoá nhà cung cấp | Cao | Thấp | Thấp |
5. Khung quyết định thực tế {#khung-quyet-dinh}
- Dữ liệu dưới 1 TB, chủ yếu có cấu trúc, nhu cầu chính là báo cáo: một data warehouse gọn nhẹ là đủ. Không cần lakehouse.
- Dữ liệu 1–50 TB, có nhu cầu ML hoặc dữ liệu phi cấu trúc: lakehouse là lựa chọn cân bằng nhất về chi phí và năng lực.
- Trên 50 TB hoặc có dữ liệu thời gian thực khối lượng lớn: lakehouse kết hợp tầng streaming, cần đầu tư nghiêm túc vào quản trị ngay từ đầu.
- Đã có warehouse đang chạy tốt: giữ lại và bổ sung lakehouse cho phần dữ liệu warehouse không xử lý được.
6. Ba việc cần làm trước khi chọn công nghệ {#ba-viec-can-lam}
Kinh nghiệm từ các dự án BigAI cho thấy thứ tự đúng là: thống nhất định nghĩa chỉ số trước, xác định người chịu trách nhiệm cho từng miền dữ liệu, rồi mới chọn công nghệ. Làm ngược lại gần như luôn dẫn tới việc phải xây lại tầng dữ liệu nghiệp vụ sau 12 tháng.