BigQuery BQ.insert_rows_json 和 BQ.load_from_json 之间的差异？
Differences between BigQuery BQ.insert_rows_json and BQ.load_from_json?
我想将数据流式传输到 BigQuery 中，并且我在考虑使用 PubSub + Cloud Functions，因为不需要转换（至少现在）并且使用 Cloud Data Flow 感觉有点过头了将行插入 table。我是对的？
数据使用 Python 脚本从 GCP VM 流式传输到 PubSub，格式如下：
{'SEGMENT':'datetime':'2020-12-05 11:25:05.64684','values':(2568.025,2567.03)}
BigQuery 架构是 datetime:timestamp, value_A: float, value_B: float。
我的问题是：
a) 我是否需要将其以 json/dictionary 的形式推送到 BigQuery 中，所有值都是字符串，还是必须使用 table 的数据类型？
b) 使用 BQ.insert_rows_json 和 BQ.load_table_from_json 有什么区别，我应该使用哪个来完成这项任务？
编辑：
我要获取的其实是一些资产的行情数据。说出大约 28 种乐器并捕捉它们的所有滴答声。平均每天，每个工具有 ~60.k 次报价，所以我们说的是每月约 3360 万次调用。 （现在）需要的是将它们插入 table 中以供进一步分析。我目前不确定是否应该执行真正的流式传输或每批次加载。由于项目还在做分析，我觉得不需要数据流，但应该使用 PubSub，因为它可以在时机成熟时更容易地扩展到数据流。这是我第一次实现流媒体管道，我正在使用我通过课程和阅读学到的所有知识。如果我有错误的方法，请纠正我:)。
例如，当一个报价与第 n 个报价之间的价格差为 10 时，我绝对想做的是，对另一个 table 执行另一个插入。为此，我应该使用数据流还是云函数方法仍然有效？因为这就像一个触发条件。基本上，触发器类似于：
if price difference >= 10:
process all these ticks
insert the results in this table
但是我不确定如何实现这个触发器。
回答您的问题：
a) 您需要使用库的接受格式推送到 BigQuery，通常是集合或格式化为 table 定义的 JSON 文档。
b) 要将数据添加到 BigQuery，您可以流式传输数据或加载文件。
对于您的示例，您需要流式传输数据，因此请使用 'streaming api' 方法 insert_rows* 系列。
加上Marton(Pentium10)的精彩解答
a) 您可以在 BigQuery 中流式传输一个 JSON，一个有效的 json。你的例子不是。关于类型，根据您的模式有一个自动 coercion/conversion。你可以看到这个here
b) 加载作业加载 GCS 中的文件或您放入请求中的内容。批处理是异步的，可能需要几秒钟或几分钟。此外，您被限制为 1500 load per days and per table -> 每分钟工作 1 个（每天 1440 分钟）。加载作业有几个有趣的方面。
- 首先，它是免费的！
- 您的数据会立即加载到正确的分区中，并立即可在该分区中请求
- 如果加载失败，则不会插入任何数据。因此，最简单的方法是在没有双倍值的情况下重播文件。
相反，流式作业实时将数据插入BigQuery。当您有实时限制时（尤其是可视化、异常检测等），这很有趣。但也有不好的一面
- 您被限制为 500k rows per seconds (in EU and US), 100k rows in other regions，每秒最大 1Gb
- 数据不是直接在分区中，而是在 buffer name
UNPARTITIONED for a while or up to have this buffer full. 中。因此，在构建和测试实时应用程序时，您必须考虑这种特殊性。
- 是not free。最便宜的区域是每 Gb 0.05 美元。
既然您已经意识到这一点，请问问自己的用例。
- 如果您需要实时（小于 2 分钟的延迟），毫无疑问，流媒体适合您。
- 如果您每月只有几 Gb，流式传输也是最简单的解决方案，只需 $
- 如果您有大量数据（每秒超过 1Gb），BigQuery 不是好的服务，请考虑 BigTable（you can request with BigQuery as a federated table）
- 如果您的数据量很大（每分钟 1 或 2Gb）并且您的用例要求数据在分钟以上时新鲜，您可以考虑特殊设计
- 创建 PubSub 请求订阅
- 创建一个 HTTP 触发的 Cloud Function（或 Cloud 运行 服务）来拉取订阅 1 分钟，然后将拉取的内容作为加载作业提交给 BigQuery（不需要文件，您可以 post 内存中的内容直接到 BigQuery）。然后优雅地存在
- 创建一个每分钟触发一次服务的 Cloud Scheduler。
编辑 1：
成本不应驱动您的用例。
如果目前仅用于分析，您只需想象每天触发一次您的工作以获取完整订阅。使用您的指标：60k 指标 * 28 个仪器 * 100 字节（24 + 内存丢失），您只有 168Mb。您可以将其存储在 Cloud Functions 或 Cloud 运行 内存中并执行加载作业。
流式传输对于实时来说真的很重要！
数据流，在流模式下，每月至少花费 20 美元（1 名 n1-standard1 类型的小工人。使用 Cloud Functions 在 BigQuery 中插入流式数据超过 1.5Gb。
最终，关于流式传输或批量插入的智能触发器，这实际上是不可能的，如果您更改逻辑，则必须重新设计数据摄取。但首先，只有当您的用例需要这个时！！
我想将数据流式传输到 BigQuery 中，并且我在考虑使用 PubSub + Cloud Functions，因为不需要转换（至少现在）并且使用 Cloud Data Flow 感觉有点过头了将行插入 table。我是对的？
数据使用 Python 脚本从 GCP VM 流式传输到 PubSub，格式如下：
{'SEGMENT':'datetime':'2020-12-05 11:25:05.64684','values':(2568.025,2567.03)}
BigQuery 架构是 datetime:timestamp, value_A: float, value_B: float。
我的问题是：
a) 我是否需要将其以 json/dictionary 的形式推送到 BigQuery 中，所有值都是字符串，还是必须使用 table 的数据类型？
b) 使用 BQ.insert_rows_json 和 BQ.load_table_from_json 有什么区别，我应该使用哪个来完成这项任务？
编辑：
我要获取的其实是一些资产的行情数据。说出大约 28 种乐器并捕捉它们的所有滴答声。平均每天，每个工具有 ~60.k 次报价，所以我们说的是每月约 3360 万次调用。 （现在）需要的是将它们插入 table 中以供进一步分析。我目前不确定是否应该执行真正的流式传输或每批次加载。由于项目还在做分析，我觉得不需要数据流，但应该使用 PubSub，因为它可以在时机成熟时更容易地扩展到数据流。这是我第一次实现流媒体管道，我正在使用我通过课程和阅读学到的所有知识。如果我有错误的方法，请纠正我:)。
例如，当一个报价与第 n 个报价之间的价格差为 10 时，我绝对想做的是，对另一个 table 执行另一个插入。为此，我应该使用数据流还是云函数方法仍然有效？因为这就像一个触发条件。基本上，触发器类似于：
if price difference >= 10:
process all these ticks
insert the results in this table
但是我不确定如何实现这个触发器。
回答您的问题：
a) 您需要使用库的接受格式推送到 BigQuery，通常是集合或格式化为 table 定义的 JSON 文档。
b) 要将数据添加到 BigQuery，您可以流式传输数据或加载文件。
对于您的示例，您需要流式传输数据，因此请使用 'streaming api' 方法 insert_rows* 系列。
加上Marton(Pentium10)的精彩解答
a) 您可以在 BigQuery 中流式传输一个 JSON，一个有效的 json。你的例子不是。关于类型，根据您的模式有一个自动 coercion/conversion。你可以看到这个here
b) 加载作业加载 GCS 中的文件或您放入请求中的内容。批处理是异步的，可能需要几秒钟或几分钟。此外，您被限制为 1500 load per days and per table -> 每分钟工作 1 个（每天 1440 分钟）。加载作业有几个有趣的方面。
- 首先，它是免费的！
- 您的数据会立即加载到正确的分区中，并立即可在该分区中请求
- 如果加载失败，则不会插入任何数据。因此，最简单的方法是在没有双倍值的情况下重播文件。
相反，流式作业实时将数据插入BigQuery。当您有实时限制时（尤其是可视化、异常检测等），这很有趣。但也有不好的一面
- 您被限制为 500k rows per seconds (in EU and US), 100k rows in other regions，每秒最大 1Gb
- 数据不是直接在分区中，而是在 buffer name
UNPARTITIONEDfor a while or up to have this buffer full. 中。因此，在构建和测试实时应用程序时，您必须考虑这种特殊性。 - 是not free。最便宜的区域是每 Gb 0.05 美元。
既然您已经意识到这一点，请问问自己的用例。
- 如果您需要实时（小于 2 分钟的延迟），毫无疑问，流媒体适合您。
- 如果您每月只有几 Gb，流式传输也是最简单的解决方案，只需 $
- 如果您有大量数据（每秒超过 1Gb），BigQuery 不是好的服务，请考虑 BigTable（you can request with BigQuery as a federated table）
- 如果您的数据量很大（每分钟 1 或 2Gb）并且您的用例要求数据在分钟以上时新鲜，您可以考虑特殊设计
- 创建 PubSub 请求订阅
- 创建一个 HTTP 触发的 Cloud Function（或 Cloud 运行 服务）来拉取订阅 1 分钟，然后将拉取的内容作为加载作业提交给 BigQuery（不需要文件，您可以 post 内存中的内容直接到 BigQuery）。然后优雅地存在
- 创建一个每分钟触发一次服务的 Cloud Scheduler。
编辑 1：
成本不应驱动您的用例。
如果目前仅用于分析，您只需想象每天触发一次您的工作以获取完整订阅。使用您的指标：60k 指标 * 28 个仪器 * 100 字节（24 + 内存丢失），您只有 168Mb。您可以将其存储在 Cloud Functions 或 Cloud 运行 内存中并执行加载作业。
流式传输对于实时来说真的很重要！
数据流，在流模式下，每月至少花费 20 美元（1 名 n1-standard1 类型的小工人。使用 Cloud Functions 在 BigQuery 中插入流式数据超过 1.5Gb。
最终，关于流式传输或批量插入的智能触发器，这实际上是不可能的，如果您更改逻辑，则必须重新设计数据摄取。但首先，只有当您的用例需要这个时！！