Data lake là gì? Kiến trúc, lakehouse và cách xây dựng

Mục lục

1. Data lake là gì?
2. Thuật ngữ data lake ra đời từ đâu?
3. Schema-on-read và schema-on-write khác nhau thế nào?
4. Kiến trúc data lake gồm những thành phần nào?
5. Data lake lưu dữ liệu ở đâu và theo định dạng nào?
6. Data lake, data warehouse và data lakehouse khác nhau thế nào?
7. Data swamp là gì và làm sao tránh?
8. Doanh nghiệp nào thực sự cần data lake?
9. Quy trình xây dựng data lake từng bước
10. Bảo mật và dữ liệu cá nhân trong data lake: cần lưu ý gì tại Việt Nam?
11. Những hiểu lầm phổ biến về data lake
12. Câu hỏi thường gặp

Data lake là gì?

Data lake là gì? Đó là một kho lưu trữ tập trung, nơi doanh nghiệp đổ vào mọi loại dữ liệu mà không cần sắp xếp trước. Dữ liệu giữ nguyên định dạng gốc: bảng xuất từ phần mềm kế toán, tệp JSON từ ứng dụng di động, log máy chủ, ảnh chụp, tệp PDF, ghi âm cuộc gọi. Theo cách AWS mô tả, data lake là kho tập trung cho phép lưu toàn bộ dữ liệu có cấu trúc và phi cấu trúc ở mọi quy mô.

Trong tiếng Việt, data lake thường được dịch là hồ dữ liệu: nhiều dòng chảy đổ về một nơi, nước chưa lọc, ai cần thì múc lên xử lý theo cách riêng.

Hồ dữ liệu chứa ba nhóm dữ liệu:

• Có cấu trúc (structured): bảng hàng, cột như đơn hàng, hoá đơn.
• Bán cấu trúc (semi-structured): JSON, XML, log sự kiện.
• Phi cấu trúc (unstructured): ảnh, video, ghi âm, email, tài liệu scan.

Ví dụ minh hoạ: một chuỗi bán lẻ chép dữ liệu phần mềm bán hàng, CRM, app và camera đếm khách vào một hồ chung mỗi ngày. Phòng tài chính lấy phần đã làm sạch để lập báo cáo. Nhóm phân tích ghép log app với đơn hàng để tìm vì sao khách bỏ giỏ. Nhóm AI dùng ảnh kệ hàng để huấn luyện mô hình phát hiện hết hàng.

Thuật ngữ data lake ra đời từ đâu?

Ngày 14/10/2010, James Dixon, khi đó là giám đốc công nghệ (CTO) của công ty phần mềm phân tích Pentaho, viết bài blog “Pentaho, Hadoop, and Data Lakes”. Ông so sánh: nếu data mart giống một cửa hàng nước đóng chai, đã lọc sạch, đóng gói, sắp xếp để dùng ngay, thì data lake là một khối nước lớn ở trạng thái tự nhiên hơn. Nước từ nguồn chảy vào hồ, và nhiều người dùng có thể tới quan sát, lặn xuống hay lấy mẫu.

Bối cảnh lúc đó là làn sóng Apache Hadoop. Log và dữ liệu web tăng rất nhanh, không vừa với kho dữ liệu truyền thống vốn đòi thiết kế bảng trước. Hệ thống tệp phân tán HDFS cho phép lưu rẻ trên nhiều máy thường, nên ý tưởng “lưu hết đã, tính sau” trở nên khả thi.

Trong những năm tiếp theo, hồ dữ liệu dần chuyển từ cụm Hadoop tự vận hành sang dịch vụ lưu trữ đối tượng trên đám mây. Năm 2021, nhóm tác giả Michael Armbrust, Ali Ghodsi, Reynold Xin và Matei Zaharia công bố bài báo về kiến trúc lakehouse tại hội nghị CIDR, mở ra giai đoạn hồ dữ liệu có thêm giao dịch và quản lý bảng như kho dữ liệu. Bức tranh rộng hơn về dữ liệu khối lượng lớn, tốc độ cao được phân tích trong bài big data và mô hình 5V.

Schema-on-read và schema-on-write khác nhau thế nào?

Đây là khác biệt cốt lõi giúp bạn hiểu data lake. Lược đồ (schema) là bản mô tả cấu trúc dữ liệu: có những cột nào, kiểu gì, quan hệ ra sao.

