【问题标题】:Google BigQuery DML Update query on rows still in the Streaming buffer仍在流式缓冲区中的行上的 Google BigQuery DML 更新查询
【发布时间】:2019-02-28 16:45:23
【问题描述】:

我最近一直在尝试为 Google 的 Big Query 流式 API 提供一种重试机制,用于在有时仍位于流式缓冲区中的行上使用 UPDATE 语句运行 DML 查询。由于这些行尚未导出到表中,BI 的 api 禁止对其运行 UPDATE 或 DELETE 语句。据我了解,没有办法自己手动刷新流缓冲区。

我的问题是,对于具有某种重试机制的调用,是否有一种方法或良好做法可以在宣布的可能的 90 分钟等待时间内执行此操作(行可以在缓冲区中)?

【问题讨论】:

  • 我遇到了同样的问题,如果他们看到这个,我希望 Pavan 或 Elliott 的官方回答。我们需要解决这个问题,它在一些大表上是不可维护的。

标签: google-app-engine google-bigquery


【解决方案1】:

我建议将发生流式传输的表中的数据复制到另一个可以不受限制地运行 DML 的表。可以使用jobs.insert API 创建另一个永久表 您需要将此永久表视为真实的来源,在原始表上您可以 enable table's expiration timepartition expiration 根据您的需要和应对频率。 现在,当您拥有永久表时,您可以对该数据进行一些其他处理或生成报告等。 上面的缺点是你可能有一些迟到的数据,你应该获取/复制合理的数据窗口并将其重复数据删除到永久表以保证最新数据

我假设流式传输到您的表可以一次又一次地运行,因此理论上您可能永远无法运行 DML,因为流式缓冲区永远不会为空。

无论如何,如果您仍然需要运行一些重试机制,请尝试使用 https://github.com/awaitility/awaitility 之类的东西

【讨论】:

  • 我想听听您的进程的继续。您将数据复制到新表,运行 DML,但如何继续?你现在如何处理表格和副本?
  • 表保持原样(但可能是这样,因为该表有保留期,因此出于业务目的,副本(带有一些转换)被视为有价值的表
  • 我没有关注你。当您拥有 DML 时,您需要在报表/仪表板中主动查询的数据集上保存该数据。因此,您必须以某种方式写回原始表,或者将报告工具转移到新表。很多问题要处理,它没有解释。你的答案不完整。
  • 我编辑了答案以考虑您的意见,谢谢他们
  • 所以您的建议是尝试维护类似 cqrs 模式的东西。这不是过度复制表格吗?为了能够运行 DML 查询,我必须将每行加倍持久化两次。关于流永远不会为空,无法查询的行只是仍在流中的行。有些工人不断地读取给定表的缓冲区,并将它们写成列格式。写入时,它们被标记为垃圾并从缓冲区中删除。我不认为总是“满”的缓冲区会是这里的问题。
猜你喜欢
  • 2019-05-02
  • 1970-01-01
  • 1970-01-01
  • 2023-03-05
  • 2021-12-22
  • 2017-08-22
  • 1970-01-01
  • 2018-10-25
  • 1970-01-01
相关资源
最近更新 更多