Tư duy batch processing — input bất biến, output phái sinh

TL;DR: Batch processing là xử lý một khối dữ liệu kích thước cố định (bounded) thành output mới — chạy tới khi xong rồi dừng, khác stream xử lý dòng sự kiện vô tận. Nguyên tắc nền là input bất biến, output phái sinh: job chỉ đọc dữ liệu gốc, không sửa, và ghi kết quả ra nơi khác. Nhờ vậy chạy lại luôn an toàn (idempotent), lỗi thì dựng lại từ nguồn — không có trạng thái nửa vời để dọn. Mẫu pipe của Unix (mỗi tool một việc, nối nhau qua giao diện đồng nhất là dòng text) chính là hình mẫu thu nhỏ của MapReduce/Spark ở bài sau.

Mỗi đêm, một sàn thương mại điện tử dựng lại bảng "sản phẩm bán chạy 24h" từ khoảng 40 triệu dòng log đơn hàng trong ngày. Google thì chạy pipeline dựng chỉ mục (indexing) xử lý ~20 TB tài liệu đã crawl mỗi lượt để tạo chỉ mục tìm kiếm. Hai việc này có độ trễ cao — tính bằng phút tới giờ — nhưng đó không phải điểm yếu cần sửa: chúng đánh đổi độ trễ lấy throughput khổng lồ và tính đơn giản.

Điều làm chúng đơn giản không phải công cụ, mà là một kỷ luật: dữ liệu gốc (log, HTML) không bao giờ bị sửa, và mọi thứ job sinh ra (bảng xếp hạng, chỉ mục) đều là bản phái sinh có thể vứt đi rồi dựng lại. Bài này giải thích vì sao kỷ luật "input bất biến → output phái sinh" là hạt nhân của mọi hệ batch, và vì sao nó bắt nguồn từ cách Unix nối các lệnh nhỏ qua pipe.

1. Analogy — nhà máy chế biến theo lô

Một nhà máy nước ép nhận vào một lô trái cây đã cân đong sẵn cho ca sản xuất. Trong suốt ca, không ai đổ thêm hay rút bớt trái khỏi lô đó — lô là cố định. Dây chuyền chạy: rửa → ép → lọc → đóng chai, mỗi trạm làm đúng một việc rồi đẩy sang trạm sau. Sản phẩm ra là mẻ nước ép mới; đống vỏ và bã là phụ phẩm — không ai lấy nước ép "trộn ngược" vào lô trái cây ban đầu.

Nếu mẻ nước ép bị lỗi (nêm sai tỉ lệ), bạn không mất gì ở nguyên liệu: lô trái cây vẫn còn nguyên (nếu giữ lạnh), chỉnh công thức rồi ép lại. Đây chính là batch: lô nguyên liệu = input bất biến, dây chuyền = pipeline, mẻ nước = output phái sinh.

2. Batch là gì — bounded input, chạy rồi dừng

Hình dung hai kiểu bài toán. Một: "tính doanh thu tháng 6" — dữ liệu tháng 6 là một khối hữu hạn, đã đóng, bạn biết chính xác điểm bắt đầu và kết thúc. Hai: "hiện số đơn hàng đang tăng theo thời gian thực" — dữ liệu là một dòng không bao giờ dứt.

Kiểu một là batch: input bounded (biết biên), job đọc hết khối đó, tính ra kết quả, rồi kết thúc. Kiểu hai là stream (Module 2): input unbounded, job chạy mãi, xử lý từng sự kiện khi nó tới.

Vì input đã đóng, batch được tự do sắp xếp lại công việc cho hiệu quả: đọc tuần tự cả khối (throughput đĩa cao nhất), sort toàn bộ, chia cho nghìn máy. Đó là lý do batch nuốt được TB–PB dữ liệu mà stream khó theo kịp — đổi lại là độ trễ.

3. Vì sao input phải bất biến?

Đây là hạt nhân của tư duy batch. Một job batch tuân hai quy tắc: (1) chỉ đọc input, không bao giờ sửa nó; (2) ghi kết quả ra một nơi khác.

flowchart LR
  SRC["Source of truth<br/>(input BAT BIEN)"] -->|"chi doc"| JOB["Batch job"]
  JOB -->|"ghi ra noi khac"| OUT["Derived data<br/>(output PHAI SINH)"]
  OUT -.->|"hong? xoa sach"| REBUILD["Chay lai job"]
  SRC -->|"input van nguyen"| REBUILD
  REBUILD --> OUT

