时间序列数据的 Bigtable 与 Bigquery 用例答案

【问题标题】：Big table vs Big Query usecase for timeseries data时间序列数据的 Bigtable 与 Bigquery 用例
【发布时间】：2019-02-22 20:43:38
【问题描述】：

我希望为我的时间序列数据用例最终确定大表与大查询。

我已经通过https://cloud.google.com/bigtable/docs/schema-design-time-series

这是用于存储 Omniture 数据，其中包含网站访问者密钥（一些长密钥）、他的 cookie id（一些长密钥）、他的 IP 的时间戳系列数据网络点击、cookie 等信息

什么可以用作大表的行键？正如我从最佳实践中学到的，我不能使用时间戳或 CookieId 作为前缀。但应该有一个标识符（最好是字母？），然后是时间序列后缀。今天的数据量为 5 亿，52 列存储在 SQL 表中。我认为数据可能会根据 OLTP 处理进行更新。但是稍后会在时间序列数据上查询该表以进行 OLAP 处理。

a) Big table 将是这里的最佳选择，还是我应该使用 Big Query，因为稍后根据时间序列数据进行查询会对我有更多帮助？ b）如果使用大表，最好的行键是什么，因为时间序列是我为我的数据看到的唯一含义过滤器。我相信，使用表中的其他字段，如visitorkey、cookieid ids(Long ids) 作为时间戳前缀仍然会导致整个数据填满 Bigtable 中的 1 个节点，而不是分发。

请告诉我。

【问题讨论】：

我可能对此并不陌生，但几个月前我们在这里工作时遇到了同样的问题。我们得出的结论是，BigTable 更适合需要快速检索的生产应用程序，而不是分析用例。看起来您正在寻找数据科学类型的案例。我建议使用 BigQuery。如果您需要生产中的结果，您可以将 BigTable 视为架构的一部分，而不是数据仓库
是的，我的用例是数据仓库/科学。我对使用 BigQuery 持相同看法，
FKrauss - 事实上，我们经常看到人们使用 Bigtable 作为生产架构的一部分，而不是数据仓库/查询系统。我的回答详细说明了原因，您可能会觉得这很有趣！我只是想反驳一下 Bigtable 不适用于分析用例的想法。必然是！但它更多的是基于大规模 MapReduce 或基于 Dataflow 的分析模型，因为正如您所发现的那样，它并不总是能很好地适应更多 SQL-y 工作负载。

标签： google-bigquery bigtable google-cloud-bigtable

【解决方案1】：

（我是 Cloud Bigtable 团队的工程师）

正如您从我们的文档中发现的那样，行键格式是您在使用 Bigtable 时做出的最大决定，因为它决定了可以有效执行哪些访问模式。在时间戳之前使用visitorKey + cookie 作为前缀，我觉得这样可以避免热点问题，因为几乎可以肯定，您网站的访问者比集群中的节点多得多。 Bigtable 一直服务于这些时间序列用例！

但是，您也来自 SQL 架构，它并不总是适合 Bigtable 的架构/查询模型。所以这里有一些问题可以帮助您入门：

您是否计划执行大量临时查询，例如“SELECT A FROM Bigtable WHERE B=x”？如果是这样，强烈推荐 BigQuery。如果不执行全表扫描，Bigtable 无法支持此查询。一般来说，Bigtable 更倾向于将数据的一个简单子集快速流回到数据流作业中，而不是在查询本身中嵌入复杂的处理。
是否需要多行 OLTP 事务？同样，请使用 BigQuery，因为 Bigtable 仅支持单行内的事务。
您是否正在以高 QPS 流式传输新活动？ Bigtable 对于这些类型的大容量更新要好得多。请记住，Bigtable 最初的目的是作为随机访问接收器，用于在 Google 的搜索索引中更新网络爬虫！
您想对数据执行任何类型的大规模复杂转换吗？同样，Bigtable 在这里可能会更好，因为您可以更快地流出和返回数据，并让 Dataflow 作业中的自定义业务逻辑做任何您想做的事情。

如果您需要这些功能的某种组合，您也可以将这两种服务组合起来。例如，假设您一直在接收大量更新，但希望能够执行复杂的即席查询。如果您可以处理稍微延迟的数据版本，则将更新写入 Bigtable，然后使用 Dataflow 定期扫描表并将最新事件的后处理版本导出到 BigQuery 可能是有意义的。 GCP 还允许 BigQuery 在某些地区直接从 Bigtable 提供查询：https://cloud.google.com/bigquery/external-data-bigtable

【讨论】：

基于不同列的即席查询，无多行 OLTP 事务，无流式新事件。在一天中的某些部分可能会有更多的插入。将根据时间戳数据进行查询 - 每天或在某天到某天之间。将是一些转换和连接。查看带有日期分区的 Big Query。请确认。请更多地了解热点。与仅在 BT 中具有时间戳相比，visitorKey + cookie + 时间戳如何避免热点？鉴于此组合，我认为我无法根据特定的行键进行过滤。
BigQuery 听起来像是适合您的工作负载的工具，因为它具有临时查询和联接。对于 Bigtable 中热点的未来参考，我们需要关注的是我们不希望所有传入的写入都命中相同的行范围，因为这样负载就不能跨服务器分散。使用时间戳（尤其是细粒度的时间戳）为行键添加前缀是这种反模式的经典示例。以visitorKey + cookie + timestamp 作为你的key，有||visitorKey+cookie||单独的行范围在任何给定的时间戳接收更新，因此可以将它们拆分到多个服务器。
非常感谢您的澄清
@DouglasMcErlean 什么样的 1) delay 在一致性和 2) 使用 BigQuery+BigTable 时性能下降（2x/10x？）可以预期吗？
1) 如果您使用联合查询，则没有。如果您要写入 Bigtable，然后手动将内容镜像到 BigQuery，这完全取决于您执行镜像的频率。 2) 众所周知，联合查询比使用 BigQuery 的本机存储要慢，因为该格式未针对 BigQuery 进行优化。但我不确定减速到底有多大，因为我不是 BigQuery 专家。如果您进行镜像，这种减速现象就会消失，因为您使用的是 BigQuery 及其原生存储格式。