• Schema-on-write (áp lược đồ khi ghi): bạn phải thiết kế bảng trước. Dữ liệu được làm sạch, chuyển đổi cho khớp lược đồ rồi mới được ghi. Dữ liệu sai định dạng bị từ chối. Đây là cách của data warehouse.
• Schema-on-read (áp lược đồ khi đọc): dữ liệu được ghi nguyên dạng. Cấu trúc chỉ được áp khi có người truy vấn. Cùng một tệp log, nhóm marketing đọc theo phiên truy cập, nhóm kỹ thuật đọc theo mã lỗi. Đây là cách của data lake.

Schema-on-read giúp nạp dữ liệu mới rất nhanh. Đổi lại, gánh nặng hiểu dữ liệu dồn sang người đọc; thiếu tài liệu mô tả, mỗi người hiểu một kiểu. Vì vậy hồ dữ liệu hiện đại thường kết hợp: vùng thô dùng schema-on-read, vùng phục vụ báo cáo áp lược đồ chặt như kho dữ liệu.

Kiến trúc data lake gồm những thành phần nào?

Không có chuẩn bắt buộc, nhưng hầu hết kiến trúc data lake có 5 thành phần: nạp, lưu trữ, các vùng dữ liệu, xử lý và truy vấn, quản trị.

Tầng nạp dữ liệu (ingestion)

Nạp theo lô (batch) chạy định kỳ, ví dụ mỗi đêm chép đơn hàng trong ngày. Nạp dòng (streaming) đưa sự kiện vào gần như tức thời, như lượt bấm trên app hay tín hiệu cảm biến. Kỹ thuật bắt thay đổi (change data capture, CDC) chỉ chép các dòng mới thêm, sửa, xoá từ cơ sở dữ liệu nghiệp vụ.

Tầng lưu trữ

Thường là lưu trữ đối tượng (object storage) trên đám mây hoặc HDFS tại chỗ. Lưu trữ tách rời tính toán: bạn giữ nhiều dữ liệu với chi phí thấp và chỉ bật máy tính toán khi cần.

Các vùng dữ liệu: Bronze, Silver, Gold

Cách tổ chức phổ biến nhất là kiến trúc medallion. Tài liệu của Databricks mô tả đây là chuỗi lớp dữ liệu thể hiện mức chất lượng tăng dần, và nói rõ đây là thực hành được khuyến nghị chứ không phải yêu cầu bắt buộc. Một số nơi gọi các vùng là raw, cleansed, curated; ý nghĩa tương tự.

Vùng	Tên gọi khác	Chứa gì	Ai dùng
Bronze	Raw, landing, vùng thô	Dữ liệu nguyên gốc từ nguồn, chỉ ghi thêm, không sửa; giữ để kiểm toán và xử lý lại khi cần	Kỹ sư dữ liệu
Silver	Cleansed, vùng đã làm sạch	Dữ liệu đã khử trùng lặp, chuẩn hoá kiểu, kiểm tra lỗi, ghép mã khách hàng giữa các hệ thống	Nhà phân tích, nhà khoa học dữ liệu
Gold	Curated, vùng phục vụ	Bảng tổng hợp theo chủ đề nghiệp vụ, chỉ số KPI, đặc trưng cho mô hình học máy	Người dùng BI, ban lãnh đạo, ứng dụng AI

Nhiều nơi thêm vùng sandbox để thử nghiệm mà không ảnh hưởng dữ liệu chính thức.

Tầng xử lý và truy vấn

Apache Spark cho xử lý lớn và học máy, Trino hoặc Presto cho truy vấn SQL, Apache Flink cho xử lý dòng. Nhờ định dạng mở, nhiều công cụ cùng đọc một bảng mà không phải sao chép.

Tầng quản trị và bảo mật

Gồm danh mục dữ liệu (data catalog), metadata, phân quyền, mã hoá, nhật ký truy cập và theo dõi dòng dữ liệu (data lineage). Đây là phần hay bị bỏ qua nhất, xem phần data swamp bên dưới.

Data lake lưu dữ liệu ở đâu và theo định dạng nào?

Lưu trữ đối tượng (object storage)

