我正在将数据从云数据流汇中流到三个大Query表中，但是在目标表之一上看到了非常缓慢的查询结果 - A"小"，约150万行。如果我停止数据流流动作业并稍后返回表，则同一查询运行迅速地。这是标准SQL方言中的查询：
SELECT appname, start_time_to_minute, SUM(sum_client_bytes + sum_server_bytes) as `sum`
FROM `myproject.myset`.`mysmalltable`
GROUP BY 1, 2
- appName：字符串
- start_time_to_minute：timestamp
- sum_client_bytes：Integer
- sum_server_bytes：integer
作业ID：bquijob_568af346_15c82f9e5ec-需要12s。
通过流媒体，该表增长了每分钟约2000行。同一项目中的另一个目标表通过流媒体增长得更快，也许每分钟200,000行。如果我在流式传输时在mysmalltable上运行上述查询，则可以接近一分钟。我们在类似的查询上经历了几分钟的查询时间。
作业ID：bquijob_7b4ea8a1_15c830b7f12，它需要42.8S
如果我添加了一个过滤器，情况会变得更糟，例如
WHERE REGEXP_CONTAINS(`appname`, 'Oracle')
作业ID：bquijob_502b0a06_15c830d9ecf，需要57S
昨天一个超过6分钟：
作业ID：bquijob_49761f0d_15c80c6f415，花了6m38s
我知道，为了支持查询"实时"数据，BigQuery的效率较低的数据提供商可以在流中运行缓冲。这意味着这里吗？有什么方法可以使这些查询在30岁以下的不足之下可靠地运行？例如，以某种方式避免流媒体缓冲区并使用> 1分钟的旧数据？如果引用流缓冲区的牵连，它仍然对我来说并不完全加起来，因为我认为从mysmalltable中读取的大多数数据仍然是本机格式的。
我感谢任何指导！
我也看过这种行为，我的解决方法(我不会说解决了，因为这主要是Google的东西(，而是使用Micro Batching流插入。当并发较低时，流插入的效果非常好，但是真正的BigData(例如，在我的情况下，数十万(是最好的方法是使用微批量。我正在使用3分钟窗口的File_loads选项，并且效果很好。希望这可以帮助您。