Openflow 扩展和成本注意事项¶
Snowflake Openflow 在多个领域都有成本方面的考虑，包括基础设施、计算、数据引入等。扩展 Openflow 需要了解这些成本。 以下部分将总体介绍 Openflow 的成本，并通过多个示例说明扩展 Openflow 运行时及相关成本的情况。
Openflow 成本¶
使用 Openflow 时可能会产生以下类型的成本：
成本类别 |
描述 |
|---|---|
Openflow（在您的 Snowflake 账单上显示为“Openflow 计算 BYOC”） |
成本基于连接器运行时在“自带云 (BYOC)”环境中使用的虚拟 CPU 核心 (vCPU) 的数量。您仅需为活跃运行时付费。这笔特定费用不包括用于 Openflow 管理流程的计算。按秒计算 Credit 使用量，最低为 60 秒。 有关使用 VCPU 和扩展影响的示例，请参阅 Openflow 扩展。 有关每 vCPU 每小时费率的信息，请参阅 Snowflake 服务消耗表 中的表 1(g)。 此外，Account Usage 架构中的 METERING_DAILY_HISTORY 和 METERING_HISTORY 视图可使用针对 有关在 Snowflake 中探索计算成本的更多信息，请参阅 了解计算成本。 |
基础设施（仅适用于 BYOC 配置） |
仅适用于 BYOC 部署，例如，您可以直接向 AWS 等云提供商付款，以购买在您的环境中配置的、用于运行 Openflow 的底层基础设施。这主要包括计算（用于为运行连接器预置的运行时的计算，以及用于管理运行时的计算）、网络和存储成本，并将显示在 CSP 账单上。 下图说明了 EC2 计算需求： 
|
引入 |
使用 Snowpipe 或 Snowpipe Streaming 等服务将数据加载到 Snowflake 中的成本，根据数据量计算。相关成本将显示在您 Snowflake 账单上相应的引入服务行项目下。某些连接器可能需要标准的 Snowflake 仓库，从而产生额外的仓库成本。例如，数据库 CDC 连接器需要一个 Snowflake 仓库，来存储初始快照和增量变更数据捕获 (CDC)。您可以安排 MERGE 操作来管理计算成本。 |
遥测数据引入 |
标准版 Snowflake 会对以下操作计费：将日志和指标发送至 Openflow 部署，以及将运行时数据发送至 Snowflake 内的事件表。遥测数据每 GB 的 credit 费率可在 Snowflake 服务消耗表 的表格 5 中找到。 |
Openflow 扩展¶
您选择的运行时和扩展行为对于有效管理成本至关重要。Openflow 支持不同的运行时类型，每种类型都有自己的扩展特征。
运行时类型和相关成本¶
下表说明了各种运行时的扩展行为及其相关成本：
运行时 |
Activity 页面 |
Snowflake 成本 |
云成本 |
|---|---|---|---|
无运行时 |
无 |
无成本 |
Dataplane 的计算和存储 |
1 个小型运行时 (1vCPU) :newline:`.`（最小 1，最大 2） |
激活 1 小时 . 运行时无法扩展到 2。 |
1 个运行时 x 1 个节点 x 1 vCPU x 1 小时 = 1 . 总计 = 1 vCPU 小时 |
Dataplane 的计算和存储 |
2 个小型运行时 (1 vCPU)（最小/最大 = 2）:newline: |
小型运行时：2 个节点激活 1 小时 . 大型运行时：10 个节点激活 1 小时 |
2 个运行时 x 2 个节点 x 2 vCPU x 1 小时 = 4 vCPU . 1 个运行时 x 10 个节点 x 8 vCPU x 1 小时 = 80 vCPU . 总计 = 84 vCPU 小时 |
Dataplane 的计算和存储 |
1 个中型运行时 (4vCPU):newline:`.`（最小 =1，最大 = 2） |
前 20 分钟运行 1 个节点 . 20 分钟后，扩展到 2 个节点 . 40 分钟后，缩减回 1 个节点 . 总计 1 小时 . |
20 分钟 = 1/3 小时 . 1 个运行时 x 1 个节点 x 4 vCPU x 1/3 小时 = 1 1/3 . 1 个运行时 x 2 个节点 x 4 vCPU x 2/3 小时 = 2 1/3 . 1 个运行时 x 1 个节点 x 1 个节点 x 4 vCPU x 1/3 小时 = 1 1/3 . 总计 = 5 1/2 vCPU 小时 |
Dataplane 的计算和存储 |
1 个中型运行时 (4vCPU):newline:`.`（最小/最大 = 2） |
前 30 分钟运行 2 个节点 . 30 分钟后暂停。 |
30 分钟 = 1/2 小时 . 1 个运行时 x 2 个节点 x 4 vCPU x 1/2 小时 = 4 . 总计 = 4 vCPU 小时 |
Dataplane 的计算和存储 |
将运行时映射到 EC2 实例类型¶
选择运行时类型（T 恤大小）会导致运行时 Pod 被调度到关联的 EC2 节点组 {key}-sm-group、{key}-md-group 或 {key}-lg-group 上，其资源如下表所示：
运行时类型 |
vCPUs |
可用内存 (GB) |
EC2 实例类型 |
EC2 节点组 |
EC2 节点 – CPUs |
EC2 节点 – 内存 (GB) |
|---|---|---|---|---|---|---|
小 |
1 |
2 |
m7i.xlarge |
{key}-sm-group |
4 |
16 |
中 |
4 |
10 |
m7i.4xlarge |
{key}-md-group |
16 |
64 |
大 |
8 |
20 |
m7i.8xlarge |
{key}-lg-group |
32 |
128 |
您选择的运行时类型会影响每秒消耗的内核数量 (vCPUs)。当需要调度更多 Pod 时，Openflow 会根据 CPU 使用情况扩展底层 EC2 节点组，直到达到运行时创建期间设定的最大节点设置。
EKS 节点组配置的最小大小为 0 个节点，最多 50 个节点。所需大小根据运行时所需的 CPU 和内存进行动态调整。
云服务提供商根据托管客户运行时的底层节点进行收费。当调度相应大小的首个运行时时，会创建底层 EC2 实例。
计算 Openflow 运行时消耗的示例¶
用户向 Openflow 请求 BYOC 部署，然后安装 Openflow 代理和部署
用户尚未创建任何运行时。分配了 0 个 vCPUs，因此没有 Openflow 软件成本。
用户的云服务提供商向用户收取 Openflow BYOC 部署的预置计算和存储费用。
Openflow 总消耗 = 0 vCPU 小时
用户创建了一个小型运行时，最小节点数 = 1，最大节点数 = 2。运行时在 1 个节点上保留 1 小时。
1 个小型运行时 = 1 vCPU
Openflow 总消耗 = 1 vCPU 小时
用户创建了 2 个小型运行时，每个运行时的最小/最大节点数为 2 个；以及 1 个大型运行时，其最小/最大节点数为 10 个。这些运行时持续活跃了 1 小时
2 个节点上的 2 个小型运行时 = 2 个运行时 x 2 个节点 x 1 vCPU = 4 vCPUs
10 个节点上的 1 个大型运行时 = 1 个运行时 x 10 个节点 x 8 vCPU = 80 vCPUs
Openflow 总消耗 = (4 vCPU + 80vCPU) x 1 小时 = 84 vCPU 小时
用户使用 1 个节点创建 1 个中型运行时。20 分钟后，它会扩展到 2 个节点。20 分钟后，它会缩减回 1 个节点，再运行 20 分钟。
1 个中型运行时 = 4 vCPUs
20 分钟 = ⅓ 小时
（1 个节点 x 4 vCPU x ⅓ 小时）+（2 个节点 x 4 vCPU x ⅓ 小时）+（1 个节点 x 4 vCPU x ⅓ 小时）
4/3 vCPU 小时 + 8/3 vCPU 小时 + 4/3 vCPU 小时
Openflow 总消耗 = 16/3 vCPU 小时，因此大约 5.33 vCPU 小时
用户使用 2 个节点创建 1 个中型运行时，然后在 30 分钟后将其暂停
1 个中型运行时 = 4 vCPU
30 分钟 = ½ 小时
Openflow 总消耗 =（2 个节点 x 4 vCPU x ½ 小时）= 4 vCPU 小时