Mỗi lượt click trên website, giao dịch trong ứng dụng, hành động của người dùng hay bản ghi log đều có thể trở thành dữ liệu quan trọng. Vấn đề là khi số lượng event tăng lên hàng nghìn hoặc hàng triệu bản ghi, việc tự xây dựng một hệ thống tiếp nhận, buffer, xử lý, gom batch và lưu trữ dữ liệu sẽ nhanh chóng trở nên phức tạp.

Một data pipeline truyền thống thường cần nhiều thành phần: endpoint nhận dữ liệu, message queue, stream processor, worker xử lý, cơ chế retry, batch job và object storage. Mỗi lớp đều cần vận hành, scale và giám sát riêng.

Cloudflare Pipelines kết hợp với R2 hướng đến việc đơn giản hóa kiến trúc này. Dữ liệu có thể được gửi liên tục qua HTTP hoặc từ Cloudflare Workers, đi vào một stream bền vững, được lọc và biến đổi bằng SQL, sau đó tự động gom thành batch để ghi xuống R2 dưới dạng JSON, Parquet hoặc Apache Iceberg table.

Với doanh nghiệp cần xây dựng hệ thống tracking, event logging hoặc data pipeline nhưng không muốn tự vận hành nhiều lớp hạ tầng streaming, LionTech có thể hỗ trợ thiết kế kiến trúc Cloudflare Pipelines và R2 theo nhu cầu dữ liệu thực tế.

Luồng thu thập event qua stream, xử lý bằng SQL, gom batch và lưu dữ liệu vào R2. 

1. Cloudflare Pipelines là gì?

Cloudflare Pipelines là dịch vụ ingest và xử lý dữ liệu streaming, giúp kết nối nguồn dữ liệu với nơi lưu trữ thông qua ba thành phần chính:

Theo tài liệu Cloudflare, Streams là các durable, buffered queues nhận events qua HTTP endpoint hoặc Worker binding. Pipelines kết nối Streams với Sinks và có thể dùng SQL để validate, filter, transform, enrich hoặc restructure dữ liệu trong quá trình ingest.

Kiến trúc cơ bản có thể hình dung như sau:

Website / App / Worker → Stream → SQL Processing → Batch → R2

Thay vì tự xây dựng từng thành phần riêng biệt, doanh nghiệp có thể dùng Pipelines như lớp ingestion và processing nằm giữa hệ thống tạo event và R2.

2. Cloudflare Pipelines và R2 giải quyết bài toán gì?

Bài toán lớn của dữ liệu realtime không chỉ là “nhận được event”. Hệ thống còn phải giải quyết nhiều vấn đề phía sau:

Streams trong Cloudflare Pipelines được thiết kế như durable buffered queues, giúp nhận và giữ events để xử lý ngay cả khi downstream processing có độ trễ hoặc gặp lỗi. Sau đó, Pipelines xử lý dữ liệu và chuyển đến sink tương ứng.

2.1. So sánh kiến trúc tự xây dựng và Cloudflare Pipelines

Giá trị lớn nhất không nằm ở việc thay một API bằng một API khác, mà là giảm số lượng thành phần doanh nghiệp phải tự vận hành.

3. Luồng dữ liệu realtime với Cloudflare Pipelines hoạt động như thế nào?

Một pipeline cơ bản có thể chia thành bốn bước:

3.1. Bước 1: Event được tạo từ website, ứng dụng hoặc hệ thống

Nguồn dữ liệu có thể là:

Ví dụ một event tracking có thể chứa:

{

  "event_type": "product_view",

  "user_id": "u_12345",

  "product_id": "p_987",

  "country": "VN",

  "timestamp": "2026-07-04T08:30:00Z"

}

Điểm quan trọng là event nên được thiết kế theo schema rõ ràng ngay từ đầu. Nếu mỗi team gửi một cấu trúc dữ liệu khác nhau, data lake phía sau sẽ nhanh chóng trở nên khó dùng.

3.2. Bước 2: Dữ liệu được ingest qua HTTP hoặc Workers

Cloudflare Streams có thể nhận dữ liệu từ hai nguồn chính:

