Kiến trúc cho xử lý dữ liệu luồng (Streaming Architecture) - Phần 1: Giá trị của Streaming và Kiến trúc Streaming Ingest

Trong nhiều năm, các hệ thống phân tích dữ liệu chủ yếu dựa trên dữ liệu được xử lý theo lô (batch), nghĩa là doanh nghiệp chỉ có thể nhìn thấy những gì đã xảy ra trong quá khứ. Tuy nhiên, khi tốc độ thay đổi của thị trường ngày càng nhanh, việc chờ hàng giờ hoặc hàng ngày để đưa ra quyết định không còn phù hợp. Đây chính là lý do kiến trúc xử lý dữ liệu luồng (Streaming Architecture) ngày càng trở thành một thành phần quan trọng của các nền tảng dữ liệu hiện đại.

Trong bài viết đầu tiên của series Kiến trúc cho xử lý dữ liệu luồng, chúng ta sẽ tìm hiểu vì sao dữ liệu luồng tạo ra lợi thế cạnh tranh, các cấp độ giá trị mà Streaming mang lại, cũng như những kiến trúc phổ biến để thu thập dữ liệu thời gian thực như Streaming ETL, Streaming ELT, Streaming Insert và xử lý dữ liệu từ các thiết bị IoT.

1. Giá trị của dữ liệu luồng

Thời gian là tiền bạc: Quyết định càng nhanh, giá trị càng cao

Giá trị của một quyết định kinh doanh sẽ giảm dần theo thời gian và khoảng cách.

• Ví dụ về sự tiện lợi: Nếu Ngân hàng A mất 3 ngày để duyệt một khoản vay, nhưng Ngân hàng B chỉ mất vài phút, thì Ngân hàng B sẽ có lợi thế cạnh tranh tuyệt đối nhờ tốc độ.

• Ví dụ về ngăn chặn rủi ro: Trong việc phát hiện gian lận thẻ tín dụng, nếu bạn phát hiện ngay lúc thẻ vừa được quẹt, bạn có thể từ chối giao dịch đó ngay lập tức. Nếu đợi vài giờ sau mới biết thì thiệt hại đã xảy ra và việc đòi lại tiền sẽ rất tốn kém.

Đưa ra quyết định đúng ngữ cảnh (In Context)

Dữ liệu luồng không chỉ là về tốc độ, mà còn về việc hiểu ngữ cảnh hiện tại của khách hàng. Việc đưa ra quyết định ngay khi sự việc đang diễn ra (ví dụ: khách đang ở trên website hoặc đang ở gần một cửa hàng) có giá trị cao hơn nhiều so với việc phân tích dữ liệu đó sau vài ngày.

Tầm quan trọng trong các ngành công nghiệp

Các cách mà "dòng chảy dữ liệu" đang thay đổi cuộc chơi trong nhiều lĩnh vực:

• Bán lẻ: Gửi ưu đãi cá nhân hóa ngay khi khách đang xem hàng trên web hoặc thông báo lỗi vận chuyển tức thì.

• Tài chính: Ngăn chặn gian lận và phân tích rủi ro trong tích tắc.

• Y tế: Theo dõi tình trạng bệnh nhân liên tục và cảnh báo ngay khi có dấu hiệu bất thường.

• Viễn thông: Tối ưu hóa độ tin cậy của mạng lưới và ngăn chặn gian lận thuê bao.

Bốn cấp độ giá trị của Streaming

Có 4 mức độ tăng dần:

·       Streaming Ingest (Thu thập luồng): Chỉ đơn giản là đưa dữ liệu vào kho lưu trữ nhanh nhất có thể.

·        Real-time Dashboards (Bảng điều khiển thời gian thực): Giúp con người quan sát diễn biến kinh doanh ngay lúc này qua các biểu đồ.

