Lambda vs Kappa — hai cách kết hợp batch và stream

TL;DR: Lambda Architecture (Nathan Marz, 2011) kết hợp batch và stream bằng ba lớp: batch layer tính kết quả chính xác từ toàn bộ lịch sử, speed layer bù real-time, serving layer gộp lại để trả query. Cái giá là hai codebase cho cùng một logic — logic drift giữa hai lớp là rủi ro hàng đầu. Kappa Architecture (Jay Kreps, 2014) bỏ batch layer: chỉ stream xử lý event, Kafka long-retention cho phép replay reprocess lịch sử. Đơn giản hơn nhưng tốn storage: 50.000 events/s × 200 bytes ≈ 864 GB/ngày; giữ 90 ngày ≈ 78 TB Kafka hot storage, đắt hơn cold storage khoảng 10 lần. Ở quy mô cực lớn (Uber — hàng triệu trips/ngày, retention dài đạt hàng Petabyte), chi phí này buộc họ giới hạn retention vài ngày, không adopt Kappa đầy đủ.

Hệ thống thống kê của một nền tảng streaming video cần hiển thị hai con số cùng lúc: tổng lượt xem mọi thời đại của mỗi video (độ chính xác tuyệt đối, tính từ log lịch sử hàng TB) và số người đang xem ngay lúc này (cập nhật trong vài giây). Hai yêu cầu đối lập: một cần throughput batch lịch sử, một cần độ trễ stream real-time.

Bạn đã học batch ở Module 1 — input bất biến, idempotent, throughput khổng lồ — và stream ở Module 2 — event, producer/consumer, phản hồi mili giây. Hai thế giới đó giỏi những thứ khác nhau. Câu hỏi kiến trúc tự nhiên khi cần cả hai: kết hợp thế nào? Nathan Marz và Jay Kreps đưa ra hai câu trả lời khác nhau. Bài này so sánh, phân tích cái giá, và giúp bạn lập luận khi nào chọn cái nào.

1. Analogy — phòng mổ, phòng cấp cứu, và bộ hồ sơ số

Hệ thống y tế lớn có hai bộ phận phục vụ cùng một mục tiêu: thông tin về bệnh nhân. Phòng mổ (mổ phiên, đặt lịch) tập hợp đầy đủ bệnh án, chạy phân tích chi tiết, cho kết quả chính xác tuyệt đối — nhưng mất vài giờ. Phòng cấp cứu cần thông tin ngay, chấp nhận xấp xỉ từ vài số đo gần nhất, phản hồi trong vài phút. Bảng điều phối ở đầu dãy nhà gộp kết quả của cả hai: khi phòng mổ trả về kết quả đầy đủ, nó thay thế xấp xỉ của cấp cứu.

Lambda là hệ thống y tế đó. Kappa là quyết định táo bạo hơn: đặt cả phòng mổ vào trong phòng cấp cứu — dùng một quy trình duy nhất cho mọi ca, và giữ toàn bộ bộ hồ sơ số (Kafka log) đủ lâu để khi cần phân tích kỹ, chạy lại từ đầu.

2. Lambda Architecture — ba lớp song song

2.1 Cấu trúc ba lớp

Nathan Marz đề xuất Lambda Architecture năm 2011 trong bài "How to beat the CAP theorem", xây trên nền immutable master dataset — log sự kiện chỉ append, không bao giờ bị sửa (bạn đã thấy tư duy này ở Tư duy batch — Module 1).

flowchart TB
  SRC["Raw events<br/>(immutable log)"]

  subgraph BATCH["Batch Layer (Spark / Hadoop)"]
    BL["Recompute tat ca tu dau<br/>moi N gio den ngay"]
    BV["Batch views<br/>(chinh xac, day du lich su)"]
    BL --> BV
  end

  subgraph SPEED["Speed Layer (Flink / Storm)"]
    SL["Process event real-time<br/>chi tinh du lieu moi"]
    SV["Speed views<br/>(xap xi, chi window gan nhat)"]
    SL --> SV
  end

  subgraph SERVING["Serving Layer"]
    MV["Merge: batch view + speed view<br/>-> tra loi query"]
  end

  SRC --> BL
  SRC --> SL
  BV --> MV
  SV --> MV
  MV --> QUERY["Query / API"]

