google-bigquery - BigQuery 可以被视为通用 DW 吗？

Question

我的大部分平台都在 Google Cloud 上，我们对此非常满意。但就目前而言，在我看来，虽然BigQuery (BQ)可以处理难以想象的数据量，但它只能在价格和性能方面表现良好，适用于狭窄的场景。当我们正在考虑更改为 时Redshift，我想分享我的（可能是错误的）结论，以避免误解。

以下是我们现在的部分和结论：

1. 我们需要stream数据到BQ. 维度内容可能会更改，更改必须流式传输到 BQ。
2. 假设某些用户将事务更改record X为“ steve”，而不是“ John”，然后更改为“ Robert”。BQ由于这些限制，流式传输到的挑战是您必须至少等待 30 分钟才能再次 DML 记录 X（尽管我在 DML 42 分钟后出现缓存错误）。所以我们需要构建的不仅仅是队列，因为第三个 DML 不需要等待 30 分钟，而第二个 DML 必须被忽略。
3. 由于您只能insert/*在表上同时运行操作（delete/delete, delete/update, update/update不允许），因此所有非insert DML流式操作都必须是serialized.
4. DML latency是一个巨大的问题。流式传输insert是可以的，也很容易bulk insert，但是流式传输delete或update每次操作将花费您半秒的时间，并且必须serialized基于表格。因此，如果您的系统中发生了很多updates事情，那么您可能queue永远不会结束。
5. 尽管本文指出BQ能够处理“对查询延迟极为敏感的工作负载”，但在我看来，这在很大程度上取决于您的用例。对于我的用例（小resultset），SQL延迟太高，对于一个小查询来说至少需要两秒钟。
6. 价格是不可预测的，据我了解，它不适合您希望resultset在不那么大的情况下运行数百个小查询的用例datasets。您为扫描时访问的数据列付费（但请记住，没有索引）。如果您有 a 60KB resultset，无论您的过滤条件多么精确120GB dataset，您都将为此付出代价（您可以尝试避免使用、和其他技术，但是当一组非常基本的索引可以完成这项工作时，它会增加您的复杂性）。120GBshardingpartitionrollup temporary tables

当然，好的一面是BQ完整serverless的，没有基础设施复杂性，没有调优，没有索引，不用担心高可用性并且存储价格是公平的。

所以，据我所知，如果你想要低延迟，如果你的数据发生变化（即使是很少的变化），如果你的用例不要求你扫描大量数据，你应该避免BQ.

欢迎任何考虑。

[编辑]：小Resultset而大Dataset。因此，postgree 可能不是我们想要成为的选择。

标签： google-bigqueryamazon-redshiftdata-warehouse

Answer 1

作为后续，我在原帖中提到的问题上学到了一些要点。

虽然我认为我写的都是对的，但我提到的大部分问题的解决方案都不是 Redshift。您将解决几个问题，创造几个其他问题，并且仍然会面对其中的大部分。

因此，关于我对 Redshift 的了解导致我决定继续使用（披露：BQ我与BQ

• RedshiftDML 延迟与BQ. 不同的原因，几乎相同的症状。如本文档所述，您可以为已更新的每一列存储 1 MB。
• 与基础设施方面相比，太多细节BQ
• 这项技术对我来说似乎更古老。无共享架构是众所周知的痛苦管理任务的来源，虽然这是一个非常难以解决的问题，但十多年前Oracle就已经解决了这个问题。Google BQ以完全不同的方式面对问题，将存储层与处理层分开。作为一种postgre演变，Redshift 保留了一些DDL约束语言（如主键），它们不仅无害，而且在使用时会产生错误的输出select distinct，例如。
• 本身不支持复杂的结构arrays是绝对不行的。似乎 Redshift 可以通过频谱访问 S3 中的外部数据，但这不是我们想要的。
• 虽然我没有深入探讨这个话题，但Redshift在我看来，将数据流式传输到BQ.

从好的方面来说，如果你使用 DW 的时间超过 20% ，它会更便宜，这是我的情况，你会发现更多的 BI 工具覆盖率。

如果流数据和 DML 延迟是最重要的，或者您需要较小结果集上的 SQL 延迟，那么使用 Oracle 或其他非列式 DW 可能会更好。