Thực hành: dựng đường ống thu thập và lưu dữ liệu cảm biến IoT cho nhà máy của khách

Thử hình dung một dây chuyền có 200 cảm biến, mỗi cảm biến gửi một số đo mỗi giây. Nhân với 86.400 giây trong ngày, bạn có 17.280.000 bản ghi. Với khối lượng ấy, một lựa chọn sai về khóa lưu trữ không còn là lỗi nhỏ, vì nó lặp lại hàng chục triệu lần mỗi ngày.

Tài liệu giới thiệu của Apache Kafka nêu thẳng use case này: liên tục thu thập và phân tích dữ liệu cảm biến từ thiết bị IoT, chẳng hạn ở nhà máy hay trang trại điện gió. Nếu muốn làm FDE cho khách hàng sản xuất, sớm muộn bạn cũng sẽ phải dựng một đường ống như vậy ngay trong xưởng của họ.

Phần dưới đây phác thảo đường ống đó qua năm bước, từ cảm biến, giao thức ở biên, Kafka cho tới kho lưu trữ. Mục tiêu không phải cài đặt từng thành phần, mà là chốt đúng các quyết định thiết kế trước khi bạn viết dòng code đầu tiên ở site khách.

Bạn sẽ dựng gì, và cần chuẩn bị gì?

Kết quả cuối cùng gồm một sơ đồ năm khối, một schema sự kiện, giả mã cho phần ghi vào Kafka và phần đọc ra, cùng một thiết kế row key có lý do rõ ràng. Toàn bộ code trong bài là giả mã đã đơn giản hóa, không gắn với API của thư viện nào.

Bạn cần nắm khái niệm publish/subscribe, biết đọc JSON và hiểu sơ qua NoSQL dạng key/value. Nên có sẵn một tờ giấy nháp, vì phép tính tải là phần người mới hay bỏ qua nhất.

Bước 1: Biết xưởng có những cảm biến nào trước khi viết code

IBM định nghĩa cảm biến là thiết bị phát hiện thay đổi trong môi trường. Trong sản xuất, IoT công nghiệp được dùng để giám sát hiệu suất máy. Vì vậy, câu hỏi đầu tiên ở site không phải “dùng Kafka bản nào” mà là “cần theo dõi máy nào, và cảm biến nào đang đo nó”.

Hãy lập một bảng liệt kê cảm biến với các cột: id, máy gắn cảm biến, đại lượng đo, đơn vị, tần suất gửi và giao thức. Đây là thứ đầu tiên bạn ngồi rà lại cùng kỹ sư vận hành của khách.

Kiểm tra: dòng nào trong bảng cũng phải có tần suất gửi. Thiếu cột này, bạn không tính được tải ở bước 5.

Bước 2: Chốt hình dạng của một sự kiện

Kafka định nghĩa event streaming là việc thu thập dữ liệu theo thời gian thực từ các nguồn như database và cảm biến. Mỗi số đo sẽ trở thành một sự kiện, nên cần chuẩn hóa sự kiện ngay từ đầu:

{
  "plant": "nha-may-a",
  "line": "line-3",
  "sensor_id": "temp-042",
  "metric": "temperature_c",
  "value": 71.4,
  "ts": "2026-10-09T08:00:01Z"
}

Đơn vị được ghi thẳng vào tên metric, còn thời gian dùng một định dạng thống nhất. Đây là lựa chọn thiết kế của bài chứ không phải chuẩn bắt buộc. Dù vậy, nó tránh được một lỗi kinh điển: hai dây chuyền gửi nhiệt độ theo hai đơn vị khác nhau mà không ai hay.

Kiểm tra: nhìn vào một sự kiện bất kỳ, bạn biết ngay nó đến từ nhà máy nào, dây chuyền nào, cảm biến nào và được đo lúc mấy giờ.

Bước 3: Để MQTT và OPC UA làm việc ở biên

Kai Waehner, người viết nhiều về data streaming, cho rằng MQTT rất hợp với mạng chập chờn và băng thông hạn chế. Theo ông, OPC UA hợp với tự động hóa công nghiệp, còn Kafka bổ trợ chứ không cạnh tranh với hai giao thức này.

Trên thực tế, bạn giữ nguyên giao thức mà thiết bị của khách đang dùng, rồi thêm một lớp chuyển tiếp từ MQTT hoặc OPC UA vào Kafka. Tôn trọng hạ tầng sẵn có giúp bạn lấy được lòng tin của đội vận hành nhanh hơn bất kỳ bộ slide kiến trúc nào.

Kiểm tra: cột giao thức trong bảng ở bước 1 giờ đã có giá trị cho từng cảm biến.

Bước 4: Publish vào Kafka, subscribe để ghi xuống kho

Kafka cho phép publish (ghi) và subscribe (đọc) các luồng sự kiện. Phía ghi có giả mã như sau:

# Giả mã, đã đơn giản hóa
for message in nguon_mqtt_hoac_opcua:
    event = chuan_hoa(message)        # đúng schema ở bước 2
    publish(topic="sensor-readings", value=event)

Phía đọc subscribe cùng topic đó và ghi xuống kho lưu trữ:

# Giả mã, đã đơn giản hóa
subscribe(topic="sensor-readings")
for event in stream:
    row_key = tao_row_key(event)      # thiết kế ở bước 5
    write(table="readings", key=row_key, value=event)

Hàm chuan_hoa là nơi xử lý đơn vị, múi giờ và các trường bị thiếu. Hãy dồn mọi logic làm sạch vào đây thay vì rải ra từng consumer.

