我们的数据仓库团队正在评估BigQuery作为数据仓库列存储解决方案，并对其功能和最佳使用有一些疑问 . 我们现有的etl管道通过队列异步消耗事件，并将事件明确地保存到我们现有的数据库技术中 . 幂等体系结构允许我们有时重放几个小时或几天的事件来纠正错误和数据中断，而没有重复的风险 .
在测试BigQuery时，我们尝试使用带有唯一键的实时流插入API作为insertId . 这为我们提供了一个短窗口的upsert功能，但是稍后重新流式传输数据会导致重复 . 因此，我们需要一个优雅的选项来实时删除欺骗，以避免数据差异 .
我们有几个问题，并希望得到任何答案 . 关于在ETL架构中使用BigQuery的任何其他建议也值得赞赏 .
-
除了使用tableId之外，是否存在重复实时流的重复实现？
-
如果我们尝试进行插入（通过删除后跟一个使用BigQuery API的插入），删除总是在插入之前，还是操作是异步到达的？
-
是否可以实现实时流式传输到登台环境，然后计划合并到目标表？这是其他列存储技术的常见解决方案，但我们没有看到任何文档表明它在BigQuery中的使用 .
1 回答
我们让重复发生，并且write our logic and queries以每个实体都是流数据的方式 . 例如：用户配置文件是流数据，因此有很多行及时放置，当我们需要选择最后一个数据时，我们使用最新的行 .
Delsert在我看来并不合适，因为你只限于96 DML statements per day per table . 因此，这意味着您需要临时存储表批处理，以便稍后发出处理一批行的单个DML语句，并从临时表更新实时表 .
如果您考虑使用delsert，可能更容易考虑编写查询以仅读取最近的行 .
可以进行流式处理，然后进行计划合并 . 实际上你可以在同一个表中重写一些数据，例如：删除重复数据 . 或者从临时表中预定查询批量内容并写入活动表 . 这在某种程度上与让重复发生并稍后在查询中进行处理相同，如果您写入同一个表，也称为重新实现 .