Kiến trúc dữ liệu thời gian thực cho AI Trading #18

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Kiến trúc dữ liệu thời gian thực cho AI Trading là hệ thống nhận event liên tục, giữ đúng thời điểm và thứ tự, phát hiện thiếu hoặc trùng, rồi cung cấp dữ liệu còn hạn cho model. “Thời gian thực” không chỉ là nhanh; pipeline còn phải biết dữ liệu đúng tới lúc nào và có thể phát lại.

Đọc xong, bạn sẽ hiểu:

Pipeline từ nguồn dữ liệu tới model, signal, risk và execution gồm những lớp nào.

Vì sao event time, received time, processing time và sequence phải đi cùng giá trị.

Cách điền Real-time Data Contract Card bằng CSV giả, chưa cần API key.

1. “Dữ liệu thời gian thực” trong AI Trading thực sự là gì?

a. Nhanh chưa chắc đủ và đúng

Real-time ở đây là pipeline cập nhật liên tục trong giới hạn độ trễ và độ mới đã đo. Có ba câu hỏi khác nhau:

Latency: event mất bao lâu để đi từ nguồn tới một điểm trong hệ thống?
Freshness: dữ liệu hiện tại cách thời điểm sự kiện bao xa?
Completeness: tập event cần thiết có đủ hay đang thủng một đoạn?

Chart có thể nhảy mỗi giây nhưng thiếu message, hoặc feed đủ mà processor chậm 30 giây. “Màn hình còn chạy” không trả lời được ba câu trên.

b. Ba chiếc đồng hồ

Mỗi event nên mang ít nhất ba mốc:

Event time: lúc sự kiện xảy ra tại nguồn.
Received/ingestion time: lúc hệ thống của bạn nhận event.
Processing time: lúc processor thực sự xử lý event.

Ví dụ một tick giá có event_time = 10:00:00.100, tới connector lúc 10:00:00.450 và được tính feature lúc 10:00:00.470. Source-to-ingestion latency là 350ms; thêm 20ms nữa mới xử lý xong. Nếu chỉ lưu processing time, bạn không biết thị trường đã phát giá đó từ khi nào.

Nó giống lá thư có giờ viết, giờ tới bưu cục và giờ nhập máy.

c. WebSocket là đường truyền, không phải giấy bảo hành

WebSocket giữ kết nối hai chiều để server đẩy cập nhật liên tục. Nó hữu ích cho dữ liệu thị trường, nhưng connection mở không có nghĩa mọi message đều đủ và đúng thứ tự.

Tài liệu Coinbase nêu sequence number tăng theo từng message; khoảng nhảy lớn hơn một có thể báo message bị mất, còn số nhỏ hơn trước có thể là message đến sai thứ tự. Họ cũng nói consumer cần xử lý gap và out-of-order dù kết nối dùng TCP Coinbase WebSocket Overview.

2. Kiến trúc tám lớp từ nguồn tới execution

a. Dòng dữ liệu chính

Một kiến trúc dễ đọc có tám lớp:

Source: exchange, broker, news hoặc dữ liệu nội bộ.
Ingestion: connector nhận event, gắn received time và theo dõi connection.
Validate + normalize: kiểm schema, kiểu dữ liệu, symbol, timestamp và đơn vị.
Durable event log: nhật ký bền vững giữ event để audit và replay.
Stream processor + state: sắp thứ tự, dedup, window, aggregate và giữ trạng thái.
Online feature + model: tạo biến live và model output.
Signal + risk gate: kiểm freshness, hạn dùng và giới hạn rủi ro.
Execution + monitoring: gửi action được phép, đọc kết quả và giám sát.

AWS cũng chia streaming thành source, ingestion, storage, processing và downstream destination AWS Data Analytics Lens. Trading thêm signal, risk và execution vì đầu ra có thể tác động tài khoản.

b. Hot path và replay path

Hot path đưa event hợp lệ tới feature/model với latency thấp. Replay path đọc lại event từ durable log để khôi phục state, điều tra lỗi hoặc tái tạo feature. Hai đường phải dùng cùng data contract và logic biến đổi quan trọng.

Durable log giống camera hành trình: đường live giúp phản ứng, bản gốc giúp xem lại. Không có replay, signal lạ khó điều tra.

Hình 1 — Đường chạy nhanh tạo quyết định; durable log giữ khả năng replay và kiểm toán.

c. Raw, normalized và feature là ba tầng khác nhau

Raw event là bản nhận nguyên gốc. Normalized event chuẩn hóa tên field, kiểu, timezone và đơn vị. Feature là biến được tính từ event, ví dụ return 1 phút hoặc volume rolling.