Object storage lưu mỗi tệp như một “đối tượng” kèm metadata và định danh duy nhất, truy cập qua API. Dịch vụ phổ biến gồm Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage; theo tài liệu AWS, S3 Standard được thiết kế cho độ bền 99,999999999% mỗi năm. Nhiều nhà cung cấp đám mây trong nước cũng có dịch vụ tương thích giao thức S3. Nếu chưa quen mô hình thuê hạ tầng theo mức dùng, hãy đọc bài điện toán đám mây cho doanh nghiệp.

Định dạng tệp: vì sao Parquet phổ biến?

Ở vùng Silver và Gold, định dạng gần như mặc định là Apache Parquet: định dạng tệp nguồn mở hướng cột (column-oriented), có cơ chế nén và mã hoá hiệu năng cao. Khi bạn chỉ cần cột “doanh thu” và “ngày”, công cụ không phải đọc cả bảng 80 cột. Apache ORC là một định dạng cột khác.

Định dạng bảng mở: Delta Lake, Apache Iceberg, Apache Hudi

Tệp Parquet đơn lẻ không có “giao dịch”: một lần ghi gián đoạn có thể để lại dữ liệu dở dang. Định dạng bảng mở (open table format) thêm lớp nhật ký và metadata trên các tệp Parquet, biến thư mục tệp thành “bảng” có giao dịch ACID, cập nhật, xoá, du hành thời gian (time travel) và thay đổi lược đồ an toàn.

Tiêu chí	Delta Lake	Apache Iceberg	Apache Hudi
Xuất phát	Databricks giới thiệu năm 2017; Linux Foundation tiếp nhận ngày 16/10/2019	Phát triển tại Netflix; vào Apache Incubator 16/11/2018, thành dự án cấp cao nhất 20/05/2020	Phát triển tại Uber năm 2016, mở nguồn năm 2017; ASF công bố là dự án cấp cao nhất ngày 04/06/2020
Điểm mạnh nổi bật	Giao dịch ACID, time travel, ép lược đồ, lịch sử kiểm toán	Nhiều công cụ (Spark, Trino, Flink, Presto, Hive, Impala) cùng làm việc an toàn trên một bảng; đổi lược đồ không cần ghi lại bảng	Cập nhật, xoá (upsert, delete) hiệu quả; xử lý tăng dần; chỉ mục nâng cao
Phù hợp khi	Hệ sinh thái chủ yếu dùng Spark	Cần nhiều công cụ truy vấn khác nhau, tránh phụ thuộc một nhà cung cấp	Dữ liệu thay đổi liên tục từ CDC, cần cập nhật bản ghi thường xuyên

Hãy chọn theo công cụ đội ngũ đang dùng và kiểu dữ liệu chủ đạo.

Data lake, data warehouse và data lakehouse khác nhau thế nào?

Data warehouse (kho dữ liệu) gom dữ liệu có cấu trúc từ nhiều hệ thống, làm sạch trước khi lưu, tối ưu cho báo cáo và SQL. Kiến trúc tầng, star schema và ETL được trình bày trong bài kho dữ liệu và cách xây dựng. Bảng dưới chỉ đặt các mô hình cạnh nhau.

Tiêu chí	Data lake	Data warehouse	Data lakehouse
Loại dữ liệu	Mọi loại: bảng, log, ảnh, âm thanh, văn bản	Chủ yếu có cấu trúc	Mọi loại
Lược đồ	Áp khi đọc (schema-on-read)	Áp khi ghi (schema-on-write)	Linh hoạt ở vùng thô, chặt ở vùng phục vụ
Lưu trữ	Object storage giá rẻ, tệp mở	Thường là định dạng riêng của hệ quản trị kho	Object storage với định dạng bảng mở
Giao dịch ACID	Không có sẵn	Có	Có, nhờ Delta Lake, Iceberg hoặc Hudi
Thế mạnh	Rẻ, linh hoạt, phục vụ học máy và AI	Số liệu nhất quán, truy vấn nhanh	Một bản dữ liệu cho cả BI và AI
Rủi ro	Thành data swamp nếu thiếu quản trị	Khó đưa dữ liệu phi cấu trúc vào, đổi lược đồ chậm	Đòi hỏi đội ngũ kỹ năng cao, công nghệ còn thay đổi nhanh

Data lakehouse là gì?

