配额和限制

本文档列出了适用于 Dataflow 的配额和限制。

配额用于限制您的 Google Cloud 项目可使用的共享 Google Cloud 资源（包括硬件、软件和网络组件）的数量。因此，有以下功能的系统具有配额：

  • 监控 Google Cloud 产品和服务的使用情况或消耗情况。
  • 出于某些原因限制这些资源的消耗量，包括确保公平性和减少使用量高峰。
  • 维护可自动强制执行规定限制的配置。
  • 提供请求或更改配额的方法。

在大多数情况下，当超过配额时，系统会立即阻止对相关 Google 资源的访问，并且您尝试执行的任务将失败。在大多数情况下，配额适用于每个 Google Cloud 项目，并由使用该 Google Cloud 项目的所有应用和 IP 地址共享。

如需增加或减少大多数配额，请使用 Google Cloud 控制台。如需了解详情，请参阅申请更高的配额。

Dataflow 资源也有限制。这些限制与配额系统无关。除非另有说明，否则无法更改限制。

Dataflow 代管式服务具有以下配额和限制：

  • 每个 Google Cloud 项目每分钟最多可以发出 300 万个请求。
  • 每个 Dataflow 作业最多可使用 2,000 个 Compute Engine 实例。如果不指定工作器可用区，则每个使用 Streaming Engine 的流式处理作业或使用基于服务的 Dataflow Shuffle 的批处理作业最多可以使用 4,000 个 Compute Engine 实例。
  • 默认情况下，每个 Google Cloud 项目可以运行最多 25 个并发的 Dataflow 作业。
  • 每个 Dataflow 工作器都有在一个时间间隔输出的日志上限。如需了解确切的限制，请参阅日志记录文档。
  • 如果您选择接受组织级别的配额，则默认情况下每个组织可以运行最多 125 个并发的 Dataflow 作业。
  • 每个用户每分钟最多可以发出 15,000 个监控请求。
  • 每个用户每分钟最多可以发出 60 个作业创建请求。
  • 每个用户每分钟最多可以发出 60 个作业模板请求。
  • 每个用户每分钟最多可以发出 60 个作业更新请求。
  • 每个 Google Cloud 项目在各个区域可拥有以下数量的 Shuffle 槽：
    • asia-east1：48 个槽
    • asia-northeast1：24 个槽
    • asia-northeast3：32 个槽
    • asia-south1：64 个槽
    • asia-southeast1：64 个槽
    • australia-southeast1：24 个槽
    • europe-west1：640 个槽
    • europe-west2：32 个槽
    • europe-west3：40 个槽
    • europe-west4：512 个槽
    • northamerica-northeast1：512 个槽
    • us-central1：640 个槽
    • us-east1：640 个槽
    • us-east4：64 个槽
    • us-west1：384 个槽
    • us-west2：24 个槽
    • us-west3：24 个槽
    • 其他：16 个槽
    16 个槽足以同时对大约 10 TB 的数据进行重排处理。
  • Dataflow 批量作业将在 30 天后取消。

Compute Engine 配额

在 Dataflow 服务上运行流水线时，Dataflow 会创建 Compute Engine 实例来运行流水线代码。

Compute Engine 配额按区域来指定。请查看您的项目的 Compute Engine 配额，并在需要时申请进行以下调整：

  • CPU 数量：Dataflow 的默认机器类型为 n1-standard-1（用于批处理）、n1-standard-2（用于使用 Streaming Engine 的作业）和 n1-standard-4（用于不使用 Streaming Engine 的作业）。 FlexRS 默认使用 n1-standard-2 机器。在 Beta 版阶段，FlexRS 使用 90% 的抢占式虚拟机和 10% 的常规虚拟机。Compute Engine 计算 CPU 数量的方式是将每个实例的 CPU 总数相加。例如，运行 10 个 n1-standard-4 实例计为 40 个 CPU。请参阅 Compute Engine 机器类型，了解每种机器类型所对应的 CPU 个数。
  • 使用中的 IP 地址数：项目使用中的 IP 地址数量必须足够容纳所需数量的实例。如需使用 10 个 Compute Engine 实例，您就需要有 10 个使用中的 IP 地址。
  • 永久性磁盘：Dataflow 为每个实例都挂接了永久性磁盘。
    • 用于批处理流水线的默认磁盘大小为 250 GB，用于流处理流水线的默认磁盘大小为 400 GB。对于 10 个实例，默认情况下，批处理作业需要 2500 GB 的永久性磁盘。
    • 用于 Dataflow Shuffle 批处理流水线的默认磁盘大小为 25 GB。
    • 用于 Streaming Engine 流式流水线的默认磁盘大小为 30 GB。
    • 在运行流处理作业时，Dataflow 服务目前仅支持每个工作器实例 15 个永久性磁盘。每个永久性磁盘是单个 Compute Engine 虚拟机的本地磁盘。最低资源配额是工作器数量与磁盘数量之比为 1:1。
    • Compute Engine 用量是根据平均工作器数量来计算，而 Persistent Disk 用量则是以 --maxNumWorkers 的确切数量为准。系统会重新分配永久性磁盘，使每个工作器都会挂接相同数量的磁盘。
  • 区域级代管式实例组：Dataflow 会将您的 Compute Engine 实例部署为区域级代管式实例组。您需要确保自己拥有以下相关配额：
    • 每个 Dataflow 作业具有一个实例组
    • 每个 Dataflow 作业具有一个实例模板
    • 每个 Dataflow 作业具有一个区域级代管式实例组