Ba lớp phân vai rõ:

• Batch layer: đọc toàn bộ log lịch sử từ đầu, tính lại kết quả hoàn chỉnh định kỳ — mỗi vài giờ hoặc mỗi ngày. Kết quả là batch view — chính xác tuyệt đối nhưng cũ theo chu kỳ recompute.
• Speed layer: xử lý event real-time chỉ cho khoảng thời gian chưa có trong batch view mới nhất. Kết quả là speed view — có thể xấp xỉ, nhưng nhanh (giây đến phút).
• Serving layer: khi nhận query, gộp batch view + speed view. Khi batch view mới được tính xong, speed view của window đó trở nên thừa và bị loại bỏ — batch đã phủ đầy đủ.

2.2 Ví dụ worked — đếm lượt xem video

Hệ thống video muốn trả "tổng lượt xem của video X tính đến thời điểm này". Lambda triển khai như sau:

-- Batch layer (chay moi 1 gio, doc tu dau den 1h truoc)
batch_view["video_total_views"] =
    read_all_events("view_events/")
        .filter(e -> e.type = "view")
        .group_by(e -> e.video_id)
        .count()

-- Speed layer (chay lien tuc, chi doc event tu 1h truoc den hien tai)
speed_view["video_recent_views"] =
    stream("view_events")
        .filter(e -> e.type = "view")
        .group_by(e -> e.video_id)
        .count_in_window("1h")

-- Serving layer (khi co query cho video X)
total_views(video_id) =
    batch_view[video_id]        -- chinh xac den 1h truoc
    + speed_view[video_id]      -- gan dung 1h vua qua

Mỗi giờ, khi batch job hoàn thành, speed view cho giờ đó trở nên thừa — batch đã tính chính xác rồi, speed view bị gỡ bỏ.

3. Cái giá của Lambda — hai codebase, một kết quả

Điểm đau thực tế nhất của Lambda: tính "lượt xem video X" phải được implement hai lần:

• Batch layer: Spark/Python, đọc file Parquet, tính offline.
• Speed layer: Flink/Java, đọc Kafka stream, tính real-time.

Cùng một kết quả logic, hai codebase, hai ngôn ngữ, hai framework, hai đội on-call.

Faded step — thực hành phân tích logic drift:

Một team dùng Lambda tính "tổng doanh thu theo quốc gia". Sau 6 tháng, họ phát hiện batch view và speed view lệch nhau khoảng 3% cho cùng ngày.

Ba nguyên nhân team đó tìm ra: (a) batch dùng tỷ giá snapshot 00:00 UTC, speed dùng tỷ giá real-time khi event tới → lệch khi tỷ giá biến động trong ngày; (b) batch đọc toàn bộ event kể cả late-arrival lên tới 30 phút, speed bỏ event tới sau 5 phút → lệch ở những ngày nhiều event trễ; (c) batch tính theo ngày UTC, speed tính theo ngày local của user → lệch ở timezone xa UTC. Cả ba lỗi đều thuần logic — đúng loại lỗi không xuất hiện nếu chỉ có một codebase.

4. Kappa Architecture — bỏ batch, chỉ stream và replay