·        Stream Analytics (Phân tích luồng): Hệ thống tự tính toán và đưa ra cảnh báo cho con người khi thấy có gì đó bất thường (ví dụ: máy móc sắp hỏng).

·        Continuous Intelligence (Trí tuệ liên tục): Đây là cấp độ cao nhất, nơi AI tự động đưa ra hành động mà không cần con người can thiệp.

Tóm lại: Giá trị lớn nhất của Streaming là biến dữ liệu từ "những con số trong quá khứ" thành "hành động trong hiện tại". Thay vì chỉ biết chuyện gì đã xảy ra, doanh nghiệp có thể tác động trực tiếp vào kết quả ngay khi sự việc đang diễn ra.

2. Streaming Ingest (Thu thập dữ liệu luồng)

Streaming Ingest (Thu thập dữ liệu luồng) là bước nền tảng để đưa dữ liệu từ các nguồn phát sinh vào hệ thống lưu trữ ngay lập tức.

Streaming ETL

Thông thường, ETL (Trích xuất - Biến đổi - Nạp) là một quá trình chạy theo định kỳ (ví dụ: mỗi đêm một lần). Tuy nhiên, Streaming ETL thực hiện việc này ngay lập tức khi dữ liệu phát sinh.

Mục tiêu chính của Streaming ETL là đưa dữ liệu vào các kho dữ liệu hiện đại (như BigQuery, Redshift, hay Snowflake) sao cho kết quả truy vấn luôn phản ánh những gì đang xảy ra ngay lúc này. Bước "Biến đổi" (Transform) nằm ở giữa để đảm bảo dữ liệu khi nạp vào kho phải sạch, gọn và sẵn sàng để sử dụng ngay.

Lấy ví dụ về một hệ thống thu thập dữ liệu nhật ký (logs) từ ứng dụng và đưa vào Kho dữ liệu (Data Warehouse).

Local Agent (Tác nhân tại chỗ)

Local Agent có thể được hiểu một cách đơn giản là một "người đưa tin" hoặc một "trạm trung chuyển" được cài đặt ngay tại nơi dữ liệu được sinh ra. Local Agent là thành phần chịu trách nhiệm chính trong việc thu thập và làm cho dữ liệu sẵn sàng để theo dõi hoặc truy vấn trong thời gian thực. Thay vì để ứng dụng tự loay hoay gửi dữ liệu đi, Local Agent sẽ đứng ra làm nhiệm vụ đó để ứng dụng tập trung vào công việc chính của mình.

Có 2 lựa chọn tùy theo nhu cầu của doanh nghiệp:

Con đường thứ nhất: Xử lý theo lô nhỏ (Micro-batching) - Đường nét đứt

Hãy tưởng tượng bạn có một thùng thư. Thay vì mang từng lá thư đi gửi, bạn đợi cứ mỗi 5 phút (hoặc khi thùng đầy) thì mới mang cả xấp ra bưu điện.

• Cách hoạt động: Dữ liệu được ghi tạm vào các tệp trên bộ nhớ đám mây (Cloud Blob Storage). Khi có tệp mới, một hàm xử lý tự động (như AWS Lambda hay Cloud Functions) sẽ được kích hoạt để nạp dữ liệu vào kho.

• Ưu điểm: Tiết kiệm chi phí vì bạn chỉ trả tiền cho hàm xử lý khi nó chạy.

• Nhược điểm: Có độ trễ (dữ liệu có thể cũ từ vài chục giây đến vài phút).

Con đường thứ hai: Đường ống luồng (Streaming Pipeline) - Đường nét liền

Đây giống như một băng chuyền tự động. Mỗi khi có một món hàng (sự kiện) xuất hiện, nó được xử lý và chuyển thẳng đến đích ngay lập tức.

• Cách hoạt động: Từng sự kiện được đẩy vào một hàng đợi tin nhắn (như Kafka hoặc Pub/Sub), sau đó đi qua một đường ống xử lý luồng (như AWS Glue hoặc Google Dataflow) để được chèn thẳng vào kho dữ liệu.

