读数据自助服务实践指南：数据开放与洞察提效20成本管理服务

1. 成本管理服务

1.1. 为了利用云中可用的无限资源，企业需要无限的预算

• 1.1.1. 成本管理对于确保数据平台的有限预算与业务优先级的有效配合至关重要

• 1.1.2. 由于有众多选择，所以成本管理就像黑盒，需要不断优化成本，以适应日常工作中变化的工作负载

1.2. 操作阶段的最后一部分是成本管理

• 1.2.1. 成本管理在云计算中尤其重要，因为按需付费模式（与传统的预先购买、固定成本模式不同）随使用量呈线性增长

• 1.2.2. 随着数据大众化，数据用户可以在提取洞察的过程中实现自助服务，这存在资源浪费和成本不受约束的风险

1.3. 数据用户通常会占用资源，但不积极利用这些资源，从而导致资源利用率低

• 1.3.1. 在高端GPU上运行的一个错误查询可以在几个小时内花费数千美元，这通常会让数据用户感到惊讶

1.4. 成本管理服务提供管理和优化成本所需的可见性和管控

1.5. 痛点

• 1.5.1. 根据场景的具体情况，有许多节省成本的策略

• 1.5.2. 数据用户很难高效地扩展处理和利用云计算的弹性

• 1.5.3. 由于资源通常没有标签，而且云服务提供商提供的折扣使得真正的成本计算变得困难，不同的团队拥有的预算不同，所以成本花费和退款很难跟踪

1.6. 成本管理没有简单的通用方法，需要在性能、支出和利用率三者之间取得平衡

• 1.6.1. 考虑到大量生产查询的离线成本优化、持续监控的开销（以避免成本高昂的查询）​，以及定期重新访问在云产品中使用的服务以降低成本，优化成本耗时会增加整体的洞察耗时

1.7. 理想情况下，成本管理服务应该能够通过扩展分配的资源来自动管理资源的供应和需求，以响应突发的数据处理工作负载

• 1.7.1. 可以通过分析工作负载、分配的资源属性、预算、性能和可用性SLA，来自动分析和推荐成本节约策略

• 1.7.2. 能以细粒度的告警和监控跨数据管道、应用程序和团队的预算使用情况等形式提供可观测性的成本报告

1.8. 通过简化数据用户的成本管理，可使降低总体的洞察耗时

2. 路线图

2.1. 今天海量数据的很大一部分是在云中存储和处理的

2.2. 按需付费的模式有多种选择，尤其是无服务器（serverless）处理，其成本取决于查询扫描的数据量

2.3. 如果不仔细管理，数据处理的成本可能会非常高

2.4. 监控成本使用

• 2.4.1. 云处理账户通常由数据工程和IT团队建立

• 2.4.2. 单个产品账户支持多个不同的数据科学家、分析师和用户团队

• 2.4.3. 团队提供的资源通常没有标记，这使得责任追究变得困难

• 2.4.4. 缺乏对适当实例类型的了解会导致浪费大量成本

2.5. 持续成本优化

• 2.5.1. 第一阶段发生在设计管道时

  • 2.5.1.1. 该阶段评估最适合工作负载和SLA要求的可用即用即付模型的选项

• 2.5.2. 第二阶段分析利用率并不断优化配置

  • 2.5.2.1. 成本优化是一个不断完善和改进的过程，目标是建立和运行一个成本意识系统，在实现业务成果的同时将成本降至最低

• 2.5.3. 成本优化的系统将充分利用所有资源，以尽可能低的价格实现结果，并满足功能需求

3. 最小化优化成本耗时

3.1. 包括选择经济高效的服务、配置服务和运营服务，以及基于持续的工作负载应用成本优化所花费的时间

3.2. 支出可观测性

• 3.2.1. 支出可观测性包括告警、预算、监控、预测、报告和精细的成本归属，目标是为业务和技术涉众提供可见性和治理

• 3.2.2. 将资源成本归因到具体项目和团队的能力推动了资源高效使用的行为，并有助于减少浪费

• 3.2.3. 支出可观测性建立在聚合和分析多种不同类型的数据基础上，数据包括资源库存、资金成本和相关折扣、资源标签、用户到团队/项目的映射、使用情况和性能

• 3.2.4. 成本归属是一个挑战，目前是通过账户结构和标签来完成的

  • 3.2.4.1. 账户结构可以是父账户到多个子账户，也可以是用于所有处理的单个账户

• 3.2.5. 成本可观测性的另一个方面是当资源不再被使用，或者孤立的项目不再拥有所有者时，配置发生更改时发出告警

3.3. 供需匹配