Giữ raw bất biến; đưa event sai vào quarantine và ghi reason. Event chuẩn nên có source, symbol, event_type, event_time, received_at, sequence/event_id, value, schema_version.

3. Sequence, heartbeat và cách biết feed bị thủng

a. Sequence 100 rồi 102 là một tín hiệu dừng

Sequence là số thứ tự giúp phát hiện thiếu, trùng hoặc lệch thứ tự. Nếu nhận 100 rồi 102, chart vẫn có thể vẽ điểm mới nhưng hệ thống phải giả định 101 có thể đã mất.

Heartbeat là message định kỳ báo connection/tiến độ còn sống. Coinbase cho biết heartbeat có sequence và last trade ID để kiểm tra message lỡ; một số channel có thể drop message và cần lấy phần thiếu qua REST Coinbase WebSocket Channels. Heartbeat không thay thế dữ liệu.

Hình 2 — Giá trị có thể đúng nhưng đã muộn hoặc nằm sau một message bị thiếu.

b. Reconnect cần snapshot rồi mới nhận delta

Snapshot là trạng thái đầy đủ tại một mốc; delta là phần thay đổi sau đó. Với order book, reconnect rồi chỉ đọc delta mới giống xem các nước cờ tiếp theo mà không biết bàn cờ hiện tại.

Policy an toàn thường là: đánh dấu state not_ready, lấy snapshot, xác nhận sequence, replay delta sau snapshot, rồi mới mở lại đường tạo feature. Nếu không resync được thì dừng signal.

c. Duplicate, retry và phạm vi “exactly-once”

Hãy theo một event E42. Nếu E42 được gửi hai lần, deduplication dùng event_id để chỉ giữ một bản. Nếu hệ thống phải thử lại thao tác ghi lệnh, idempotency giúp lần thử lại không tạo lệnh thứ hai. Nếu E42 đến muộn so với thời gian sự kiện, watermark và late-event policy quyết định chờ, cập nhật lại hay loại bỏ. Vì vậy, “exactly-once” chỉ nên được tuyên bố trong phạm vi pipeline đã kiểm soát; API hoặc broker bên ngoài vẫn cần khóa idempotency riêng.

At-least-once cho phép retry nên duplicate có thể xảy ra. Deduplication nhận diện trùng; idempotency ngăn xử lý lại nhân đôi kết quả.

Kafka có guarantee gồm exactly-once Apache Kafka, nhưng phải đọc đúng phạm vi. Dataflow nói record có thể xử lý lại, còn kết quả trong pipeline được commit một lần Dataflow exactly-once. Nó không bảo đảm lệnh ngoài pipeline chỉ gửi hay khớp một lần.

d. Watermark và event đến muộn

Watermark ước lượng pipeline đã tiến tới đâu theo event time. Event tới sau mốc đã đóng là late event. Flink dùng watermark cho dữ liệu out-of-order; ứng dụng phải chọn chờ, cập nhật, tách luồng hoặc bỏ có log Flink Time Attributes.

Không có late policy thì cùng dữ liệu có thể cho kết quả khác giữa live và replay.

4. Tám lỗi pipeline và checklist trước khi model được đọc

a. Tám lỗi thường gặp

Stale feed: message cuối đã quá hạn.
Sequence gap: thiếu một đoạn mà pipeline vẫn chạy.
Duplicate: volume hoặc count bị cộng hai lần.
Out-of-order: event cũ cập nhật đè state mới.
Clock skew: đồng hồ các máy lệch nhau.
Schema drift: nguồn thêm/đổi field làm parser hiểu sai.
Backpressure: tốc độ nhận lớn hơn tốc độ xử lý, hàng đợi tăng và data cũ dần.
Bad reconnect: connection nối lại nhưng state chưa khôi phục.

Còn một lỗi rất khó thấy là train/serve skew: cách tạo feature khi train khác cách tạo feature live. Ví dụ backtest dùng candle đã đóng, còn live đọc candle đang chạy. Chênh lệch này có thể nguy hiểm hơn vài mili-giây latency.

b. Checklist trước model

Data contract có schema version và owner.
Event time, received time, processing time đều có mặt.
Sequence/event ID và dedup key được kiểm.
Event sai đi quarantine, không tự sửa raw.
Freshness gate chặn dữ liệu hết hạn.
Gap/reconnect có snapshot + replay policy.
Durable log đủ để replay.
Feature train và live có parity test.
Monitoring có stop rule rõ.

Model phải đứng ngoài khi thiếu timestamp/sequence, freshness breach, state chưa resync, schema lạ hoặc replay không khớp.

c. Theo dõi cái gì?

Theo dõi event lag, processing lag, gap count, duplicate/late/invalid rate, last-good-event và replay parity.