• Ưu điểm: Tốc độ cực nhanh, dữ liệu có sẵn để truy vấn gần như ngay lập tức.

• Nhược điểm: Thường tốn kém hơn do hệ thống phải hoạt động liên tục để sẵn sàng xử lý từng sự kiện.

Tại sao chúng ta cần bước "Biến đổi" (Processing) ở giữa?

Việc xử lý dữ liệu trước khi nạp vào kho là cực kỳ quan trọng để:

• Lọc dữ liệu: Loại bỏ những thông tin rác hoặc không cần thiết.

• Làm sạch: Sửa các giá trị bị thiếu hoặc sai định dạng.

• Nhận diện người dùng: Kết nối các hành động riêng lẻ thành một phiên làm việc duy nhất của khách hàng.

• Bảo mật: Mã hóa hoặc ẩn các thông tin nhạy cảm (như số thẻ tín dụng) trước khi lưu trữ.

Tóm lại: Nếu doanh nghiệp của bạn không yêu cầu dữ liệu phải xuất hiện trong vòng vài giây, hãy chọn cách Xử lý theo lô nhỏ để tiết kiệm chi phí. Chỉ nên sử dụng Đường ống luồng khi tốc độ thực sự là yếu tố sống còn của bài toán kinh doanh.

Streaming ELT

Trong Streaming ETL dữ liệu được "Biến đổi" (Transform) trước khi nạp vào kho. Tuy nhiên, Streaming ELT (Trích xuất - Nạp - Biến đổi) lại đảo ngược quy trình này:

• Ý tưởng: Thay vì cố gắng dự đoán xem người dùng cần gì để dọn dẹp dữ liệu trước, bạn nạp thẳng dữ liệu thô (raw data) vào kho dữ liệu (DWH) hoặc hồ dữ liệu (Data Lake) ngay lập tức.

• Tại sao lại chọn ELT: ELT phù hợp khi bạn có nhiều nhóm người dùng khác nhau với các nhu cầu phân tích khác nhau mà bạn không thể dự đoán hết được. Ngoài ra, nếu các bước biến đổi dữ liệu đòi hỏi kiến thức chuyên môn về nghiệp vụ (ví dụ: kế toán, nhân sự), thì để người dùng nghiệp vụ tự thực hiện phép biến đổi trong kho dữ liệu sẽ hiệu quả hơn là nhờ các lập trình viên làm thay.

• Hiệu quả kinh tế: Một điểm thú vị là: dữ liệu càng lớn thì việc nạp và xử lý liên tục (Streaming ELT) càng trở nên rẻ và hiệu quả hơn so với việc đợi nạp theo lô lớn mỗi ngày.

Hình trên mô tả cách dữ liệu đi từ ứng dụng vào kho dữ liệu mà không đi qua các bước lọc hay làm sạch phức tạp ở bên ngoài.

• Hai con đường nạp dữ liệu:

• Đường nét đứt (Load - Micro-batching): Dữ liệu được gom lại thành những tệp nhỏ và nạp vào kho theo từng đợt ngắn.

• Đường nét liền (Insert - Events happen): Từng sự kiện được chèn trực tiếp vào kho ngay khi nó vừa phát sinh.

• "Phép thuật" nằm trong Kho dữ liệu: Điểm quan trọng nhất là "Materialize view" bên trong ô Data Warehouse (Materialize view là một view lưu sẵn kết quả của truy vấn, giúp truy vấn nhanh hơn vì không phải tính toán lại mỗi lần truy cập nhưng cần được làm mới (refresh) để phản ánh những thay đổi của dữ liệu nguồn). Thay vì biến đổi dữ liệu trên đường đi, dữ liệu thô được nạp vào, sau đó sử dụng các "Materialize view" để tự động biến các dữ liệu thô đó thành các bảng kết quả sạch sẽ và gọn gàng ngay bên trong kho dữ liệu.