Jay Kreps đặt câu hỏi trực tiếp trong "Questioning the Lambda Architecture" (O'Reilly, 2014): nếu stream engine đủ mạnh để tính kết quả real-time, tại sao không dùng stream để tính cả kết quả lịch sử bằng cách replay log từ đầu?

Ý tưởng cốt lõi của Kappa: không cần batch layer riêng. Khi cần "recompute từ đầu", bạn chạy consumer stream version mới trên Kafka log từ offset 0 — đó chính là batch job, chỉ dùng đúng engine stream, một codebase.

flowchart TB
  SRC["Raw events<br/>(append-only)"]

  subgraph KAFKA["Kafka (long-retention log)"]
    LOG["Log luu tru du lau<br/>(30-90 ngay) de reprocess"]
  end

  subgraph STREAM["Stream Processing (Flink / Kafka Streams)"]
    V1["Consumer v1 (hien tai)<br/>dang serving"]
    V2["Consumer v2 (version moi)<br/>replay tu offset 0"]
  end

  subgraph SERVING["Serving Layer"]
    VIEW["Materialized view<br/>(tu stream v1)"]
    VIEW2["View moi (dang build)<br/>chay song song"]
  end

  SRC --> LOG
  LOG --> V1
  LOG -->|"replay tu dau"| V2
  V1 --> VIEW
  V2 --> VIEW2
  VIEW2 -.->|"cutover khi v2 bat kip"| VIEW

Luồng reprocess trong Kappa:

1. Phát hiện bug trong logic tính (vd fix currency conversion): viết consumer version 2.
2. Chạy consumer v2 song song v1, replay từ offset 0 của Kafka log — v2 "đuổi" v1 theo thời gian vì đọc từ log đã có sẵn.
3. Khi v2 đã xử lý hết log cũ và bắt kịp real-time, cutover: chuyển query sang view của v2, dừng v1.
4. Chỉ có một codebase — v2 thay v1 hoàn toàn, không song song vĩnh viễn. Logic drift biến mất vì không còn hai codebase.

4.1 Kafka retention — nút thắt cổ chai của Kappa

Kafka phải giữ log đủ lâu để reprocess lại lịch sử xa. Chi phí thực tế:

Giả sử hệ thống nhận 50.000 events/giây, mỗi event 200 bytes (JSON nhỏ sau nén):

• Lưu lượng/ngày: 50.000 × 200 bytes × 86.400 giây ≈ 864 GB/ngày
• Giữ 30 ngày (phổ biến trong tài liệu Kappa): 864 × 30 ≈ 26 TB
• Giữ 90 ngày (để reprocess xa): 864 × 90 ≈ 78 TB

Kafka hot storage (SSD trên broker cluster) đắt hơn cold storage (S3, GCS) khoảng 10 lần. 78 TB Kafka hot tương đương chi phí của khoảng 780 TB S3.

Faded step — tính toán retention cost:

Kết quả: 20.000 × 500 × 86.400 ≈ 864 GB/ngày — đúng bằng ví dụ 50k×200B vì tích events×bytes/event bằng nhau (20.000×500 = 50.000×200 = 10 MB/s). Giữ 60 ngày: 864 × 60 ≈ 52 TB. Hệ này ít hơn ví dụ 90 ngày (78 TB) nhưng nhiều hơn 30 ngày (26 TB). Bài học: retention days quan trọng hơn sự chênh lệch events/s khi tích events×bytes bằng nhau.

Đây là lý do Uber — một trong những tổ chức dùng Kafka quy mô lớn nhất — giới hạn Kafka retention chỉ vài ngày và không adopt Kappa đầy đủ. Ở quy mô hàng triệu trips/ngày với metadata phong phú, hot storage 30–90 ngày sẽ đạt hàng Petabyte.

5. Lambda vs Kappa — khi nào chọn cái nào?

Hai câu hỏi để chọn:

Câu 1 — Reprocess cần xa bao nhiêu ngày? Nếu cần recompute lại 5 năm log → Kafka retention 5 năm là bất khả thi về chi phí → Lambda (batch layer đọc từ cold storage S3). Nếu 30–90 ngày đủ → Kappa khả thi. Kết hợp Kafka tiered storage (hot 30 ngày + cold S3 tự động) giảm chi phí Kappa đáng kể.

Câu 2 — Batch logic có thể express bằng stream không? Nếu batch dùng full global sort, iterative ML training, hoặc join phức tạp trên toàn bộ lịch sử → khó stream hoá → Lambda. Nếu mọi tính toán express được bằng windowed stream ops và stateful aggregation → Kappa.

6. Pitfall — hai lỗi ngược chiều

6.1 Lambda: codebase drift âm thầm

❌ SAI — 2 codebase, logic diverge theo thoi gian
   Batch (Spark/Python): sum(revenue * exchange_rate_00h_utc)
   Speed (Flink/Java):   sum(revenue * exchange_rate_realtime)
   => Cung mot ngay, 2 con so lech 2-5%.
   => Ai dung? Khong ai biet. Debug mat nhieu gio.
   => On-call nhan doi: phai hieu ca Spark va Flink de trace.

✅ DUNG — hoac Kappa (1 codebase), hoac Lambda voi Apache Beam
   Apache Beam: viet pipeline logic 1 lan,
   Beam runner tu sinh batch job (Spark) va stream job (Flink)
   tu cung mot pipeline definition.
   => 1 logic, 2 mode, khong drift.

6.2 Kappa: retention cạn khi cần reprocess xa

❌ SAI — retention 7 ngay, phat hien bug tu 25 ngay truoc
   Kafka retention chi giu 7 ngay -> mat log co.
   Khong the reprocess chinh xac 25 ngay truoc.
   Phai doc tu cold storage (S3) -> bat buoc viet batch job
   -> quay lai Lambda-like, mat loi the Kappa.

✅ DUNG — dimensioning retention theo reprocess window thuc te
   1. Xac dinh: reprocess xa nhat bao nhieu ngay? (30-90 la pho bien)
   2. Dat retention >= window do.
   3. Cost qua cao? Dung Kafka tiered storage (hot 30 ngay + cold S3 tu dong).
   4. Reprocess window > 6 thang? Cân nhac Lambda thay Kappa.

7. 📚 Deep Dive

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

• Tư duy batch — Module 1: nền của Lambda batch layer — input bất biến, idempotent, reprocess từ nguồn. Batch layer trong Lambda là một batch job đúng nghĩa này, chỉ chạy định kỳ thay vì một lần.
• Tư duy stream — Module 2: nền của speed layer (Lambda) và toàn bộ Kappa. Producer/consumer model, unbounded input, state liên tục — đặc biệt phần "Kết quả luôn là bản tạm thời" giải thích tại sao speed view trong Lambda cần được thay bởi batch view khi batch chạy xong.
• Bài 01 — CDC: trong thực tế Lambda/Kappa, CDC thường là nguồn event vào Kafka. Debezium đọc WAL → Kafka topic → Lambda/Kappa pipeline tiêu thụ. Hiểu CDC giúp thiết kế nguồn dữ liệu cho cả hai kiến trúc.
• Bài 05 — Capstone đồ án: lab tổng hợp toàn module. Chọn Lambda hay Kappa và justify tại sao là một phần của đồ án — nơi bạn áp dụng bộ câu hỏi hai trục ở bài này vào bài toán cụ thể.

9. Tóm tắt

• Lambda Architecture (Marz, 2011): batch layer (chính xác, chậm) + speed layer (nhanh, xấp xỉ) + serving layer gộp. Giải quyết "cần cả hai", nhưng phải duy trì 2 codebase cho cùng một logic.
• Logic drift là rủi ro hàng đầu Lambda: hai framework khác nhau diverge theo thời gian → batch view và speed view lệch nhau cho cùng window. Fix: Apache Beam (một pipeline, hai mode).
• Kappa Architecture (Kreps, 2014): bỏ batch layer, chỉ stream + Kafka long-retention. Reprocess = consumer version mới replay từ offset 0, chạy song song v1, cutover khi bắt kịp. Một codebase, đơn giản hơn.
• Chi phí Kappa: 50.000 events/s × 200 B ≈ 864 GB/ngày; giữ 90 ngày ≈ 78 TB Kafka hot storage (đắt hơn cold ~10 lần). Uber (quy mô hàng triệu trips/ngày → hàng Petabyte) giới hạn retention vài ngày vì cost — không adopt Kappa đầy đủ.
• Chọn Lambda khi reprocess cần xa hơn retention khả thi, hoặc batch logic phức tạp không thể express bằng stream.
• Chọn Kappa khi retention 30–90 ngày đủ cho reprocess window, stream engine đủ mạnh, và muốn giảm complexity vận hành.

10. Tự kiểm tra

Bài tiếp theo: Capstone đồ án — thiết kế hệ dữ liệu phái sinh đầu-cuối