1. 從一張乾淨的表，往前追到訊息入口

Day 13 我關心的是清洗後的設備讀數能否通過檢查、每日統計能否追到來源。但如果設備持續送來事件，我還得往前問：資料進入 BigQuery 之前，發生了什麼？同一筆讀數可能因網路中斷而重送，也可能已經收到，卻在寫入下一站時失敗。只看最後的表格，我不一定看得出這些差異。

這次串流資料實作讓我先從 Pub/Sub 入手。Pub/Sub 是以主題（topic）接收發布者的訊息，再由訂閱（subscription）交給接收端。

2. 我先建立訂閱，才發布測試訊息

實作時，我建立主題及拉取型訂閱，發布 JSON 訊息，再從訂閱拉取並確認收到。順序不是形式上的差別：訂閱會從建立後開始替自己保留符合條件的訊息。若要取得更早發布的訊息，必須事先考慮主題的訊息保留等設定，不能期待事後建立一個訂閱就自動擁有所有歷史資料。

拉取畫面出現訊息時，我一開始容易把它當成「已處理」。其實拉取只表示接收端拿到了訊息；確認（acknowledgment，簡稱 ack）才是告訴 Pub/Sub，這次交付已完成。官方文件說明，接收端必須在確認期限內回覆；逾期時，訊息可能再次投遞。對設備資料而言，這意味著寫入結果表的動作和確認訊息的時機，需要一起設計。若還沒完成寫入就先確認，後面的失敗便可能沒有原訊息可重試。

3. 讓一直失敗的訊息有地方可查

附檔的另一段操作，是建立死信主題及其訂閱，設定原訂閱的轉送規則和必要權限，再反覆拉取但不確認訊息，觀察無法順利處理的訊息最後去哪裡。這讓我第一次把「重試」與「隔離」視為兩件事：暫時失敗可以再試，持續失敗則需要有人看得見、查得到。

Google Cloud 把死信主題稱為 dead-letter topic。它適合存放反覆無法交付的訊息，但設定的最大投遞次數是近似值，轉送採盡力而為；不能把它寫成「恰好重試指定次數後一定轉入」。如果設備訊息欄位不完整，死信佇列的價值也不是自動修好資料，而是留下來源、錯誤原因與後續處置的線索。權限沒有設對，投遞次數的計算與轉送也可能不如預期。

4.「至少一次」讓去重成為下游的責任

Pub/Sub 訂閱預設採至少一次投遞。即使來源只發布一次，同一則訊息也可能因確認期限或處理失敗而再次送達。因此 Day 13 所談的「同一事件不能重複計入」，不只是一條清洗 SQL，也是一項從訊息入口延伸到結果表的規則。

我會讓來源端替每次測量提供穩定的事件識別資訊，再在下游依約定規則判斷是否已處理。這裡不能單靠 Pub/Sub 產生的訊息 ID：如果設備或中介程式把同一筆業務事件重新發布成一則新訊息，新的發布行為就不是原訊息的再次投遞。Pub/Sub 也提供拉取型訂閱的「精確一次投遞」選項，但它所保證的是特定訂閱的投遞與確認語意，不能替來源重複發布、BigQuery 表格寫入或業務上的去重作出端到端保證。

5. 需要重查時，先確認當初保留了什麼

我原本以為，只要訊息曾進過主題，將來就能隨時重拉。官方文件讓這個想法變得具體：訂閱預設會保留未確認訊息一段時間，但已確認的訊息預設會從該訂閱移除；若要重播已確認訊息，需設定相應的保留與 seek（把訂閱讀取位置移到指定時間或快照）條件。主題訊息保留也會影響新訂閱能否取得建立前發布的訊息。

這會改變我做測試的順序。若設備更新後才發現解碼規則有誤，「重新處理昨天的事件」是否可行，取決於昨天是否真的留下可重播的訊息，而不是今天多寫一條查詢。保留時間越長也會牽涉儲存費用，因此它需要和可追溯的需求一起決定。

6. 我會用三種事件驗收入口

完成這次操作後，我不再以「成功拉到一筆訊息」作為唯一驗收。我會測試正常讀數能否處理後確認、相同事件重送時是否避免重複計入，以及無法解析的讀數能否進入可查的錯誤路徑。這是下一步要驗證的設計，不是附檔已完成的設備測試結果。

Day 13 的資料品質規則守住了提供分析的表；Pub/Sub 的確認、重試和死信則守住資料抵達那張表之前的過程。下一篇我會把訊息寫進 BigQuery，再看「持續收到資料」和「即時產出正確統計」之間還隔著什麼。

參考資料

1. Google Cloud, Subscription overview
2. Google Cloud, Dead-letter topics
3. Google Cloud, Exactly-once delivery
4. Google Cloud, Configure message retention for a subscription
5. Google Cloud, Replay and purge messages with seek