在异步实时ETL管道中重复数据删除BigQuery

时间:2017-03-27 19:52:02

标签: google-bigquery

我们的数据仓库团队正在评估BigQuery作为数据仓库列存储解决方案,并对其功能和最佳使用有一些疑问。我们现有的etl管道通过队列异步消耗事件,并​​将事件明确地保存到我们现有的数据库技术中。幂等体系结构允许我们有时重放几个小时或几天的事件来纠正错误和数据中断,而没有重复的风险。

在测试BigQuery时,我们尝试使用带有唯一键的实时流插入API作为insertId。这为我们提供了一个短窗口的upsert功能,但是稍后重新流式传输数据会导致重复。因此,我们需要一个优雅的选项来实时/近实时删除欺骗,以避免数据差异。

我们有几个问题,并希望得到任何答案。关于在ETL架构中使用BigQuery的任何其他建议也很受欢迎。

  • 是否存在实时重复数据删除的通用实现 除了使用tableId?
  • 之外的流式传输
  • 如果我们尝试一个插入(通过删除后跟一个插入使用 bigQuery API)删除总是在insert之前,或者do 这些操作是异步到达的吗?
  • 是否可以将实时流实现到分段中 环境,然后是计划合并到目标 表?这是其他列存储器的常见解决方案 技术,但我们没有看到任何文件表明其使用 大量查询。

1 个答案:

答案 0 :(得分:3)

我们让重复发生,并write our logic and queries以每个实体都是流数据的方式。例如:用户配置文件是一个流数据,因此有很多行按时间排列,当我们需要选择最后一个数据时,我们使用最新的行。

Delsert在我看来并不合适,因为你只限于96 DML statements per day per table。所以这意味着你需要临时存储一个表批量,以便稍后发出一个处理一批行的DML语句,并从临时表中更新一个活动表。

如果您考虑使用delsert,可能更容易考虑编写查询以仅读取最近的行。

可以进行流式传输,然后进行计划合并。实际上你可以在同一个表中重写一些数据,例如:删除重复数据。或者从临时表中预定查询批量内容并写入活动表。这在某种程度上与让重复发生并稍后在查询中进行处理相同,如果您写入同一个表,也称为重新实现。