• Lợi ích: Cách làm này giúp dữ liệu luôn sẵn sàng ở trạng thái thô nhất để phục vụ các mục đích kiểm tra hoặc phân tích sâu sau này, đồng thời vẫn cung cấp kết quả nhanh chóng cho các báo cáo thông qua các View đã được tính toán sẵn.

Tinh thần ở đây: Đừng làm phức tạp hóa đường ống dữ liệu ở bên ngoài. Nếu kho dữ liệu của bạn đủ mạnh (như BigQuery hay Snowflake), hãy đẩy toàn bộ dữ liệu vào đó và tận dụng sức mạnh của SQL để biến đổi dữ liệu. Điều này không chỉ giúp dữ liệu luôn cập nhật (fresh) mà còn cho phép nhiều người trong tổ chức có thể tiếp cận và sử dụng dữ liệu một cách linh hoạt nhất.

Streaming Insert

Việc đưa dữ liệu vào kho (Data Warehouse - DWH) thường cần các "người vận chuyển" trung gian như Local Agent (tác nhân tại chỗ) hoặc các đường ống xử lý (Streaming Pipeline). Tuy nhiên, Streaming Insert (Chèn dữ liệu luồng) là một phương pháp "đi tắt" hiện đại hơn.

• Ý tưởng: Thay vì phải cài đặt một phần mềm trung gian để gom dữ liệu rồi mới gửi đi, chính ứng dụng của bạn (ví dụ: trang web hoặc ứng dụng di động) sẽ tự tay "chèn" thẳng dữ liệu vào kho ngay khi có sự kiện phát sinh.

• Tại sao lại chọn cách này: Nếu Kho dữ liệu (DWH) của bạn cung cấp một giao diện lập trình ứng dụng (Streaming API), thì các ứng dụng hiện đại có thể bỏ qua mọi bước trung gian phức tạp. Điều này giống như việc bạn tự mình mang lá thư đến tận tay người nhận thay vì phải bỏ vào thùng thư và đợi bưu tá đến lấy.

• Ứng dụng (Applications): Chứa một thành phần nhỏ gọi là Client library (thư viện máy khách) của nhà cung cấp đám mây.

• Hành động (Insert): Mũi tên đi thẳng từ ứng dụng tới Kho dữ liệu mà không có bất kỳ trạm dừng nào ở giữa.

• Ví dụ thực tế: Google BigQuery, nơi việc chèn dữ liệu luồng có thể được thực hiện chỉ bằng một lệnh gọi API đơn giản qua ngôn ngữ lập trình Python. Tương tự, Snowflake cũng có tính năng "Snowpipe Streaming" để làm điều này.

Tinh thần ở đây: Càng ít thành phần trung gian, hệ thống càng nhanh và gọn nhẹ.

• Nếu ứng dụng của bạn được xây dựng theo kiểu "thuần đám mây" (cloud-native), hãy tận dụng các thư viện có sẵn để gửi dữ liệu trực tiếp 

         Cloud Native là gì? Tư duy thiết kế hệ thống hiện đại cho thời đại đám mây

• Cách tiếp cận này giúp giảm bớt gánh nặng quản lý các máy chủ trung gian và giúp dữ liệu xuất hiện trong kho để phân tích gần như ngay lập tức sau khi sự kiện xảy ra.

Một số hệ thống nhắn tin (như Google Pub/Sub) cũng cho phép tự động đẩy dữ liệu vào kho ngay khi nhận được sự kiện, giúp ứng dụng chỉ việc gửi tin nhắn đi mà không cần lo lắng về phần còn lại.

Luồng từ các thiết bị nằm ở biên (IoT)

Đối với các thiết bị Internet vạn vật (IoT) nằm ở "biên" (edge) — như cảm biến trong nhà máy, camera an ninh hay thiết bị thông minh —chúng ta cần những giải pháp đặc biệt và chuyên dụng hơn là những hàng đợi tin nhắn thông thường.

