Tư duy stream — event, input vô tận, xử lý liên tục

TL;DR: Stream processing là xử lý dòng sự kiện vô tận (unbounded) — job không bao giờ dừng, phản hồi từng event ngay khi nó tới. Khác batch (khối hữu hạn, chạy rồi dừng), stream không biết điểm kết thúc nên không thể gom cả khối rồi tính: thay vào đó cần xử lý từng event khi tới, duy trì state liên tục, và đặt window để nhóm sự kiện theo thời gian. Mô hình nền là producer/consumer: producer phát event vào một topic/channel, consumer đọc và xử lý mãi không ngừng. Kết quả bạn tính luôn là bản tạm thời, cập nhật theo event mới — không có "điểm hoàn thành" như batch output.

Batch xử lý tốt cực kỳ khi dữ liệu đã đóng — bạn thấy điều đó ở Module 1. Nhưng không phải mọi bài toán đều chờ được. Ngân hàng cần phát hiện giao dịch gian lận trong vài giây sau khi sự kiện xảy ra, không phải sau khi batch đêm chạy xong. Hệ thống phân tích lưu lượng mạng cần đếm số kết nối bất thường theo thời gian thực, không chờ đến 0 giờ sáng. Những bài toán này có chung một đặc điểm: dữ liệu không bao giờ đóng — sự kiện cứ tới mãi, và bạn cần phản hồi ngay, không phải chờ có đủ khối.

Bài này giải thích tại sao mô hình batch không khớp khi input là dòng vô tận, stream xử lý sự việc khác thế nào (event, producer/consumer, window, state liên tục), và đặt nền để bạn hiểu Kafka và Flink ở các bài sau.

1. Analogy — điều phối viên tổng đài trực

Hãy so sánh hai cách vận hành trung tâm hỗ trợ khách hàng. Cách thứ nhất: thu thập tất cả yêu cầu trong ngày, 11 giờ đêm mới mở ra xử lý một lần — đó là batch. Cách thứ hai: điều phối viên ngồi trực 24/7, cứ có cuộc gọi đến là nhấc máy xử lý ngay — đó là stream.

Điều phối viên stream không biết hôm nay sẽ có bao nhiêu cuộc gọi (input vô tận); không thể "gom hết rồi mới trả lời" (phải xử lý ngay); và phải ghi nhớ context của từng khách hàng đang nói chuyện (duy trì state).

2. Stream là gì — event, producer, consumer

Mọi hệ thống stream đều xoay quanh một đơn vị nhỏ nhất: event (sự kiện). Event là một thực tế đã xảy ra, bất biến, được gắn timestamp: "khách hàng #1402 vừa nhấn thanh toán lúc 14:32:07.831", "cảm biến #77 ghi nhiệt độ 38.4°C lúc 14:32:08.012". Event không bị sửa sau khi phát ra — nó chỉ append vào dòng.

Dòng event này chạy qua mô hình producer/consumer:

flowchart LR
  P1["Producer A<br/>(payment-service)"] -->|"event"| CH["Topic /<br/>Channel"]
  P2["Producer B<br/>(sensor-service)"] -->|"event"| CH
  CH -->|"stream"| C1["Consumer X<br/>(fraud-detector)"]
  CH -->|"stream"| C2["Consumer Y<br/>(analytics)"]

• Producer phát event vào topic (kênh chủ đề). Nhiều producer khác nhau có thể cùng ghi vào một topic.
• Consumer đọc event từ topic và xử lý. Nhiều consumer có thể đọc cùng một topic độc lập — fraud detector và analytics cùng nhận event thanh toán mà không ảnh hưởng nhau.
• Topic/Channel là điểm tách biệt: producer không biết ai đang đọc; consumer không biết ai đang ghi. Producer chạy nhanh hay chậm không ảnh hưởng trực tiếp tới consumer.

Sự tách biệt này là thiết kế chủ đích. Consumer đọc theo tốc độ của mình, có thể bắt kịp hay tụt lại (consumer lag). Khi consumer bị lag, topic giữ lại event để consumer đọc sau — không mất sự kiện. Bạn sẽ thấy Kafka hiện thực hóa ý tưởng này cụ thể ở bài 02 — Log-based broker.

3. Vì sao input vô tận đổi cách xử lý?

Đây là câu hỏi cốt lõi của bài. Batch mạnh vì có điểm kết thúc: sau khi đọc hết khối, bạn có thể sort toàn bộ, gom theo key, tính aggregate trên tập đầy đủ. Stream không có điểm kết thúc — dòng event sẽ còn đến mãi. Điều đó thay đổi ba thứ căn bản.

3.1 Không gom được toàn bộ — phải dùng window

Batch có thể tính "tổng doanh thu tháng 6" vì tháng 6 đã đóng. Stream không thể hỏi "tổng doanh thu từ trước đến nay" mà có ý nghĩa thực tế — con số thay đổi từng giây. Thay vào đó, stream phải giới hạn phạm vi thời gian bằng window: "tổng doanh thu 5 phút vừa qua", "số kết nối mới trong 1 giờ cuối". Window biến câu hỏi vô tận thành câu hỏi hữu hạn tính được.

-- Batch: tinh tren toan bo input (da dong)
total_revenue = sum(all_orders.amount)

-- Stream: phai dung window (vo tan -> co gioi han)
total_revenue_last_5min = sum(events WHERE event_time >= now() - 5min)
-- Window dong moi 5 phut, tinh lai tu dau -> output cap nhat lien tuc

3.2 Phải duy trì state liên tục

Batch tính số lần mỗi IP xuất hiện bằng sort | uniq -c — sort cả khối rồi đếm. Stream không thể sort dòng vô tận. Thay vào đó, consumer duy trì một state trong bộ nhớ: mỗi event đến, cập nhật state tức thì rồi tiếp tục.

