Cloud DE 2 — Lưu trữ đám mây & Data Lake

Vì sao lưu trữ là nền móng của Data Engineering trên cloud

Trong kiến trúc dữ liệu cloud hiện đại, lưu trữ (storage) tách hẳn khỏi tính toán (compute) — đây là thay đổi lớn nhất so với thời Hadoop. Dữ liệu nằm yên ở một lớp lưu trữ rẻ, bền, gần như vô hạn; còn các engine (Spark, Trino, warehouse) chỉ là những cụm compute tạm thời bật lên đọc dữ liệu đó rồi tắt đi. Hệ quả: bạn có thể có nhiều engine cùng đọc một tập dữ liệu, tắt compute qua đêm mà không mất dữ liệu, và trả tiền lưu trữ riêng với trả tiền tính toán riêng.

Bài này (tiếp theo Cloud DE 1 — Tổng quan) đi sâu vào lớp lưu trữ đó: object storage làm nền data lake, các loại storage khác (block, file), tiering, bảo mật và các tính năng tuân thủ. Với một ngân hàng phải giữ lịch sử giao dịch nhiều năm theo luật, đây là lớp chịu trách nhiệm vừa lưu rẻ, vừa an toàn, vừa không được lộ ra ngoài.

Object storage — nền tảng của data lake

Object storage (Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage) là kiểu lưu trữ trung tâm của mọi data lake/lakehouse trên cloud. Đặc điểm khiến nó thống trị:

• Rẻ: tính tiền theo GB-tháng thực dùng (không phải dung lượng cấp phát), rẻ hơn nhiều lần block storage.
• Gần như vô hạn: bạn không phải cấp phát trước dung lượng; đổ vào bao nhiêu cũng được, không có "ổ đầy".
• Bền vững cực cao: S3 công bố độ bền (durability) 99.999999999% — thường gọi là "11 số 9". Nghĩa là kỳ vọng mất tối đa 1 object trong mỗi 10 tỷ object mỗi năm, nhờ tự động sao chép qua nhiều thiết bị/khu vực.
• HTTP API: truy cập qua REST (GET/PUT/DELETE trên URL), không phải qua POSIX filesystem. Mọi ngôn ngữ, mọi engine đều nói được HTTP.
• Tách khỏi compute: dữ liệu tồn tại độc lập với bất kỳ máy chủ nào.

Vì sao object storage thay HDFS làm data lake

Thế hệ data lake đầu tiên (~2010) dùng HDFS — filesystem phân tán chạy trên chính các máy tính toán của cụm Hadoop. Mô hình đó gắn chặt storage với compute: muốn thêm dung lượng phải thêm máy, và các máy đó phải luôn bật để giữ dữ liệu. Object storage phá vỡ ràng buộc này:

Tiêu chí	HDFS (on-prem)	Object storage (cloud)
Storage & compute	Gắn chặt (co-located)	Tách rời hoàn toàn
Mở rộng dung lượng	Thêm máy (đắt, thủ công)	Tự động, vô hạn, elastic
Chi phí khi không tính toán	Vẫn trả tiền cả cụm	Chỉ trả tiền lưu trữ
Độ bền	Tự quản replica 3x	11 số 9, nhà cung cấp lo
Vận hành	Team tự lo NameNode, DataNode	Managed, gần như zero-ops

Ngày nay hầu như không ai dựng HDFS mới cho data lake; các distro Hadoop cũ đều hỗ trợ đọc/ghi thẳng lên S3/ADLS/GCS.

Bucket, key/prefix, object, metadata

Object storage KHÔNG có thư mục thật. Mô hình dữ liệu phẳng gồm 4 khái niệm:

• Bucket (S3/GCS) / container (Azure): không gian tên gốc, tên duy nhất toàn cầu (với S3). Ví dụ ncb-datalake-prod.
• Key: đường dẫn đầy đủ của object trong bucket, ví dụ raw/transactions/2026/06/30/part-000.parquet. Key chỉ là một chuỗi.
• Prefix: phần đầu của key. Vì các engine coi dấu / như phân cách, prefix raw/transactions/2026/06/30/ trông như một "thư mục" nhưng thực chất chỉ là thư mục ảo — không có object nào tên là thư mục, chỉ là các key cùng chung tiền tố.
• Object: đơn vị lưu trữ = dữ liệu (bytes) + metadata (Content-Type, kích thước, thời gian, tag, và metadata tuỳ biến của người dùng). Object là bất biến (immutable): ghi đè = tạo phiên bản mới, không sửa tại chỗ.