Nghe hiển nhiên, nhưng bốn hệ quả của nó là toàn bộ sức mạnh của batch:

• Chạy lại an toàn (idempotent). Job chết giữa chừng? Chạy lại từ đầu — vì input không đổi, lần chạy lại cho đúng kết quả như chưa từng lỗi. Điều kiện đi kèm: output của lần hỏng phải bị vứt/ghi đè toàn phần khi chạy lại (framework batch tự bỏ output của task lỗi), không được append thêm — nếu không sẽ ra kết quả nhân đôi. Nhờ đó không còn "trạng thái nửa vời" để dọn dẹp.
• Reprocess cả lịch sử. Phát hiện công thức tính sai từ ba tháng trước? Vì log gốc còn nguyên, sửa code rồi chạy lại trên đúng dữ liệu cũ — dựng lại toàn bộ output đúng. Nếu bạn đã ghi đè input, dữ liệu cũ mất, không sửa lại được.
• Debug bằng tái lập. Output tháng trước trông lạ? Chạy lại job trên input y hệt, quan sát. Input bất biến biến "bug production" thành thứ tái lập được — thứ xa xỉ trong hệ mutable.
• Tách nguồn-sự-thật khỏi phái sinh. Input là source of truth (sự thật gốc); mọi output là derived data (phái sinh) — bản sao dẫn xuất, luôn dựng lại được. Ranh giới này cho phép thử nghiệm thoải mái: chạy job mới, ghi ra output mới, so sánh, mà không rủi ro gì cho dữ liệu gốc.

4. Triết lý Unix — pipe và giao diện đồng nhất

Tư duy này không mới. Nó có từ Unix thập niên 1970, trong một dòng lệnh mà mọi kỹ sư đều từng gõ. Giả sử bạn có file log web access.log, muốn tìm 5 địa chỉ IP gọi nhiều nhất:

# Tim 5 IP goi nhieu nhat trong access.log
cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head -5

Chuỗi này chạy như một pipeline batch thu nhỏ:

• cut -d' ' -f1 — lấy cột đầu (IP) của mỗi dòng. Đọc từ input, ghi ra output.
• sort — gom các IP giống nhau về cạnh nhau (chuẩn bị cho đếm).
• uniq -c — đếm số lần lặp mỗi IP liền kề.
• sort -rn — sắp giảm dần theo số đếm.
• head -5 — lấy 5 dòng đầu.

Access.log (BAT BIEN)
   |
   v  cut     -> stream cac IP
   v  sort    -> IP da gom nhom
   v  uniq -c -> "<count> <IP>"
   v  sort -rn-> xep giam dan
   v  head -5 -> top 5
   v
Ket qua (PHAI SINH) — access.log KHONG doi

Hai đặc điểm ở đây là toàn bộ DNA của batch:

• Mỗi công cụ làm đúng một việc và làm tốt. sort chỉ biết sắp xếp — kể cả sắp file lớn hơn RAM (nó tự chia chunk, sort, trộn — chính là external sort bạn sẽ recall ở bài sau).
• Giao diện đồng nhất (uniform interface): mọi công cụ đọc dòng text từ đầu vào, ghi dòng text ra đầu ra. Nhờ một giao diện chung, bất kỳ tool nào cũng nối được với bất kỳ tool nào qua | (pipe) — không cần biết nhau. access.log không hề bị sửa; kết quả là dữ liệu mới.

Doug McIlroy, cha đẻ Unix pipe, gói triết lý này thành: "viết chương trình làm một việc và làm tốt; viết chương trình để phối hợp với nhau; xử lý dòng text, vì đó là giao diện phổ quát." MapReduce ở bài sau chỉ là công thức này phóng to: map giống cut (biến đổi từng dòng), shuffle giống sort (gom theo key), reduce giống uniq -c (tổng hợp mỗi nhóm) — nhưng chạy trên nghìn máy thay vì một terminal.

5. Derived data — thứ luôn dựng lại được

Khi input là source of truth bất biến, mọi thứ khác trong hệ trở thành derived data: chỉ mục tìm kiếm, cache, bảng tổng hợp, báo cáo, materialized view. Đặc tính chung của chúng: mất cũng không sao — vì luôn tính lại được từ nguồn.

