資料補送到達較晚時如何更新已發布摘要

摘要已發布不表示資料已完整

早上八時發布前班產量九百八十件，八時十分設備補送二十件前班事件。這時需要的是可追溯的摘要修訂，不是直接在畫面上加二十。先確認這些事件是新的有效資料，歸屬前班且尚未計入，再決定受影響的統計範圍。

摘要至少保留區間、指標定義、資料截至點、計算規則版本、發布版本與狀態。初版、暫結及修訂版的定義由業務決定，但讀者應能辨認手上數字是否可能更新，不能所有檔案都叫最終版。

先區分晚到新事件、重送舊事件與更正既有事件。新事件可能增加計數，重送不應增加，更正可能改變數值或分類。把三者都當「補送二十筆」直接加總，是造成越補越多的常見原因。

本文適用於由事件明細產生的工業摘要，示例在資料副本中推演。不同資料庫的快取、物化檢視與交易行為依文件確認；文中的步驟不是已在正式系統執行的更新紀錄。

先對補送資料做身分與內容核對，保留新事件ID清單。再用事件時間、班次、設備及產品等分類鍵找受影響摘要。接收時間用於判斷何時知道這筆資料，不能默認把晚到產量算到現在這班。

案例：補送二十筆中五筆其實是已存在事件的重送，另十五筆是新事件。若初版九百八十件已包含那五筆，正確重算為九百九十五件，不是一千件。先核對去重後件數，才有資格談摘要增量。

若其中三筆新事件屬隔壁班，本班只增加十二件，得到九百九十二件；另三件交由其所屬摘要處理。這說明接收包的筆數與單一報表增量並不相同，必須逐筆歸屬後再彙總。

一筆事件也可能影響多種指標：產量、良率、平均值及最大值。更新清單要按依賴關係展開，不能只改產量而讓分母、良率與圖表維持舊數。把關聯摘要列成待重算清單，才不會漏掉下游使用者。

完成這一步應有一張影響表，列出新增、更正及衝突事件數，受影響區間，以及哪些摘要尚待處理。未知歸屬先列待核對，不為了快速完成就塞進當前報表。

若原摘要有一百筆有效測量，總和二千五百，平均二十五；晚到十筆總和三百，平均三十。更新後總和二千八百、樣本數一百一十，平均約二十五點四五四五，不是把二十五與三十平均成二十七點五。

因此摘要最好保留可重算的基礎量，例如有效樣本數、總和及品質篩選規則。若是時間加權平均，分母是有效時間而非樣本數，另按定義保存。不能因兩個指標都叫平均，就共用不適當的增量公式。

最大值在新增資料時可比較，但若原最大值所屬事件後來被更正或排除，只看新資料就找不到新的最大值。中位數、百分位與去重計數也不能普遍用簡單加減處理；能力不足時從受影響明細重算。

選擇整段重算或受控差額更新後，要保證重跑不再次增加。整段重算是重新建立該區間結果，差額更新則需要記錄哪些變更已套用。不可先重算成九百九十五，再把十五筆補送增量加一次。

以原始明細重建的結果作核對基準，可以發現增量狀態遺漏。測試同一補送檔重放兩次，第二次不應改變有效事件數與摘要值；若有衝突內容則另進處置流程，不靜默覆蓋。

下游若會把摘要匯入另一套系統，也要提供報表區間與修訂版本作識別。新版本應按介面約定取代該區間舊值或套用已標識的差額，而不是每下載一次就當新增產量匯入。通知文字本身不能代替資料端的版本控制。

重算時保存使用的資料快照或明確截至點，避免產量查詢看到新資料而良率查詢還用舊資料。新版本全部相關指標核對完成後，再按系統支持的方式發布一致版本，讀者不應看到半套新舊數字。

若使用PostgreSQL物化檢視，資料是保存的查詢結果，不會因明細新增就必然立即更新；官方文件說明需刷新結果。實際刷新可能影響讀取與資源，應依部署方式評估，本文不直接在正式環境下執行命令。

摘要版本記錄前值、後值、差額、修訂原因及事件依據。原版仍可查詢，最新指標明確指向當前版本。只覆蓋同一個檔案而不保留歷史，會讓曾經下載的人無法解釋手上數字為什麼不同。

若新版本計算或發布失敗，保留舊版可用並標示更新待完成，依系統設計重試。不要先刪掉所有舊摘要再開始一連串不受保護的插入，否則途中失敗會讓報表一片空白或只剩部分資料。

完成後確認快取、下載檔及下游查詢使用的版本一致。資料庫已更新但瀏覽器仍顯示舊版，是發布鏈路問題，不應再次補加資料試圖讓畫面變動。

練習：初版有效件數五百，補送十二筆，其中四筆重複、兩筆屬下一班，其餘本班新事件。本班應增加六件到五百零六，下一班另處理兩件。再次送相同十二筆，本班仍是五百零六。

失敗時先查去重、區間歸屬與重算策略，再看快取及版本發布。若摘要與明細不同，保留兩者的截至點，避免拿不同時間快照比較後誤判計算錯誤。

問：晚到幾筆就加幾件嗎？答：先去重並確認單位、品質與歸屬。

問：平均值能直接加平均增量嗎？答：要按原指標分母計算，通常需保存總和與有效數。

問：摘要刷新就等於留下修訂歷史嗎？答：不是，版本與原因需另外設計保存。

問：舊版不再是最新可以刪嗎？答：依保存規則留存，至少讓已發布結果可追溯。