本页面介绍了在开始开发代码之前规划数据流水线的重要注意事项。数据流水线将数据从一个系统移动到另一个系统，通常是业务信息系统的关键组成部分。数据流水线的性能和可靠性会影响这些更广泛的系统以及您的业务要求得到满足的效果。
如果您在开发数据流水线之前进行规划，则可以提升其性能和可靠性。本页面介绍了 Dataflow 流水线的各种规划注意事项，其中包括：
- 流水线的效果预期，包括衡量标准
- 将您的流水线与数据源、接收器和其他连接的系统集成在一起
- 对流水线、来源和接收器进行地区化
- 安全性，例如数据加密和专用网络
定义和衡量 SLO
衡量性能的一项重要指标是您的流水线满足业务要求的程度。服务等级目标 (SLO) 提供了能够与可接受的阈值进行比较的切实性能定义。例如，您可以为系统定义以下示例 SLO：
数据新鲜度：根据不迟于 3 分钟前发生的用户网站活动生成 90% 的产品推荐。
数据正确性：在日历月份内，包含错误的客户账单小于 0.5%。
数据隔离/负载均衡：一个工作日内，所有高优先级支付在提交后 10 分钟内处理，并在下一个工作日完成标准优先级支付。
您可以使用服务等级指标 (SLI) 来衡量 SLO 合规性。SLI 是一个可量化的指标，指示系统满足指定 SLO 的程度。例如，您可以将最近处理的用户活动的年龄用作 SLI，以此衡量示例数据新鲜度 SLO。如果您的流水线根据用户活动事件生成产品推荐，并且 SLI 报告事件时间和事件处理时间之间的延迟为 4 分钟，则推荐产品不会考虑 4 分钟之前的用户网站活动。如果处理流式数据的流水线超出系统延迟时间（4 分钟），则表示不符合 SLO。
由于流水线之外的系统组件会影响您的 SLO，因此捕获一系列描述系统整体性能的 SLI 非常重要，此性能超出了流水线本身的性能，包括描述系统端到端运行状况的指标。例如，您的 Dataflow 流水线可采用可接受的延迟时间计算结果，但下游系统可能发生性能问题，从而影响更广泛的 SLO。
如需详细了解需要考虑的重要 SLO，请参阅站点可靠性工程一书。
数据新鲜度
数据新鲜度是指与数据存在时间相关的数据的易用性。《站点可靠性工程》一书中介绍了以下数据新鲜度 SLO，其采用最常见的流水线数据新鲜度 SLO 格式：
X% 的数据在 Y [秒、天、分钟] 内处理完毕。此 SLO 是指在给定时间段内处理的数据百分比。它通常用于处理有界限数据源的批处理流水线。这种类型的 SLO 的指标是关键处理步骤的输入和输出数据大小（相对于所用的流水线运行时）。您可以选择一个步骤来读取输入数据集，选择另一个步骤来处理每个输入项。例如，SLO 可能是“对于 Yak 游戏 Shave，在匹配完成后的 30 分钟内，应该包括影响玩家得分的 99% 的用户活动”。
最早的数据不早于 X [秒、天、分钟]。此 SLO 是指流水线生成的数据存在时间。它通常用于可处理无界限来源数据的流处理流水线。对于此类 SLO，使用的指标指示流水线处理数据所需的时间。有两个可能的指标：最早未处理项的存在时间（未处理的项在队列中的存在时间）或最近处理过的项的存在时间。例如，SLO 是“产品推荐是根据不晚于 5 分钟的用户活动生成的。”
流水线作业在 X [秒、天、分钟]内成功完成。此 SLO 会设置成功完成截止时间，通常用于可处理有界限数据源数据的批处理流水线。除了需要指示作业成功的其他信号之外（例如导致错误的已处理元素百分比），此 SLO 还需要流水线的总用时和作业完成状态。例如，SLO 是“当前工作日的客户订单应在次日上午 9 点处理”。
如需了解如何使用 Cloud Monitoring 衡量数据新鲜度，请参阅 Dataflow 作业指标。
数据正确性
数据正确性是指没有错误的数据。您可以通过不同的方法确定数据正确性，包括：
端到端流水线测试，您可以在流水线成功通过单元测试和集成测试后在预生产环境中运行这些测试。您可以使用持续交付实现自动化端到端流水线测试。
在生产环境中运行流水线，当您使用监控功能观察与数据正确性相关的指标时。
对于运行中的流水线，定义数据正确性目标通常涉及在一段时间内测量正确性。例如：
- 对于每个作业，不到 X% 的输入项包含数据错误。您可以使用此 SLO 来测量批处理流水线的数据正确性。例如，SLO 是“每个每日批处理作业处理的电表读数中，不到 3% 的读数包含数据输入错误”。
- 在 X 分钟的移动窗口内，不到 Y% 的输入项包含数据错误。您可以使用此 SLO 来测量流处理流水线的数据正确性。例如，“SLO”是“过去一小时内不到 2% 的电表读数包含负值”。
如需测量这些 SLO，请使用适当时间段内的指标来按类型累积错误数量。错误类型的示例包括由于架构不正确或数据超出有效范围，因此数据不正确。
如需了解如何使用 Cloud Monitoring 衡量数据正确性，请参阅 Dataflow 作业指标。
数据隔离和负载均衡
数据隔离涉及按属性细分数据，从而简化负载均衡。例如，在在线付款处理平台中，您可以细分数据，以便使单个付款具有标准优先级或高优先级。然后，您的流水线可以使用负载均衡来确保高优先级付款在标准优先级付款之前处理。
假设您为付款处理定义以下 SLO：
- 高优先级付款在 10 分钟内进行处理。
- 标准优先级付款将在下一个工作日的上午 9 点进行处理。
如果付款平台遵守这些 SLO 规定，则当高优先级付款完成后，客户可以在报告信息中心查看最终确定的高优先级付款。相比之下，标准付款可能要到第二天才会显示在信息中心上。
在此示例场景中，您具有以下选项：
- 运行单个流水线以同时处理标准优先级付款和高优先级付款。
- 根据多个流水线中的优先级隔离数据并实现负载均衡。
以下各部分详细介绍了每个选项。
使用单个流水线根据混合 SLO 来实现
下图展示了用于同时处理高优先级和标准优先级付款的单个流水线。该流水线接收来自流式数据源（例如 Pub/Sub 主题或 Apache Kafka 主题）的新付款通知。然后，它会立即处理付款并使用流式插入将事件写入 BigQuery 中。
单个流水线的优势在于，它可以简化运营要求，因为您只需管理单个数据源和流水线即可。Dataflow 使用自动调节功能，这些功能有助于尽可能快速、高效地运行您的作业。
单个流水线的缺点是共享流水线无法优先处理高优先级付款再处理标准优先级付款，而流水线资源在这两种付款类型之间共享。在上述业务场景中，您的流水线必须维护两个 SLO 中较严格的那一个。也就是说，无论已处理付款的实际优先级如何，流水线都必须使用 SLO 进行高优先级付款。另一个缺点是，如果发生工作积压，流处理流水线就无法根据工作的紧急程度来优先处理积压工作。
使用专门为特定 SLO 量身定制的多个流水线
您可以使用两个流水线来隔离资源并根据特定 SLO 来实现。下图演示了此方法。
高优先级付款将隔离到流处理流水线以进行优先处理。标准优先级付款由每天运行且使用 BigQuery 加载作业写入处理后结果的批处理流水线进行处理。
在不同流水线中隔离数据具有一定的优势。如需根据较严格的 SLO 实现高优先级付款，您可以为专用于高优先级付款的流水线分配更多资源，从而缩短处理时间。资源配置包括添加 Dataflow 工作器、使用更大的机器以及启用自动扩缩功能。通过将高优先级项与单独的处理队列分离，还可以减少因标准优先级付款突然激增而导致处理延迟的情况。
如果您使用多个流水线将数据与批处理数据源和流处理来源隔离开来并实现数据的负载平衡，则 Apache Beam 编程模型允许高优先级（流式）流水线和标准优先级（批处理）流水线共享同一个代码。唯一的例外是初始读取转换，该转换从批处理流水线的有界限来源中读取数据。如需了解详情，请参阅创建可重复使用的转换库。
规划数据源和接收器
要处理数据，需要将数据流水线与其他系统集成。这些系统被称为“来源”和“接收器”。数据流水线从来源读取数据并将数据写入接收器。除了来源和接收器之外，数据流水线还可以与外部系统进行交互，以便在处理步骤中扩充数据、过滤或调用外部业务逻辑。
为了提高可扩缩性，Dataflow 会跨多个工作器并行运行流水线的各个阶段。流水线代码和 Dataflow 服务之外的因素也会影响流水线的可扩缩性。这些因素可能包括以下内容：
外部系统的可扩缩性：与您的流水线交互的外部系统可以限制性能，且可生成可扩缩性上限。例如，如果 Apache Kafka 主题针对所需的读取吞吐量配置的分区数量不足，则可能会影响流水线的性能。为帮助确保流水线及其组件达到您的性能目标，请参阅适合您使用的外部系统的最佳做法文档。您还可以通过提供内置可扩缩性的 Google Cloud 服务来简化基础架构容量规划。如需了解详情，请参阅本页面上的使用 Google Cloud 管理的来源和接收器。
数据格式选项：某些数据格式的速度可能比其他格式要快。例如，使用支持可并行读取的数据格式（如 Avro）的速度通常比使用在字段中嵌入换行符的 CSV 文件要快，而且比使用压缩文件要快。
数据位置和网络拓扑：数据源和接收器相对于数据流水线的地理便捷性和网络特征可能会影响性能。如需了解详情，请参阅本页面上的地区注意事项。
外部服务调用
每次从流水线调用外部服务都会产生开销，从而可能降低流水线的性能和效率。如果您的数据流水线调用外部服务，请尽可能将多个数据元素批量处理为单个请求，以减少开销。许多原生 Apache Beam I/O 转换会自动执行此任务，包括 BigQueryIO 和流式插入操作。除了容量限制之外，某些外部服务还会强制执行配额限制，以限制一段时间内的总调用次数（例如，每日配额），或者限制调用速率（例如每秒请求数）。
由于 Dataflow 并行处理多个工作器中的工作，因此过多的流量可能会使外部服务过载，或耗尽可用配额。使用自动扩缩功能时，Dataflow 可能会尝试添加工作器以运行缓慢的步骤（例如外部调用）进行补偿。添加工作器可能会对外部系统产生更大的压力。确保外部系统可以支持您的预期加载要求，或将来自流水线的流量限制在可持续等级。如需了解详情，请参阅限制批次大小和同时调用外部服务。
使用 Google Cloud 代管的来源和接收器
将 Google Cloud 代管的服务与 Dataflow 流水线搭配使用，以提供内置可扩缩性、一致性能以及满足大多数要求的配额和限制，从而消除容量管理的复杂性。您仍需注意流水线操作的不同配额和限制。Dataflow 本身设有配额和限制。您可以通过联系 Google Cloud 支持团队来增加一部分配额和限制。
Dataflow 使用 Compute Engine 虚拟机实例来运行作业，因此您需要足够的 Compute Engine 配额。Compute Engine 配额不足可能会影响流水线自动扩缩或阻止作业启动。
本部分的其余内容探索了不同的 Google Cloud 配额和限制如何影响您设计、开发和监控流水线的方式。Pub/Sub 和 BigQuery 用作流水线来源和接收器的示例。
示例 1：Pub/Sub
当您将 Pub/Sub 与 Dataflow 搭配使用时，Pub/Sub 会提供一个可扩缩、持久的事件提取服务，以便在流处理数据流水线中传递消息。您可以使用 Google Cloud 控制台查看 Pub/Sub 配额占用以及增加配额限制。如果您有任何流水线超过每个项目的配额和限制，我们建议您申请增加配额。
Pub/Sub 配额和限制基于项目级用量设计。具体而言，不同项目中的发布者和订阅者具有独立的数据吞吐量配额。如果多个流水线发布或订阅单个主题，您可以通过将每个流水线部署到自己的项目中来获得该主题允许的最大吞吐量。在此配置中，每个流水线使用不同的基于项目的服务账号来使用和发布消息。
在下图中，流水线 1 和流水线 2 共享提供给项目 A 的相同订阅者和发布者吞吐量配额。相比之下，流水线 3 可以使用附加到项目 B 的整个订阅者和发布者吞吐量配额。
多条流水线可以通过使用单独的主题订阅从单个 Pub/Sub 主题中读取数据，这样一来，Dataflow 流水线便可以独立于其他订阅者（在本例中为其他流水线）拉取和确认消息。借助此功能，您可以通过创建其他 Pub/Sub 订阅轻松克隆流水线。创建其他订阅有助于创建副本流水线以实现高可用性（通常用于流处理使用场景）、根据相同资料运行其他测试流水线，以及启用流水线更新。
示例 2：BigQuery
多种语言的 Apache Beam SDK（包括 Java、Python 和 Go）都支持读取和写入 BigQuery 数据。当您使用 Java 时，BigQueryIO 类提供了此功能。BigQueryIO 支持两种数据读取方法：EXPORT（表导出）和 DIRECT_READ。不同的读取方法会使用不同的 BigQuery 配额。
表导出是默认的读取方法。其工作原理如下图所示：
下图展示了以下流程：
- BigQueryIO 调用 BigQuery 导出请求来导出表数据。导出的表数据将写入临时 Cloud Storage 位置。
- BigQueryIO 从临时 Cloud Storage 位置读取表数据。
BigQuery 导出请求受到导出配额限制。还必须先完成导出请求，然后流水线可以开始处理数据，这会为作业增加额外的运行时间。
相比之下，直接读取方法使用 BigQuery Storage API 直接从 BigQuery 读取表数据。BigQuery Storage API 使用 gRPC 为表行数据提供高吞吐量读取性能。 使用 BigQuery Storage API 可避免执行导出步骤，可避免导出配额限制，从而可能缩短作业运行时间。
下图显示了使用 BigQuery Storage API 的流程。与使用 BigQuery 导出请求的流程相比，此流程更加简单，因为它只需执行一个直接读取步骤，即可将表中的数据提取到流水线。
将数据写入 BigQuery 表也会影响自己的配额。使用 BigQuery 加载作业的批处理流水线会使用表和项目级层适用的不同 BigQuery 加载作业配额。同样，使用 BigQuery 流式插入的流处理流水线会使用 BigQuery 流式插入配额。
如需确定最适合读写数据的方法，请考虑您的使用场景。例如，避免使用 BigQuery 加载作业来每天数千次将数据附加到表中。使用流处理流水线将近乎实时的数据写入 BigQuery。为此，您的流式处理流水线应使用流式插入或 Storage Write API。
地区注意事项
Dataflow 在多个 Google Cloud 区域中作为托管式服务提供。选择用于运行作业的区域时，请考虑以下因素：
- 数据源和接收器的位置
- 数据处理位置的偏好或限制
- 仅在特定地区中提供的 Dataflow 功能
- 用于管理给定作业执行的区域
- 用于作业工作器的区域
对于给定作业，用于作业和工作器的区域设置可能会有所不同。如需了解详情（包括何时指定区域和可用区），请参阅 Dataflow 区域文档。
通过指定地区来运行 Dataflow 作业，您可以基于地区注意事项针对高可用性和灾难恢复进行规划。如需了解详情，请参阅高可用性和地理冗余。
区域
Dataflow 区域可存储和处理与作业相关的元数据，如 Apache Beam 图本身的相关信息，比方说转换名称。这些端点还可以控制工作器行为，例如自动扩缩。指定区域有助于满足您对安全性和合规性、数据存储区域以及作业区域放置的需要。为避免跨区域网络调用造成性能影响，我们建议尽可能为作业和工作器使用同一区域。
Dataflow 工作器
Dataflow 作业使用 Compute Engine 虚拟机实例（称为 Dataflow 工作器）来运行流水线。Dataflow 作业可以使用任何 Compute Engine 区域来放置工作器，包括没有 Dataflow 位置的区域。通过为作业指定工作器区域，您可以控制工作器的区域位置。如需指定工作器地区或区域，请执行以下操作：
- 如果您使用 gcloud CLI 从 Dataflow 模板创建作业，请使用
--worker-region标志替换工作器地区，或使用--worker-zone标志替换工作器区域。 - 如果您使用 Apache Beam Java SDK 创建作业，请使用流水线选项为工作器设置地区和区域。使用
workerRegion替换工作器地区，或使用workerZone替换工作器区域。
为降低网络延迟时间并提高吞吐量，我们建议您在地理位置靠近您的数据源和接收器的地区创建工作器。如果您在创建作业时没有为工作器指定区域或可用区，则 Dataflow 会自动默认使用与作业位于同一区域的可用区。
如果您不使用 Dataflow Shuffle 服务或 Streaming Engine，则作业处理的数据（即存储在任何 PCollection 对象中的数据）将位于作业的工作器中（假设没有用户代码在工作器外部传输数据）。如果启用了 Dataflow Shuffle 服务或 Streaming Engine，则由 PCollection 对象表示的分布式数据集可以在工作器和这些服务之间传输。
数据加密注意事项
作为全托管式服务，Dataflow 将 Google 拥有和 Google 管理的密钥用于运行中数据和静态数据，以便自动加密通过数据流水线的数据。您可能希望管理自己的加密密钥，而不是使用 Google 拥有和 Google 管理的密钥。在这种情况下，Dataflow 使用 Cloud Key Management Service (KMS) 来支持客户管理的加密密钥 (CMEK)。您还可以使用 Cloud HSM，它是一种云托管的硬件安全模块 (HSM) 服务，该服务可让您在 FIPS 140-2 3 级认证的 HSM 集群中托管加密密钥以及执行加密操作。
当您使用 CMEK 时，Dataflow 会使用您的 Cloud KMS 密钥来加密数据，但数据选取、分组和联接等基于数据密钥的操作除外。如果数据密钥包含敏感数据（例如个人身份信息 (PII)），您必须在密钥进入 Dataflow 流水线之前对其进行哈希处理或转换。
专用网络注意事项
您的网络和安全要求可能会要求基于虚拟机的工作负载（例如 Dataflow 作业）仅使用专用 IP 地址。借助 Dataflow，您可以指定工作器使用专用 IP 地址进行所有网络通信。如果已停用公共 IP，您必须在子网上启用专用 Google 访问通道，以便 Dataflow 工作器可以访问 Google API 和服务。
我们建议您停用 Dataflow 工作器的公共 IP，除非您的 Dataflow 作业需要公共 IP 来访问 Google Cloud 外部的网络资源。如果停用公共 IP，则 Dataflow 工作器无法访问子网外部的资源，也无法访问对等 VPC 网络。同样，系统会阻止经由网络从子网外部或从对等 VPC 网络访问虚拟机工作器。
如需详细了解如何使用 --usePublicIps 流水线选项来指定工作器是否只应使用专用 IP，请参阅流水线选项。
后续步骤
- 开发和测试流水线。
- 了解如何设计完整的流水线工作流。
- 详细了解 Google 的数据处理流水线的网站可靠性工程 (SRE) 做法。