Streaming data là gì?

Mục lục

1. Streaming data là gì?
2. Một sự kiện trong luồng trông như thế nào?
3. Dữ liệu luồng được xử lý thế nào từ đầu đến cuối?
4. Event time và watermark: vì sao luồng dữ liệu dễ tính sai?
5. Cửa sổ thời gian là gì và có những loại nào?
6. Đảm bảo “đúng một lần” có thật không?
7. Những công cụ nào dùng cho dữ liệu luồng?
8. Streaming data khác xử lý theo lô và ETL ở đâu?
9. Ví dụ ứng dụng cho doanh nghiệp Việt Nam
10. Khi nào nên và không nên dùng streaming?
11. Rủi ro vận hành và dữ liệu cá nhân trong luồng
12. Câu hỏi thường gặp

Streaming data là gì?

Streaming data là dữ liệu được phát ra liên tục, theo từng phần nhỏ, từ rất nhiều nguồn cùng lúc. Theo AWS, dữ liệu này thường có khối lượng lớn, được phát ra tăng dần và hay cần xử lý với độ trễ thấp. Mỗi bản ghi thường chỉ vài kilobyte. Giá trị nằm ở số lượng và tốc độ chứ không nằm ở kích thước từng bản ghi.

Về bản chất, bạn không có “tệp dữ liệu” để mở ra xem. Bạn có một dòng chảy. Dữ liệu cần được xử lý tăng dần mà không có toàn bộ tập dữ liệu trong tay. Vì vậy câu hỏi quen thuộc như “tổng doanh thu cả ngày” phải đổi thành “doanh thu trong 5 phút gần nhất, cập nhật mỗi 10 giây”.

Cần tách hai nghĩa dễ nhầm của chữ “streaming”:

• Streaming nội dung: xem video hoặc nghe nhạc trực tuyến mà không phải tải về trước.
• Streaming dữ liệu: luồng sự kiện giữa các hệ thống, là chủ đề của bài này.

Nếu bạn muốn nắm khái niệm rộng hơn về độ trễ và tính tức thời, hãy đọc thêm bài về dữ liệu thời gian thực. Streaming data là hình thức dữ liệu, còn “thời gian thực” là yêu cầu về độ trễ mà luồng dữ liệu giúp đạt được.

Một sự kiện trong luồng trông như thế nào?

Hầu hết luồng dữ liệu là chuỗi sự kiện (event) bất biến: một việc đã xảy ra, tại một thời điểm, với một số thuộc tính. Bạn không sửa sự kiện cũ mà chỉ thêm sự kiện mới. Ví dụ minh hoạ cho một cửa hàng bán lẻ trực tuyến:

Trường	Ví dụ minh hoạ	Vai trò
event_id	mã duy nhất của sự kiện	Khử trùng lặp khi gửi lại
event_type	add_to_cart, payment_failed	Phân loại, định tuyến
event_time	thời điểm khách bấm nút trên thiết bị	Tính cửa sổ thời gian đúng
ingest_time	thời điểm máy chủ nhận được	Đo độ trễ truyền
key	mã phiên hoặc mã thiết bị	Giữ các sự kiện cùng đối tượng đi cùng một phân vùng
payload	mã sản phẩm, số tiền, mã lỗi	Nội dung nghiệp vụ

Cặp event_time và ingest_time là chi tiết mà nhiều bài giới thiệu bỏ qua, nhưng nó quyết định kết quả tính toán có đúng hay không. Phần sau sẽ nói rõ.

Nguồn phát có thể dùng nhiều định dạng như JSON, Avro hoặc CSV, với các kiểu chuỗi, số, ngày và nhị phân. Vì thế các nhóm dữ liệu thường định nghĩa sẵn lược đồ (schema) cho từng loại sự kiện và kiểm tra khi ghi vào luồng. Nếu bạn chưa rõ khác biệt giữa các dạng này, xem bài về dữ liệu có cấu trúc và phi cấu trúc.

