IoT 感測器兼顧即時性、完整性、可擴展性，哪種架構最合適？

情境

先感受問題：三個要求，選項 A 只能同時滿足一個

東嶸製造導入了 10,000 台生產設備感測器，每台每 100 毫秒回傳一次溫度和震動資料。

IT 架構師立偉面對三個要求：

要求 1：毫秒級即時性：設備異常要在 500 毫秒內觸發停機警報，避免設備損壞。

要求 2：資料完整性：所有歷史感測器資料要完整保留，供未來訓練預測性維護模型。

要求 3：可擴展性：未來可能增加到 50,000 台感測器，系統架構要能橫向擴展。

這三個要求的困難在於：

要即時，資料就得在「靠近設備的地方」就處理，不能先傳到遠端雲端再計算（網路延遲太高）。

要完整性，所有原始資料都得傳到雲端儲存，不能在本地就丟掉。

要可擴展，架構不能是單機，必須是分散式、可水平擴展的設計。

舊方法

不同架構為什麼分別只能滿足部分要求

1. 直接傳雲端的延遲問題：感測器 → 雲端 API Gateway → 分析，中間需要網路往返（Round-Trip Time），即使光纖也需要 10-50 毫秒，加上雲端處理時間，毫秒級回應幾乎做不到。設備異常時，警報已經來不及。
2. 批次處理的延遲問題：批次特徵工程（Batch Feature Engineering）是累積一段時間的資料後一起計算，天然無法達到毫秒級響應。用在事後分析很好，但不適合即時監控。
3. 資料倉儲不適合存原始感測器資料：資料倉儲（Data Warehouse）設計給結構化的商業智慧查詢，不適合存儲每 100 毫秒一筆的高頻時序原始資料。資料湖（Data Lake）才能以低成本存儲大量原始格式資料。
4. RESTful API 的吞吐量瓶頸：RESTful API 每個請求需要建立 HTTP 連線，10,000 台設備每 100 毫秒各發一個請求，每秒 100,000 個 HTTP 請求，API Gateway 很快就達到瓶頸。MQTT 或 Kafka 等訊息協定設計來處理這種高頻連接。
5. 無法同時做即時和事後分析：如果架構只設計了「即時路徑」（本地邊緣計算但不存雲端），就無法用完整歷史資料做 AI 模型訓練；如果只設計了「批次路徑」（存到雲端但不在本地即時計算），就達不到毫秒級響應。

新方法

三層架構：邊緣即時 + 流式處理 + 雲端資料湖

東嶸製造立偉設計的架構分三層：

第一層：感測器 → 邊緣運算節點

每個廠區有一台邊緣計算伺服器，接收附近幾百台感測器的資料。邊緣節點在本地就做初步計算，不需要先傳到雲端，網路延遲從 50ms 降到 1-2ms。

第二層：邊緣節點 → 流式資料處理框架（Stream Processing Framework）

使用 Apache Flink 或 Apache Kafka Streams，在資料「流動的當下」做異常偵測計算（例如：滑動視窗內溫度均值超閾值），觸發毫秒級警報。同時，這層也把資料串流分成兩路：一路送到即時告警，另一路傳到雲端儲存。

第三層：流式處理 → 雲端資料湖（Data Lake）→ 模型推論和訓練

所有原始感測器資料完整傳到雲端資料湖（如 AWS S3、Azure Data Lake）長期保存，供後續 AI 模型訓練用。

這就是選項 C 講的：感測器 → 邊緣運算節點 → 流式資料處理框架（Stream Processing Framework）→ 雲端資料湖 → 模型推論。

錯選項

為什麼其他選項是錯的

變形題

同個考點下次怎麼變形

延伸

想再往下看，這 5 個

• Edge AI（邊緣人工智慧）
  在感測器附近的邊緣節點執行 AI 推論，毫秒級響應的核心技術。
• 資料湖（Data Lake）
  以原始格式儲存海量多元資料，IoT 歷史感測器資料長期保存的首選。
• 即時推論（Real-time Inference）
  在流式資料進來的當下就輸出預測結果，工業 IoT 異常偵測的核心能力。
• 資料管線（Data Pipeline）
  從感測器到資料湖的完整資料流動路徑設計，IoT 架構的骨幹。
• 異常偵測（Anomaly Detection）
  在流式資料處理框架中即時識別設備異常，是這套架構的核心業務目標。