卓越运营最佳做法

本文介绍卓越运营最佳做法，内容按照以下部分中列出的体系结构原则进行组织。

1. 优化生成和发布过程

组建专职湖屋运营团队

常见的最佳做法是组建一个平台运营团队，使数据团队能够在一个或多个数据平台上工作。 该团队负责在内部创建蓝图和最佳做法。 他们提供工具（例如，用于基础结构自动化和自助访问）并确保满足安全与合规需求。 这会使保护平台数据的负担落在一个中心团队上，使分散的团队能够专注于处理数据和生成新见解。

使用企业源代码管理 (SCM)

源代码管理 (SCM) 有助于提高开发人员的工作效率，从而加快发布速度并降低开发成本。 拥有一个可帮助跟踪更改、维护代码完整性、检测错误和回滚到以前版本的工具是整体解决方案体系结构的重要组成部分。

Databricks Git 文件夹让用户能够将笔记本或其他文件存储在 Git 存储库中，从而提供克隆存储库、提交和推送、拉取、分支管理和查看文件差异等功能。 使用 Git 文件夹可以获得更好的代码可见性和跟踪。

标准化 DevOps 过程 (CI/CD)

持续集成和持续交付 (CI/CD) 指的是通过使用自动化管道，在较短且频繁的周期中开发和部署软件。 虽然它已在传统的软件工程中广泛使用了数十年，并非是一种全新的过程，但对于数据工程和数据科学团队来说，它是一个越来越必要的过程。 为了使数据产品富有价值，必须及时交付这些产品。 此外，使用者必须对这些产品中的结果有效性有信心。 与仍在许多数据工程和数据科学团队中普遍使用的手动过程相比，通过自动执行代码的生成、测试和部署流程，开发团队能够更频繁、更可靠地交付发布版本。 请参阅 Azure Databricks 上的 CI/CD 是什么？。

若要详细了解使用 Databricks Git 文件夹进行代码开发的最佳做法，请参阅使用 Git 和 Databricks Git 文件夹 (Repos) 的 CI/CD 技术。 将其与 Databricks REST API 相结合，你就可以使用 GitHub Actions、Azure DevOps 管道或 Jenkins 作业创建自动化部署流程。

标准化 MLOps 流程

MLOps 流程提供 ML 管道的可再现性，可支持跨数据团队进行更紧密的协作，减少与 DevOps 和 IT 之间的冲突，并加快发布速度。 推动关键业务决策时会用到许多模型，标准化 MLops 流程可确保一致、可靠地开发、测试和部署模型。

生成和部署 ML 模型很复杂。 有许多选项可以实现此目的，但几乎没有明确定义的标准。 因此，在过去几年，机器学习运营 (MLOps) 应运而生。 MLOps 是一系列过程和自动化措施，用于管理模型、数据和代码，以提高 ML 系统的性能稳定性和长期效率。 它涵盖数据准备、探索性数据分析 (EDA)、特征工程、模型训练、模型验证、部署和监视。

在 Databricks 平台上使用 MLOps 有助于优化机器学习 (ML) 系统的性能和长期效率：

• 始终记住业务目标：如 ML 在企业中的核心目的是实现数据驱动的决策和产品一样，MLOps 的核心目的是确保这些数据驱动的应用程序保持稳定，保持最新状态并持续对业务产生积极影响。 在确定 MLOps 技术工作的优先级时，请考虑业务影响：它是否支持新的业务用例？ 它是否可以提高数据团队的工作效率？ 它是否可以降低运营成本或风险？
• 使用专用但开放的工具来管理 ML 模型：可以使用专为 ML 模型生命周期设计的 MLflow 来跟踪和管理 ML 模型。 请参阅使用 MLflow 进行 ML 生命周期管理。
• 以模块化方式实现 MLOps：与任何软件应用程序一样，代码质量对于 ML 应用程序至关重要。 使用模块化代码可以测试各个组件并减轻将来代码重构的难度。 定义明确的步骤（例如训练、评估或部署）、超级步骤（例如训练到部署管道）和职责，以阐明 ML 应用程序的模块化结构。

Databricks 电子书《MLOps 大全》对此做了详细介绍。

定义环境隔离策略

当组织使用 Databricks 等数据平台时，通常需要在环境（如开发环境和生产环境）之间或在组织运营单位之间设置数据隔离边界。

隔离标准可能因组织而异，但通常包括以下预期：

• 用户只能按照指定的访问规则获取对数据的访问权限。
• 数据只能由指定的人员或团队管理。
• 数据在存储中以物理方式分隔。
• 只能在指定环境中访问数据。

在 Databricks 中，工作区是主要的数据处理环境，在几种情况下，独立工作区可以改善整体环境，例如：

• 使用自己的工作区隔离不同的业务部门，以避免使用同一个工作区管理员，并确保不会不小心在业务部门之间共享 Databricks 中的资产。
• 隔离软件开发生命周期环境（如开发、过渡和生产）。 例如，独立的生产工作区允许在将新工作区设置应用到生产环境之前对其进行测试。 或者，生产环境可能需要比开发环境更严格的工作区设置。 如果必须在不同的虚拟网络上部署开发、过渡和生产环境，则还需要为这三个环境设置不同的工作区。
• 拆分工作区以克服资源限制：云帐户/订阅有资源限制。 将工作区拆分为不同的订阅/帐户是确保每个工作区有足够可用资源的一种方法。 此外，Databricks 工作区还有资源限制。 拆分工作区可确保每个工作区中的工作负载始终能够访问全套资源。

但是，共享工作区也有一些缺点，应该加以考量：

• 笔记本协作无法跨工作区工作。

• 对于多个工作区，设置和维护都需要完全自动化（通过 Terraform、ARM、REST API 或其他方式）。 这对于迁移目的尤其重要。

• 如果每个工作区都需要在网络层进行保护（例如，为了防止数据泄露），则所需的网络基础设施可能非常昂贵，尤其是对于大量工作区而言。

在隔离需求和协作需求以及维护它所需的工作量之间找到平衡非常重要。

为企业定义目录策略

除了环境隔离策略外，组织还需要一个策略来构建和分离元数据和数据。 数据（包括个人身份信息、付款或健康信息）具有很高的潜在风险，随着数据泄露威胁不断加剧，无论选择哪种组织策略，都必须分离和保护敏感数据。 在逻辑和物理上将敏感数据与非敏感数据分开。

组织可以要求将某些类型的数据存储在其云租户中的特定帐户或存储桶中。 Unity Catalog 元存储允许通过其三级 catalog > schema > tables/views/volumes 命名空间来构建元数据，并在元存储、目录或架构级别配置存储位置以满足此类要求。

组织和合规性要求通常会规定，你只能在某些环境中保留某些数据。 你可能还希望将生产数据与开发环境隔离，或确保某些数据集和域永远不会合并。 在 Databricks 中，工作区是主要的计算环境，目录是主要的数据域。 使用 Unity Catalog 元存储，管理员和目录所有者可以将目录绑定到特定工作区。 这些环境感知绑定有助于确保工作区中只有某些目录可用，而无需考虑授予用户的特定数据对象权限。

有关这些主题的完整讨论，请参阅 Unity 目录最佳做法

2. 自动化部署和工作负载

使用基础结构即代码 (IaC) 进行部署和维护

基础结构即代码 (IaC) 使开发人员和运营团队能够自动管理、监视和配置资源，而无需手动配置硬件设备、操作系统、应用程序和服务。

HashiCorp Terraform 是一种常用的开源工具，用于跨多个云提供商创建安全且可预测的云基础结构。 Databricks Terraform 提供程序通过灵活强大的工具来管理 Azure Databricks 工作区和关联的云基础结构。 Databricks Terraform 提供程序的目标是支持所有 Azure Databricks REST API，从而支持自动化执行部署和管理数据平台中的最复杂部分。 Databricks Terraform 提供程序是建议用于可靠部署和管理群集和作业、配置 Azure Databricks 工作区以及配置数据访问的工具。

标准化计算配置

标准化计算环境可确保在所有环境中使用相同的软件、库和配置。 这种一致性使重现结果、调试问题和跨环境维护系统变得更加容易。 标准化环境有助于团队节省时间和资源，因为无需从头开始配置和设置环境。 还可以降低手动设置期间可能出现错误和不一致的风险。 标准化还支持在所有环境中实施一致的安全策略和实践。 这有助于组织更好地管理风险并遵守监管​​要求。 最后，标准化可以通过减少浪费和优化资源利用率来帮助组织更好地管理成本。

标准化涵盖环境设置和持续资源管理。 为了使设置保持一致，Databricks 建议使用基础结构即代码。 为了确保在一段时间内启动的计算资源配置一致，请使用计算策略。 Databricks 工作区管理员可根据一组策略规则限制用户或组的计算创建权限。 他们可以强制执行 Spark 配置设置以及群集范围的库安装。 还可以使用计算策略为项目定义 T 恤尺寸群集（S、M、L）作为标准工作环境。

对作业使用自动化工作流

为作业设置自动化工作流可以帮助减少不必要的手动任务，并通过创建和部署作业的 DevOps 流程来提高生产力。 Data Intelligence 平台提供两种方法来实现此目的：

• Databricks 作业：

  Databricks 作业可协调 Databricks Data Intelligence 平台中的数据处理、机器学习和分析管道。 它具有与 Databricks 平台集成的、完全托管的业务流程服务：

  • Databricks 作业是用于在 Databricks 工作区中运行数据处理和分析应用程序的一种方式。 作业可以是一个任务，也可以是一个具有复杂依赖项的大型多任务工作流。 Databricks 可管理所有作业的任务业务流程、群集管理、监视和错误报告。
  • 增量实时表是一个声明性框架，用于生成可靠、可维护且可测试的数据处理管道。 你定义要对数据执行的转换，增量实时表则管理任务协调、群集管理、监视、数据质量和错误处理。

• 外部业务流程协调程序：

  外部业务流程协调程序使用综合性 Azure Databricks REST API 来协调笔记本和作业等 Databricks 资产。 请参阅：

  • Apache Airflow。
  • Azure 数据工厂。

建议将 Databricks 作业用于 Databricks 中的所有任务依赖项，并在需要时将这些封装的工作流集成到外部业务流程协调程序中

使用自动化和事件驱动的文件引入

事件驱动（相对于计划驱动）的文件引入具有多种优势，包括效率、提高数据新鲜度和实时数据引入。 通过仅在事件发生时运行作业，可确保不会浪费资源，从而节省资金。

自动加载程序会在新数据文件到达云存储空间时以增量方式高效地对其进行处理。 它可以引入许多文件格式，例如 JSON、CSV、PARQUET、AVRO、ORC、TEXT 和 BINARYFILE。 通过云存储上的输入文件夹，自动加载程序会在新文件到达时自动处理它们。

对于一次性引入，请考虑改用命令 COPY INTO。

使用 ETL 框架作为数据管道

虽然可以手动执行 ETL 任务，但使用框架有很多好处。 框架可以确保 ETL 流程的一致性和可重复性。 通过提供预构建的功能和工具，框架可以自动执行常见任务，从而节省时间和资源。 ETL 框架可以处理大量数据，并且可以根据需要轻松扩大或缩小规模。 这有助于管理资源和响应不断变化的业务需求。 许多框架都包含内置的错误处理和日志记录功能，这就使识别和解决问题变得更加容易。 它们通常包括数据质量检查和验证，在将数据加载到数据仓库或数据湖之前，确保其符合某些标准。

增量实时表是一个声明性框架，用于生成可靠、可维护且可测试的数据处理管道。 你定义要对数据执行的转换，而增量实时表处理任务协调、群集管理、监视、数据质量和错误处理。

使用增量实时表，可以在 SQL 或 Python 中定义端到端数据管道：指定数据源、转换逻辑和数据的目标状态。 增量实时表维护依赖项并自动确定运行作业的基础结构。

为了管理数据质量，增量实时表会监视数据质量随时间变化的趋势，通过预定义的错误策略进行验证和完整性检查，防止错误数据进入表中。 请参阅什么是增量实时表？。

遵循 ML 工作负载的部署代码方法

代码和模型通常在软件开发阶段异步进行。 可通过两种方式实现此目的：

• 部署代码：在开发环境中为 ML 项目编码，然后将代码移至过渡环境，并在其中进行测试。 成功通过测试后，将项目代码部署到生产环境，并在其中执行。
• 部署模型：模型训练在开发环境中执行。 然后将生成的模型生成工件移至过渡环境进行模型验证检查，然后再将模型部署到生产环境。

请参阅模型部署模式。

Databricks 建议对大多数用例使用部署代码方法。 该模型的主要优势为：

• 适合在传统的软件工程工作流中使用，用户可以使用 Git 等熟悉的工具和 CI/CD 系统。
• 它支持在锁定环境中进行自动化重新训练。
• 它仅要求生产环境具有对生产训练数据的读取权限。
• 它提供对训练环境的完全控制，有助于简化可再现性。
• 它使数据科学团队能够使用模块化代码和迭代测试，这有助于在较大项目中进行协调和开发。

Databricks 电子书《MLOps 大全》对此做了详细介绍。

使用模型注册表来解耦代码和模型生命周期

由于模型生命周期与代码生命周期并不一一对应，因此 Unity Catalog 允许在其托管版本的 MLflow 模型注册表中管理 ML 模型的完整生命周期。 Unity Catalog 中的模型将 Unity Catalog 的优势扩展到 ML 模型，包括跨工作区的集中访问控制、审核、世系和模型发现。 Unity Catalog 中的模型与开源 MLflow Python 客户端兼容。

自动执行 ML 试验跟踪

跟踪 ML 试验是保存每个试验的相关元数据并组织试验的过程。 此元数据包括试验输入/输出、参数、模型和其他项目。 试验跟踪的目标是在 ML 模型开发过程的每个阶段创建可重现的结果。 通过自动化此流程，可以更轻松地缩放试验数量，并确保在所有试验中捕获的元数据的一致性。

Databricks 自动日志记录是一种无代码解决方案，它扩展了 MLflow 自动日志记录 以为 Azure Databricks 上的机器学习训练会话提供自动试验跟踪。 当你使用记录为 MLflow 跟踪运行的训练运行来训练模型时，Databricks 自动日志记录会自动捕获模型参数、指标、文件和世系信息。

重用相同的基础结构来管理 ML 管道

用于 ML 管道的数据通常来自与其他数据管道使用的数据相同的来源。 ML 和数据管道相似之处在于它们都为业务用户分析或模型训练准备数据。 两者都需要可缩放、安全且受到适当监视。 在这两种情况下，所使用的基础结构都应支持这些活动。

使用 Databricks Terraform 提供程序将 ML 环境部署自动化。 ML 需要部署基础结构，例如推理作业、服务终结点和特征化作业。 所有 ML 管道都可以作为作业自动化，许多以数据为中心的 ML 管道可以使用更专用的自动加载程序来引入图像和其他数据，并使用增量实时表来计算特征或监视指标。

确保使用模型服务进行企业级 ML 模型部署。

利用声明式管理来处理复杂的数据和 ML 项目

MLOps 中的声明式框架支持团队以高级术语定义期望的结果，并让系统处理执行细节，从而简化 ML 模型的部署和缩放。 这些框架支持持续集成和部署、自动化测试和基础设施管理，并确保模型治理和合规性，最终加快上市时间并提高整个 ML 生命周期的生产力。

Databricks 资产捆绑包 (DAB) 是一种工具，用于为 Databricks 平台简化复杂数据、分析和 ML 项目的开发。 通过捆绑包，可以轻松地在活动开发期间管理复杂的项目，其方法是利用单个简洁的声明性 YAML 语法向软件开发工作流提供 CI/CD 功能。 通过使用捆绑包自动执行项目的测试、部署和配置管理，可以在组织中将软件最佳做法作为模板化项目进行推广时减少错误。

3.管理容量和配额

管理服务限制和配额

要维护正常运行的基础设施并防止意外成本，必须管理服务限制和配额。 在云上启动的每项服务必须考虑到限制，例如访问速率限制、实例数量、用户数量和内存要求。 对于云提供商，请查看云限制。 在设计解决方案之前，必须了解这些限制。

具体而言，对于 Databricks 平台，有不同类型的限制：

Databricks 平台限制：这些是 Azure Databricks 资源的特定限制。 资源限制中记录了整个平台的限制。