Dữ liệu luồng được xử lý thế nào từ đầu đến cuối?

Kiến trúc streaming gồm bên phát (producer), bên nhận (consumer) và các broker nằm giữa chúng. Trong thực tế, người ta thường chia thành bốn lớp:

Lớp 1 và 2: nguồn và bộ đệm

Nguồn phát có thể là ứng dụng web, thiết bị IoT, máy POS, nhật ký máy chủ, hoặc luồng thay đổi từ cơ sở dữ liệu (change data capture, CDC). Các sự kiện được ghi vào bộ đệm như Apache Kafka theo từng chủ đề (topic) và chia thành các phân vùng (partition). Thứ tự chỉ được đảm bảo trong từng phân vùng, nên khoá sự kiện (ví dụ mã thiết bị) phải chọn sao cho các sự kiện cần đúng thứ tự cùng rơi vào một phân vùng.

Bộ đệm cũng tách bên phát khỏi bên nhận. Nếu bộ xử lý ngừng 10 phút để nâng cấp, sự kiện vẫn nằm trong broker và bộ xử lý đọc tiếp từ vị trí (offset) đã ghi nhớ.

Lớp 3 và 4: xử lý và đích đến

Dữ liệu thường được xử lý tuần tự theo từng bản ghi hoặc theo các cửa sổ thời gian trượt. Kết quả đi đến hai loại đích. Đích thứ nhất là hệ thống hành động, như tin nhắn cảnh báo hoặc chặn giao dịch. Đích thứ hai là kho lưu trữ để phân tích sau, như data lake hoặc kho dữ liệu. Cách nối các bước này thành một chuỗi chạy ổn định thuộc về chủ đề data pipeline.

Event time và watermark: vì sao luồng dữ liệu dễ tính sai?

Đây là phần phân biệt người hiểu streaming với người chỉ nghe tên. Có hai loại thời gian. Event time là lúc sự kiện thực sự xảy ra. Processing time là lúc hệ thống xử lý nó. Độ lệch giữa hai loại có thể đáng kể do trễ mạng và hàng đợi thông điệp.

Ví dụ minh hoạ: ứng dụng di động của một hãng giao hàng gửi vị trí tài xế. Tài xế đi qua đoạn mất sóng 40 giây, nên các điểm vị trí xảy ra lúc 10:00:50 mới tới máy chủ sau khi điểm 10:01:10 đã đến. Nếu gộp theo thời điểm nhận, điểm này bị tính sai phút.

Để xử lý, bộ xử lý luồng như Apache Flink dùng watermark, một mốc thời gian cho biết “hệ thống tin rằng mọi sự kiện có thời điểm trước mốc này đã đến”. Tài liệu của Confluent Cloud cho Flink có ví dụ khai báo watermark trễ 5 giây so với event time của cột thời gian. Với cấu hình độ lệch tối đa bằng 0, watermark luôn bằng mốc thời gian lớn nhất đã thấy.

Chọn độ trễ watermark là phép đánh đổi:

• Watermark chậm hơn (dung sai lớn): kết quả đầy đủ hơn nhưng cửa sổ đóng muộn, cảnh báo chậm.
• Watermark sát (dung sai nhỏ): kết quả ra nhanh nhưng nhiều sự kiện bị coi là muộn.

Sự kiện đến sau khi cửa sổ đã đóng không nên bị bỏ lặng lẽ. Flink có cơ chế cho phép độ trễ thêm (allowed lateness) và chuyển các sự kiện muộn sang một đầu ra phụ (side output) để lưu lại hoặc đối soát về sau. Event time cho kết quả chính xác hơn nhưng khó triển khai hơn, vì phải xử lý sự kiện muộn.

Cửa sổ thời gian là gì và có những loại nào?

Vì luồng không có điểm kết thúc nên không thể “cộng tất cả”. Người ta chia luồng thành các cửa sổ (window) hữu hạn rồi mới tổng hợp:

