# Batch, streaming hay realtime: hỏi khách điều gì hỏng nếu dữ liệu đến muộn

> Khi khách đòi “phải realtime”, việc đầu tiên FDE nên làm là hỏi lại một câu, chưa phải ngồi dựng pipeline.

Bản gốc: https://fdetimes.net/vi/bach-khoa/batch-streaming-hay-realtime/

Buổi họp thứ hai tại khách hàng, giám đốc vận hành chốt một câu mà FDE nào cũng từng nghe: “Dashboard này phải realtime.” Nếu bạn gật đầu rồi về dựng một pipeline streaming, bạn đã tự ôm về một hệ thống phải chạy suốt ngày đêm, trong khi nhu cầu thật có khi chỉ là cập nhật mỗi giờ.

Chọn sai độ mới của dữ liệu là một trong những lỗi scoping âm thầm nhất. Nó không làm demo thất bại. Nó làm hệ thống đắt hơn, khó vận hành hơn, và khi bạn rời site thì đội của khách phải gánh phần phức tạp đó.

Kỹ năng cần luyện ở đây không nằm ở công cụ. Nó nằm ở chỗ bạn biết hỏi gì để biến chữ “realtime” thành một con số, rồi chọn kiến trúc rẻ nhất vẫn đáp ứng được con số ấy.

## Năm thứ khách hay gọi chung là “realtime”

Đầu tiên là batch. AWS định nghĩa batch processing là cách máy tính định kỳ xử lý những job dữ liệu khối lượng lớn, lặp đi lặp lại. Batch cần rất ít người can thiệp, và hệ thống xử lý lượng lớn dữ liệu theo thứ tự tuần tự.

Batch còn có lợi thế về chi phí. AWS lưu ý job batch có thể chạy trên năng lực tính toán dư thừa, chẳng hạn Spot Instances với mức giảm giá tới 90%. Job ETL chạy lúc nửa đêm là ví dụ quen thuộc.

Micro-batch vẫn là batch, chỉ chạy dày hơn, vài phút một lần. Blog kỹ thuật Data Lakehouse Hub nhận xét cách này giữ được phần lớn giá trị của streaming mà vẫn đơn giản như batch. Giới hạn của nó là không xuống được mức dưới một giây.

Thứ ba là giao tiếp đồng bộ, chẳng hạn một lời gọi API chờ kết quả trả về. Theo định nghĩa của Guru, giao tiếp đồng bộ diễn ra theo thời gian thực: các bên cùng có mặt và phản hồi ngay lập tức. Đây thường là thứ người dùng thật sự nghĩ đến khi nói “realtime” cho một thao tác cụ thể.

Thứ tư là message queue. AWS mô tả queue là kiểu giao tiếp bất đồng bộ giữa các service, dùng để tách phần xử lý nặng ra khỏi luồng chính và để đệm hoặc gom việc lại. Bất đồng bộ nghĩa là phản hồi có thể đến muộn, và khác biệt cốt lõi với giao tiếp đồng bộ nằm ở thời điểm.

Cuối cùng là streaming, xử lý dữ liệu liên tục khi nó chảy vào. Cái giá cũng nằm ở chữ “liên tục”: job streaming chạy suốt ngày đêm và vẫn tốn tài nguyên trong những giờ dữ liệu thưa thớt. TDWI chỉ ra rằng phần compute vốn nằm nghỉ giữa các lần chạy batch thì trong kiến trúc streaming lúc nào cũng bật.

## Vì sao “realtime” thường chỉ là “mỗi giờ”

Data Lakehouse Hub viết thẳng rằng phần lớn yêu cầu “cần real-time” thực ra là “cần theo giờ” hoặc “cần mỗi 5 phút”. Khách không nói dối. Với người làm nghiệp vụ, “realtime” thường chỉ có nghĩa là “mới hơn bản báo cáo sáng hôm qua đang phải đọc”.

Cũng nguồn này đặt ngưỡng cho streaming: chỉ chọn khi độ trễ được tính bằng giây và dữ liệu cũ gây thiệt hại lớn. TDWI nói theo cách khác: streaming chỉ xứng với độ phức tạp của nó khi khoảng trễ được loại bỏ có giá trị nghiệp vụ thật.

**Điểm mấu chốt:** Đừng hỏi “có stream được không”, hãy hỏi “điều gì hỏng nếu dữ liệu đến muộn”.

Đó là câu hỏi TDWI khuyên đặt ra trước khi chọn streaming. Với FDE, đây là công cụ discovery hiệu quả nhất trong chủ đề này, vì nó kéo cuộc nói chuyện từ công nghệ về hậu quả, thứ mà khách hiểu rõ hơn bạn.

## Một cuộc hội thoại mẫu

Thử hình dung một công ty phân phối hàng tiêu dùng muốn “một nền tảng dữ liệu realtime”. Thay vì bàn kiến trúc, bạn tách yêu cầu thành từng use case rồi hỏi cùng một câu cho từng cái.

**FDE:** Với dashboard tồn kho của quản lý vùng, nếu số liệu trễ một tiếng thì chuyện gì xảy ra?

**Quản lý vùng:** Không sao cả. Sáng và đầu giờ chiều mới có người mở ra xem để lên kế hoạch xe.

**FDE:** Còn cảnh báo đơn hàng bất thường, ví dụ một đại lý đặt gấp mười lần bình thường?

**Trưởng phòng rủi ro:** Cái đó cần nhanh, nhưng phòng rủi ro xử lý thủ công. Trong 10 phút là ổn.

**FDE:** Còn trạng thái thanh toán khi tài xế giao hàng và thu tiền tại cửa hàng thì sao?

**Trưởng nhóm vận hành:** Tài xế phải biết ngay giao dịch thành công hay chưa rồi mới đi tiếp.

