Khi dữ liệu cần có “trí nhớ”: Câu chuyện về Version Control

Dòng ký ức dữ liệu

Có một buổi sáng đầu tuần, team BI nhận được tin nhắn quen thuộc:

“Sao dashboard doanh thu tháng 9 khác số kế toán tổng hợp vậy? Cùng query mà ra kết quả khác à?”

Không ai trả lời được ngay.
Một người mở lại file cũ, một người check lại query, một người khác mở bảng staging trên warehouse nhưng tất cả đều… giống nhau. Vấn đề là, không ai còn giữ lại bản dữ liệu gốc tại thời điểm báo cáo tháng 9. Rule commission thì vừa được cập nhật tuần trước. Và thế là, câu chuyện audit báo cáo rơi vào vòng lặp: “Chúng ta không biết dữ liệu hồi đó là gì nữa.”

Từ lúc đó, team bắt đầu nhận ra:

Khi team bắt đầu có version control, điều bạn nhận được không chỉ là “an toàn dữ liệu”, mà còn là độ tin cậy. Git.

Dữ liệu cũng cần có lịch sử

Khi nói “version control”, đa phần nghĩ đến GitHub hay GitLab nơi ta commit code, ghi lại lịch sử thay đổi, và có thể quay lại bất kỳ phiên bản nào. Nhưng dữ liệu cũng có “code” của riêng nó chỉ khác ở chỗ, nó sống, thay đổi, và đôi khi tự biến mất.

Hãy tưởng tượng bạn có một bảng sales trong warehouse, được ETL hằng ngày. Một hôm, team accounting yêu cầu cập nhật lại đơn hàng refund từ tháng 8 → và pipeline hôm đó overwrite luôn dữ liệu cũ. Nếu không có snapshot, bạn chẳng còn cách nào tái hiện số liệu tại thời điểm 31/08.
Khi bị audit hoặc cần so sánh giữa các kỳ, bạn hoàn toàn “mù”.

Nói cách khác, dữ liệu cũng cần có trí nhớ và đó là mục đích của version control.

Vậy “version control cho dữ liệu” là gì?

Hiểu đơn giản:

Version control cho dữ liệu là cách lưu trữ, theo dõi và tái tạo lại mọi trạng thái của dữ liệu theo thời gian.

Nó cho phép bạn biết:

• Dữ liệu này được sinh ra khi nào, bởi ai, từ nguồn nào.
• Rule hoặc logic nào được áp dụng tại thời điểm đó.
• Có thể quay lại đúng trạng thái dữ liệu trong quá khứ (để audit hoặc so sánh).

Cũng giống Git cho code, Data Version Control giúp bạn:

• Trace (truy vết): biết thay đổi nào xảy ra, khi nào, vì sao.
• Reproduce (tái hiện): chạy lại pipeline cũ mà ra đúng kết quả cũ.
• Compare (so sánh): thấy được sự khác biệt giữa hai phiên bản dữ liệu.

Tình huống thật: Khi BI bị “mất trí nhớ”

Trong một dự án reconciliation, team BI từng gặp một bài học đau:

• Dữ liệu commission được tính bằng rule “5% cố định” trong SQL.
• Đến tháng sau, Shopee thay đổi rule thành “3% cho order dưới 500k, 6% cho order trên 500k”.

Cả pipeline được chỉnh lại.

• Nhưng khi accounting cần đối chiếu lại số tháng 8 thì rule cũ đã bị ghi đè.
• Không ai còn nhớ giá trị cũ là bao nhiêu, và dashboard cũng hiển thị sai lệch vài trăm triệu.

Sau lần đó, team bắt đầu áp dụng data versioning cho mọi bảng tính toán quan trọng. Mỗi ngày, dữ liệu được snapshot lại, kèm cột snapshot_date. Khi audit, chỉ cần:

SELECT * FROM sales_snapshot WHERE snapshot_date = '2024-08-31';