Bước 5: Row key mới là quyết định quan trọng nhất

Bigtable là NoSQL phân tán. Mỗi bảng là một map key/value đã được sắp xếp, và mỗi hàng được đánh chỉ mục bằng đúng một row key. Bigtable được dùng cho cả dữ liệu time-series lẫn IoT. Vì hàng nằm theo thứ tự khóa, cách bạn ghép row key quyết định truy vấn nào sẽ nhanh.

Lý do nằm ngay ở chuyện bảng được sắp theo khóa. Nếu khóa bắt đầu bằng thời gian, bản ghi mới luôn có khóa lớn hơn mọi khóa cũ, nên mọi lượt ghi đều dồn về cùng một đầu của bảng.

Hệ quả suy ra trực tiếp từ đó: trong một hệ phân tán, đầu bảng ấy nằm trên một phần cụm, nên một node phải gánh gần hết 17.280.000 lượt ghi mỗi ngày trong khi các node khác gần như ngồi chơi. Đó là điểm nóng ghi (hotspot). Thêm máy cũng không giải quyết được, vì lượt ghi mới vẫn dồn về cùng một chỗ.

Ngược lại, khi khóa bắt đầu bằng thiết bị, lượt ghi của 200 cảm biến được rải ra 200 dải khóa khác nhau. Lịch sử của mỗi cảm biến cũng nằm liền nhau, và câu hỏi “máy X tuần qua thế nào” chỉ cần đọc đúng một dải khóa.

Phân tích row key ở trên dựa trên mô hình sắp xếp theo khóa của Bigtable. Nếu khách dùng Cassandra, tài liệu của dự án cho biết throughput đọc và ghi tăng tuyến tính khi thêm máy. Kiến trúc masterless giúp Cassandra chịu được sự cố của cả một data center mà không mất dữ liệu, và node hỏng có thể thay mà không gây downtime.

Những đặc tính đó lo phần quy mô, còn khóa thì vẫn do bạn thiết kế, theo đúng logic ở trên. Một phương án (đã đơn giản hóa) là chọn khóa phân vùng gồm sensor_id và ngày, ví dụ temp-042 + 2026-10-09, rồi sắp các hàng trong mỗi phân vùng theo ts.

Mỗi phân vùng khi đó chứa đúng 86.400 số đo của một cảm biến trong một ngày, lượt ghi được rải đều theo cảm biến, còn câu hỏi “máy 3 hôm qua” chỉ chạm vào một phân vùng.

Kiểm tra: viết ra ba câu truy vấn khách quan tâm nhất, rồi chỉ rõ row key của bạn phục vụ từng câu như thế nào.

Những lỗi khiến đường ống gãy ngay tuần đầu

Lỗi phổ biến nhất là chọn khóa theo thứ tự dữ liệu đến. Quay lại nhà máy giả định ở đầu bài: một tuần có 7 × 17.280.000 = 120.960.000 bản ghi, trong khi cảm biến trên máy 3 có 604.800 bản ghi. Quản đốc hỏi “máy 3 tuần qua ra sao?”.

Với khóa bắt đầu bằng thời gian, 604.800 bản ghi đó nằm xen kẽ với dữ liệu của 199 cảm biến còn lại. Hệ thống phải lướt qua cả dải 120.960.000 hàng để lọc ra phần cần. Với khóa bắt đầu bằng thiết bị, đó chỉ là một dải liền mạch.

Lỗi kế tiếp là bỏ qua phép tính tải. Hãy nhân số cảm biến với tần suất gửi và số giây trong ngày trước khi chọn kích thước cụm, đừng đợi đến lúc hệ thống đã chậm.

Cũng đừng để bảo mật lại làm sau. Vì luôn kết nối với nhau, thiết bị IoT dễ bị xâm nhập và gặp vấn đề về quyền riêng tư. Mỗi lần kéo dữ liệu ra khỏi mạng xưởng, bạn đang mở thêm một lối vào.

Vì thế, trước ngày đầu tiên ở site, hãy hỏi đội IT/OT của khách: bạn được truy cập mạng nào, dữ liệu được phép đi ra theo hướng nào, và ai duyệt các thay đổi. Kiến trúc của bạn phải đi theo những câu trả lời này, chứ không phải ngược lại.

Kỹ năng này xuất hiện ở site khách và trong CV ra sao?

Họ hỏi vì sao máy số 3 hay dừng và muốn xem lịch sử của nó. Một FDE giỏi biến câu hỏi đó thành row key, thành topic, thành bảng liệt kê cảm biến, rồi mang những thứ đó đi trao đổi lại với kỹ sư vận hành.

Khi đọc mô tả công việc, hãy để ý các từ khóa IIoT, OPC UA, MQTT, time-series và streaming khi chúng đi cùng cụm “customer-facing”. Trong CV, đừng chỉ ghi “dùng Kafka”. Hãy kể bài toán: bao nhiêu cảm biến, tần suất gửi ra sao, bạn chọn row key nào và vì sao.

Nếu chưa có dự án thật, hãy tự dựng một dự án với dữ liệu cảm biến giả lập, kèm phép tính tải và lập luận về thiết kế khóa, rồi mang nó vào buổi phỏng vấn. Đến tuần thứ hai ở xưởng, khách cần một người hiểu chiếc máy đang phát ra dữ liệu, chứ không cần thêm một người chỉ biết cài phần mềm.