Tại sao lại cần chuyên dụng? Vì các thiết bị này thường nằm ở những nơi có kết nối mạng không ổn định, cần được quản lý từ xa và đôi khi cần phải tự đưa ra quyết định ngay tại chỗ mà không chờ lệnh từ đám mây.

Hình trên minh họa một kiến trúc chuyên biệt để xử lý luồng dữ liệu từ IoT:

• Phía Biên (Edge): Thay vì chỉ có một "Local Agent" đơn giản, tại đây có các thiết bị (Device) chạy phần mềm biên (Edge software) hoặc bộ công cụ phát triển phần mềm (Edge SDK). Phần mềm này rất thông minh: nó có thể tự xử lý dữ liệu, quản lý bộ nhớ cục bộ và thậm chí chạy các mô hình AI ngay trên thiết bị.

• Hành động (Insert): Dữ liệu được chèn trực tiếp từ biên vào một "trạm tiếp nhận" trên đám mây.

• Phía Đám mây (Cloud): Thành phần quan trọng nhất ở đây là IoT Core (hoặc các dịch vụ tương đương như AWS IoT Core, Azure IoT Hub). Đây đóng vai trò là "bộ não trung tâm" trên mây để quản lý hàng triệu thiết bị, xử lý việc thiết bị mất kết nối và đảm bảo dữ liệu được đưa vào Kho dữ liệu (Data warehouse) một cách an toàn.

Các ví dụ cụ thể từ ba "ông lớn" điện toán đám mây:

• Microsoft Azure: Sử dụng IoT Devkit (phần cứng/phần mềm ở biên) kết hợp với IoT Hub trên mây.
• Amazon Web Services (AWS): Sử dụng phần mềm AWS IoT Greengrass ở biên và AWS IoT Core trên mây.
• Google Cloud: Sử dụng thiết bị Coral và phần mềm TensorFlow Lite ở biên kết hợp với Clearblade IoT Core trên mây.

Tinh thần ở đây: Đừng để bị "khóa chặt" vào một nhà cung cấp. Dù bạn dùng dịch vụ của bên nào, hãy ưu tiên các giao thức tiêu chuẩn (như MQTT). Việc này giúp bạn giữ được sự linh hoạt, có thể thay đổi nhà cung cấp hoặc hỗ trợ các loại thiết bị khác nhau trong tương lai mà không phải viết lại toàn bộ hệ thống từ đầu.

Luồng dữ liệu từ IoT không chỉ là gửi tin nhắn, mà là xây dựng một hệ thống bền bỉ, có khả năng quản lý thiết bị từ xa và tự phục hồi khi gặp sự cố mạng, giúp dữ liệu luôn chảy về kho lưu trữ để phân tích kịp thời.

Kết luận

Streaming không đơn thuần là truyền dữ liệu nhanh hơn, mà là khả năng đưa doanh nghiệp đến gần thời điểm phát sinh sự kiện nhất có thể. Khi dữ liệu được thu thập liên tục và sẵn sàng để phân tích gần như ngay lập tức, doanh nghiệp có thể chuyển từ việc phản ứng với quá khứ sang chủ động hành động trong hiện tại.

Trong bài tiếp theo của series, chúng ta sẽ tiếp tục tìm hiểu cách dữ liệu luồng được khai thác để xây dựng Real-time Dashboards và thực hiện Stream Analytics, giúp hệ thống không chỉ quan sát mà còn phát hiện các vấn đề và cơ hội ngay khi chúng xuất hiện.

Kiến trúc cho xử lý dữ liệu luồng (Streaming Architecture) - Phần 2: Real-time Dashboards và Stream Analytics

Kiến trúc cho xử lý dữ liệu luồng (Streaming Architecture) - Phần 3: Continuous Intelligence và AI thời gian thực