Mỗi Stream có thể cung cấp HTTP endpoint để các ứng dụng bên ngoài, browser hoặc bất kỳ hệ thống nào có thể gửi HTTP request đẩy dữ liệu vào pipeline. Với ứng dụng đang chạy trên Workers, dữ liệu có thể được gửi trực tiếp qua binding.

Điều này tạo ra hai mô hình phổ biến.

Mô hình trực tiếp qua HTTP:

App → HTTP endpoint → Stream

Phù hợp với:

Mô hình qua Worker:

Client → Worker → Stream

Phù hợp với:

4. Realtime ingest không có nghĩa là ghi từng event trực tiếp vào R2

Đây là điểm quan trọng khi hiểu Cloudflare Pipelines.

Pipelines có thể nhận dữ liệu streaming liên tục, nhưng dữ liệu không nhất thiết được ghi xuống R2 theo mô hình:

1 event = 1 file

Nếu làm như vậy, hệ thống sẽ tạo ra rất nhiều object nhỏ. Điều này không hiệu quả cho lưu trữ và đặc biệt bất lợi khi cần query dữ liệu sau này.

Thay vào đó, luồng hợp lý là:

Realtime events → Buffer → Batch → File → R2

Cloudflare Pipelines cho phép cấu hình rolling policy để đóng file dựa trên các điều kiện như dung lượng file, khoảng thời gian hoặc thời gian không có dữ liệu. Trong quá trình setup nâng cao, doanh nghiệp có thể tùy chỉnh ngưỡng kích thước file và khoảng thời gian tạo file mới.

4.1. Realtime và batch không đối lập nhau

Nhiều người thường nghĩ:

Trong một data pipeline hiện đại, hai khái niệm này có thể cùng tồn tại.

Realtime ingest nghĩa là event được đưa vào hệ thống liên tục ngay khi phát sinh.

Batch write nghĩa là hệ thống gom nhiều event thành nhóm trước khi ghi xuống storage.

Ví dụ:

Cách này vừa giữ được khả năng tiếp nhận dữ liệu nhanh, vừa tránh tạo hàng triệu file nhỏ.

5. Ba thành phần chính của kiến trúc Pipelines

5.1. Streams: lớp ingest và buffer

Streams là điểm đầu vào của dữ liệu. Theo Cloudflare, Streams là durable, buffered queues dùng để nhận và lưu events trước khi được xử lý trong Pipeline. Chúng hỗ trợ ingest qua HTTP endpoint và Worker binding.

Vai trò chính của Streams gồm:

Có thể xem Stream như lớp đệm giữa hệ thống tạo event và hệ thống xử lý dữ liệu.

5.2. Pipelines: lớp xử lý dữ liệu

Pipelines kết nối Streams với Sinks bằng SQL transformations. Cloudflare cho phép dùng SQL để:

Ví dụ:

INSERT INTO clean_events

SELECT

  user_id,

  event_type,

  country,

  timestamp

FROM raw_events

WHERE user_id IS NOT NULL

Pipeline trên loại bỏ events không có user_id trước khi dữ liệu được đưa vào storage.

Một ví dụ khác:

INSERT INTO purchase_events

SELECT

  user_id,

  product_id,

  amount,

  country,

  timestamp

FROM raw_events

WHERE event_type = 'purchase'

Thay vì lưu toàn bộ event rồi mới xử lý sau, doanh nghiệp có thể đưa một phần validation và filtering về ngay ingestion layer.

5.3. Sinks: nơi nhận dữ liệu đầu ra

Sinks xác định destination của dữ liệu. Cloudflare hiện hỗ trợ:

Tùy use case, doanh nghiệp có thể chọn:

6. Vì sao Parquet phù hợp với event logging và analytics?

JSON rất dễ đọc và phù hợp khi trao đổi dữ liệu giữa các ứng dụng. Nhưng khi số lượng event lớn, JSON không phải lúc nào cũng là format tối ưu cho analytics.

Parquet phù hợp hơn trong nhiều bài toán phân tích vì dữ liệu được tổ chức theo dạng columnar.

Ví dụ, một bảng event có 30 trường nhưng dashboard chỉ cần:

Query engine có thể tập trung vào các cột cần thiết thay vì xử lý toàn bộ cấu trúc record.

Cloudflare R2 sink hiện hỗ trợ output dưới dạng JSON và Parquet.

6.1. Khi nào nên dùng JSON?