• Tumbling window (cửa sổ cố định): các đoạn liên tiếp, không chồng lấn, ví dụ mỗi 1 phút đếm số đơn hàng.
• Sliding window (cửa sổ trượt): các đoạn chồng lấn, ví dụ 10 phút gần nhất và làm mới mỗi 1 phút, hợp với phát hiện bất thường.
• Session window (cửa sổ phiên): đóng khi khách im lặng quá một khoảng, ví dụ 30 phút không thao tác. Độ dài mỗi cửa sổ khác nhau.

Tài liệu Confluent nêu một truy vấn mẫu gom theo cửa sổ cố định 10 phút trên cột event time và đếm số người dùng khác nhau trong mỗi cửa sổ. Dạng truy vấn này gần với SQL, nên nhóm đã quen SQL có thể bắt đầu với Flink SQL trước khi viết mã Java hay Python.

Đảm bảo “đúng một lần” có thật không?

Sự cố xảy ra hằng ngày: máy chủ khởi động lại, mạng đứt, tác vụ chạy lại. Câu hỏi là mỗi sự kiện được tính mấy lần. Có ba mức:

Mức đảm bảo	Ý nghĩa	Hệ quả khi lỗi	Hợp với
At-most-once	Tối đa một lần	Có thể mất sự kiện	Đo lường thô, mất vài điểm không sao
At-least-once	Ít nhất một lần	Có thể trùng sự kiện	Khi đích đến khử trùng được
Exactly-once	Đúng một lần về kết quả	Phức tạp, tốn tài nguyên hơn	Số dư, kho, đối soát

Với Flink, khả năng chịu lỗi dựa trên checkpoint, một ảnh chụp trạng thái nhất quán của toàn bộ toán tử cùng vị trí đọc của luồng đầu vào. Khi khởi động lại, Flink nạp checkpoint gần nhất rồi tiếp tục từ đó. Để không ghi trùng ra ngoài, đích ghi cần hỗ trợ giao dịch như Kafka. Dữ liệu chỉ được cam kết sau khi checkpoint hoàn tất.

Exactly-once không miễn phí. Một nhóm kỹ sư xây hệ thống ghép sự kiện thời gian thực bằng Kafka và Flink đã chọn at-least-once kết hợp khử trùng lặp ở đích (idempotent sink), vì độ phức tạp của exactly-once không bù được lợi ích trong trường hợp của họ. Đây là một lựa chọn thiết kế chứ không phải khuyến nghị chung. Điều đáng nhớ là event_id trong bảng phía trên chính là thứ làm cho cách khử trùng này khả thi.

Những công cụ nào dùng cho dữ liệu luồng?

Các công cụ chia theo vai trò. Bảng dưới đây mô tả trung lập, không xếp hạng:

Vai trò	Ví dụ công cụ	Ghi chú
Bộ đệm sự kiện	Apache Kafka, Amazon Kinesis, Google Pub/Sub, Azure Event Hubs	Lưu sự kiện theo thứ tự, cho phép đọc lại
Bộ xử lý luồng	Apache Flink, Kafka Streams, Spark Structured Streaming	Kafka Streams chạy như thư viện trong ứng dụng, Flink chạy như cụm riêng
Thu thập thay đổi CSDL	Debezium và các dịch vụ CDC của nhà cung cấp cloud	Biến thao tác ghi trong CSDL thành sự kiện
Đích phân tích	Kho dữ liệu, lakehouse, CSDL chuỗi thời gian	Nơi truy vấn kết quả sau xử lý

Một so sánh thường gặp là Kafka Streams và Flink. Theo một bài hướng dẫn của Ksolves, Flink phù hợp khi cần exactly-once qua nhiều đích ghi, xử lý sự kiện phức tạp trên cửa sổ lớn, hoặc ghép luồng từ nhiều nguồn ngoài Kafka. Nếu logic chỉ là biến đổi và tổng hợp đơn giản trong một cụm Kafka, thư viện nhẹ hơn thường đủ.

