我們使用BigQuery作爲系統的分析引擎，爲報表準備數據。 根據我們的流程，數據的任何部分都可能發生變化，這也是2013-2015年的歷史數據，所以我們每天早上都會刪除並重新加載BigQuery中的所有表格。Big Query是否適應數據？
我們想了解我們的方法是否會降低性能或增加數據處理的成本。因爲它可能是BQ「適應」的表格內容，隨後的查詢變得更加高效。我不是在談論緩存，而是關於BQ在處理查詢時可能發現的一些數據重組，例如分區。
例如，大部分的查詢都與一個特定的年份，或值類型，所以BQ可能要跨越這些字段中的數據分區，一旦識別常見的查詢模式。
一般而言，BigQuery 確實根據查詢的方式來重構表格，以提高性能。如果你每天重寫你的表格，你會錯過某些性能優勢，但是因爲你一次加載數據，所以這些表格應該非常高效。
你使用不增加數據處理成本的機制。如果您對成本敏感並且查詢特定年份，則可能需要考慮將表格分成多個表格。然後您可以使用TABLE_DATE_RANGE或TABLE_QUERY函數跨這些表進行查詢。
從乍一看，它可能看起來不相關 - 但檢查Table Decorators
而在Syntax Section
對您的問題具體評論您可能會注意到7天重提的他們
所以，下面我幾毛錢 - 簡化查看：
當您將數據加載到GBQ時 - 它會保持原樣7天，之後您的數據將進行存儲和訪問優化。
這是您因每日重新加載而丟失的內容。
失去了多大？基於喬丹的答案 - 沒有多少，因爲你做的滿負荷，因此碎片可能是最小的，如果在所有
由於分區的，我希望你是不是存儲在一個大表中的所有數據2013-2016。
如果您使用/查詢模式是基於一年 - 你最好有表按一年或一個月甚至一天分區（取決於您的查詢模式）
這將大大提高你的性能和成本效益
重要 - 截至目前，您需要關心數據的分區策略，並且沒有太多（如果有的話）內置功能來支持構建分區。雖然，對於消費分區數據的一些支持 - 例如 - Table wildcard functions
我希望谷歌團隊將拿出更好的支持分區，因爲這變得越來越要求現實生活中的用例
我證實了這一點Google BQ的行爲。即使數據未更改，查詢執行計劃也會隨時間變化。不幸的是，在我們的案例中，通配符表不是一種選擇，因爲我們使用自行生成SQL代碼的BI工具。 –