6.2. Khi nào nên dùng Parquet?

7. R2 Data Catalog và Apache Iceberg mở rộng pipeline như thế nào?

Nếu chỉ cần lưu log hoặc event thô, ghi file xuống R2 có thể đã đủ. Nhưng khi dữ liệu được dùng thường xuyên cho analytics, doanh nghiệp có thể chọn sink đến R2 Data Catalog dưới dạng Apache Iceberg table.

Cloudflare Pipelines có thể ingest streaming data, xử lý bằng SQL và ghi vào R2 Data Catalog dưới dạng Iceberg tables. Dữ liệu sau đó có thể được truy vấn bằng R2 SQL hoặc các query engine hỗ trợ Apache Iceberg.

Kiến trúc lúc này trở thành:

Event Source → Stream → SQL Transform → Iceberg Table → Analytics

So với việc chỉ lưu các file rời rạc, Iceberg phù hợp hơn khi cần xây dựng:

8. Bảng kiến trúc thu thập dữ liệu realtime

Điểm mạnh của mô hình này là các lớp vẫn tách biệt về trách nhiệm nhưng không yêu cầu doanh nghiệp tự vận hành toàn bộ hạ tầng cho từng lớp.

9. Use case 1: Thu thập tracking event cho website và ứng dụng

Một doanh nghiệp thương mại điện tử cần thu thập các event:

Nếu ghi trực tiếp từng event vào database chính, hệ thống có thể tạo thêm tải không cần thiết. Nếu gửi từng event thành một object riêng vào object storage, số lượng file nhỏ sẽ tăng rất nhanh.

Kiến trúc có thể triển khai:

Website/App → Tracking endpoint → Stream → SQL Transform → Parquet → R2

9.1. Luồng xử lý

Bước 1: Người dùng phát sinh event.

Ví dụ:

{

  "event_type": "add_to_cart",

  "user_id": "U1001",

  "product_id": "P208",

  "market": "VN",

  "timestamp": "2026-07-04T08:30:00Z"

}

Bước 2: Event được gửi đến endpoint.

Endpoint có thể do Stream cung cấp trực tiếp hoặc đi qua Worker để bổ sung logic.

Bước 3: Pipeline kiểm tra dữ liệu.

Ví dụ loại:

Bước 4: Dữ liệu được chuẩn hóa.

Ví dụ:

Bước 5: Events được batch và ghi xuống R2.

Kết quả là doanh nghiệp có một kho dữ liệu tracking phục vụ:

10. Use case 2: Xây dựng hệ thống event logging tập trung

Một doanh nghiệp có nhiều hệ thống:

Mỗi hệ thống sinh ra một loại log khác nhau. Nếu lưu riêng theo từng server, việc điều tra sự cố sẽ rất khó.

Kiến trúc có thể triển khai:

Services → Pipelines → Transform → R2

Các event có thể gồm:

10.1. Pipeline có thể chuẩn hóa log

Dữ liệu từ nhiều nguồn có thể được chuyển về schema chung:

timestamp

service

environment

event_type

severity

request_id

user_id

message

Sau đó Pipeline có thể:

Kết quả là doanh nghiệp có thể xây dựng một lớp event logging tập trung trên R2 thay vì để log phân tán trên nhiều hệ thống.

Quy trình ingest event qua HTTP hoặc Worker, xử lý realtime, batch và lưu dưới dạng Parquet trong R2. 

11. Cloudflare Logs có thể đi vào Pipelines như thế nào?

Cloudflare đã bổ sung khả năng gửi logs trực tiếp vào Pipelines để ingest, transform và lưu xuống R2 dưới dạng Parquet files hoặc Apache Iceberg tables do R2 Data Catalog quản lý.

Điều này mở ra mô hình:

Cloudflare Logs → Pipelines → SQL Transform → R2

Doanh nghiệp có thể dùng cho:

Nếu dữ liệu được ghi dưới dạng Iceberg table, doanh nghiệp còn có thể query bằng R2 SQL hoặc các engine tương thích với Apache Iceberg.

Xem thêm: Mua Cloudflare Enterprise tại Việt Nam ở đâu?

12. Cách xử lý dữ liệu trước khi ghi vào R2

Một trong những lợi ích lớn của Pipelines là doanh nghiệp không cần lưu mọi event nguyên trạng.