Là có thể quay về “quá khứ”. Tưởng phức tạp, nhưng chỉ một thay đổi nhỏ như vậy đã cứu team hàng chục giờ reconciliation mỗi tháng.

Cấu trúc của version control trong data team

Để hiểu đúng “version control cho dữ liệu”, hãy chia nó thành ba lớp tương tự ba tầng trong một hệ thống data pipeline:

1. Version control cho code (logic)

Đây là phần dễ nhất:

• Dùng Git cho script SQL, Python, hoặc dbt model.
• Mỗi lần thay đổi logic, commit với message rõ ràng.

Ví dụ:

git commit -m "feat: update commission rate for Shopee >=500k"

Điều này đảm bảo pipeline ETL của bạn có thể được tái hiện (reproduce) tại mọi thời điểm.

2. Version control cho business rule / config

Business thay đổi nhanh và không thể cứ sửa trong code. Cách làm tốt là chuyển rule vào bảng cấu hình có thời gian hiệu lực, ví dụ:

rule_id	platform	rate	effective_date	expiry_date
1	Shopee	0.05	2024-01-01	2024-03-31
2	Shopee	0.06	2024-04-01	null

Bảng này chính là “git log” của business rule. Bạn không cần sửa code, chỉ cần query:

WHERE order_date BETWEEN effective_date AND COALESCE(expiry_date, NOW())

Là tự động áp dụng đúng rule theo thời gian.

3. Version control cho dữ liệu (snapshot)

Phần cốt lõi nhất. Cứ mỗi kỳ (ngày, tuần, tháng), snapshot dữ liệu quan trọng.
Ví dụ:

CREATE TABLE sales_snapshot_20251001 AS SELECT *, CURRENT_DATE AS snapshot_date FROM sales;

Hoặc lưu theo SCD Type 2:

order_id	nmv	valid_from	valid_to	is_current
123	500000	2024-09-01	2024-09-30	FALSE
123	600000	2024-10-01	null	TRUE

Khi có thay đổi, bạn đóng valid_to của bản cũ, insert bản mới.
Vậy là dữ liệu của bạn “có lịch sử”.

Công cụ & cách triển khai thực tế

Tuỳ quy mô team, ta có thể chọn cách khác nhau.

1. Trong data warehouse (Postgres, BigQuery, Snowflake)

• Tạo schema riêng, ví dụ: sales_snapshot hoặc _history.
• Dùng Airflow hoặc dbt snapshot để lưu dữ liệu định kỳ.
• Thêm metadata:

SELECT *, CURRENT_TIMESTAMP AS loaded_at, 'job_name' AS source_job
  FROM staging.sales;

→ Dễ audit, trace lỗi hoặc rollback.

2. Với file (CSV, Excel, Parquet)

Nếu team chưa dùng warehouse phức tạp, có thể:

• Lưu folder theo ngày:

data

├─ raw/2025-10-01/

├─ raw/2025-10-02/

• Hoặc dùng DVC (Data Version Control) — hoạt động như Git cho dữ liệu, lưu metadata và link đến file lớn (Parquet, CSV). Bạn có thể “checkout” lại version cũ của dataset như code.
• Với team Data Lake, có thể dùng LakeFS — cho phép tạo branch dữ liệu, merge hoặc rollback tương tự Git.

3. Trong Power BI hoặc Excel

Không có hệ thống versioning như Git, nhưng có thể:

• Ghi chú version dataset dưới footer dashboard.

“Dataset version: sales_snapshot_2025-10-01”

• Lưu file Power BI theo tên sales_dashboard_v202510.pbix.
• Duy trì folder /dataset/ chứa bản dữ liệu gốc theo ngày.

Ưu điểm và khuyết điểm của việc version hóa dữ liệu

Ưu điểm

1. Audit dễ dàng
   → Có thể chứng minh báo cáo nào dựa trên dữ liệu nào.
   → Giúp passing audit và kiểm toán nhanh hơn.
2. Reproducibility
   → Dù logic thay đổi, bạn vẫn có thể tái hiện kết quả cũ.