• 3.3.1. 供需匹配包括自动增加和减少分配的资源

  • 3.3.1.1. 服务根据策略自动向处理集群添加和删除服务器节点

    3.3.1.1.1. 处理集群可以被认为短时的，并通过旋转来处理一个作业

  • 3.3.1.2. 作为扩展的一部分，该服务利用不同的供应选项

  • 3.3.1.3. 服务将工作负载特性适当地映射到可用的管理服务中

• 3.3.2. 对于处理高负载查询的服务，按查询付费可能比为已分配的集群资源付费要昂贵得多

• 3.3.3. 关键的挑战是在即时需求中，在经济效益与资源故障、高可用性与供应时间之间实现平衡

  • 3.3.3.1. 按需扩展资源对性能也有影响

3.4. 持续成本优化

• 3.4.1. 关键挑战是云中有太多的可用选项，理解这些策略的价值及其影响非常重要

  • 3.4.1.1. 理解这些策略需要专业知识和对广泛因素的理解，即存储分层、计算实例类型、托管服务的类型（无服务器数据还是传统数据）以及地理分布

  • 3.4.1.2. 计算选项的范围越来越广，需要了解与计算、内存和网络相关的硬件组

• 3.4.2. 目的是优化开支，缩小项目间资源分配与相应业务需求之间的差距

4. 定义需求

4.1. 成本优化没有通用的方案，成本管理服务的重要性取决于云产品的使用规模

4.2. 对于在云端操作许多数据平台的企业来说，成本管理服务是必不可少的

4.3. 痛点

• 4.3.1. 预算是否失控，在不影响业务需求的情况下有没有明确减少开支的途径

• 4.3.2. 云产品支出和业务优先级之间是否存在一致性差距

• 4.3.3. 分配的云资源的总体利用率是否较低

• 4.3.4. 通过更改已部署管道的配置，是否存在明显的积压机会以降低成本

• 4.3.5. 是否有很大比例的资源没有标签

• 4.3.6. 是否有很大比例的托管服务被使用

• 4.3.7. 不同项目的云产品预算分配是否基于预测

• 4.3.8. 是否有预防性告警，以避免数据用户可能不知道处理成本非常高昂

• 4.3.9. 在云端运行的工作负载是否可预测，而不是即席的

4.4. 功能性需求

• 4.4.1. 支出可观测性

  • 4.4.1.1. 提供预算分配、成本和使用情况报告（CUR）​、不同项目使用的资源、预测报告和资源标签支持等方面的告警和监控功能

• 4.4.2. 自动扩展

  • 4.4.2.1. 自动扩展和缩减资源，以及按需启动处理集群的策略

• 4.4.3. 优化建议

  • 4.4.3.1. 通过关闭未使用的资源、更改配置和策略、更改资源类型、针对工作负载类型使用不同的服务、计算类型、预留和托管服务等建议，以更好地匹配工作负载特征来降低成本

• 4.4.4. 互操作性

  • 4.4.4.1. 与部署在云中的现有服务清单的互操作性：数据库、存储、服务数据存储、计算实例和托管服务

  • 4.4.4.2. 支持不同的即用即付成本模型

4.5. 非功能性需求

• 4.5.1. 直观的仪表盘

  • 4.5.1.1. 目标是在用户中创造一种成本意识和优化的文化

  • 4.5.1.2. 仪表盘和报表需要简单直观

• 4.5.2. 可扩展支持

  • 4.5.2.1. 该服务应该很容易扩展到越来越多的系统和服务

  • 4.5.2.2. 数据用户、财务、高管和审计师应该能够定制仪表盘，以提取可操作的洞察

5. 实现模式

5.1. 连续成本监控模式

• 5.1.1. 将实际成本、每个项目使用情况和数据用户活动关联起来，以创建可操作的监控仪表盘，用于预测和预算告警

• 5.1.2. 目标是聚合与成本跟踪相关的不同方面，并为数据用户、财务和管理人员提供一个相关且可操作的视图

• 5.1.3. 工作原理

  • 5.1.3.1. 定义预算

    5.1.3.1.1. 为不同的项目及其团队定义预算

  • 5.1.3.2. 标记资源

    5.1.3.2.1. 标记是一个简单的标签，由一个用户定义的键和一个可选值组成，用于更容易地管理、搜索和筛选资源

    5.1.3.2.2. 被动式治理可以手动或使用脚本识别不正确的标签

    5.1.3.2.3. 主动式治理确保在资源创建时一致地应用标准化标签

  • 5.1.3.3. 聚合信息

    5.1.3.3.1. 信息被聚合并关联到一个单一的窗格中

  • 5.1.3.4. 定义告警

    5.1.3.4.1. 当花费或使用量超过（或预测将超过）预算金额时，将设置告警

    5.1.3.4.2. 当利用率下降到定义的阈值以下时，也会告警

• 5.1.4. 计算基于成本的关键绩效指标，即保留实例覆盖率和利用率、每日运行率、未充分利用的资源、未标记资源的百分比以及百分比差异（预算与实际）​

