BigQuery 查询需要很长时间答案

【问题标题】：BigQuery query taking a long timeBigQuery 查询需要很长时间
【发布时间】：2015-11-19 23:14:25
【问题描述】：

对我的一张表进行简单的计数查询需要很长时间（约 18 秒）才能完成，该表有大约 50 万行，在更大的表（大约 3 百万）中进行相同的查询需要不到3 秒。架构完全相同，查询是一个简单的 SELECT count(*) FROM [dataset.table]

任何想法为什么会发生这种情况以及我可以做些什么来防止它？

【问题讨论】：

每个查询处理多少数据？
您能否为耗时 18 秒的查询提供作业 ID？
@JenTong ：根据 UI，计数处理 0B。根据相同的 UI，表本身有 404 MB
@JordanTigani ：我可以提供，每次我查询都会发生，我应该在这里发布 id 吗？
是的，请发布它，它会让 BigQuery 工程师之一查看查询统计信息以找出问题所在。小表上的 COUNT(*) 不会花费那么长时间。

标签： google-bigquery

【解决方案1】：

看起来您的表的问题在于它是由很多小块创建的；这需要做更多的查询工作，因为我们在文件系统操作（列出文件并打开它们）上花费了大量时间。

即便如此，一张和你一样大的桌子也不应该那么慢； BigQuery 目前正在经历高文件系统负载，这会导致延迟的高度可变性。我们正在积极努力解决这个问题。所以这是第一个问题。

第二个问题是我们可能应该更好地压缩表。我已经提交了一个内部错误，我们应该调整我们的启发式算法，使其在压缩方面更具侵略性。

作为一种解决方法，您可以通过在原地复制表格来手动压缩表格。换句话说，运行SELECT * from ... 并将输出写入同一个表，使用writeDisposition:WRITE_TRUNCATE、destinationTable:<your table> 和allowLargeResults:true 和flattenSchema:false。

同样，这最后一步不应该是必需的，但现在它应该可以改善您的情况。

【讨论】：

关于通过“select *”查询进行自压缩的一个警告：只有在查询开始和查询完成之间没有加载数据时，您才能执行此操作。查询运行的数据视图在操作开始时确定，并且在作业成功结束的时间点将发生 WRITE_TRUNCATE。如果您正在将数据流式传输到表或运行加载作业，那么您可能会因这种技术而丢失数据。
我的表是在没有任何数据的情况下创建的，然后所有数据都（正在）流入其中。如果我这样做，我会经常遇到这个问题吗？将数据以更大的块而不是流式加载到其中会阻止这种情况发生吗？我可以轻松地停止流式传输、自压缩，然后恢复流式传输。但我需要多久执行一次？