Ba câu trả lời cho ba mức độ mới rất khác nhau. Ghi lại thành bảng là bạn có bản scoping đầu tiên:

| Use case | Điều gì hỏng nếu trễ | Độ trễ chịu được | Lựa chọn hợp lý |
|---|---|---|---|
| Dashboard tồn kho | Gần như không gì, người dùng xem 2 lần/ngày | 1 giờ | Batch theo giờ |
| Cảnh báo đơn bất thường | Xử lý chậm một đơn rủi ro | 10 phút | Micro-batch 5 phút |
| Xác nhận thanh toán | Tài xế đứng chờ, giao dịch treo | Vài giây | Gọi API đồng bộ, đẩy phần xử lý nặng vào queue |

Nhìn lại bảng, cả ba dòng đều không cần một pipeline streaming đầy đủ. Ngay cả trường hợp gấp nhất cũng chỉ cần một lời gọi đồng bộ trả kết quả ngay, còn phần ghi sổ, đối soát và phân tích có thể đi qua queue để xử lý sau.

Yêu cầu “nền tảng realtime” ban đầu hóa ra là ba hệ thống nhỏ, mỗi cái rẻ và dễ vận hành hơn nhiều.

## Tự làm tại site khách

Bước đầu tiên là liệt kê từng quyết định sẽ dùng dữ liệu, chứ không phải từng nguồn dữ liệu. Một bảng dữ liệu có thể phục vụ ba quyết định với ba mức độ trễ khác nhau.

Tiếp theo, với mỗi quyết định, hỏi người thật sự đưa ra quyết định đó: họ xem số liệu lúc nào, bao lâu một lần, và nếu số trễ thì điều gì hỏng. Đổi câu trả lời thành một con số cụ thể như “1 giờ”, “5 phút”, “2 giây”, rồi xin họ xác nhận bằng văn bản.

Sau đó chọn mức đơn giản nhất đáp ứng được con số ấy, theo thứ tự batch, micro-batch, queue, rồi mới tới streaming.

Data Lakehouse Hub khuyên chỉ nâng cấp khi có lý do chính đáng, nên bạn hãy ghi rõ điều kiện nâng cấp, chẳng hạn “nếu tỷ lệ đơn rủi ro bị xử lý muộn vượt ngưỡng X thì chuyển sang streaming”.

Có dòng điều kiện đó, vài tháng sau hai bên chỉ cần nhìn số liệu để quyết định có nâng cấp hay không, thay vì tranh luận lại từ đầu.

## Những lỗi hay gặp

Lỗi phổ biến nhất là hỏi người mua thay vì hỏi người dùng. Người ký hợp đồng dễ muốn “realtime” vì nghe hiện đại, còn người mở dashboard mỗi sáng mới biết họ thật sự cần gì.

Lỗi thứ hai là để một use case gấp quyết định kiến trúc cho mọi thứ. Chỉ một luồng cần trả lời trong vài giây không có nghĩa là toàn bộ nền tảng phải stream. Hãy tách nó ra và giữ phần còn lại ở batch.

Lỗi thứ ba là quên chi phí vận hành sau khi bàn giao. Một job streaming chạy liên tục cần người trực, cần giám sát và tiêu tài nguyên cả lúc nửa đêm. Nếu đội của khách chưa từng vận hành hệ thống như vậy, bạn đang để lại cho họ một món nợ.

## Trả lời câu hỏi phỏng vấn “khách đòi realtime” ra sao?

Đây là dạng câu hỏi tình huống rất hợp để luyện trước buổi phỏng vấn FDE: “Khách nói dashboard phải realtime. Bạn làm gì trong tuần đầu?”

Một câu trả lời tốt đi theo đúng trình tự ở trên. Bạn tách yêu cầu thành từng quyết định, hỏi người dùng thật “điều gì hỏng nếu số liệu trễ”, chốt mỗi use case bằng một con số độ trễ, chọn mức rẻ nhất đáp ứng được, và nêu điều kiện để sau này nâng cấp lên streaming.

Hãy kết thúc bằng một ví dụ có số, như bảng ba use case ở trên, vì nó cho thấy bạn hiểu cả chi phí lẫn nghiệp vụ.

Biết dựng pipeline streaming là một kỹ năng tốt. Nhưng điều khiến người phỏng vấn nhớ đến bạn thường là khoảnh khắc bạn hỏi lại khách “điều gì hỏng nếu trễ?” và mang về một con số đủ rõ để chọn kiến trúc đúng.

**Thử ngay tuần này:**

- Chọn một dashboard hoặc báo cáo bạn đang làm, hỏi người dùng chính “nếu số này trễ 1 giờ thì điều gì hỏng?”, rồi ghi câu trả lời thành một con số độ trễ.
- Lập bảng 4 cột (use case, điều gì hỏng nếu trễ, độ trễ chịu được, kiến trúc) cho ba luồng dữ liệu trong hệ thống hiện tại.
- Tìm một job đang chạy streaming hoặc chạy quá dày, thử đề xuất chuyển sang micro-batch và ghi lại phần tài nguyên tiết kiệm được.

## Nguồn

- [What is Batch Processing? – AWS](https://aws.amazon.com/what-is/batch-processing/)

- [Message Queues – AWS](https://aws.amazon.com/message-queue/)

- [Synchronous vs Asynchronous Communication: What's the Difference?](https://www.getguru.com/reference/synchronous-vs-asynchronous-communication)

- [Batch vs. Streaming: Choose the Right Processing Model](https://datalakehousehub.com/blog/2026-02-de-best-practices-06-batch-vs-streaming)

- [Streaming vs. Batch Processing – TDWI Data 101](https://tdwi.org/blogs/data-101/2026/05/streaming-vs-batch-processing.aspx)