Hệ quả thực tế: object storage tuyệt vời để đọc/ghi cả file, nhưng không phải filesystem — không rename rẻ (rename = copy + delete), không append hiệu quả, không phù hợp với sửa từng byte. Đây là lý do các table format (Delta/Iceberg/Hudi — xem Lakehouse) ra đời để cung cấp transaction, update/delete và schema trên nền object storage vốn chỉ ghi cả file.

Storage class & tiering

Object storage phân dữ liệu thành nhiều storage class (tầng lưu trữ), rẻ dần theo mức độ "lạnh" — càng ít truy cập thì lưu càng rẻ nhưng lấy ra càng chậm và có phí truy xuất. Đây là đánh đổi trung tâm giữa giá lưu vs tốc độ/chi phí truy xuất.

Tầng	Ví dụ (S3)	Dùng cho	Giá lưu	Truy xuất
Hot / Standard	S3 Standard	Dữ liệu nóng, đọc thường xuyên	Cao nhất	Ngay, không phí retrieval
Infrequent	S3 Standard-IA	Ít đọc nhưng cần nhanh	~50% Standard	Có phí retrieval/GB
Archive	S3 Glacier Flexible	Lưu lâu, hiếm đọc	Rất thấp	Phút–giờ + phí
Deep Archive	S3 Glacier Deep Archive	Tuân thủ, gần như không đọc	Thấp nhất	12–48h + phí cao

Chuyển tầng thủ công là bất khả thi ở quy mô lớn, nên dùng lifecycle policy: quy tắc tự động chuyển object sang tầng lạnh hơn theo tuổi. Ví dụ (minh hoạ, cú pháp S3 lifecycle rút gọn): object dưới prefix raw/transactions/ sau 90 ngày chuyển sang Standard-IA, sau 1 năm sang Glacier, sau 7 năm thì xoá (hoặc giữ vĩnh viễn nếu luật yêu cầu). Chi tiết tối ưu chi phí và các phí ẩn (retrieval, minimum storage duration, per-object overhead) xem FinOps 3 — Chi phí lưu trữ & phân tầng.

Object vs block vs file storage

Không phải mọi thứ đều là object storage. Ba loại lưu trữ nền tảng phục vụ mục đích khác nhau:

Loại	Ví dụ	Giao diện	Dùng khi nào
Object	S3, ADLS, GCS	HTTP API, key-value	Data lake, backup, file lớn bất biến, dữ liệu phân tích
Block	EBS, Persistent Disk, Azure Disk	Ổ đĩa thô gắn vào 1 VM	OS, database vận hành (Postgres/Oracle), thư mục làm việc của compute
File	EFS, Azure Files, Filestore (NFS)	Filesystem POSIX chia sẻ	Nhiều VM cùng đọc/ghi 1 hệ thư mục, ứng dụng legacy cần POSIX

Điểm cần nhớ:

• Block storage là "ổ đĩa ảo", chỉ gắn được vào (thường) một máy chủ, hiệu năng IOPS cao, độ trễ thấp — bắt buộc cho database và OS. Tính tiền theo dung lượng cấp phát, không phải dung lượng dùng, nên đắt.
• File storage cung cấp semantics POSIX (thư mục thật, khoá file, append) qua NFS/SMB, chia sẻ được cho nhiều máy — hợp với app cần filesystem mà object storage không đáp ứng được.
• Object storage thắng ở quy mô lớn, dữ liệu bất biết đọc song song — chính là hồ dữ liệu.

Nguyên tắc: database → block, thư mục chia sẻ legacy → file, data lake/analytics → object.

Tính nhất quán, durability và availability

