淹水

當城市承受瞬間暴雨、河流氾濫，淹水不再只是天災，而是考驗軟體架構、數據管線與即時反應能力的工程競賽。在那些決定性的數分鐘內，毫秒級的事件串流處理、邊緣感測器的雜訊濾除，以及機器學習模型的推論延遲，直接關乎人命與財產安全。我們在生產環境中看過，一套設計不良的淹水警報管線，比淹水本身更早淹沒救災單位的通訊頻道。這篇文章從資深軟體架構師的視角，拆解淹水監測、預測到警報發佈的完整技術棧，並分享我們在實務中踩過的坑。

淹水（flooding）這個議題，表面上是水利工程，但當資料以每秒數十萬筆從物聯網裝置灌入，問題立刻變成高吞吐量的串流處理、地理空間索引、以及多雲環境的訊息推播可靠度。我將用實際可用的開源工具、雲端服務與分散式設計模式，說明如何打造一套能撐過洪峰考驗的淹水應變平台。以下所有討論，都基於我們幫地方政府與港口管理單位建置系統的實戰經驗，每一段架構決策都有具體的 trade-off 分析。

淹水監測系統的感測層架構與邊緣運算

淹水監測的第一步，是建立可靠的水位與雨量感測網路。傳統的水文站使用 PLC 搭配 4G 路由器，但在都市淹水的場景裡，我們需要更密集的感測點：道路積水感測器、下水道人孔蓋下的超音波水位計、甚至攝影機進行影像淹水辨識。這些裝置的通訊環境極不穩定，因此邊緣運算成為必要條件。我們選擇了 NVIDIA Jetson Nano 與 Raspberry Pi 4 建構邊緣閘道，搭配 Rust 撰寫的輕量級 MQTT 客戶端，把原始感測資料以 Protocol Buffers 格式壓縮後傳輸。

邊緣端不只是轉發資料，還負責初步的淹水風險推論。我們部署了一套輕量化的 TensorFlow Lite 模型，能根據前五分鐘的水位上升速度、累積雨量，直接判斷是否觸發本地警報。這解決了 4G 斷網時中央系統無法即時反應的致命缺陷。實測發現，將推論移到邊緣後，淹水告警從雲端回傳的端到端延遲從 920ms 降到 40ms，這在淹水速度超過每小時 30 公分的情境裡，等於多爭取到 25 秒的逃生窗口。

邊緣裝置的電力與防水也是工程挑戰。我們在台北市區實地安裝時，發現即使 IP68 規格的防水盒，在高濕度環境下仍會因為日夜溫差內部結露。後來導入主動式除濕控制器，並以 Prometheus 監控溫濕度與電池電壓，才讓裝置的 MTBF 從三週提升到超過一年。這些基礎設施細節，往往是淹水監測系統從 PoC 走向正式營運的關鍵障礙。

即時水文數據流處理與串流平台選型

當淹水感測點擴張到 2,000 點、每五秒回傳一筆資料，中央系統每秒就得消化四百筆訊息。我們選擇 Apache Kafka 作為訊息骨幹，搭配 KSQL 進行水位異常的即時過濾與聚合。原始資料從 MQTT broker 透過 Kafka Connect 的 MQTT source connector 流入，避免自行開發協定轉換程式。我們也設定了 compact 的 topic 來維護每個感測點的最新水位狀態，供 API 查詢使用，同時保留 append-only 的原始事件 topic 給後續模型訓練。

淹水監測的資料流有一個特殊需求：延遲異常偵測。水位突然從正常值跳到淹水警戒線，通常代表感測器故障而非真實淹水。我們利用 Kafka Streams 實作 hopping window 的變異數分析，當水位值超出六倍標準差時自動標記為可疑，並通知維運團隊。這套機制讓誤報率從原本的 23% 大幅降到 4%，大幅減輕應變中心的負擔。相關的資料流處理邏輯也可以擴展到其他水文資料，例如河川流速與雨量筒數據的交叉驗證。

針對淹水高峰時期的流量暴增，我們採取 backpressure 與 elastic scaling 策略。Kafka 叢集在 Kubernetes 上以 Strimzi operator 管理，配合 KEDA 根據 consumer lag 動態擴充 pod 數量。我們也在 Kafka 生產端設定了不重試、失敗即捨棄的寫入策略，避免在網路不穩時讓邊緣裝置資源耗盡。這些設計確保淹水事件發生時，資料管線不會因為流量 spike 而崩塌，維持警報的連續性。

淹水預測模型的機器學習實戰

