1. 我原本以為，換格式只是換一種存法

延續 Day 10 的設備事件情境，我試著思考一份感測資料要怎麼從來源進入分析平台。設備可能定期匯出 CSV，也可能透過 API 傳送 JSON；如果資料要長期留在資料湖，還可能轉成 Parquet。我原本把這些看成檔案格式的選擇，認為只要內容相同，換一種格式不會改變太多事。

但開始設計後，我發現格式會影響我能從資料本身得知多少資訊。收到一個溫度值時，我需要知道它使用什麼單位、對應哪台設備、何時測得；如果一次回傳多筆讀數，我還要知道它們如何與同一台設備保持關聯。檔案能被打開，只代表我讀得到內容，不代表我已經正確理解它。

2. CSV 方便交換，也把解釋工作交給接收端

假設設備系統每天匯出 CSV，它的優點很明顯：容易檢視，也容易交給其他工具處理。但欄位名稱和儲存的文字值，未必足以說明業務含義。temperature 是攝氏還是華氏？時間欄位記的是設備測量時間，還是平台收到檔案的時間？這些問題不能靠副檔名回答。

因此我會把「收到 CSV」與「確認欄位定義」視為兩件事。載入時要處理分隔符號、標題列與 Schema（欄位結構及型別）；提供分析前，則要確認單位、時間基準及缺值的處理規則。Google Cloud 的 CSV 載入文件也提醒，標題列的辨識會受資料內容影響，必要時應明確指定略過標題列及 Schema。這讓我更確定：載入成功是起點，還不是資料定義完成。

3. JSON 的階層可以保留資料關係

如果設備透過 API 回傳 JSON，一次事件可能包含設備資訊，以及一組連續讀數。我原本會想盡快把每個讀數攤成獨立資料列，讓它看起來像熟悉的表格。查了 BigQuery 官方文件後，我才知道這不是唯一選擇。

BigQuery 支援 nested fields（巢狀欄位）與 repeated fields（重複欄位），可以用 STRUCT 保存相關欄位，用 ARRAY 保存一組值。官方指出，合適的巢狀結構可以保留資料之間的關係，並減少某些查詢對表格連接的需求。

這改變了我對「攤平」的看法。若我要看每台設備有哪些讀數，保留階層可能更貼近來源；若我要比較所有讀數的分布，再用 UNNEST 展開。結構應該服務查詢目的，而不是在資料進來時一律消除。

4. Parquet 讓格式開始參與效能設計

當資料需要以檔案形式保存、供分析引擎反覆讀取時，Parquet 的價值就不同於 CSV。它是欄式格式，來源檔也帶有 Schema。Google Cloud 文件說明，BigQuery 載入 Parquet 時可以從來源取得 Schema；資料進入 BigQuery 管理的資料表後，則會轉為 BigQuery 自己的欄式儲存格式 Capacitor。

這裡有個我原本容易混淆的地方：Parquet 是檔案格式，Capacitor 是 BigQuery 管理資料的內部格式。 如果我已決定把資料載入 BigQuery 管理的資料表，不必只為了讓表格成為欄式儲存，就先把來源檔轉成 Parquet。但若檔案本身要留在資料湖，並供不同引擎使用，檔案格式及其 Schema 就值得在架構設計時提早考慮。

所以我現在選格式會先問資料的去向：它主要用來交換、保留 API 的階層關係，還是作為可被反覆分析的檔案？同一份來源資料，到了不同階段，可能有不同的合適表示方式。

5. 資料品質必須變成能執行的判斷

即使格式選對了，資料也不會自動可信。設備讀數可能缺少識別資訊、出現不合理的值，或因重送而重複。只說「資料品質不好」，無法讓下一次處理變得更穩定。

我需要把疑問改寫成規則：正式讀數是否必須有設備識別資訊？允許的數值範圍由誰訂定？遇到相同事件識別碼時，如何判斷是重送還是兩次有效事件？有些規則可以直接驗證；有些則必須先和資料來源的負責人確認。尤其是「數值不合理」，不能只憑工程師的直覺決定門檻。

Google Cloud 現行的 Knowledge Catalog（原 Dataplex Universal Catalog）支援定義並執行資料品質掃描，規則可以包括非空值、唯一性、有效值集合及自訂 SQL。它讓我看見從一次性檢查走向持續驗收的方法：把已確認的判斷寫成規則，讓每批新資料都接受同樣的檢查。

6. 品質結果還需要能追到來源

一張資料表今天通過檢查，不代表使用者明天看到的結果仍然可靠。來源可能更新欄位、設備韌體可能改變輸出內容，轉換規則也可能被修改。我因此不能只留下「通過」或「失敗」，還要知道檢查的是哪批資料、使用哪一版規則，以及結果如何產生。

Google Cloud 在討論 Dataplex 資料治理時，把資料剖析、品質檢查與 lineage（資料血緣，記錄資料來源與流轉關係）放在一起。 我從中得到的理解是：治理不是替資料加上一個分類名稱，而是讓使用者能回答「這份資料從哪裡來、代表什麼、目前通過了哪些檢查」。當這些資訊可以查到，報表上的數字才比較有機會被追問，也比較有理由被信任。

7. 跨雲時，更需要共同理解資料

起初我會習慣替不同雲端的產品找對照名稱：一個平台的資料目錄，在另一個平台對應什麼服務？但 BigQuery 於 2026 年 6 月的版本資訊指出，Cross-cloud Lakehouse 已以 Preview 形式支援 AWS Glue 作為遠端目錄供應者，讓 Google Cloud 的查詢引擎能透過跨雲目錄取得資料資訊，查詢相關資料時不一定要先整批搬移。這項能力仍處於 Preview，適用條件需要依正式文件確認。

這讓我把注意力從「產品名稱能否一一對上」，移到更根本的問題：不同系統是否能理解同一份資料的 Schema、Metadata（中繼資料）和品質狀態？CSV、JSON、Parquet 各有用途，但格式本身無法替資料建立可信度。只有當結構、定義、驗證規則和來源紀錄能一起被保留下來，資料跨過系統邊界後，別人才有辦法繼續正確使用它。

參考資料

1. Google Cloud, Load CSV data from Cloud Storage
2. Google Cloud, Specify nested and repeated columns in table schemas
3. Google Cloud, Load Parquet data from Cloud Storage
4. Google Cloud, Use auto data quality
5. Google Cloud Blog, How Dataplex provides data governance for the AI era
6. Google Cloud, BigQuery release notes