Câu đoán chắc: sequence 100→102 vi phạm rule tăng đúng 1. Câu có điều kiện: message 101 có thể bị mất, hoặc 102 đến trước 101. Chưa đủ bằng chứng để kết luận nguyên nhân, nhưng đủ lý do dừng feature và recovery.

5. Bài tập 15 phút: điền Real-time Data Contract Card

a. Công cụ và dữ liệu giả

Dùng Google Sheets, LibreOffice hoặc Markdown. Tạo sáu dòng CSV với các cột event_id, symbol, event_time, received_at, sequence, price, schema_version. Cố ý cho sequence đi 98, 99, 100, 102, 102, 103.

Tính lag_ms = received_at - event_time, khoanh gap và duplicate. Không cần feed thật.

b. Mẫu đối chiếu đã điền

Trường	Mẫu đã điền
Source	Demo tick CSV
Clocks	event_time, received_at, processed_at
Dedup key	source + symbol + sequence
Freshness SLA	received_at - event_time ≤ 2 giây
Late policy	Quarantine và ghi reason
Gap recovery	Dừng feature, lấy snapshot, replay delta
Raw storage	Giữ nguyên event nhận được
Stop rule	Gap, schema lạ hoặc freshness breach
Owner	Data pipeline owner
Decision	QUARANTINE — sequence gap 100 → 102

Hình 3 — Không qua freshness và sequence gate thì event chưa được tạo feature.

c. Điểm dừng

Kết quả đúng của bài tập là đánh dấu dòng nghi vấn và giải thích reason. Chưa dùng API key, feed trả phí, broker hoặc tiền thật.

6. Tổng kết

a. Năm ý chính

Real-time cần đo latency, freshness và completeness, không chỉ nhìn tốc độ cập nhật.
Ba clock và sequence phải đi cùng value để biết event xảy ra, đến và được xử lý khi nào.
Hot path phục vụ quyết định; durable log và replay phục vụ recovery, audit và parity.
Gap, duplicate, late event, schema drift và backpressure phải có policy trước khi model đọc.
Không qua Data Contract Card và freshness gate thì event nên ở quarantine.

b. Câu hỏi tự kiểm tra

Vì sao WebSocket còn kết nối chưa chứng minh feed đầy đủ?
Event time khác received time ở đâu?
Sequence 100→102 nên kích hoạt hành động nào?
Exactly-once trong stream pipeline có bảo đảm lệnh ngoài sàn chỉ chạy một lần không?

c. Gợi ý đáp án

Xem gợi ý câu 1

Connection chỉ nói đường truyền còn mở; message vẫn có thể gap, trùng hoặc out-of-order. → xem mục 1.

Xem gợi ý câu 2

Event time là lúc sự kiện xảy ra tại nguồn; received time là lúc hệ thống của bạn nhận nó. → xem mục 1.

Xem gợi ý câu 3

Dừng tạo feature, quarantine đoạn nghi vấn và chạy gap recovery/snapshot trước khi mở lại. → xem mục 3.

Xem gợi ý câu 4

Không. Guarantee có phạm vi; effect trong pipeline không tự bao phủ side effect ở execution venue. → xem mục 3.

d. Thuật ngữ cần nhớ

Thuật ngữ	Giải thích ngắn
Latency	Khoảng trễ giữa hai mốc thời gian.
Freshness	Dữ liệu hiện tại cách event time bao xa.
Event time	Lúc sự kiện xảy ra tại nguồn.
Received time	Lúc hệ thống nhận event.
Sequence	Số thứ tự dùng phát hiện thiếu, trùng hoặc lệch.
Durable log	Nhật ký event bền vững dùng cho replay và audit.
Replay	Chạy lại pipeline từ event đã lưu.
Watermark	Ước lượng tiến độ event time của stream.
Backpressure	Hàng đợi tăng vì tốc độ nhận vượt tốc độ xử lý.
Quarantine	Vùng tách event nghi vấn khỏi đường tạo feature.

e. Nguồn tham khảo

Đọc lại Data trong AI Trading, Signal trong AI Trading và AI Agent và Agentic Trading, học tiếp Backtest khác Forward Test thế nào, hoặc quay về AI Trading là gì?.

Chọn đúng bài trong lộ trình

Bài này tập trung vào kiến trúc dữ liệu AI Trading — pipeline, event time, sequence, replay và freshness. Nếu bạn cần bức tranh chung trước khi đi sâu, hãy bắt đầu từ AI Trading là gì? Hướng dẫn từ nền tảng đến kiểm định. Các bước liên quan trực tiếp là Data trong AI Trading là gì, Rủi ro API, sàn và lỗi thực thi và Quy trình xây một hệ thống AI Trading.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.