数据流用例（小型 SQL 查询）
Use case for dataflow (small SQL queries)
我们正在使用 Cloud Function 来转换 BigQuery 中的数据：
- 所有数据都在 BigQuery 中
- 为了转换数据，我们只使用 BigQuery 中的 SQL 查询
- 每个查询每天运行一次
- 我们最大的 SQL 查询运行大约 2 到 3 分钟，但大多数查询运行不到 30 秒
- 我们每天执行一次大约 50 个查询，而且这个数字还在增加
我们最初尝试使用 Dataflow 做同样的事情（SQL 在 BigQuery 中查询），但是：
- 启动数据流大约需要 10 到 15 分钟
- 编码比我们的云功能更复杂
- 当时，数据流 SQL 没有实现
每次我们与使用 GCP 的人（用户、培训师或审核员）交谈时，他们都会推荐使用 Dataflow。
那么在我们的用例中，我们是否错过了 Dataflow 的某些东西 "magic"？有没有办法让它在几秒钟而不是几分钟内启动？
另外，如果我们在 Dataflow 中使用流式处理，费用是如何计算的？我知道批量我们为使用的东西付费，但是如果我们使用流媒体怎么办？算作全职运行服务吗？
感谢您的帮助
对于第一部分，BigQuery VS Dataflow，我在几周前与 Google 讨论过这个问题，他们的建议很明确：
- 当您可以在 SQL 中表达您的转换并且可以使用 BigQuery (external table) 访问您的数据时，使用 BigQuery 总是更快、更便宜。即使请求很复杂。
- 对于所有其他用例，最推荐使用 Dataflow。
- 实时（真正需要实时，实时计算指标 with windowing）
- 当您需要联系外部时 API（ML、外部服务...）
- 当您需要使用 BigQuery 以外的东西（Firestore、BigTable、Cloud SQL、...）或从 BigQuery 无法访问的来源读取时。
是的，Dataflow 在 3 分钟后启动并在 3 分钟后再次停止。很长...你为这个无用的时间付出代价。
对于批处理，就像流式传输一样，您只需为用于管道的计算引擎的数量（和大小）付费。数据流在您提供的边界内自动缩放。流式传输管道不会缩放到 0。如果您没有在 PubSub 中发送消息，您仍然至少有 1 个 VM 正在运行并且您需要为此付费。
我们正在使用 Cloud Function 来转换 BigQuery 中的数据： - 所有数据都在 BigQuery 中 - 为了转换数据，我们只使用 BigQuery 中的 SQL 查询 - 每个查询每天运行一次 - 我们最大的 SQL 查询运行大约 2 到 3 分钟，但大多数查询运行不到 30 秒 - 我们每天执行一次大约 50 个查询，而且这个数字还在增加
我们最初尝试使用 Dataflow 做同样的事情（SQL 在 BigQuery 中查询），但是： - 启动数据流大约需要 10 到 15 分钟 - 编码比我们的云功能更复杂 - 当时，数据流 SQL 没有实现
每次我们与使用 GCP 的人（用户、培训师或审核员）交谈时，他们都会推荐使用 Dataflow。 那么在我们的用例中，我们是否错过了 Dataflow 的某些东西 "magic"？有没有办法让它在几秒钟而不是几分钟内启动？
另外，如果我们在 Dataflow 中使用流式处理，费用是如何计算的？我知道批量我们为使用的东西付费，但是如果我们使用流媒体怎么办？算作全职运行服务吗？
感谢您的帮助
对于第一部分，BigQuery VS Dataflow，我在几周前与 Google 讨论过这个问题，他们的建议很明确：
- 当您可以在 SQL 中表达您的转换并且可以使用 BigQuery (external table) 访问您的数据时，使用 BigQuery 总是更快、更便宜。即使请求很复杂。
- 对于所有其他用例，最推荐使用 Dataflow。
- 实时（真正需要实时，实时计算指标 with windowing）
- 当您需要联系外部时 API（ML、外部服务...）
- 当您需要使用 BigQuery 以外的东西（Firestore、BigTable、Cloud SQL、...）或从 BigQuery 无法访问的来源读取时。
是的，Dataflow 在 3 分钟后启动并在 3 分钟后再次停止。很长...你为这个无用的时间付出代价。
对于批处理，就像流式传输一样，您只需为用于管道的计算引擎的数量（和大小）付费。数据流在您提供的边界内自动缩放。流式传输管道不会缩放到 0。如果您没有在 PubSub 中发送消息，您仍然至少有 1 个 VM 正在运行并且您需要为此付费。