3. Transparency
   → Dễ theo dõi ai đã thay đổi gì, ở đâu, khi nào.
4. An toàn khi rollback
   → Lỡ ETL ghi sai, có thể revert nhanh về snapshot trước đó.
5. Nền tảng cho Data Governance
   → Version control là bước đầu tiên của hệ thống data có kiểm soát.

Khuyết điểm

1. Tốn dung lượng lưu trữ
   → Snapshot hàng ngày dễ nhân bản dữ liệu khổng lồ.
   → Giải pháp: chỉ lưu delta hoặc dùng định dạng Parquet để nén.
2. Cần discipline từ team
   → Nếu không có quy trình commit rõ ràng, versioning sẽ lộn xộn như file Excel “final_final2”.
3. Cần công cụ hỗ trợ
   → dbt snapshot, DVC, hoặc LakeFS đều cần setup ban đầu.
   → Với team nhỏ, có thể dùng giải pháp “manual nhưng có nguyên tắc”.

Cách áp dụng cho data team (gợi ý thực hành)

Dưới đây là roadmap đơn giản mà team BI hoặc Data Engineer có thể áp dụng ngay:

Giai đoạn 1: Thiết lập mindset

• Mọi thay đổi về logic hoặc rule đều cần có version note.
• Ghi rõ lý do khi update rule hoặc dataset.
• Không xoá dữ liệu cũ chỉ thêm version mới.

Giai đoạn 2: Chuẩn hoá bảng config

• Tạo bảng dim_commission_rule, dim_brand_mapping, dim_channel_fee có effective_date & expiry_date.
• Tách logic khỏi SQL chính.

Giai đoạn 3: Snapshot dữ liệu định kỳ

• Chọn 3 bảng quan trọng (vd: sales, inventory, commission_summary).
• Tạo job snapshot daily hoặc weekly.
• Lưu thêm metadata (snapshot_date, loaded_by, source_system).

Giai đoạn 4: Tự động hóa version tracking

• Dùng dbt snapshot hoặc Airflow DAG có naming convention:
• sales_snapshot_{{ ds }}.

• Tích hợp Git commit + snapshot id → để trace toàn bộ pipeline.

Giai đoạn 5: Governance & review

• Mỗi tháng, review lại các rule hết hạn.
• Log thay đổi vào changelog BI:

Date	Table	Change	Owner	Ticket
2025-10-01	dim_commission_rule	Update Amazon rate	Viet.Tran	BI-123

Bức tranh lớn hơn: Data Versioning = Data Reliability

Khi team bắt đầu có version control, điều bạn nhận được không chỉ là “an toàn dữ liệu”, mà còn là độ tin cậy.

• Accounting hỏi: “Sao số hôm nay khác hôm qua?”
  → Bạn mở snapshot: “Hôm qua tính theo rule cũ, hôm nay rule mới.”
• Sếp hỏi: “Báo cáo tháng 8 anh dùng lại được không?”
  → Bạn chỉ cần đổi filter snapshot_date = '2024-08-31'.

Không còn cảnh “em nhớ là hôm đó số khác cơ mà”.
Dữ liệu trở nên minh bạch, có lịch sử, và đáng tin.

Đừng để dữ liệu bị mất trí nhớ

Dữ liệu cũng như con người nếu không có trí nhớ, nó chỉ sống được trong hiện tại. Version control giúp dữ liệu của bạn có ký ức: nhớ lại hôm qua, hiểu được hôm nay, và dự đoán ngày mai.

Với team data, đây không phải chuyện “có nên làm hay không”, mà là bước nền để xây dựng một hệ thống BI trưởng thành. Một pipeline có version control là pipeline mà bạn có thể tin tưởng. Và một team data có version control là team có trách nhiệm.

Nếu code có Git, thì data cũng cần “trí nhớ” của riêng mình.
Đó chính là Data Version Control — nơi dữ liệu thôi không chỉ “chạy”, mà bắt đầu “sống có ý nghĩa.”