Data lakehouse là kiến trúc đặt các tính năng của kho dữ liệu (giao dịch, quản lý lược đồ, hiệu năng truy vấn) trực tiếp lên trên hồ dữ liệu. Bài báo tại CIDR 2021 nêu ba đặc điểm: dựa trên định dạng mở truy cập trực tiếp như Apache Parquet, hỗ trợ tốt học máy và khoa học dữ liệu, và có hiệu năng hàng đầu. Nhóm tác giả cho rằng mô hình hai tầng “hồ cộng kho” gây dữ liệu lỗi thời, chi phí cao và phụ thuộc nhà cung cấp.

Nói đơn giản: thay vì chép dữ liệu từ hồ sang kho rồi duy trì hai bản, lakehouse giữ một bản trên object storage cho cả BI lẫn học máy cùng đọc.

Data swamp là gì và làm sao tránh?

Data swamp (đầm lầy dữ liệu) là hồ dữ liệu mất kiểm soát: dữ liệu vẫn đổ vào nhưng không ai biết tệp nào chứa gì, bản nào đúng. AWS cảnh báo rằng thiếu danh mục, bảo mật và kiểm soát truy cập, dữ liệu không thể được tìm thấy hay tin cậy, dẫn tới “data swamp”.

Dấu hiệu hồ đang thành đầm lầy:

• Cùng một chỉ số doanh thu, hai phòng ban ra hai con số.
• Không ai dám xoá gì; chi phí lưu trữ tăng đều mỗi tháng.
• Không trả lời được câu hỏi “dữ liệu cá nhân của khách hàng A đang nằm ở những đâu”.

Năm trụ cột quản trị giúp tránh data swamp:

1. Danh mục dữ liệu (data catalog): mục lục của hồ. Ví dụ: AWS Glue Data Catalog, Unity Catalog, Apache Atlas, DataHub, OpenMetadata.
2. Metadata đầy đủ: ghi rõ nguồn, chủ sở hữu, ý nghĩa cột, mức nhạy cảm, có chứa dữ liệu cá nhân hay không.
3. Phân quyền chi tiết: theo vai trò, tới mức cột và dòng. Marketing xem được hành vi mua nhưng không thấy số điện thoại.
4. Kiểm soát chất lượng: kiểm tra tự động khi dữ liệu đi từ Bronze sang Silver. Hiểu vì sao chất lượng đầu vào quyết định kết quả qua bài nguyên lý rác vào, rác ra.
5. Vòng đời dữ liệu: giữ bao lâu, khi nào chuyển lưu trữ lạnh, khi nào xoá hoặc ẩn danh hoá.

Ngoài công cụ, cần chỉ định người chịu trách nhiệm (data owner) cho từng miền dữ liệu và vận hành theo cách tiếp cận DataOps.

Doanh nghiệp nào thực sự cần data lake?

Data lake không phải bước bắt buộc của mọi dự án dữ liệu. Bạn nên cân nhắc khi có ít nhất hai trong các dấu hiệu sau:

• Có nhiều dữ liệu bán cấu trúc và phi cấu trúc: log, cảm biến, ghi âm, ảnh, hồ sơ scan.
• Có kế hoạch học máy hoặc AI cần dữ liệu thô, chi tiết, lưu lâu.
• Khối lượng dữ liệu tăng nhanh, lưu trong kho dữ liệu hoặc cơ sở dữ liệu nghiệp vụ trở nên quá đắt.
• Cần giữ bản gốc để kiểm toán hoặc xử lý lại khi logic tính toán thay đổi.

Nếu dữ liệu chủ yếu từ vài phần mềm kế toán, bán hàng và nhu cầu chính là báo cáo, kho dữ liệu đám mây hoặc công cụ BI thường đủ và rẻ hơn.

Ứng dụng thường gặp theo ngành (ví dụ minh hoạ)

• Bán lẻ, thương mại điện tử: ghép lịch sử mua, hành vi duyệt web, phản hồi khách để cá nhân hoá gợi ý sản phẩm.
• Ngân hàng, tài chính: lưu log giao dịch và thiết bị chi tiết để huấn luyện mô hình phát hiện gian lận.
• AI tạo sinh trong doanh nghiệp: hồ tài liệu nội bộ là nguồn cho hệ thống hỏi đáp theo kiến trúc RAG truy xuất tài liệu.

Hồ dữ liệu cũng là “nguyên liệu” quen thuộc của nhà khoa học dữ liệu; vai trò và kỹ năng của nghề này được bàn trong bài khoa học dữ liệu là gì.

Quy trình xây dựng data lake từng bước