Hầu hết nhà cung cấp cloud lớn đều có dịch vụ tương đương dạng quản lý sẵn. Nhóm nhỏ nên cân nhắc dịch vụ quản lý để giảm gánh vận hành cụm, và kiểm tra giá hiện hành trên trang nhà cung cấp vì mô hình tính phí thay đổi theo thời gian.

Streaming data khác xử lý theo lô và ETL ở đâu?

Tiêu chí	Xử lý theo lô (batch)	Streaming
Đơn vị xử lý	Tập dữ liệu hữu hạn đã gom	Từng sự kiện hoặc cửa sổ nhỏ
Độ trễ kết quả	Phút đến giờ, thường theo lịch	Mili giây đến phút
Chạy lại khi sai	Chạy lại cả lô, tương đối đơn giản	Phải đọc lại từ offset và dựng lại trạng thái
Xử lý dữ liệu muộn	Ít lo, vì chờ đủ rồi mới chạy	Cần event time, watermark
Vận hành	Chạy rồi dừng	Chạy liên tục 24/7, cần giám sát
Chi phí hạ tầng	Trả theo lần chạy	Tài nguyên chiếm dụng liên tục

Với ETL, bước trích xuất thường chạy theo lịch, ví dụ mỗi đêm. Bài ETL là gì giải thích quy trình đó. Streaming không xoá ETL mà thay lịch chạy bằng dòng chảy liên tục. Một hệ thống thực tế hay chạy song song: luồng cho cảnh báo tức thì, lô ban đêm cho đối soát và báo cáo tổng.

Ví dụ ứng dụng cho doanh nghiệp Việt Nam

Các tình huống sau là ví dụ minh hoạ, không phải số liệu của doanh nghiệp cụ thể.

• Thương mại điện tử: sự kiện xem sản phẩm, thêm giỏ, thanh toán lỗi chảy vào một luồng. Cửa sổ trượt 5 phút đếm tỷ lệ thanh toán thất bại theo cổng thanh toán. Khi tỷ lệ vượt ngưỡng đã đặt, hệ thống báo đội vận hành trước khi khách phàn nàn.
• Logistics: định vị GPS của xe gửi mỗi vài giây. Luồng tính khoảng cách tới điểm giao để cập nhật giờ dự kiến. Dữ liệu từ vùng mất sóng đến muộn nên cần watermark.
• Tài chính và thanh toán: chấm điểm rủi ro giao dịch trong lúc khách còn đang chờ xác nhận. Tình huống này cần độ trễ thấp và thường cần exactly-once cho các số cộng dồn.
• Sản xuất: nhiệt độ, độ rung từ cảm biến máy. Luồng so sánh với ngưỡng và dự báo hỏng hóc. Nội dung này được mở rộng hơn ở bài AI trong sản xuất.

Ở mỗi trường hợp, giá trị đến từ việc rút ngắn khoảng thời gian giữa sự kiện và hành động. Nếu không có hành động nào đi kèm, luồng chỉ làm dữ liệu đến sớm hơn mà không làm quyết định tốt hơn.

Khi nào nên và không nên dùng streaming?

Hai câu hỏi giúp phân loại: kết quả có kích hoạt hành động tự động không, và chậm bao lâu thì mất giá trị.

Nên cân nhắc streaming khi

• Giá trị của kết quả giảm nhanh theo thời gian, như phát hiện gian lận hay cảnh báo hỏng máy.
• Có nhiều nguồn sinh sự kiện liên tục, và hệ quả của việc đến muộn đã được tính trước.
• Có đội vận hành hệ thống chạy 24/7, hoặc dùng dịch vụ quản lý có hỗ trợ.

Chưa nên khi