• Strong consistency: trước đây S3 chỉ eventually consistent (ghi xong đọc lại có thể chưa thấy). Từ 2020, S3 cung cấp strong read-after-write consistency cho mọi thao tác — GCS và ADLS Gen2 cũng vậy. Nghĩa là ghi object xong, mọi lần đọc/list ngay sau đó luôn thấy phiên bản mới nhất. Điều này quan trọng cho pipeline: không còn lỗi "job đọc dữ liệu vừa ghi mà chưa thấy".
• Durability (độ bền) ≠ availability (độ sẵn sàng). Durability = xác suất dữ liệu không bị mất (11 số 9 với S3). Availability = xác suất dữ liệu truy cập được ngay lúc bạn cần (SLA thường ~99.9%). Một object có thể vẫn tồn tại (bền) nhưng tạm không đọc được (sự cố khu vực) — hai chỉ số này độc lập.

Hiệu năng khi đọc/ghi

Object storage cho throughput cực lớn nhưng phải khai thác đúng:

• Song song hoá (parallel): throughput đến từ việc đọc nhiều object đồng thời qua nhiều kết nối, không phải đọc tuần tự một file khổng lồ. Một engine như Spark/Trino tự chia partition đọc song song hàng trăm file cùng lúc.
• Prefix / partition: chia dữ liệu theo prefix (ví dụ theo ngày dt=2026-06-30/) giúp engine prune — chỉ đọc prefix cần thiết thay vì quét cả bucket. Bố cục prefix hợp lý là yếu tố hiệu năng lớn nhất.
• Tránh small files: hàng triệu file nhỏ (vài KB) giết hiệu năng — mỗi file là một request HTTP có overhead, và metadata/listing trở thành nút cổ chai. Gom về file 128 MB–1 GB (thường Parquet nén). Đây là "small files problem" kinh điển của data lake.

Bảo mật lưu trữ

Lớp lưu trữ chứa dữ liệu nhạy cảm nhất, nên bảo mật là bắt buộc, không phải tuỳ chọn (xem thêm Cloud DE 4 — Mạng & bảo mật và Bảo mật dữ liệu ngân hàng):

