Hướng dẫn xây dựng Data Lake kho dữ liệu cho phân tích lớn

Data Lake là kho lưu trữ tập trung chứa dữ liệu ở dạng gốc, có cấu trúc lẫn không cấu trúc (bảng từ database, log, file JSON, ảnh, tài liệu), thường đặt trên object storage chi phí thấp, để phục vụ phân tích, báo cáo và học máy ở quy mô lớn. Xây dựng một Data Lake dùng được, không biến thành "đầm lầy dữ liệu", cần: chia vùng dữ liệu theo mức độ xử lý, định dạng lưu trữ cột hiệu quả, lớp bảng mở có giao dịch, đường ống nạp dữ liệu đáng tin cậy và quản trị chặt về danh mục, chất lượng, quyền truy cập. Bài viết đi qua từng thành phần.

Data Lake, Data Warehouse và Lakehouse

Data Lake thuần dễ thành đầm lầy: file đổ vào không ai biết nội dung, không cập nhật hay xóa được bản ghi, đọc ra kết quả không nhất quán. Kiến trúc lakehouse ra đời để khắc phục bằng các định dạng bảng mở như Apache Iceberg, Delta Lake, Apache Hudi, bổ sung giao dịch, quản lý schema và truy vấn theo thời điểm lên trên object storage.

Doanh nghiệp chỉ có vài nguồn dữ liệu có cấu trúc và nhu cầu chủ yếu là báo cáo thì một data warehouse là đủ; xem bài triển khai hệ thống BI. Data Lake đáng đầu tư khi dữ liệu đa dạng, khối lượng lớn hoặc cần phục vụ học máy.

Kiến trúc tổng thể

1. Nguồn: database nghiệp vụ, ứng dụng SaaS, log ứng dụng, sự kiện hành vi người dùng, thiết bị IoT, file từ đối tác.
2. Nạp dữ liệu: theo lô (batch) hoặc theo luồng (streaming).
3. Lưu trữ: object storage (Amazon S3, Google Cloud Storage, Azure Data Lake Storage, hoặc MinIO tự host).
4. Lớp bảng: Iceberg, Delta Lake hoặc Hudi.
5. Xử lý: Apache Spark, Flink, dbt trên engine SQL.
6. Truy vấn: Trino, Spark SQL, Athena, BigQuery, Snowflake, DuckDB cho phân tích nhỏ.
7. Quản trị: danh mục dữ liệu, kiểm soát truy cập, theo dõi nguồn gốc dữ liệu (lineage).

Chia vùng dữ liệu: bronze, silver, gold

Mô hình "medallion" chia dữ liệu theo mức độ tinh chế:

• Bronze (thô): dữ liệu nạp nguyên trạng từ nguồn, kèm thời điểm nạp và nguồn gốc. Không sửa, để có thể xử lý lại khi logic thay đổi.
• Silver (đã làm sạch): chuẩn hóa kiểu dữ liệu, loại bản ghi trùng, gộp nguồn, che dữ liệu nhạy cảm.
• Gold (sẵn sàng dùng): bảng tổng hợp theo nghiệp vụ, chỉ số đã định nghĩa, phục vụ trực tiếp dashboard và mô hình.

Mỗi vùng có quyền truy cập riêng: kỹ sư dữ liệu làm việc với bronze, nhà phân tích dùng silver và gold, người dùng kinh doanh chủ yếu thấy gold.

Định dạng lưu trữ và tổ chức file

• Parquet là định dạng cột phổ biến nhất: nén tốt, đọc nhanh khi chỉ cần một số cột. ORC là lựa chọn tương tự. Tránh lưu CSV, JSON ở các vùng silver và gold.
• Phân vùng theo cột hay lọc như ngày, nhưng đừng phân vùng quá chi tiết tạo ra hàng triệu file nhỏ.
• Gộp file nhỏ (compaction) định kỳ; các định dạng bảng mở có công cụ hỗ trợ.
• Vòng đời lưu trữ: chuyển dữ liệu bronze cũ sang lớp lưu trữ rẻ hơn.

Nạp dữ liệu đáng tin cậy

Từ database nghiệp vụ

Thay vì sao chép toàn bộ bảng mỗi đêm, dùng Change Data Capture (CDC) đọc log thay đổi của database (ví dụ Debezium với PostgreSQL, MySQL) để nạp các thay đổi gần thời gian thực mà không làm nặng database nguồn. Schema nguồn được thiết kế tốt, như hướng dẫn trong bài thiết kế database schema chuẩn, giúp việc đồng bộ đơn giản hơn nhiều.

Từ sự kiện và log

Ứng dụng phát sự kiện vào Kafka, sau đó connector hoặc job streaming ghi xuống lake theo lô nhỏ. Bài so sánh RabbitMQ, Kafka và Redis Pub/Sub giải thích vì sao Kafka hợp vai trò đường ống này.

Từ SaaS và file đối tác

Dùng công cụ ELT có sẵn connector hoặc job định kỳ gọi API. Lưu nguyên phản hồi vào bronze trước khi biến đổi.

Quản trị: tránh biến lake thành đầm lầy

• Danh mục dữ liệu: mỗi bảng có mô tả, chủ sở hữu, nguồn, tần suất cập nhật, ý nghĩa cột. Công cụ như DataHub, OpenMetadata hoặc danh mục của nhà cung cấp cloud.
• Kiểm tra chất lượng tự động: số dòng, giá trị null, tính duy nhất, khoảng giá trị hợp lệ; dừng đường ống hoặc cảnh báo khi vi phạm.
• Kiểm soát truy cập theo cột và hàng: che số điện thoại, email với người không cần; giới hạn dữ liệu theo khu vực.
• Dữ liệu cá nhân: xác định cột chứa dữ liệu cá nhân, có quy trình xóa khi người dùng yêu cầu (định dạng bảng mở hỗ trợ xóa bản ghi), tuân thủ quy định bảo vệ dữ liệu cá nhân.
• Lineage: biết bảng gold được tạo từ những bảng nào để đánh giá tác động khi nguồn thay đổi.

Kiểm soát chi phí

Object storage rẻ nhưng chi phí tính toán khi truy vấn có thể tăng nhanh. Một số biện pháp: chọn đúng cột và lọc theo phân vùng; tạo bảng gold tổng hợp sẵn cho dashboard thay vì để mỗi lần mở dashboard quét bảng chi tiết; tự động tắt cụm xử lý khi rảnh; theo dõi chi phí theo nhóm người dùng và truy vấn.

Lộ trình triển khai

1. Chọn hai ba trường hợp sử dụng cụ thể có giá trị, ví dụ phân tích hành vi người dùng ứng dụng, dự báo nhu cầu.
2. Dựng nền tối thiểu: object storage, một định dạng bảng mở, một engine truy vấn, danh mục.
3. Nạp các nguồn cần cho trường hợp sử dụng đầu tiên, đi qua đủ ba vùng.
4. Bàn giao bảng gold cho người dùng, thu phản hồi.
5. Mở rộng nguồn và trường hợp sử dụng, song song củng cố quản trị.