BigQuery - 6 年的订单迁移、表/查询设计

Posted 2023-03-24

【中文标题】BigQuery - 6 年的订单迁移、表/查询设计

【英文标题】：BigQuery - 6 Years of Order Migration, Table / Query Design

【发布时间】：2017-07-15 20:20:31

【问题描述】：

我正在构建一个 Spark 作业，将 6 年的电子商务订单/事件迁移到我们新的 BigQuery 仓库，以补充新的流式处理功能。迁移的数据与新数据位于同一模型中，并且视图将根据需要公开部分。

我们有 4 个数据集：

数据（原始数据 - 分层 JSON） 视图（例如原始数据上的 DIMS - 通常是平坦的，但并非总是如此） pre_aggs（例如，包含一些关键汇总暗淡的货币隐藏原始总数 - 平坦） 报告（如您所想）

与一些流入且无限制的新实时数据不同，此历史数据的迁移是批量和有界的（例如，我不必担心迟到的事件/水印和重复）。我还可以通过 event 时间（orderPlacedTimestamp）手动对数据进行分区，并保留在正确的日期分区表中（后缀？）。 BQ 中压缩的完整数据约为 2 GB 和 200 万行，因此不是海量但相当复杂的结构，需要在视图层中取消嵌套。我可以选择将原始表和聚合表编写为 Spark 的实体表，因此我真的很想按照最佳实践执行此操作并优化性能（查询速度更重要，值得多花点钱）

我发现这篇关于 SQL/Query lambda 架构的非常好的博客是一些启发，并将尝试做类似的事情。

https://www.linkedin.com/pulse/building-robust-real-time-etl-google-bigquery-lambda-novozhilov

我仍然想知道如何最好地存储/分区这些数据，然后构建基于时间的查询来匹配。每周，每月报告可能是最常见的。

我的选择似乎：

一个表中的所有内容 - 看起来不错且简单?

每个时间段一个表，例如每年，每月

order_history_2017 或 order_history_201701

我们有一个日历查找 dim，每一行都有可以使用上述后缀的键 - 例如 201701 表示 2017 年 1 月。

每月意味着 72 张桌子，这似乎相当多，也许每年更好？

为了争论，说它的月表，在 BQ（标准 SQL）中查询包含连续时间线的表的正确前缀的最佳方法是什么，使用正确的后缀动态构建表名（动态可能?

例如说我想查询 2017-01-10 和 2017-02-10 之间的所有订单（订单有 orderPlacedTimestamp） - 这意味着只扫描（和联合？）order_history_2017-01-10 和 order_history_2017-02在这种情况下为 -10 个表，如下所示：

SELECT *
FROM order_history_201701 UNION ALL
SELECT *
FROM order_history_201702
WHERE order.orderPlacedTimestamp BETWEEN DATE(“2017–01-10”) and DATE(“2017-02-10”)

然后，我可能会遇到这些历史数据也需要与“实时”（流式）数据结合的场景 - 包​​含在类似 lambda 设计文章的视图中。

我没有想到的选项。

BQ 有这么多选择！ :)

无论如何，这是我目前的想法，任何关于这个主题的智慧之言，在表设计和优化查询构造方面都会受到极大的赞赏。

谢谢大家！

【问题讨论】：

您能不能简单地使用 BigQuery 的内置分区功能（您只看到一张表，但不为全表扫描付费）-cloud.google.com/bigquery/docs/partitioned-tables

嗨，格雷厄姆，感谢您的评论。除非我错过了一些关键功能（我现在回到 docos 确认，也许我有！），分区是基于 INGEST/LOAD 时间的，不适合我需要的历史“真实日期”分区。除非您可以在数据中设置一个自定义字段以用作分区时间（例如 orderPlacedTime - 真实事件时间），否则我看不到此用例的这种方法的价值？但如前所述，我可能有这个错误，并会回去确认或不理解我的理解。再次感谢您的回复！ :)

您可以使用$YYYYMMDD 表示法（分区装饰器）自己指定分区，从而将数据放入所需的分区。我们使用这种技术实时流式传输并根据数据自己的时间字段将历史数据加载到正确的分区中。 cloud.google.com/bigquery/docs/…

据我所知，您可以将分区装饰器回溯至最长 1-2 年，但不能回溯 6 年。这是我在之前的 SO 帖子之一中读到的内容。所以它可能是不可靠的信息。

确实如此。但是是否有一些技术可以解决这个限制（我更喜欢使用 Dataflow）。 ***.com/questions/38993877/…

【参考方案1】：

我的建议是认真考虑 Partitioned Tables 的原生 BigQuery 功能

虽然流式传输到分区表有一些 limitations（您可以流式传输到过去 30 天内的分区，以及相对于当前日期的未来 5 天）没有这样的加载或查询作业的限制

相对很久以前，我考虑过使用此选项来解决按列分区而不是按日期分区的方法，方法是在“0001-01-01”和“9999-12-31”（3,652,058 天）之间映射一些归因于日期- 因此要划分的不同属性值）。 POC 在概念上是成功的，但我仍然不喜欢它，特别是 Google 团队强烈承诺（至少我当时是这么认为的）介绍 partitioning by date or int column 的表。我决定等一下。

同时，刷新并仔细检查对分区表的加载或查询仍然没有分区特定的限制（因为它在 SO Post 中以某种方式听起来） - 我做了快速测试，你可以在下面看到结果

第 1 步 - 创建分区表 - project.dataset.partitioned_table 我只是为此使用了 UI。

第二步 - 将查询结果插入表的不同分区

#standardSQL
SELECT 13 AS a

以 project.dataset.partitioned_table$YYYYMMDD 作为目标 （您可以为此使用 DML 的 INSERT）

我在 AC (0001-01-01) 和 ? 结尾之间的日期范围内运行了几次(9999-21-31)

第 3 步 - 检查结果

#standardSQL
SELECT DATE(_partitiontime) AS partition_, a
FROM `project.dataset.partitioned_table`
ORDER BY a

结果是（请记住 - 分区格式_这里是 YYYYMMDD）

partition_      a
----------      --
2017-07-16      1
2017-07-16      2
2017-07-16      3
2017-07-16      4
2017-07-15      5
2017-07-14      6
2010-01-01      7
2001-01-01      8
1001-01-01      9
0001-01-01      10
4001-01-01      11
7001-01-01      12
9999-12-31      13

【讨论】：

您使用什么技术/模式来绕过最大 2500 个分区限制 Mikhail（即约 6 年）？ - cloud.google.com/bigquery/docs/…

... 不仅有2500 max partitions 限制，还有每日限制： 2,000 partition updates per table, per day. 和速率限制： 50 partition updates every 10 seconds.！这取决于，但我认为在这篇文章中的大多数实际情况下 - 每年应该有一天分区表（假设原始数据）。

我们应该强烈考虑，要求增加这个限制

很棒的讨论伙计们——所以只是为了澄清一下米哈伊尔，你是说要绕过分区的限制，即每年有 1 个表（例如，customers_2017、customers_2016 等），每个表都是它本身一个日期（天）分区表，从而确保如果您只有一张表（例如客户），则不会违反时间限制？

是的。现在可以选择每年一张表，以将分区数量保持在限制范围内