簡單的幾個操作，降低 BigQuery 大筆的存儲費用！（理想情境中可以節省九成左右）

BigQuery 的表格存儲一直以來都有很多項計費的模式，而主要分成兩個維度：

1. Long-term & Active：長期未更新（90天）的資料會進入 Long-term，有較低的價格。
2. Logical & Physical：不同的儲存模式，Logical 計費基於未壓縮的大小，而 Physical 則是壓縮後來計價，因此雖然 Physical 單位價格高兩倍，但若壓縮比超過 2:1，則能節省存儲成本，也是今天想討論的重點。

Long-term & Active 的區別，可以展現在 Partition table 中，這種分割表，會依照你定義的分區單位（日、月、年等，我們通常使用日為分區單位）去將資料表存成小張的表，可以讓早於 90 天前的資料小表轉為 Long-term 表，降低成本。

這份官方文件有蠻清楚的說明，講述如何檢測在你的資料倉儲中轉換是否能降低成本、降低多少。

文件中的範例提到他的壓縮比大約是 16~25:1，是如何做到這麼高的壓縮比的？

詳細的技術細節他應該是不會公開，不過有幾個蠻有趣的點可以分享：

BigQuery 採用 column-based 的方式進行存儲，因此同個 column 的資料重複性越高，會有越高的壓縮比，也許有幾種不同的實現方法，但概念類似。

例如，連續數據 [100, 101, 102] 可壓縮為 [100, +1, +1]。
或是，文字資料採用代碼來表示，把縣市轉換為數字來儲存之類的方法。

除了有趣之外，知道這些之後，有什麼可以做的呢？
不要 Typo！意外發現 Typo 可不單純只是影響分析，而還會影響存儲壓縮比，責任重大啊！
除了避免之外，就是要做好 Monitoring 跟 Testing，來在事後做監控與修正。

另，time travel 功能在計費上會有影響，是上述方法沒有辦法直接計算出來的，畢竟 time travel 儲存的變動資料是一個變數，無法計算而得。可以運用 INFORMATION_SCHEMA.TABLE_STORAGE 中的 TIME_TRAVEL_PHYSICAL_BYTES 跟 FAIL_SAFE_PHYSICAL_BYTES，以現在的水平去推算可能產生的額外成本。

參考官方文件），通常 time travel 預設為 7 天，允許使用者訪問過去 7 天的資料版本。文件提到 Physical 儲存模式會額外收費，意思是若這七天有變動的資料，會有額外的 active storage 費用，而 logical 模式依照未壓縮的資料大小來計費，time travel 的部分已經包含在內，不會另外收費。若要再更節省、且沒有回溯的需求，可以考慮將 time travel 的期間縮短，否則頻繁修改的大資料集也會產生不少非預期成本。

如何轉換？

轉換以資料集為單位進行，只需要在資料集的 Advanced options 中調整 Storage Billing Model 的設定即可。

並且，這項轉換是不會影響到查詢效能跟計費的（On-demand compute），不用擔心。