專案參考

第一次處理百萬級資料時，專案面臨一個特別的限制：所有邏輯必須透過 API 完成，資料庫（DB）的規格已經預先設定，無法更改。因此，整體的負載優化只能從資料處理層著手。

起初：資料流處理與逐筆轉換

在初期，由於對整體流程不熟悉，我採用了資料流（streaming）方式進行逐筆清理與轉換。在小型測試資料下運行良好，但一旦進入實際場景後，處理速度急劇下降，加上業務邏輯越來越複雜，程式碼變得難以維護與閱讀。

轉折：退一步觀察資料規律

當開發陷入瓶頸後，我決定暫停直接開發，重新觀察資料格式與欄位變化的規律，發現許多處理邏輯其實具有明確的模式：

• 某些欄位具備可預測的範圍

• 某些資料變化可以用數學運算或規則匹配進行預處理

• 可以透過 hash 值、時間戳、設備編號等方式切割資料批次進行平行處理

解法：數學轉換 + 批次處理

為了提升效能與可維護性，我採取了以下策略：

1. 觀察規律，數學優化 利用明確的規則或公式預測資料行為，通過數學運算直接計算轉換結果，取代逐筆的條件判斷與字串處理，大幅減少 CPU 的運算與記憶體的操作。

2. 批次導向流程重構

   • 初步讀取檔案，先不處理資料，只記錄每一行的位置與內容摘要
   • 根據行數將資料分割為固定大小的批次（例如每批 50,000 筆）
   • 在批次中進行預處理、驗證、計算雜湊
   • 若該批次全數通過驗證，則進行資料寫入與 commit
   • 若任一筆資料異常，則整批 rollback，以保證資料的原子性與無殘留。

結語

由於實際資料涉及隱私，無法公開細節，不過我用類似結構的範例資料進行演練，來驗證可行性與潛在效益。目前看起來已能大幅簡化邏輯，並為後續維護與擴充打下更穩定的基礎。