异步实时ETL流水线中的反复制BigQuery

Question

我们的数据仓库团队正在评估BigQuery作为一种数据仓库列存储解决方案，并对其特性和最佳使用提出了一些问题。我们现有的etl管道通过队列异步地消耗事件，并将事件等效地保存到我们现有的数据库技术中。幂等结构允许我们在没有重复风险的情况下，偶尔重播几个小时或几天的事件，以纠正错误和数据中断。

在测试BigQuery时，我们尝试使用具有唯一密钥的实时流插入api作为insertId。这为我们提供了在短窗口上重新插入的功能，但是稍后数据的重新流会导致重复。因此，我们需要一个优雅的选项来消除实时/近实时的欺骗，以避免数据差异。

我们有几个问题，希望得到任何一个问题的答案。对于在ETL体系结构中使用BigQuery的任何其他建议也将不胜感激。

• 除了使用tableId之外，是否有一个消除实时流复制的通用实现？
• 如果我们尝试删除(通过删除，然后使用BigQuery API插入)，删除总是在插入之前进行，还是操作异步到达？
• 是否可以实现实时流到暂存环境，然后是预定的合并到目标表？这是其他列存储etl技术的常见解决方案，但我们还没有看到说明它在BigQuery中使用的文档。

Answer 1

我们让复制发生，而编写我们的逻辑和查询的方式是每个实体都是流数据。用户配置文件是一个流数据，所以有很多行被放置在时间上，当我们需要选择最后的数据时，我们使用最近的行。

在我看来，Delsert是不合适的，因为您仅限于每个表每天96个DML语句。因此，这意味着您需要在表批中存储临时存储，以便稍后发出处理一批行的单个DML语句，并从临时表中更新一个活动表。

如果您考虑删除，也许考虑编写一个查询只读取最近的行会更容易一些。

流和计划的合并是可能的。实际上，您可以在同一个表中重写一些数据，例如:删除dups。或计划从临时表中查询批处理内容并写入活动表。这在某种程度上与let复制的发生相同，然后在查询中处理它，如果您写到同一个表，也称为再物化。