Đừng bắt đầu bằng việc chọn công nghệ; hãy bắt đầu từ bài toán. Quy trình dưới đây phù hợp cho dự án đầu tiên của doanh nghiệp vừa.

1. Xác định 1–3 bài toán cụ thể. Ví dụ: dự báo tồn kho theo cửa hàng, phân tích lý do khách huỷ đơn. Ghi rõ ai dùng, cần dữ liệu gì, đo thành công bằng chỉ số nào.
2. Kiểm kê và phân loại nguồn dữ liệu. Liệt kê nguồn, định dạng, dung lượng; đánh dấu nguồn chứa dữ liệu cá nhân, dữ liệu nhạy cảm.
3. Chọn nơi đặt hồ. Đám mây quốc tế, đám mây trong nước hay tại chỗ; cân nhắc chi phí, kỹ năng đội ngũ và yêu cầu pháp lý.
4. Thiết kế vùng và quy ước. Quy tắc đặt tên; vùng Bronze, Silver, Gold, sandbox; Parquet và một định dạng bảng mở.
5. Dựng quản trị trước khi nạp dữ liệu. Bật catalog, phân quyền, mã hoá, nhật ký truy cập. Làm sau sẽ tốn hơn nhiều.
6. Xây pipeline nạp và làm sạch. Bắt đầu với vài nguồn, đặt kiểm tra chất lượng tự động ở mỗi bước chuyển vùng.
7. Mở cho người dùng. Nối công cụ BI vào vùng Gold, cấp sandbox cho nhóm phân tích.
8. Đo lường và mở rộng. Theo dõi chi phí, độ trễ dữ liệu, số người dùng thực tế. Chỉ thêm nguồn khi có bài toán cần.

Bảo mật và dữ liệu cá nhân trong data lake: cần lưu ý gì tại Việt Nam?

Hồ dữ liệu gom dữ liệu khách hàng, nhân viên về một nơi và giữ lâu, nên là điểm tập trung rủi ro bảo mật và pháp lý.

Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15

Luật được Quốc hội thông qua ngày 26/06/2025, có hiệu lực từ 01/01/2026. Nghị định 356/2025/NĐ-CP ngày 31/12/2025 hướng dẫn luật, có hiệu lực cùng ngày 01/01/2026 và thay thế Nghị định 13/2023/NĐ-CP. Các điểm tác động trực tiếp tới hồ dữ liệu:

• Điều 3 (nguyên tắc): chỉ thu thập, xử lý dữ liệu cá nhân đúng phạm vi, mục đích cụ thể, rõ ràng; lưu trữ trong khoảng thời gian phù hợp với mục đích xử lý, trừ khi pháp luật quy định khác. Tư duy “lưu hết, tính sau” không còn phù hợp với dữ liệu cá nhân.
• Điều 20 (chuyển dữ liệu xuyên biên giới): việc sử dụng nền tảng ở ngoài lãnh thổ Việt Nam để xử lý dữ liệu cá nhân thu thập tại Việt Nam được tính là chuyển dữ liệu xuyên biên giới. Bên chuyển phải lập hồ sơ đánh giá tác động và gửi cơ quan chuyên trách trong 60 ngày, trừ các trường hợp miễn như tổ chức lưu dữ liệu cá nhân của người lao động trên dịch vụ điện toán đám mây.
• Điều 30 (dữ liệu lớn, AI, điện toán đám mây): xử lý dữ liệu cá nhân phải đúng mục đích, trong phạm vi cần thiết; hệ thống phải tích hợp biện pháp bảo mật phù hợp, có xác thực, định danh và phân quyền truy cập.
• Điều 8 (xử lý vi phạm): phạt tối đa 5% doanh thu năm trước liền kề với vi phạm về chuyển dữ liệu xuyên biên giới của tổ chức; tối đa 3 tỷ đồng với nhiều vi phạm khác.

Luật Dữ liệu số 60/2024/QH15

Luật ban hành ngày 30/11/2024, hiệu lực từ 01/07/2025. Điều 13 yêu cầu chủ sở hữu, chủ quản dữ liệu ngoài khu vực nhà nước áp dụng tiêu chí phân loại dữ liệu cốt lõi và dữ liệu quan trọng. Điều 23 quy định riêng việc chuyển, xử lý dữ liệu cốt lõi, quan trọng xuyên biên giới, bao gồm cả trường hợp dùng nền tảng xử lý đặt ngoài lãnh thổ. Hãy gắn nhãn phân loại cho từng tập dữ liệu trong catalog ngay từ đầu.