• Mã hoá at-rest: S3/ADLS/GCS mã hoá mặc định mọi object khi lưu (SSE-S3 dùng khoá do cloud quản lý). Với dữ liệu ngân hàng, nên dùng CMK (customer-managed key qua KMS) để tự kiểm soát khoá, xoay khoá và ghi log mọi lần dùng khoá — đáp ứng yêu cầu tuân thủ.
• Chặn public access: sự cố lộ bucket (bucket vô tình để công khai, lộ dữ liệu khách hàng) là một trong những dạng rò rỉ dữ liệu phổ biến nhất trên cloud. Bật Block Public Access ở cấp account, không dùng ACL public. Không bao giờ đặt dữ liệu ngân hàng trên bucket public.
• Bucket policy / IAM: kiểm soát ai được đọc/ghi qua IAM policy và bucket policy — theo nguyên tắc least-privilege, chỉ cấp quyền tối thiểu, phân theo prefix (ví dụ team A chỉ đọc raw/domainA/*).

Versioning, replication, object lock

Ba tính năng cho phục hồi và tuân thủ:

• Versioning: bật versioning thì mỗi lần ghi đè/xoá tạo một phiên bản mới, phiên bản cũ vẫn giữ. Chống xoá/ghi đè nhầm và chống ransomware — có thể khôi phục về phiên bản trước.
• Replication (cross-region): tự động sao chép object sang bucket ở khu vực khác (CRR) để phục hồi thảm hoạ (DR) và giảm độ trễ đọc cho người dùng ở vùng khác. Với ngân hàng, CRR thường bắt buộc cho dữ liệu quan trọng.
• Object lock (WORM): khoá object theo mô hình Write-Once-Read-Many — trong thời hạn retention đã đặt, không ai (kể cả admin) được sửa/xoá object. Đây là cơ chế đáp ứng yêu cầu tuân thủ/retention (giữ chứng từ giao dịch bất biến X năm theo luật, phục vụ audit và tránh chỉnh sửa gian lận).

Tích hợp với warehouse & query engine

Vì dữ liệu nằm trên object storage dạng file mở (Parquet/ORC), nhiều engine đọc trực tiếp mà không cần nạp vào database riêng:

• External table: định nghĩa bảng ảo trỏ vào một prefix trên S3 (Snowflake external table, BigQuery external table, Redshift Spectrum, Athena). Query chạy trực tiếp trên file.
• Trino / Spark: đọc thẳng Parquet trên object storage qua catalog (Hive Metastore, Glue, Unity Catalog), không copy dữ liệu.
• Lakehouse table format: Delta/Iceberg thêm lớp transaction log trên các file đó, biến prefix thành bảng ACID có time travel, update/delete.

Đây chính là điểm khiến object storage là single source of truth: một tập dữ liệu, nhiều engine đọc — không nhân bản, không đồng bộ.

Sơ đồ: object storage làm nền data lake + tiering

Use case thực tế

Bối cảnh: NCB xây data lake trên S3 lưu lịch sử giao dịch 7 năm theo yêu cầu lưu trữ chứng từ. Ước lượng: ~2 TB dữ liệu giao dịch mới mỗi tháng, dạng Parquet nén.

Thiết kế storage:

1. Bố cục prefix: s3://ncb-datalake-prod/raw/transactions/dt=YYYY-MM-DD/ — phân vùng theo ngày để engine chỉ quét ngày cần, và gom file ~256 MB tránh small files.
2. Tiering bằng lifecycle: dữ liệu 90 ngày đầu ở S3 Standard (dashboard, phân tích rủi ro đọc thường xuyên). Sau 90 ngày → Standard-IA. Sau 1 năm → Glacier Flexible. Giữ đủ 7 năm rồi mới cho phép xoá. Ước tính: đưa dữ liệu năm cũ xuống Glacier giảm chi phí lưu phần đó tới ~80% so với để nguyên Standard.
3. Bảo mật: mã hoá CMK qua KMS (khoá riêng của ngân hàng, xoay định kỳ, log mọi lần dùng); bật Block Public Access toàn account; IAM phân quyền theo prefix (team risk chỉ đọc, team ingest được ghi).
4. Tuân thủ: bật Object Lock (WORM) với retention 7 năm cho prefix raw/transactions/ — không ai xoá/sửa được chứng từ trong thời hạn, đáp ứng audit và chống chỉnh sửa gian lận.
5. DR: bật Cross-Region Replication sang khu vực thứ hai và versioning để chống xoá nhầm.

Khai thác: bộ phận rủi ro dùng external table (Athena/Trino) query thẳng Parquet trên S3 để tính hạn mức, chấm điểm (Scorecard) mà không cần nạp lại vào warehouse — compute bật khi cần, tắt khi xong, dữ liệu vẫn nằm yên trên object storage.

Ghi nhớ

• Object storage (S3/ADLS/GCS) là nền của data lake/lakehouse: rẻ, gần như vô hạn, bền 11 số 9, HTTP API, tách storage khỏi compute — thay thế HDFS.
• Mô hình phẳng: bucket → key/prefix (thư mục ảo) → object (bất biến) + metadata. Không phải filesystem: rename/append đắt, không sửa tại chỗ → cần table format cho ACID.
• Storage class + lifecycle policy: tự chuyển hot → infrequent → archive theo tuổi để cân giá lưu vs tốc độ/chi phí truy xuất.
• Block (EBS) cho DB/OS, file (EFS/NFS) cho thư mục chia sẻ, object cho data lake — chọn đúng loại theo nhu cầu.
• S3/ADLS/GCS nay strong read-after-write consistency; phân biệt durability (không mất) vs availability (truy cập được).
• Hiệu năng đến từ prefix/partition + đọc song song + tránh small files (gom file 128 MB–1 GB).
• Bảo mật bắt buộc: mã hoá at-rest (CMK), chặn public access (chống lộ bucket), IAM/bucket policy least-privilege.
• Versioning + replication (CRR) + object lock (WORM) cho phục hồi và tuân thủ retention nhiều năm.
• Nhiều engine (Trino/Spark/warehouse external table) đọc trực tiếp trên object storage → một single source of truth, không nhân bản dữ liệu.