其他配额

根据您正在使用的数据源和接收器，您可能还需要其他的配额。

  1. Pub/Sub：如果您使用的是 Pub/Sub，则可能需要其他的配额。在计划配额时，请注意，处理来自 Pub/Sub 的 1 条消息涉及到 3 项操作。如果您使用自定义时间戳，则应预见到操作次数会增加一倍，因为 Dataflow 将创建一个单独的订阅来跟踪自定义时间戳。
  2. BigQuery：如果您针对 BigQuery 使用流处理 API，则需遵守配额限制和其他限制。

查找并增加配额

您可以查看 Dataflow 专用配额的当前使用情况：

  1. 在 Google Cloud 控制台中，转到 API 和服务。
    转到 API 和服务
  2. 如需查看当前的 Shuffle 槽配额使用情况，请在配额标签页上找到表的 Shuffle 槽行，然后在用量图表列中点击显示用量图表。

如需增加作业配额，请与 Google Cloud 支持团队联系，我们会将限额增加到更适合您需求的值。默认配额为 25 个并发 Dataflow 作业（针对您的项目）或 125 个并发 Dataflow 作业（针对您的组织）。

此外，您可以提交支持请求来提高批处理作业的 Shuffle 槽配额，并为项目中的所有作业指定预期的最大并发 Shuffle 数据集大小。在请求额外的 Shuffle 配额之前，请使用 Dataflow Shuffle 运行您的流水线并查看实际的 Shuffle 配额使用情况。

对于流式作业，您可以向 Google Cloud Platform 支持服务提交支持请求来提高 Streaming Engine 吞吐量。在请求中，请为每个运行作业的地区指定您希望每分钟在工作器之间重排的最大数据量。

Dataflow 服务还可能用到 Google Cloud 的多款产品，如 BigQuery、Cloud Storage、Pub/Sub 和 Compute Engine。这些产品（连同其他 Google Cloud 服务）使用配额来限制您可以在项目中使用的资源数量上限。在使用 Dataflow 时，您可能需要调整这些服务的配额设置。

Dataflow Prime

Dataflow 和 Dataflow Prime 的配额和限制是相同的。如果您有 Dataflow 配额，则无需额外的配额即可使用 Dataflow Prime运行作业。

限制

本节介绍 Dataflow 在正式使用环境下的实际限制。

限额 数量
每个流水线的工作器数量上限。 1000
作业创建请求的大小上限。步骤很多且名称冗长的流水线说明可能会达到此限制。 10 MB
模板启动请求的大小上限。 1 MB
辅助输入分片的数量上限。 20000
单个元素的大小上限（应用更严格的条件 [例如 Streaming Engine] 时除外）。 2 GB
Streaming Engine 中单个元素值的大小上限 80 MB
每个工作器在指定时间段内生成的日志条目数量上限。 每 30 秒 15000 条消息
每个项目的自定义指标数量上限。 100
存储建议的时长。 30 天
Streaming Engine 限制 数量
Pub/Sub 消息的字节数上限。 7 MB
大键的大小上限。超过 64 KB 的键会导致性能下降。 2 MB
侧边输入的大小上限。 80 MB
TagValue 和 TagBag 使用的状态标记的长度上限。 64 KB