-- Consumer dem so lan IP xuat hien (stream, worked example)
state = {}              -- bang dem song song qua toan bo vong doi consumer

on_event(e):
    ip = e.source_ip
    state[ip] = state.get(ip, 0) + 1   -- cap nhat tuc thi
    if state[ip] > THRESHOLD:
        alert("Unusual traffic from " + ip)

-- state khong reset giua cac event -- no song trong suot vong doi consumer

State sống trong suốt vòng đời của consumer — không reset giữa chừng như biến trong batch job. Bài 03 sẽ đào sâu cách giới hạn state theo window để tránh state tích luỹ vô hạn.

3.3 Kết quả luôn là bản tạm thời

Batch output là kết quả hoàn chỉnh tại thời điểm job chạy xong: "top 10 sản phẩm ngày hôm qua" là con số cuối cùng, không đổi. Stream output là kết quả đang diễn ra: "top 10 sản phẩm 1 giờ qua" cập nhật mỗi vài giây khi event mới đến. Không có "xong" — chỉ có "tính tới thời điểm này".

4. Batch vs stream — so sánh trực tiếp

Không có kẻ thắng tuyệt đối — chọn theo bài toán. Báo cáo doanh thu hàng tháng: batch đủ và đơn giản hơn. Phát hiện gian lận trong 3 giây: stream là lựa chọn duy nhất. Nhiều hệ thống thực tế chạy cả hai song song (kiến trúc Lambda/Kappa — Module 3 sẽ bàn).

5. Micro-batch vs true streaming — ranh giới cần biết

Một biến thể phổ biến nằm giữa hai thái cực: micro-batch (Apache Spark Structured Streaming). Thay vì xử lý từng event, micro-batch gom event thành các khối nhỏ (vài trăm mili giây đến vài giây) rồi chạy batch job mini trên đó.

flowchart TD
  STREAM["Event stream (unbounded)"]
  STREAM --> MB["Micro-batch<br/>(gom event, moi 500ms)"]
  STREAM --> TS["True streaming<br/>(xu ly tung event)"]
  MB --> OUT1["Mini batch job<br/>-> output moi 500ms"]
  TS --> OUT2["Output ngay khi event toi<br/>(ms latency)"]

Khi bài này dùng "stream", ý nghĩa rộng bao gồm cả micro-batch — điểm phân biệt là input unbounded và job chạy mãi, không phải chi tiết triển khai từng event hay micro-batch.

6. Pitfall — nhầm stream với batch "chạy nhanh hơn"

❌ SAI — gom event roi chay batch moi phut
   cron job moi phut: doc log -> tinh toan -> ghi ket qua
   => van la batch, khong phai stream.
   => Do tre toi thieu 1 phut (event xay ra ngay sau batch vua chay
      phai cho den luot sau).
   => Khi can < 1 giay, khong dat duoc voi cach nay.

✅ DUNG — consumer chay lien tuc, xu ly event khi toi
   consumer loop:
       event = channel.read()         -- block cho den khi co event
       update_state(event)            -- cap nhat state tuc thi
       if should_alert(state):
           emit_alert()               -- phat canh bao ms sau event
   => Do tre tinh bang ms, khong phai phut.

7. 📚 Deep Dive

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

• Tư duy batch — Module 1: nền đối xứng của bài này — batch bounded vs stream unbounded. Đọc lại "Vì sao input phải bất biến?" và "Derived data" để thấy stream thừa kế triết lý append-only theo cách riêng: event là log chỉ append, không sửa.
• Bài 02 — Log-based broker: Kafka hiện thực hóa mô hình producer/consumer ở bài này. Topic = log append-only; consumer tự giữ offset; nhiều consumer đọc cùng log độc lập — chi tiết kỹ thuật của channel "không mất event khi consumer lag".
• Bài 03 — Windowing: đào sâu các loại window (tumbling/sliding/session), event-time vs processing-time, và watermark — khái niệm giải quyết bài toán "event đến trễ" mà bài này chỉ đề cập sơ qua.
• Bài 04 — Stream join và exactly-once: khi cần ghép hai stream lại và đảm bảo mỗi event chỉ xử lý đúng một lần — xây trực tiếp trên producer/consumer và state liên tục ở bài này.

9. Tóm tắt

• Stream xử lý input unbounded (dòng sự kiện vô tận): job chạy mãi, phản hồi từng event khi tới — không có bước "xong, dừng" như batch.
• Mô hình nền: producer phát event vào topic, consumer đọc và xử lý liên tục; hai bên tách biệt — không biết nhau, không ảnh hưởng tốc độ nhau.
• Input vô tận đổi ba thứ: cần window để nhóm sự kiện (không gom cả khối), duy trì state liên tục (không reset), và kết quả luôn tạm thời (cập nhật theo event mới, không có điểm hoàn thành cố định).
• Batch mạnh khi input bounded (sort/gom toàn bộ, throughput khổng lồ). Stream mạnh khi cần độ trễ thấp (mili giây–giây) với input không bao giờ đóng. Không có kẻ thắng tuyệt đối — chọn theo bài toán; nhiều hệ thống chạy cả hai.
• Micro-batch (Spark) là trung gian: gom event thành batch mini vài trăm ms. True streaming (Flink) xử lý từng event tức thì. Cả hai đều là "stream" theo nghĩa rộng — input unbounded, job chạy mãi.
• Pitfall: coi stream là "batch chạy thường xuyên hơn" — cron mỗi phút vẫn là batch, vẫn có độ trễ 1 phút. Stream thật sự là consumer không dừng, event tới lúc nào xử lý lúc đó.

10. Tự kiểm tra

Bài tiếp theo: Log-based broker — Kafka giữ log và offset cho nhiều consumer