Vòng đời dữ liệu — từ ingest đến archive

TL;DR: Mọi mẩu dữ liệu đều đi qua một vòng đời: ingestion (nhập vào hệ thống), storage (lưu để dùng), serving (phục vụ truy vấn), và archival/retention (lưu trữ dài hạn hoặc xoá). Ở mỗi giai đoạn bạn đánh đổi giữa độ tươi của dữ liệu (freshness) và chi phí (cost): dữ liệu mới truy cập nhiều nên để ở tầng nhanh-đắt (hot), dữ liệu cũ ít đụng tới đẩy xuống tầng chậm-rẻ (cold). Cuối vòng đời, retention policy quyết định giữ bao lâu rồi xoá — vừa để tiết kiệm, vừa để tuân thủ quy định (như GDPR). Hiểu vòng đời này giúp bạn thiết kế hệ thống không phình chi phí và không vi phạm pháp lý.

Một startup logistics chạy ổn trong năm đầu: mỗi đơn hàng sinh ra vài chục dòng tracking event, tất cả nằm trong một bảng tracking_event trên database chính. Sang năm thứ ba, bảng đó có 4 tỉ dòng. Query "trạng thái đơn hôm nay" vẫn nhanh, nhưng hoá đơn cloud tăng gấp 6 lần — phần lớn là tiền lưu trữ những event từ hai năm trước mà không ai từng đọc lại. Không ai quyết định "giữ mọi thứ mãi mãi"; nó chỉ xảy ra vì không ai thiết kế cho phần kết thúc của dữ liệu.

Dữ liệu không phải thứ ghi một lần rồi nằm yên. Nó sống — được sinh ra, dùng nhiều, dùng ít dần, rồi nên được lưu nguội hoặc xoá. Bài này vạch ra bốn giai đoạn của vòng đời và quyết định cốt lõi ở mỗi giai đoạn, để bạn thiết kế cho cả vòng đời chứ không chỉ cho lúc dữ liệu còn mới.

1. Analogy — Kho hàng nhiều tầng

Hình dung một công ty bán lẻ quản lý hàng hoá qua nhiều khu lưu trữ, mỗi khu một mục đích:

• Cửa nhận hàng (ingestion): xe tải dỡ hàng, nhân viên kiểm đếm và dán nhãn trước khi cho vào kho. Hàng vào ồ ạt, phải xử lý kịp.
• Kệ trước cửa hàng (storage nóng): hàng bán chạy để ngay tầm với, lấy trong vài giây — đắt chỗ nhưng tiện.
• Quầy phục vụ (serving): nhân viên lấy hàng từ kệ giao cho khách — đây là lúc dữ liệu thực sự được "dùng".
• Kho ngoại ô (archival): hàng tồn lâu, ít người hỏi, chuyển ra kho xa rẻ tiền; hết hạn sử dụng thì thanh lý (xoá).

Không ai để mọi món hàng ngay quầy thu ngân — chỗ đó quá đắt. Cũng không ai vứt hàng còn bán được. Bí quyết là chuyển hàng giữa các tầng theo mức độ được hỏi tới. Dữ liệu y hệt vậy.

2. Bốn giai đoạn của vòng đời

flowchart LR
  SRC["Nguon su kien<br/>(app, sensor, log)"] -->|"ingest"| ING["Ingestion<br/>validate + chuan hoa"]
  ING --> HOT[("Hot storage<br/>nhanh, dat")]
  HOT --> SRV["Serving<br/>query nguoi dung"]
  HOT -->|"du lieu nguoi dan"| COLD[("Cold storage<br/>cham, re")]
  COLD -->|"het han"| DEL["Retention:<br/>xoa / an danh"]

Mỗi mũi tên là một quyết định thiết kế, không phải bước tự động. Ta đi qua từng giai đoạn.

2.1 Ingestion — nhập dữ liệu vào hệ thống

Ingestion là điểm dữ liệu lần đầu chạm hệ thống của bạn: một sự kiện click, một bản ghi cảm biến, một dòng log, một đơn hàng. Quyết định ở đây:

• Validate sớm hay muộn? Bắt lỗi format ngay lúc nhập (schema-on-write) giúp dữ liệu downstream luôn sạch, nhưng làm chậm đường nhập. Hoặc nhận tất, validate khi đọc (schema-on-read) — nhập nhanh nhưng đẩy rủi ro về sau.
• Batch hay streaming? Gom theo lô (mỗi giờ một lần) đơn giản và rẻ; nhận từng sự kiện theo luồng (streaming) cho độ trễ thấp nhưng phức tạp hơn.

Hai kieu ingest:
  Batch    : gom 1 gio -> nap 1 lan   (don gian, tre 1 gio)
  Streaming: nhan tung su kien ngay    (phuc tap, tre vai giay)

2.2 Storage — lưu dữ liệu để dùng

Sau khi nhập, dữ liệu cần một chỗ nằm. Quyết định lớn nhất là phân tầng nóng/ấm/nguội (tiered storage), bàn kỹ ở mục 3. Ngoài ra: chọn cách encode dữ liệu khi ghi xuống đĩa (text hay binary — đó là chủ đề bài 02), và chọn mô hình lưu trữ (row hay column — đã chạm ở Module 10).

2.3 Serving — phục vụ truy vấn

Đây là lúc dữ liệu trả lại giá trị: một query đọc nó để trả lời câu hỏi của người dùng hay dashboard. Quyết định: dữ liệu phục vụ cần tươi tới mức nào? Số dư tài khoản phải tức thì; báo cáo "doanh thu tháng trước" chấp nhận trễ vài giờ. Mức freshness yêu cầu quyết định bạn phục vụ từ tầng nóng hay từ một bản sao trễ hơn.