• Người dùng chỉ xem báo cáo ngày hoặc tuần. Một lịch chạy mỗi giờ thường là đủ.
• Dữ liệu nguồn vốn đã cập nhật theo lô, ví dụ file đối soát ngân hàng cuối ngày. Làm luồng ở phía sau không làm dữ liệu mới hơn.
• Chưa thống nhất cách định nghĩa chỉ số, vì luồng chỉ làm sai nhanh hơn.

Nếu cần dashboard cập nhật liên tục, cách tiếp cận micro-batch (gom lô rất nhỏ, vài giây đến vài phút) là điểm giữa hợp lý và ít tốn kém hơn. Phần hiển thị có thể xem ở bài dashboard là gì.

Rủi ro vận hành và dữ liệu cá nhân trong luồng

Luồng chạy liên tục nên sự cố lan nhanh. Một thay đổi tên trường ở ứng dụng nguồn có thể làm hỏng bộ xử lý ngay trong phút kế tiếp. Các rủi ro hay gặp:

• Độ trễ tăng dần (consumer lag): bộ xử lý đọc chậm hơn tốc độ ghi. Cần theo dõi khoảng cách giữa offset mới nhất và offset đã xử lý.
• Thay đổi lược đồ: thêm hoặc đổi kiểu trường làm bên nhận lỗi. Dùng kho đăng ký lược đồ và kiểm tra tương thích trước khi phát hành.
• Phân vùng lệch (hot partition): một khoá như mã cửa hàng lớn chiếm phần lớn sự kiện và làm nghẽn một phân vùng.
• Sự kiện trùng hoặc mất: xem lại mức đảm bảo giao hàng ở trên.

Các rủi ro này thuộc phạm vi theo dõi chất lượng và sức khoẻ dữ liệu, được trình bày ở bài data observability.

Câu hỏi thường gặp

Streaming data có phải là dữ liệu thời gian thực không?

Hai khái niệm gần nhau nhưng không đồng nghĩa. Streaming mô tả cách dữ liệu đến: liên tục, từng sự kiện. Thời gian thực mô tả độ trễ mong muốn của kết quả. Bạn có thể có luồng nhưng chỉ xử lý mỗi 5 phút, hoặc có yêu cầu thời gian thực mà không cần luồng.

Streaming data khác big data thế nào?

Big data nói về quy mô và độ đa dạng của dữ liệu, còn streaming nói về cách dữ liệu được sinh và xử lý theo thời gian. Streaming data thường nằm trong bối cảnh dữ liệu lớn, nhưng một luồng nhỏ vẫn là streaming. Đặc điểm của dữ liệu lớn được trình bày trong bài big data là gì.

Doanh nghiệp nhỏ có cần dùng streaming không?

Thường là chưa cần. Nếu quyết định kinh doanh được đưa ra theo ngày hoặc tuần, xử lý theo lô đơn giản và rẻ hơn. Streaming đáng cân nhắc khi có một tình huống cụ thể mà chậm vài phút gây thiệt hại, ví dụ gian lận thanh toán hay dừng máy.

Kafka và Flink có phải là streaming data không?

Không. Chúng là công cụ. Kafka lưu và chuyển các sự kiện, còn Flink tính toán trên luồng. Streaming data là chính dòng sự kiện đi qua các công cụ đó.

Watermark là gì và có bắt buộc không?

Watermark là mốc cho biết các sự kiện trước thời điểm đó coi như đã đến đủ, để cửa sổ có thể đóng và xuất kết quả. Nếu bạn tính theo event time thì cần watermark. Nếu chỉ tính theo thời điểm xử lý, bạn không cần, nhưng kết quả sẽ lệch khi dữ liệu đến trễ.

Ai thiết kế và vận hành hệ thống streaming?

Thường là kỹ sư dữ liệu, phối hợp với đội ứng dụng sinh sự kiện và đội vận hành hạ tầng. Vai trò này được mô tả ở bài data engineer là gì.