12.1. Filter

Loại dữ liệu không cần thiết:

12.2. Transform

Chuyển dữ liệu về format chuẩn:

12.3. Select

Chỉ giữ field cần thiết.

Ví dụ raw event có 50 fields nhưng analytics chỉ cần 12 fields. Có thể loại bỏ dữ liệu dư ngay trong ingestion layer.

12.4. Restructure

Đưa dữ liệu từ nhiều nguồn về cùng schema.

Ví dụ:

created_at → timestamp

eventName → event_type

countryCode → country

Cloudflare Pipelines hỗ trợ các thao tác filter, transform, enrich và restructure bằng SQL khi dữ liệu đi từ Stream đến Sink.

13. Monitoring một data pipeline cần theo dõi gì?

Một pipeline không chỉ cần “chạy được”. Doanh nghiệp cần biết dữ liệu có đang đi hết luồng hay không.

Cloudflare Pipelines cung cấp metrics để theo dõi lượng dữ liệu:

Các metrics trên dashboard cũng có thể được truy cập programmatically thông qua Cloudflare GraphQL Analytics API.

13.1. Các chỉ số nên theo dõi

Cloudflare cũng đã bổ sung dropped event metrics để giúp phát hiện sớm vấn đề chất lượng dữ liệu và hiểu vì sao streaming events bị loại bỏ.

14. Khi nào Cloudflare Pipelines và R2 phù hợp?

14.1. Phù hợp khi doanh nghiệp cần

14.2. Đặc biệt phù hợp khi

15. Những điểm cần thiết kế trước khi triển khai

Một data pipeline tốt không bắt đầu từ việc tạo Stream. Nó bắt đầu từ việc xác định dữ liệu nào thật sự cần thu thập.

15.1. Thiết kế event schema

Cần xác định:

15.2. Phân loại dữ liệu

Không nên đẩy mọi dữ liệu vào một Stream duy nhất.

Có thể tách:

15.3. Chọn output format

JSON nếu ưu tiên dữ liệu thô, dễ đọc.

Parquet nếu ưu tiên analytics.

Iceberg nếu muốn xây data lakehouse có khả năng query và quản lý table tốt hơn.

15.4. Thiết kế batching

Cần cân bằng giữa:

Batch quá nhỏ tạo nhiều file. Batch quá lớn làm dữ liệu xuất hiện chậm hơn trong storage.

Cloudflare cho phép cấu hình rolling policy theo kích thước file và thời gian, giúp doanh nghiệp điều chỉnh theo đặc điểm workload.

16. Checklist triển khai Cloudflare Pipelines và R2

16.1. Nguồn dữ liệu

16.2. Schema

16.3. Processing

16.4. Storage

16.5. Monitoring

17. Kết luận: Realtime ingestion hiệu quả cần đi cùng batching và storage phù hợp

Cloudflare Pipelines và R2 tạo ra một kiến trúc phù hợp cho doanh nghiệp cần thu thập dữ liệu liên tục nhưng không muốn tự vận hành nhiều lớp hạ tầng streaming. Event có thể được ingest qua HTTP hoặc Workers, buffer trong Streams, xử lý bằng SQL và tự động chuyển đến R2.

Điểm quan trọng là realtime ingestion không đồng nghĩa với việc ghi từng event thành một file riêng. Pipelines cho phép dữ liệu được tiếp nhận liên tục, sau đó gom batch và lưu dưới dạng JSON, Parquet hoặc Apache Iceberg. Cách tiếp cận này giúp cân bằng giữa tốc độ thu thập dữ liệu và hiệu quả lưu trữ, phân tích về sau.

Với các bài toán như user tracking, clickstream, event logging, security logs hoặc xây dựng data lake trên R2, kiến trúc cần được thiết kế từ event schema, luồng ingest, SQL transformation, batching cho đến format lưu trữ.

Nếu doanh nghiệp đang cần xây dựng hệ thống tracking, event logging hoặc data pipeline trên Cloudflare, LionTech có thể hỗ trợ đánh giá nguồn dữ liệu, thiết kế kiến trúc Pipelines + R2 và xây dựng lộ trình từ realtime ingestion đến analytics phù hợp với nhu cầu thực tế.

Liên hệ với LionTech tại: