本页概述了配置经典计算资源的最佳做法。 对于大多数新工作负载，Databricks 建议使用无服务器计算，这不需要配置。 如果无服务器计算不支持工作负荷（请参阅 无服务器限制），请使用以下最佳做法来配置经典计算资源。
注意
结构化流式处理工作流具有特定配置建议。 请参阅结构化流处理的生产考虑因素。
访问模式
可将经典计算资源分配到标准或专用访问模式，从而确定谁可以附加到和使用计算资源。
Databricks 建议对大多数工作负荷使用标准访问模式。 标准计算可由多个用户和组共享，同时强制实施用户隔离和所有数据访问权限。 这使其成为对于大多数工作负载而言更易于管理且更具成本效益的选择。
仅当工作负荷具有特定的标准计算限制（例如 GPU 上的 ML 运行时、RDD API 或 R）时，才使用专用访问模式。有关详细信息，请参阅 标准计算要求和限制。
如果启用了 Unity 目录，请不要设置 spark.databricks.passthrough.enabled。 凭据透传是一种旧版访问模式，与 Unity Catalog 不兼容。
请参阅访问模式。
Databricks Runtime 版本
使用最新的长期支持 （LTS） Databricks Runtime 版本。 LTS 版本接收扩展的安全修补程序和 bug 修复，确保工作负载与最新的平台功能保持稳定且兼容。
仅当工作负荷使用 GPU、分布式 ML 训练或 AutoML 时，才选择机器学习运行时。 Databricks Runtime for ML 预装了大量库；如果并不需要这些库，它们可能会与你自己的依赖项发生冲突，从而导致错误或引发不易察觉的正确性问题。 请参阅训练 AI 和 ML 模型。
配置卫生
这些做法使计算配置保持干净，工作负载可移植。
避免使用 init 脚本
Init 脚本可能会引入意外行为，包括破坏工作负荷的库冲突，并使环境无法预测。 请改为将库添加到计算策略中、在笔记本中使用 %pip install，或在环境规范中定义依赖项。请参阅 向策略添加库。
避免硬编码 Spark 配置
避免在计算或作业定义中硬编码 Spark 配置（例如 spark.executor.memory 或 spark.dynamicAllocation.*）。 硬编码值会替代Azure Databricks提供的内置优化，这通常会导致浪费的支出或性能下降。 仅当你确有特定理由需要覆盖默认配置时，才使用笔记本范围内的会话配置。
避免使用计算节点本地存储路径
不要在计算本地路径上存储数据，这些路径不会在计算生命周期之外保留。 请改用 Unity 目录卷或临时存储。 请参阅什么是卷？。
避免使用 DBFS 挂载
DBFS 装载缺少适当的访问控制列表（ACL）。 请改用 Unity 目录卷或工作区文件系统（WSFS）。 请参阅什么是卷？。
避免安装计算作用域库
在计算级别安装库会跨作业创建环境偏差。 请改为在笔记本中使用 %pip install，或在环境规范文件中定义依赖项。这也使传统工作负载更易于迁移到无服务器架构。
Performance
评估你是否会从 Photon 中受益
许多工作负载都能从 Photon 中受益，但它对 SQL 工作负载以及涉及复杂转换的 DataFrame 操作最有帮助，例如连接、聚合以及对大型表进行的数据扫描。 具有频繁磁盘访问、宽表或重复数据处理特征的工作负载，性能也有所提升。
不涉及宽转换或大数据量的简单批处理 ETL 作业，在启用 Photon 后可能受影响很小，尤其是在查询通常可在两秒内完成的情况下。
使用自动缩放
配置自动缩放，以便长时间运行的任务可以在作业执行期间动态添加和移除工作节点。 请参阅 “启用自动缩放”。
使用实例池减少开始时间
实例池会从云服务提供商处预留计算资源。 池可减少新的群集开始时间，并确保计算资源可用性。 请参阅池配置参考。
成本优化
使用计算策略
Azure Databricks建议使用计算策略。 利用计算策略，可以创建专为个人计算、共享计算、Power User 和作业等特定用途设计的预配置计算资源。 策略会限制配置计算设置时需要做出的决策。
如果你无权访问策略，请联系你的工作区管理员。请参阅默认策略和策略系列。
计算资源规格注意事项
注意
以下建议假定你已创建不受限制的群集。 工作区管理员应仅向高级用户授予此权限。
人们通常将计算大小与工作器数量相关联，但需要考虑其他一些重要因素：
- 执行程序的内核总数（计算）：所有执行程序的内核总数。 这决定了计算的最大并行度。
- 执行程序的总内存量：所有执行程序的 RAM 总量。 这决定了在将数据溢写到磁盘之前，内存中可以存储的数据量。
- 执行程序本地存储：本地磁盘存储的类型和数量。 本地磁盘主要用于在随机操作和缓存期间发生溢写的情况。
其他注意事项包括工作器实例类型和大小，这也会影响上述因素。 在确定计算资源规模时，请考虑以下事项：
- 工作负载将消耗多少数据？
- 工作负载的计算复杂性如何？
- 从何处读取数据？
- 数据在外部存储中是如何分区的？
- 需要多少并行度？
工作器的数量与工作器实例类型的规格大小之间需要进行权衡。 配置有两个辅助角色（每个辅助角色有 16 个核心和 128 GB RAM）的计算与配置有 8 个辅助角色（每个辅助角色有 4 个核心和 32 GB RAM）的计算具有相同的计算和内存。
计算配置示例
以下示例展示了基于特定工作负载类型的计算建议。 这些示例还包括要避免的配置，以及这些配置不适用于工作负载类型的原因。
注意
本部分中的所有示例都可以受益于使用无服务器计算，而不是启动新的计算资源。 如果您的工作负载不受无服务器计算支持，请参考以下建议来配置您的传统计算资源。
数据分析
数据分析师通常会执行需要多个分区数据的处理任务，因此会导致许多 Shuffle 操作。 由较少但更大的节点组成的计算资源可减少执行这些混洗所需的网络和磁盘 I/O。
大型虚拟机类型的单节点计算可能是最佳选择，对于单个分析师尤其如此。
分析工作负载可能需要重复读取相同的数据，因此推荐的节点类型是启用了磁盘缓存的存储优化型节点，或是具备本地存储的实例。
建议用于分析工作负载的其他功能包括：
- 启用自动终止，确保计算在处于非活动状态一段时间后终止。
- 请考虑根据分析师的典型工作负载启用自动缩放。
基础批处理 ETL
对于不需要宽转换（例如联接或聚合）的简单批处理 ETL 作业，请使用内存和存储要求较低的实例。 与其他类型的工作人员相比，这样可能更节省成本。
复杂批处理 ETL
对于复杂的 ETL 作业，例如需要跨多个表执行 Union 和 Join 操作的作业，Azure Databricks 建议使用更少的工作器，以减少数据混洗量。 为平衡辅助角色较少的情况，需要增加实例的大小。
复杂转换可能需要大量计算。 如果发现明显的磁盘溢写或 OOM 错误，请增加实例可用的内存。
（可选）使用实例池来减少计算启动时间，并减少运行作业管道时的运行时总数。
训练机器学习模型
若要训练机器学习模型，Azure Databricks建议使用个人计算策略创建计算资源。
使用具有大型节点类型的单个节点计算进行初始试验。 减少节点数可降低随机操作的影响。
增加更多工作进程有助于提高稳定性，但由于数据混洗会带来额外开销，应避免增加过多工作进程。
推荐使用启用了磁盘缓存的存储优化型工作器，或具有本地存储的实例，以适应对同一数据的重复读取，并支持缓存训练数据。
建议用于机器学习工作负载的其他功能包括：
- 启用自动终止，确保计算在处于非活动状态一段时间后终止。
- 使用实例池，允许将计算限制为预先批准的实例类型。
- 使用策略确保一致的计算配置。