• 5.1.5. Lyft的AWS成本管理

5.2. 自动扩展模式

• 5.2.1. 根据实际需求上下调整资源分配，以节省成本

• 5.2.2. 侧重于利用云的弹性来响应增加的工作负载请求

• 5.2.3. 鉴于云的弹性，以防突发事件的供应已经被即时供应所取代

  • 5.2.3.1. 减少了闲置资源，即使在请求数量激增的情况下，也能提供稳定的性能

• 5.2.4. 自动扩展是一种平衡行为，其目标是尽量减少浪费，同时考虑启动时间、可用性和性能SLA

• 5.2.5. 工作原理

  • 5.2.5.1. 扩展触发器

    5.2.5.1.1. 监控解决方案会收集并跟踪未完成的请求数量、队列深度、利用率、服务时间延迟等

    5.2.5.1.2. 基于用户配置的阈值，将生成一个用于扩展的触发器

    5.2.5.1.2.1. 触发器也可以基于时间

  • 5.2.5.2. 评估策略

    5.2.5.2.1. 不同类型的策略可用于扩展

    5.2.5.2.2. 通常是使用基于需求的扩展、基于时间的扩展和缓冲策略的组合

    5.2.5.2.3. 最常见的策略是自定义资源的启动和停止时间表

  • 5.2.5.3. 混合和匹配资源

    5.2.5.3.1. 在扩展过程中，资源组合可以以最低的成本为请求提供最佳服务

    5.2.5.3.2. 扩展可以将现有计算实例与预留实例和按需实例混合使用

• 5.2.6. 部署使用的策略类型的组合

  • 5.2.6.1. 基于需求的扩展

    5.2.6.1.1. 在需求高峰期间，通过自动增加资源数量以保持性能，并在需求消退时通过减少容量以降低成本

    5.2.6.1.2. 典型的触发指标是CPU利用率、网络吞吐量、延迟等

    5.2.6.1.3. 策略需要考虑新资源的供应速度，以及供需之间的余量大小，以应对需求变化率和资源故障

  • 5.2.6.2. 基于缓冲区的扩展

    5.2.6.2.1. 缓冲区是一种机制，当应用程序在一段时间内以不同的速率运行时，它们可以与处理平台进行通信

  • 5.2.6.3. 基于时间的扩展

    5.2.6.3.1. 对于可预测的需求，采用基于时间的方法

    5.2.6.3.2. 系统可以按计划在规定的时间内进行放大或缩小

    5.2.6.3.3. 扩展不依赖资源的利用率级别

    5.2.6.3.4. 其优势是资源可用性不会因为启动程序而出现任何延迟

5.3. 成本建议模式

• 5.3.1. 分析当前适用的著名启发式方法和实践，以推荐成本优化策略

• 5.3.2. 成本建议模式分析工作负载和资源使用模式，为优化成本提出策略建议

• 5.3.3. 成本优化是一个持续的过程，建议会随着时间的推移而不断变化

• 5.3.4. 建议基于变更的复杂性而不是预期的影响来应用

• 5.3.5. AWS Trusted Advisor

• 5.3.6. Azure Advisor

• 5.3.7. Cloud Custodian

  • 5.3.7.1. 一个基于规则的开源引擎

• 5.3.8. Ice

  • 5.3.8.1. Netflix最初开发的一个优化工具

• 5.3.9. Stax

• 5.3.10. Cloudability

• 5.3.11. CloudHealth

• 5.3.12. Datadog

• 5.3.13. 原则

  • 5.3.13.1. 消除闲置资源

    5.3.13.1.1. 是一个低风险的结果，用户经常会启动资源而忘记关闭它们

  • 5.3.13.2. 选择正确的计算实例

    5.3.13.2.1. 云计算支出中占比最大的是计算成本

    5.3.13.2.2. 根据工作负载需求具有正确的计算带宽、网络带宽和存储带宽的实例

    5.3.13.2.3. 选择正确的购买选项，即按需、竞价和预留实例

  • 5.3.13.3. 分层存储并优化数据传输成本

    5.3.13.3.1. 考虑到数据量不断增长，请确保将数据归档到更便宜的层级，尤其是在不经常使用的情况下

    5.3.13.3.2. 数据传输成本也会显著增加

  • 5.3.13.4. 利用工作负载的可预测性

    5.3.13.4.1. 将频繁和可预测的工作负载（例如，全天候的数据库工作负载）与不频繁、不可预测的工作负载（例如，交互式探索性查询）分开

    5.3.13.4.2. 成本建议规则对这些工作负载应用不同的策略建议

  • 5.3.13.5. 优化应用程序设计

    5.3.13.5.1. 包括更基本的设计选择，例如地理位置选择、托管服务的使用等