Có bắt buộc lưu dữ liệu trong nước không?

Không có quy định chung buộc mọi data lake phải đặt tại Việt Nam. Tuy nhiên, Luật An ninh mạng số 116/2025/QH15 (ban hành ngày 10/12/2025, hiệu lực từ 01/07/2026, thay thế Luật An ninh mạng 2018 và Luật An toàn thông tin mạng 2015) tại khoản 3 Điều 25 yêu cầu doanh nghiệp trong nước và ngoài nước cung cấp dịch vụ trên mạng viễn thông, Internet, dịch vụ gia tăng tại Việt Nam, có xử lý thông tin cá nhân, dữ liệu mối quan hệ và dữ liệu do người dùng tạo ra tại Việt Nam, phải lưu trữ dữ liệu này tại Việt Nam trong thời gian do Chính phủ quy định. Nếu bạn thuộc nhóm này, hãy kiểm tra văn bản hướng dẫn hiện hành trước khi chọn vị trí đặt hồ.

Biện pháp kỹ thuật nên có

• Gắn nhãn cột chứa dữ liệu cá nhân trong catalog; mã hoá khi lưu và khi truyền.
• Che (masking) hoặc mã hoá giả danh (pseudonymization) số điện thoại, số giấy tờ tùy thân ngay từ vùng Silver.
• Phân quyền tới mức cột, dòng; ghi nhật ký mọi truy cập.
• Có quy trình xoá dữ liệu của một người trên toàn hồ khi họ yêu cầu. Định dạng bảng mở hỗ trợ xoá bản ghi giúp việc này dễ hơn.

Những hiểu lầm phổ biến về data lake

• “Cứ đổ mọi thứ vào, quản lý sau.” Đây là con đường ngắn nhất tới data swamp.
• “Có data lake thì không cần data warehouse.” Hai mô hình phục vụ mục đích khác nhau.
• “Lên đám mây là nhà cung cấp lo bảo mật.” Phân quyền, mã hoá, tuân thủ luật vẫn là việc của doanh nghiệp.

Câu hỏi thường gặp

Hồ dữ liệu là gì, có giống data lake không?

Giống nhau. Hồ dữ liệu là cách dịch tiếng Việt của data lake: kho tập trung lưu mọi loại dữ liệu ở dạng gốc, chỉ áp cấu trúc khi cần phân tích.

Data lake và data warehouse nên chọn cái nào?

Nếu nhu cầu chính là báo cáo trên dữ liệu có cấu trúc, hãy bắt đầu với data warehouse. Nếu cần lưu log, ảnh, văn bản cho phân tích khám phá hoặc học máy, data lake phù hợp hơn. Nhiều nơi dùng cả hai hoặc chọn lakehouse.

Data lakehouse là gì, có thay thế data lake không?

Lakehouse là data lake được bổ sung giao dịch ACID, quản lý lược đồ và hiệu năng truy vấn nhờ định dạng bảng mở như Delta Lake, Iceberg, Hudi. Nó là bước phát triển của data lake, không phải một thứ tách rời.

Doanh nghiệp nhỏ có cần data lake không?

Thường chưa cần, trừ khi có nhiều dữ liệu phi cấu trúc hoặc kế hoạch AI rõ ràng.

Đặt data lake trên đám mây nước ngoài có vi phạm luật không?

Không tự động vi phạm, nhưng phát sinh nghĩa vụ. Theo Điều 20 Luật 91/2025/QH15, xử lý dữ liệu cá nhân thu thập tại Việt Nam trên nền tảng ngoài lãnh thổ là chuyển dữ liệu xuyên biên giới, cần lập hồ sơ đánh giá tác động trừ trường hợp được miễn. Một số doanh nghiệp cung cấp dịch vụ mạng còn có nghĩa vụ lưu dữ liệu tại Việt Nam theo Luật An ninh mạng 2025.

Data lake có dùng được cho AI tạo sinh không?

Có. Tài liệu, email, ghi âm đã chuyển văn bản trong hồ là nguồn tri thức cho mô hình và hệ thống hỏi đáp nội bộ. Điều kiện là dữ liệu được làm sạch, gắn metadata và phân quyền đúng.