Bigquery：频繁更新记录

Question

我们计划将 bigquery 用于库存系统的分析目的。 由于这是库存，storeid-productid 组合的记录将经常更改。 就数量而言，总的商店产品记录在 200M - 400M 之间。 预计每天总共有 500K 个突变。 突变来自kafka主题。

从成本的角度来看，什么是最佳解决方案。 选项是

1. kafka 侦听器发出 DML 语句。 UPDATE inventory SET quantity=? WHERE productid=? AND storeid=? . => 我对这个选项的评估是，这是最简单的，但可能会产生更高的成本，因为 bigquery 没有主键的概念。 搜索索引/ 集群等有帮助吗？

2. 有一个暂存表，我们存储每个突变，然后定期使用MERGE更新主\报告表

像这样的东西https://cloud.google.com/blog/products/bigquery/performing-large-scale-mutations-in-bigquery （然而这是一篇 2018 年的文章，事情可能已经改变了很多 - 例如，我认为这里提到的 3 小时延迟现在是 30 分钟）

MERGE dataset.Inventory T
USING dataset.inventory_staging S
ON T.ProductID = S.ProductID and T.storeid = S.storeid
WHEN MATCHED THEN
  UPDATE SET quantity = s.quantity
WHEN NOT MATCHED THEN
  INSERT (ProductID, quantity) VALUES (ProductID, quantity)

现在第二个问题，如果我们要采用第二种方法，

将 kafka 主题下沉到大查询的成本效益高的方法是什么。 Kafka -> GCS -> BQ 是否比流式解决方案有任何优势（例如样板 kafkalistener 执行https://cloud.google.com/bigquery/docs/write-api#write-api-overview ）

Answer 1

为每个项目运行一个 UPDATE 语句会非常昂贵，您需要有阶段表并定期运行 MERGE。

Kafka -> GCS -> BQ 是最具成本效益的方式。

作为附加建议，您可以探索在 Pub/Sub 中创建一个主题来替代 kafka。 Pub / Sub 也直接接收bigquery 。

Answer 2

对于第一个问题，单个 UPDATE 语句是行不通的，计划 MERGES 在数据可用性方面有一些权衡，因此另一种选择是存储所有突变并对数据进行版本化，以便您始终可以恢复最后一个值。

然后，您可以安排一个查询，通过从源表中删除旧版本来删除或存档旧版本。 这将改进数据扫描。

关于你的第二个问题，解决这个问题的最快方法是：

Kafka > PubSub 接收器 > Bigquery。

请注意每一步的限制和特定转换。

https://cloud.google.com/pubsub/docs/connect_kafka#convert-to-pubsub

https://cloud.google.com/pubsub/docs/bigquery