淹水預測的本質是時間序列迴歸結合空間推論。我們最初試圖用 XGBoost 處理結構化水文數據，但發現淹水的非線性暴漲特徵很難被梯度提升樹捕捉。後來轉向 基於注意力的時序卷積神經網路（TCN），並參考了 TensorFlow Time Series 官方教學中的進階模式，自行設計了多變數輸入架構：同時餵入過去一小時的雨量、潮位、下水道水位與堰門開度，預測未來十五分鐘的淹水面積與深度。

模型訓練的瓶頸在於淹水標記資料極度不平衡--日常正常資料佔 99. 7%，淹水事件稀少。為此我們採用 SMOTE-ENC 合成少數樣本，並在 loss function 中加入 focal loss 加權，強化模型對淹水事件的敏感度。最終在測試涵蓋 2023 年幾次颱風的真實資料上，預測淹水是否發生的召回率達到 0. 91，且能提前 12 分鐘發出警戒。我們將模型封裝成 MLflow 模型服務，透過 gRPC 端點讓下游警報系統呼叫，p99 推論延遲控制在 180ms 內。

淹水模型的可解釋性同樣重要，因為水利單位需要知道為何系統建議關閉某個抽水站。我們整合了 SHAP 值計算，在每個預測請求的 metadata 裡附上各特徵的影響權重，並用 Streamlit 建立給防災工程師的互動式儀表板。淹水風險不再是黑箱，工程師能比對模型推論與自身經驗，快速建立信任，這在決策生死關頭格外關鍵。

地理資訊系統與淹水風險圖資整合

淹水量測沒有空間座標就毫無意義。我們使用 PostGIS 儲存感測點的經緯度、淹水範圍多邊形，以及 Lidar 產出的高解析度 DEM 數值地形模型。淹水模擬結果透過 GeoJSON 格式發布，前端以 MapLibre GL JS 渲染，確保即使在行動裝置上也能流暢顯示淹水潛勢圖。地理空間索引的選擇直接影響查詢效能：對經常查詢的近期淹水事件，我們使用 R-tree 索引，並將資料按時間分區（partition），讓存取頻繁的最近三天資料集中於 SSD 快層。

淹水圖資的來源多元，包括政府開放平台的河川水位站、雷達雨量估計，以及我們自行布建的淹水感測器。整合這些異質資料時，坐標系統的轉換（TWD97 → WGS84）常出現半公尺以內的偏移，對都市排水系統的精確定位造成困擾。我們為此寫了一組 Python 工具，利用 GDAL 庫自動校正並輸出統一的 Cloud Optimized GeoTIFF (COG)，讓淹水視覺化與分析都能直接取用雲端儲存的單一檔案，不需下載整份圖資。

淹水風險的呈現不能只有靜態地圖。我們透過 Apache Sedona 在 Spark 叢集上執行大規模空間交集運算，將即時水位數據與淹水潛勢圖疊合，動態計算每條道路的淹水風險分級。這些結果經由 OGC API - Features 標準介面餵給「淹水儀表板」，讓救災人員一眼看出哪些路段即將封閉、那些地下道必須預先拉起封鎖線。

雲端架構下的淹水警報發布機制

當淹水預測模型判定風險超過閾值，警報必須在五秒內送達數以萬計的訂閱者--包含防災人員的手機、轄區內的公共廣播系統、以及民眾的 App 推播。我們設計了一套多雲的訊息派送管線：警報事件先寫入 Google Cloud Pub/Sub，再由多個 subscriber 並行處理，各自負責 SMS（透過 Twilio）、FCM 推播（Android）、APNs（iOS），以及 LTE 細胞廣播（CBS）的觸發。為確保跨雲高可用，我們同時在 AWS 部署了對等的備援管線，利用 Route 53 的 health check 自動切換。

淹水警報的推送最怕重複通知與延遲。我們採用 exactly-once 語意不容易實現，實務上改用 idempotent key 設計：每則警報帶有唯一的事件 ID，客戶端維護已處理 ID 的布隆過濾器，避免重複顯示。在訊息格式上，我們定義了簡潔的 JSON 結構，包含淹水地點的 polyline、預估水深、疏散建議，並限定 payload 必須在 4KB 以內，以確保低頻寬環境仍可順利傳遞。

淹水期間的流量會瞬間爆量，因此我們在所有推播通道前都設置了 rate limiter 與優先級佇列。高優先級（淹水已開始）訊息直接略過佇列以最低延遲推送，日常測試警報則可在系統滿載時被延遲。我們曾經歷某次大型演練，十分鐘內湧入六百萬次推播請求，因為事前規劃了自動水平擴展的 Fastly Edge 推播端點，加上 Redis 快取訂閱者 token，系統在 99% 的請求上都維持低於 600ms 的端到端延遲。

開源工具與開放數據在淹水分析中的應用

建置淹水監測系統不一定需要鉅額