2.4 Archival & retention — lưu trữ dài hạn hoặc xoá

Cuối vòng đời, hầu hết dữ liệu trở nên ít được hỏi tới. Hai lựa chọn: archive (chuyển sang cold storage rẻ, vẫn giữ được nếu cần) hoặc delete (xoá hẳn theo retention policy). Đây chính là giai đoạn startup ở đầu bài đã bỏ quên — và là phần dễ quên nhất vì nó không gây lỗi ngay, chỉ âm thầm đội chi phí.

3. Cơ chế bên dưới — tiered storage và quy luật tuổi-truy cập

Vì sao phân tầng lại tiết kiệm? Vì xác suất một bản ghi được truy cập giảm mạnh theo tuổi của nó. Một order vừa tạo được đọc liên tục (khách theo dõi, hệ thống cập nhật trạng thái). Order ba năm trước gần như không ai đụng. Nếu mọi bản ghi đều nằm chung một tầng đắt, bạn trả giá tầng nóng cho cả khối dữ liệu nguội.

Tiered storage khai thác điều này bằng cách giữ ba (hoặc nhiều) tầng với đánh đổi tốc độ-giá khác nhau:

Dữ liệu trôi xuống (tiering down) theo tuổi: một job định kỳ chuyển bản ghi vượt ngưỡng tuổi từ hot sang warm, rồi cold. Cái giá ở tầng cold không phải tốc độ đọc thường ngày (vì hiếm đọc) mà là độ trễ khi cần lấy lại — chấp nhận chờ là cái giá đổi lấy chi phí thấp.

4. Retention & compliance — khi xoá là bắt buộc

Không phải dữ liệu nào cũng được phép giữ mãi. Retention policy là quy tắc "giữ loại dữ liệu X trong Y lâu rồi xoá". Có hai động lực:

1. Chi phí & vệ sinh: dữ liệu không dùng vẫn tốn tiền lưu, tốn công backup, và làm chậm query nếu lẫn trong bảng nóng. Xoá bớt là tốt cho sức khoẻ hệ thống.
2. Tuân thủ pháp lý (compliance): một số quy định bắt buộc giữ tối thiểu (ví dụ chứng từ tài chính giữ nhiều năm), số khác bắt buộc xoá hoặc cho người dùng quyền yêu cầu xoá.

Ví dụ ở mức khái niệm: GDPR (quy định bảo vệ dữ liệu của EU) trao "quyền được xoá" (right to erasure) — khi người dùng yêu cầu, bạn phải xoá dữ liệu cá nhân của họ trong thời hạn quy định. Một hệ thống "giữ mọi thứ mãi mãi" không chỉ tốn tiền mà còn không thể tuân thủ yêu cầu này.

Có một lựa chọn trung gian giữa giữ và xoá: anonymization (ẩn danh) — bỏ hoặc băm các trường định danh cá nhân, giữ lại phần dữ liệu thống kê vô hại. Bạn vẫn phân tích được xu hướng mà không còn lưu thông tin cá nhân.

Ba lua chon cuoi vong doi:
  KEEP      : giu nguyen (hot/cold)      -- can truy cap hoac luat bat giu
  ANONYMIZE : bo truong dinh danh         -- giu thong ke, bo ca nhan
  DELETE    : xoa han                      -- het nhu cau / luat bat xoa

5. Pitfall — không thiết kế cho phần kết thúc

WRONG (mac dinh khong ai quyet dinh):
  moi su kien -> bang nong duy nhat -> giu mai mai

RIGHT (thiet ke ca vong doi):
  ingest -> hot (N ngay) -> warm -> cold (M thang)
         -> retention: xoa / an danh theo chinh sach

6. 📚 Deep Dive

7. Liên hệ các bài khác

• Bài 02 — Encoding & serialization: khi dữ liệu được lưu hay truyền, nó phải được encode thành byte — quyết định text vs binary ảnh hưởng kích thước và tốc độ ở mọi tầng storage.
• Bài 03 — Schema evolution: dữ liệu sống lâu hơn code, nên schema phải đổi mà không vỡ dữ liệu cũ ở tầng cold — đây là khía cạnh "tiến hoá theo thời gian" của vòng đời.
• Module 10 — OLTP vs OLAP: pipeline ETL chuyển dữ liệu từ hệ thống giao dịch (nóng) sang kho phân tích — chính là một chặng "serving + archival" trong vòng đời.
• Module 5 — Schema migration: đổi cấu trúc bảng khi dữ liệu đang sống là một thao tác giữa giai đoạn storage và serving.

8. Tóm tắt

• Dữ liệu sống qua bốn giai đoạn: ingestion (nhập + validate) → storage (lưu, phân tầng) → serving (query phục vụ) → archival/retention (lưu nguội hoặc xoá).
• Cái cân xuyên suốt là freshness vs cost: dữ liệu càng tươi và sẵn-sàng-tức-thì càng đắt; chọn điểm cân bằng theo từng loại dữ liệu.
• Tiered storage (hot/warm/cold) khai thác quy luật xác suất truy cập giảm theo tuổi — dữ liệu cũ trôi xuống tầng rẻ-chậm.
• Retention policy trả lời "giữ bao lâu rồi sao" — vì chi phí, vệ sinh hệ thống, và tuân thủ (như quyền xoá của GDPR).
• Giữa giữ và xoá có lựa chọn ẩn danh (anonymization): bỏ trường định danh, giữ phần thống kê.
• Pitfall lớn nhất: không ai quyết định "giữ hết mãi mãi" — nó xảy ra do mặc định. Mỗi loại dữ liệu cần một câu trả lời cho phần kết thúc, ngay từ lúc thiết kế.

9. Tự kiểm tra

Bài tiếp theo: Encoding & serialization — text vs binary