成本优化最佳做法

本文介绍支持成本优化原则的最佳做法，内容按原则进行组织。

1.选择最佳资源

使用性能优化的数据格式

若要充分利用 Databricks Data Intelligence Platform，必须使用 Delta Lake 作为存储框架。 它有助于生成更简单、更可靠的 ETL 管道，并附带许多性能增强功能，与使用 Parquet、ORC 和 JSON 相比，可以显著加快工作负载的速度。 请参阅 Azure Databricks 的优化建议。 如果工作负载也在作业计算上运行，则这会直接转换为较短的计算资源运行时间，从而降低成本。

使用作业计算

作业是在 Databricks 计算实例上运行非交互式代码的一种方式。 例如，可以采用交互方式或按计划运行提取、转换和加载 (ETL) 工作负载。 当然，也可以在笔记本 UI 中以交互方式运行作业。 但是，在作业计算中，非交互式工作负载的成本明显低于通用计算。 有关“作业计算”和“通用计算”的比较，请参阅定价概述。

某些作业的另一个好处是，每个作业或工作流都可以在新的计算实例上运行，从而将工作负载彼此隔离。 但是，多任务工作流还可以对所有任务重复使用计算资源，因此每个工作流只发生一次计算启动时间。 请参阅将 Azure Databricks 计算用于作业。

将 SQL 仓库用于 SQL 工作负载

对于交互式 SQL 工作负载而言，Databricks SQL 仓库是最经济高效的引擎。 请参阅定价概述。 默认情况下，所有 SQL 仓库都附带 Photon，这会加速现有的 SQL 和 DataFrame API 调用，并降低每个工作负载的总体成本。

此外，无服务器 SQL 仓库支持智能工作负载管理 (IWM)，这一组功能增强了 Databricks SQL 无服务器快速且经济高效地处理大量查询的能力。

为工作负载使用最新的运行时

Azure Databricks 平台提供不同的运行时，这些运行时已针对数据工程任务 (Databricks Runtime) 或机器学习任务（用于机器学习的 Databricks Runtime）进行优化。 构建运行时的目的是为任务提供最佳的库选项，并确保提供的所有库都是最新的并以最佳方式协同工作。 Databricks Runtime 定期发布，在主要版本之间提供性能改进。 由于更有效地使用计算资源，这些性能改进通常可节省成本。

仅将 GPU 用于正确的工作负载

带有 GPU 的虚拟机可以显著加快深度学习的计算速度，但价格显著高于仅有 CPU 的计算机。 只将 GPU 实例用于带有 GPU 加速库的工作负载。

大多数工作负载不使用 GPU 加速库，因此它们无法从支持 GPU 的实例中获益。 工作区管理员可以限制 GPU 计算机和计算资源，以防止不必要的使用。 请参阅博客文章“GPU 真的很昂贵吗？对 GPU 进行基准测试以在 Databricks 群集上进行推理”。

对工作负载使用无服务器服务

BI 用例

BI 工作负载通常使用突发数据并生成多个并发查询。 例如，使用 BI 工具的人员可能会更新仪表板或编写查询，然后只是分析结果，而不与平台进一步交互。 在此应用场景中，数据平台：

• 终止空闲计算资源以节省成本。
• 当用户使用 BI 工具请求新的或更新的数据时，快速提供计算资源。

非无服务器 Azure Databricks SQL 仓库的启动时间为几分钟，因此许多用户倾向于接受较高的成本并且不会在空闲期间终止这些仓库。 另一方面，无服务器 SQL 仓库在几秒钟内完成启动和纵向扩展，因此可以实现即时可用性和空闲终止。 这样可以带来极佳的用户体验并节省总体成本。

此外，无服务器 SQL 仓库比非无服务器仓库更早地纵向缩减，从而降低了成本。

ML 和 AI 模型服务

大多数模型都用作 REST API，用于集成到 Web 或客户端应用程序中；模型服务随着时间的推移接收不同负载的请求，并且模型服务平台应该始终提供足够的资源，但仅提供实际需要的资源（纵向扩展和纵向缩减）。

使用正确的实例类型

使用最新一代的云实例类型几乎总是能带来性能优势，因为它们提供了最佳性能和最新功能。

根据工作负载，选择正确的实例系列以获得最佳的性价比也是很重要的。 一些简单的经验法则是：

• 针对 ML、大量随机选择和溢出工作负载优化的内存
• 针对结构化流式处理工作负载和维护作业（例如优化和清空）进行优化的计算
• 针对受益于高速缓存的工作负载（例如即席和交互式数据分析）进行优化的存储
• 针对特定 ML 和 DL 工作负载进行优化的 GPU
• 无特定要求时的常规用途

选择最有效的计算大小

Azure Databricks 每个工作器节点运行一个执行程序。 因此，“执行器”和“工作器”这两个术语可在 Azure Databricks 体系结构的上下文中互换使用。 人们通常将群集大小与工作器数量相关联，但需要考虑其他一些重要因素：

• 执行程序的内核总数（计算）：所有执行程序的内核总数。 这决定了计算实例的最大并行度。
• 执行程序的总内存量：所有执行程序的 RAM 总量。 这决定了在将数据溢写到磁盘之前，内存中可以存储的数据量。
• 执行程序本地存储：本地磁盘存储的类型和数量。 本地磁盘主要用于在随机操作和缓存期间发生溢写的情况。

