如果要把設備告警事件送進 BigQuery，我以前會先想好目標資料表：設備編號、事件時間、告警類型，各自有固定型別；格式不符的資料，就在載入前修正或排除。這樣做出來的表看起來整齊，也能立刻查詢。
但我開始擔心一個問題：我現在認為不合格式的值，真的是錯誤嗎？ 假設不同設備版本把同一種狀態寫成 offline 和 OFFLINE，或者有的事件時間來自設備、有的來自接收系統，在釐清來源定義之前就統一它們，可能把值得調查的差異一起消掉。我需要的第一步，或許不是立刻產出乾淨的分析表，而是先確定自己到底收到了什麼。
以這個設備事件情境來設計資料流程，我會先保留來源傳來的事件內容，同時記錄接收時間與來源識別資訊。這一層的驗收重點是：送達的事件是否完整留下、能否回查原始內容。到了下一層，我才把狀態碼對應到統一名稱，解析事件時間，並決定缺少設備識別資訊的事件該如何處理。
這樣的分工讓我能分清兩種錯誤。事件沒被收到，是入口問題；事件收到了卻被解讀錯誤，是轉換規則問題。如果只留下最終整理好的表，兩種問題最後都可能表現為「報表少了一筆」，卻很難追出原因。
Google Cloud 的 BigQuery 文件把 ETL（Extract、Transform、Load，擷取、轉換、載入）與 ELT（Extract、Load、Transform，擷取、載入、轉換）列為兩種資料整合方式。官方表示，對多數 BigQuery 使用情境通常建議 ELT：先載入，再於 BigQuery 中轉換，讓接收資料與處理資料成為兩個較容易管理的部分。
這不是說所有來源都該毫無檢查地進入平台。我的理解是，入口仍要檢查資料能否安全接收、是否符合基本結構；只是尚未確認的業務解釋，不必全部擠在入口當下完成。對設備告警來說，「這個事件確實由來源送出」和「這個狀態應歸類為故障」是不同的判斷，值得留在不同階段處理。
如果來源是 CSV 或 JSON，BigQuery 可以自動偵測 Schema（欄位結構與型別）。我原本把它看成少填幾個設定的便利功能。官方文件讓我注意到：這是根據樣本進行的盡力推斷，並非對整批資料語意的確認。
例如一個欄位平常放設備狀態，偶爾放新韌體才會產生的狀態碼。系統可以猜出它是文字，卻不知道新狀態碼代表什麼。這時明確指定 Schema，也只解決「欄位應如何儲存」；它不會替我完成狀態碼的業務定義。BigQuery 官方同樣支援在建表或載入時明確指定 Schema，因此我可以依資料成熟度選擇自動偵測或自行定義，而不是把其中一種當成永遠正確的設定。
Raw Layer（原始資料層）對我最有用的地方，是保留重跑的可能。如果後來發現某批設備的事件時間使用不同時區，我可以修改解析規則，再從原始事件產生新的結果。若第一次處理時就覆寫原值，之後很難分辨時間差異來自設備、傳輸過程，還是我寫的轉換程式。
不過，原始層不是「什麼都存進去就算完成」。我仍需要知道資料來自哪裡、何時接收、是否有重送，以及哪些人可以讀取。下游也必須有清楚的型別與定義。我的判斷是：原始層負責留下可追查的事實，分析層負責提供可以使用的解釋。 兩層各自有驗收標準，才不會讓「保留原貌」變成放任品質問題。
Google Cloud 在 2025 年宣布 BigQuery data preparation 正式推出。Gemini in BigQuery 可以依資料內容與 Schema 建議清理及標準化方式；產生的轉換能以 SQL 檢視，也可以接入 BigQuery pipelines。官方還說明了驗證規則與錯誤表的用法，讓未通過檢查的資料有地方可查。
這讓我更在意規則本身。工具可以建議把 OFFLINE 轉成 offline，但我仍須確認兩者在不同設備版本中是否真有相同意思；工具可以辨認某種時間格式，也無法單靠格式知道應採用設備時間還是接收時間。轉換越容易建立，我越需要寫清楚：哪些差異可以自動統一，哪些異常要留待確認，以及下游表格承諾了什麼品質。
現在面對一份新資料，我不會先問「該用 ETL 還是 ELT」。我會先問：入口必須保證哪些事？哪些欄位的意思尚未確認？如果日後改了規則，能不能從原始內容重新產生結果？
在 BigQuery 上，ELT 提供了一種可行的安排：先留下可追查的來源資料，再把轉換與驗證變成明確的後續工作。即使換到其他資料平台，這個問題仍然一樣。資料管線的可靠程度，不只取決於它能否產出一張乾淨的表，也取決於我能否說清楚：那張表的每個判斷從何而來。
iThome鐵人賽
看影片追技術