Unity Catalog 限制：Unity Catalog 资源配额

订阅/帐户配额：Azure Databricks 将云资源用于其服务。 例如，Azure Databricks 上的工作负载在群集上运行，为此，Databricks 平台将启动云提供商的虚拟机 (VM)。 云提供商对可以同时启动的 VM 数量设置了默认配额。 根据需求，可能需要调整这些配额。

有关详细信息，请参阅提高 VM 系列 vCPU 配额。

同样，存储、网络和其他云服务也有必须了解和考虑的限制。

投资容量计划

容量规划需要管理云资源（例如存储、计算和网络），以在优化成本的同时保持性能。 针对预期负载的变化制定计划，这些变化可能会由于多种原因而发生，包括突然的业务变化甚至世界事件。 测试负载变化（包括意外变化），以确保工作负载可缩放。 确保所有区域都可以充分缩放，以在一个区域发生故障时支持总负载。 如下所示：

• 技术和服务限制以及云约束。 请参阅管理容量和配额。
• SLA，用于确定设计中要使用的服务。
• 成本分析，用于确定如果成本增加，应用程序中将实现多少改进。 评估价格是否值得投资。

了解和规划高优先级（卷）事件非常重要。 如果预配的云资源不足且工作负载无法缩放，则这样增加卷可能会导致中断。

4.设置监视、警报和日志记录

建立监视流程

出于多种原因，为数据平台建立监视流程至关重要。 监视流程有助于尽早发现数据质量问题、性能瓶颈和系统故障等问题，从而有助于防止停机和数据丢失。 它们可以帮助识别数据平台中效率低下之处，并通过减少浪费和提高资源利用率来优化成本。 此外，监视流程可以帮助确保符合监管要求，并提供数据访问和使用情况的审核线索。

使用本机和外部工具进行平台监视

Databricks Data Intelligence 平台具有内置的监视解决方案，并集成了外部监视系统：

• 使用 Azure 监视解决方案进行平台监视

  监视对于任何生产级解决方案而言至关重要，Azure Databricks 提供了可靠的功能，用于监视自定义应用程序指标、流式处理查询事件和应用程序日志消息。 Azure Databricks 可以将此监视数据发送到不同的日志记录服务。 以下文章说明如何将监视数据从 Azure Databricks 发送到 Azure Monitor（Azure 的监视数据平台）。

  • 将 Azure Databricks 应用程序日志发送到 Azure Monitor
  • 使用仪表板将 Azure Databricks 指标可视化
  • 排查性能瓶颈问题

• SQL 仓库监视

  监视 SQL 仓库对于了解不断变化的负载配置文件和有效管理 SQL 仓库至关重要。 使用 SQL 仓库监视，可以查看仓库处理的查询数或分配到仓库的群集数等信息。

• Databricks SQL 警报

  Databricks SQL 警报会定期运行查询、评估定义的条件，并在满足条件时发送通知。 你可以设置警报来监视业务，并在报告的数据超出预期限制时发送通知。

• 自动加载程序监视

  自动加载程序提供用于检查流状态的 SQL API。 使用 SQL 函数，可以查找有关自动加载程序流发现的文件的元数据。 请参阅监视自动加载程序。

  使用 Apache Spark 流式处理查询侦听器界面，可以进一步监视自动加载程序流。

• 作业监视

  作业监视有助于识别和解决 Databricks 作业中的问题，例如故障、延迟或性能瓶颈。 作业监视提供对作业性能的见解，使你能够优化资源利用率、减少占用并提高整体效率。

• 增量实时表监视

  事件日志是针对每个增量实时表管道创建并维护的。 事件日志包含与管道相关的所有信息，包括审核日志、数据质量检查、管道进度和数据世系。 可以使用事件日志来跟踪、了解和监视数据管道的状态。

• 流式处理监视

  流式处理是用于引入和分析的最重要数据处理技术之一。 它为用户和开发人员提供低延迟的实时数据处理功能进行分析和触发操作。 在 Databricks Data Intelligence 平台中可以监视结构化流式处理查询。

• 安全监视

  请参阅安全性、合规性和隐私 - 安全监视。

• 成本监视

  请参阅成本优化 - 监视和控制成本。