简单的几个操作，降低 BigQuery 大笔的存储费用！（理想情境中可以节省九成左右）
BigQuery 的表格存储一直以来都有很多项计费的模式，而主要分成两个维度：
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），不用担心。