Phân biệt này cởi trói cho thiết kế. Muốn đổi cấu trúc chỉ mục tìm kiếm? Đừng migrate tại chỗ đầy rủi ro — chạy một batch job dựng chỉ mục mới hoàn toàn từ dữ liệu gốc, kiểm tra, rồi chuyển sang. Muốn thử một cách tính báo cáo khác? Ghi ra một bảng output khác, so sánh song song. Vì derived data rẻ và tái tạo được, bạn thử nghiệm mà không sợ hỏng sự thật gốc.

6. Áp dụng — hình dạng một batch job

Gộp cả ba nguyên tắc — đọc nguồn read-only, ghi ra nơi khác, tính lại được — vào khung một job cụ thể. Đây là hình dạng bạn sẽ lặp lại ở mọi bài sau:

# Batch job "top san pham ban chay theo ngay"
job DailyTopProducts(date):
    src    <- read_only("orders/" + date + "/")   # NGUON: bat bien, chi doc
    ranked <- src
                .filter(o -> o.status = "PAID")    # loc
                .group_by(o -> o.product_id)       # gom theo key
                .count()                           # tong hop moi nhom
                .sort_desc()                       # xep giam dan
    write("reports/top_products/" + date + "/", ranked)   # OUTPUT: noi KHAC
    # orders/<date> khong doi -> chay lai bao nhieu lan cung ra dung ket qua

Ba dòng khớp đúng ba nguyên tắc: read_only trên orders/ (input bất biến), write ra reports/ tách biệt (output phái sinh), và vì hai điều đó, chạy lại DailyTopProducts("2026-07-08") bao nhiêu lần cũng ra cùng kết quả (idempotent). Đổi công thức count() thành tổng tiền? Sửa code rồi chạy lại trên đúng orders/ cũ — không đụng gì tới nguồn. Để ý cả luồng: filter + trích key product_id chính là map, group_by là shuffle (gom theo key), count là reduce — khung map → shuffle → reduce của bài sau, chỉ chưa phân tán.

7. Pitfall — ghi đè dữ liệu gốc

❌ SAI — pipeline mutable
   doc orders -> tinh toan -> GHI DE ket qua len chinh bang orders
   => du lieu goc mat. Sua cong thuc? Khong con input cu de chay lai.
   => job chet giua chung? Mot phan bang da bi sua, phan khac chua -> hong.

✅ DUNG — input bat bien
   doc orders (read-only) -> tinh toan -> ghi ra bang orders_summary MOI
   => orders con nguyen. Chay lai bao nhieu lan cung ra dung ket qua.

8. 📚 Deep Dive

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

• Bài 02 — MapReduce: mô hình map → shuffle → reduce chính là dòng lệnh cut | sort | uniq ở bài này phóng to ra cả cluster — shuffle là bước sort chạy phân tán.
• Bài 03 — Join trong batch: khi cần ghép hai khối dữ liệu bất biến, ta lại dựa vào sort — nối thẳng tư duy pipeline ở đây.
• Bài 05 — Thiết kế batch pipeline: lab tổng hợp, nơi bạn tự dựng chuỗi nhiều job trên nguyên tắc input bất biến → output phái sinh.
• Module 2 — Xử lý stream (bài sau): mặt còn lại — khi input là dòng vô tận thay vì khối cố định, kỷ luật bất biến biến thành "log sự kiện chỉ append".

10. Tóm tắt

• Batch xử lý input bounded (khối hữu hạn, biết điểm cuối): chạy → xong → dừng. Đổi độ trễ cao lấy throughput khổng lồ. Stream (Module 2) xử lý input unbounded.
• Hạt nhân: input bất biến, output phái sinh. Job chỉ đọc dữ liệu gốc, ghi kết quả ra nơi khác.
• Bốn hệ quả: chạy lại an toàn (idempotent), reprocess cả lịch sử khi sửa bug, debug bằng tái lập, và tách source of truth khỏi derived data.
• Triết lý Unix: mỗi tool một việc + nối qua pipe + giao diện đồng nhất (dòng text). cut | sort | uniq -c | sort -rn | head là một pipeline batch thu nhỏ — và là khuôn của MapReduce.
• Derived data (index, cache, report) luôn dựng lại được từ nguồn → thử nghiệm/đổi cấu trúc mà không rủi ro sự thật gốc.
• Anti-pattern: ghi đè input (in-place update) → mất reprocess, mất idempotent, để lại dữ liệu hỏng-một-nửa khi job chết. Luôn ghi output ra nơi tách biệt.

11. Tự kiểm tra

Bài tiếp theo: MapReduce — map, shuffle, reduce trên nghìn máy