將數據流式傳輸到BigQuery中的旋轉日誌表中

Question

我想通過insertAll將一些時間序列數據流式傳輸到BigQuery中，但只保留最近3個月（比如說）以避免無限存儲成本。通常的答案是save each day of data into a separate table，但AFAICT需要提前創建每個這樣的表。我打算直接從不安全的客戶端流式傳輸數據，這些客戶端授權的令牌只有bigquery.insertdata範圍，所以他們無法自行創建日常表格。我能想到的唯一解決方案就是運行安全的每日cron作業來創建表格 - 這並不理想，特別是因爲如果它失火了，數據將被丟棄，直到創建表格。

另一種方法是將數據流式傳輸到單個表中，並使用table decorators來控制查詢成本隨着表的增長而變化。 （我希望所有的查詢都是針對特定的時間範圍，因此裝飾器在這裏應該非常有效）。但是，無法從表中刪除舊數據，因此存儲成本在一段時間後將變得無法持續。我無法想出任何方式來自動「複製和截斷」表，以便我可以將舊數據分區到每日表中，而不會丟失當時流式傳輸的行。

關於如何解決這個問題的任何想法？如果您的解決方案允許我將舊數據重新聚合到時間較粗的行中以保留更多歷史記錄以獲得相同的存儲成本，則可以獲得獎勵積分。謝謝。

編輯：剛剛意識到這是Bigquery event streaming and table creation的部分副本。

Answer 1

如果你看流媒體API發現文檔，有一個叫做「templateSuffix」的好奇的新實驗領域，有一個非常相關的描述。

我也指出沒有官方文檔發佈，所以應特別注意使用這一領域 - 尤其是在生產環境中。實驗領域可能有錯誤等。我可以認爲要小心從我的頭頂小心：

• 以非向後兼容的方式修改基表的模式。
• 直接以與基表不兼容的方式修改創建的表的模式。
• 直接通過此後綴傳輸到創建的表 - 行插入ID可能不適用於跨越邊界。
• 在創建的表正在主動流式傳輸時對其執行操作。

而且我確定其他的東西。無論如何，只是想我會指出。我相信官方文件將會更徹底。

Answer 2

你已經通過分區解決了它。如果表創建是一個問題，那麼在appengine中每小時都會有一個cron驗證今天和明天表總是被創建。 很可能appengine不會超過免費配額，它的正常運行時間有99.95％的SLO。克朗永遠不會倒下。

Answer 3

我們大多數人都在做與你所描述的相同的事情。

但是我們不使用cron，因爲我們提前一年創建表，或者提前5年在某個項目上創建表。你可能想知道爲什麼我們這麼做，什麼時候這樣做

我們在開發人員更改模式時會這樣做。我們進行部署，並運行一個腳本來處理舊/現有表的模式更改，腳本刪除所有未來的空表，並簡單地重新創建它們。我們並沒有用cron複雜化我們的生活，因爲我們知道模式改變的確切時刻，那就是部署，並且在如此長的時間內提前創建表沒有缺點。我們在創建用戶或關閉賬戶時也基於SaaS系統基於租戶進行此操作。

這種方式我們不需要cron，我們只需要知道部署需要在模式更改時執行此額外步驟。

至於在我對錶進行一些維護時不要丟失流式插入，您需要在應用程序級別處理業務邏輯。您可能擁有某種消息隊列，比如Beanstalkd將所有行排成一個管，然後一個工作人員推送到BigQuery。當BigQuery API響應錯誤並且您需要重試時，您可能會解決此問題。使用簡單的消息隊列很容易做到這一點。所以當你停止或重新命名某個表一段時間時，你會依賴這個重試階段。流式插入將失敗，很可能是因爲該表尚未準備好進行流式插入，例如：已暫時重命名以執行某些ETL工作。

如果你沒有這個重試階段，你應該考慮添加它，因爲它不僅幫助重試BigQuery失敗的調用，而且還允許你有一些維護窗口。