其他注意事项包括工作器实例类型和大小，这也会影响上述因素。 调整计算大小时，请考虑以下事项：

• 工作负载将消耗多少数据？
• 工作负载的计算复杂性如何？
• 从何处读取数据？
• 数据在外部存储中是如何分区的？
• 需要多少并行度？

可以在计算大小调整注意事项中找到详细信息和示例。

评估性能优化的查询引擎

Photon 是一种高性能 Databricks 原生矢量化查询引擎，可加快 SQL 工作负载和 DataFrame API 调用（用于数据引入、ETL、流式处理、数据科学和交互式查询）。 Photon 与 Apache Spark API 兼容，因此只需打开就能使用 – 无需更改代码，且没有局限性。

观察到的加速可以显著节省成本，应该评估定期运行的作业，看看使用 Photon 是否不仅速度更快，而且更便宜。

2.动态分配资源

使用自动缩放计算

借助自动缩放，Databricks 会根据作业的特征动态重新分配辅助角色。 管道的某些部分可能比其他部分的计算密集程度更高，Databricks 会自动在作业的那些阶段添加额外的工作器（并在不再需要它们时将其删除）。 与静态大小的计算实例相比，自动缩放可以降低总体成本。

在纵向缩减结构化流式处理工作负载的群集大小时，计算自动缩放具有限制。 Databricks 建议将增量实时表与增强式自动缩放用于流式处理工作负载。

使用自动终止

Azure Databricks 提供了许多功能，通过减少空闲资源和控制何时可以部署计算资源来帮助控制成本。

• 为所有交互式计算资源配置自动终止。 在指定的空闲时间后，计算资源将关闭。 请参阅自动终止。
• 对于仅在工作时间需要计算的用例，可以为计算资源配置自动终止，并且计划的进程可以在上午用户返回桌面之前重启计算（必要时还可以预热数据）。 请参阅 CACHE SELECT。
• 如果计算启动时间过长，请考虑使用群集池，请参阅池最佳做法。 Azure Databricks 池是一组空闲的、随时可用的实例。 使用空闲实例创建群集节点后，可以减少群集启动和自动缩放的时间。 如果该池中没有空闲实例，则该池会通过从实例提供程序分配新的实例进行扩展，以满足群集的请求。

当实例在池中处于空闲状态时，Azure Databricks 不会收取 Databricks 单元 (DBU) 费用，从而可以节省成本。 这会产生实例提供程序费用。

使用计算策略控制成本

计算策略可以对计算资源强制实施许多特定于成本的限制。 请参阅卓越运营 - 使用计算策略。 例如：

• 使用设置的最小工作器节点数启用群集自动缩放。
• 使用合理值（例如 1 小时）启用群集自动终止以避免为空闲时间付费。
• 确保只能选择经济高效的 VM 实例。 遵循群集配置的最佳做法。 请参阅计算配置最佳做法。
• 应用现成虚拟机实例策略。

3. 监视和控制成本

监视成本

使用 Azure 成本管理器分析 Azure Databricks 成本。 计算和工作区标记也会传送到 Azure 成本管理器。 请参阅标记群集以进行成本归因。

标记群集以进行成本归因

若要监视总提成本，并准确将 Azure Databricks 使用情况归属于组织的业务部门和团队，以便收取费用，则可以标记群集、SQL 仓库和池。 这些标记传播到详细的 Databricks 单元 (DBU) 和云提供程序 VM 和 Blob 存储使用情况，以便进行成本分析。

确保在为团队和用例设置工作区和群集时考虑成本控制和归因。 这简化了标记并提高了成本归因的准确度。

总成本包括 DBU 虚拟机、磁盘和任何关联的网络成本。 对于无服务器 SQL 仓库，DBU 成本已包括虚拟机和磁盘成本。

Azure Databricks 资源的标记可在 Azure 门户中的成本分析工具中使用

实现可观测性以跟踪成本和按存储容量使用计费

使用复杂的技术生态系统时，主动了解未知因素是维护平台稳定性和控制成本的关键。 可观测性提供了一种根据系统生成的数据分析和优化系统的方法。 这不同于监视，它侧重于识别新模式，而不是跟踪已知问题。

请参阅博客：Databricks 上的智能平衡成本优化和可靠性

定期共享成本报告

生成每月成本报告，以跟踪消耗增长和异常。 使用群集标记与拥有工作负载的团队共享这些报表。 这避免了意外情况，并使团队可以在成本过高时主动调整工作负载。

监视和管理增量共享流出量成本

与其他数据共享平台不同的是，Delta Sharing 不需要进行数据复制。 此模型具有许多优点，但也意味着在跨云或区域共享数据时，云供应商可能会收取数据流出费用。 请参阅监视和管理增量共享流出量成本（针对提供商）来监视和管理流出量费用。

4.设计经济高效的工作负载

平衡始终启用的和触发的流式处理

传统上，当人们想到流式处理时，就会想到“实时”、“24/7”或“始终启用”等术语。 如果数据引入是实时发生的，那么底层计算资源必须全天候运行，每天每小时都会产生成本。

但是，并非依赖于连续事件流的每个用例都需要将这些事件立即添加到分析数据集。 如果用例的业务要求只需要每隔几小时或每日更新一次数据，则一天只需运行几次即可满足该要求，从而显著降低工作负载成本。 Databricks 建议对没有低延迟要求的增量工作负载使用带 AvailableNow 触发器的结构化流式处理。 请参阅配置增量批处理。