可靠性最佳做法
本文介绍可靠性最佳做法，内容按照以下部分中列出的体系结构原则进行组织。
1. 防故障设计
使用支持 ACID 事务的数据格式
ACID 事务是维护数据完整性和一致性的关键功能。 选择支持 ACID 事务的数据格式有助于生成更简单、更可靠的管道。
Delta Lake 是一种开源存储框架，它提供 ACID 事务、架构实施和可缩放的元数据处理，并且可统一流处理和批数据处理。 Delta Lake 与 Apache Spark API 完全兼容，并且设计为与结构化流式处理紧密集成，让你可以轻松地将单个数据副本用于批处理和流式处理操作，并提供大规模增量处理。
对所有工作负载使用弹性分布式数据引擎
Apache Spark 用作 Azure Databricks 湖屋的计算引擎，基于弹性分布式数据处理。 如果内部 Spark 任务没有按预期返回结果，Apache Spark 会自动重新计划丢失的任务并继续执行整个作业。 这对于代码外故障很有帮助，例如短暂的网络问题或被撤销的现成 VM。 将 SQL API 和 Spark 数据帧 API 结合使用时，引擎内置了这种复原能力。
在 Databricks 湖屋中，Photon 是一个完全以 C++ 编写的本机矢量化引擎，是与 Apache Spark API 兼容的高性能计算。
自动补救无效或不符合要求的数据
数据无效或不一致可能导致依赖既定数据格式的工作负载崩溃。 要提高整个过程的端到端复原能力，最佳做法是在引入时筛选掉无效和不符合要求的数据。 支持补救的数据可确保在引入或 ETL 期间绝不会丢失或遗漏数据。 补救数据列包含由于在给定架构中缺失、类型不匹配或者记录或文件中列主体与架构中的不匹配而未分析的任何数据。
- Databricks 自动加载程序：自动加载程序是流式处理文件引入的理想工具。 它支持 JSON 和 CSV 的补救数据。 例如，对于 JSON，补救数据列包含可能由于在给定架构中缺失、类型不匹配或者列大小写不匹配而未分析的任何数据。 补救数据列是推理架构时，由自动加载程序默认作为
_rescued_data返回的架构的一部分。 - 增量实时表：构建复原工作流的另一种选择是使用具有质量约束的增量实时表。 请参阅使用 Delta Live Tables 管理数据质量。 增量实时表原生支持三种模式：保留、删除，以及记录无效时失败。 为了隔离已识别的无效记录，可以以特定方式定义预期规则，以便将无效记录存储（“隔离”）在另一个表中。 请参阅隔离无效数据。
配置作业以自动重试和终止
分布式系统很复杂，一个点的故障可能在整个系统中级联。
- Azure Databricks 作业支持任务的重试策略，该策略确定何时重试失败的运行以及重试次数。 请参阅设置重试策略。
- 可以为任务配置可选的持续时间阈值，包括任务的预期完成时间和任务的最长完成时间。
- 增量实时表还通过使用升级重试来平衡速度与可靠性，以自动执行故障恢复。 请参阅开发和生产模式。
另一方面，挂起的任务可以阻止整个作业完成，从而导致成本高昂。 Databricks 作业支持使用超时配置来终止运行时间超过预期的作业。
尽可能使用托管服务
尽可能利用 Databricks Data Intelligence 平台中的托管服务，例如：
这些服务由 Databricks 以可靠和可缩放的方式运行（不会给客户带来额外成本），使工作负载更加可靠。
2. 管理数据质量
使用分层存储体系结构
策展数据，创建分层体系结构来并确保数据质量随着数据在各层之间移动而提高。 一种常见的分层方法是：
- 原始层（铜级）：源数据引入到第一层的湖屋中，并保存在其中。 当所有下游数据都从原始层创建时，可根据需要从该层重新构建后续层。
- 策展层（银级）：第二层的用途是保存经过清理、细化、筛选和聚合的数据。 此层的目的是为跨所有角色和功能的分析和报告提供坚实、可靠的基础。
- 最终层（金级）：第三层是围绕业务或项目需求创建的。 它为其他业务部门或项目提供不同的数据产品视图，围绕安全需求准备数据（例如匿名化数据）或优化性能（例如使用预聚合视图）。 此层的数据产品被视为业务的事实。
最终层应该只包含高质量的数据，并且从业务的角度来看完全受信任。
通过减少数据冗余来提高数据完整性
复制数据会造成数据冗余，并导致完整性丢失、数据世系丢失，而且往往导致访问权限不同。 这会降低湖屋中数据的质量。
临时或一次性的数据副本本身并无害处，此副本有时对于提高敏捷性、试验和创新是必要的。 但是，当这些副本变得可操作并经常用于制定业务决策时，它们就变成了数据孤岛。 这些数据孤岛不同步会对数据完整性和质量产生重大负面影响，引发诸如“哪个数据集是主数据集？”或“数据集是最新的吗？”之类的问题。
主动管理架构
不受控制的架构更改可能导致无效数据和使用这些数据集的作业失败。 Azure Databricks 提供多种方法来验证和实施架构：
- Delta Lake 通过自动处理架构差异来支持架构验证和架构实施，以防止在引入期间插入错误记录。 请参阅架构强制。
- 自动加载程序在处理数据时会检测是否添加了新列。 默认情况下，添加新列会导致流停止并出现
UnknownFieldException。 自动加载程序支持多种架构演变模式。
使用约束和数据预期
Delta 表支持标准 SQL 约束管理子句，以确保自动检查添加到表中的数据的质量和完整性。 当违反约束时，Delta Lake 将引发 InvariantViolationException 错误以指示无法添加新数据。 请参阅 Azure Databricks 上的约束。
为了进一步改进这种处理，增量实时表支持预期：预期定义数据集内容的数据质量约束。 预期由说明、不变量以及当记录违反不变量时要执行的操作组成。 对查询的期望使用 Python 修饰器或 SQL 约束子句。 请参阅使用 Delta Live Tables 管理数据质量。
采用以数据为中心的机器学习方法
Databricks Data Intelligence Platform 的 AI 愿景的核心指导原则是以数据为中心的机器学习方法。 随着生成式 AI 变得越来越普遍，这种观点仍然同样重要。
任何 ML 项目的核心组件都可以简单地看作是数据管道：特征工程、训练、模型部署、推理和监视管道都是数据管道。 因此，操作 ML 解决方案需要将来自预测、监视和特征表的数据与其他相关数据合并。 从根本上说，实现此目的的最简单方法是在用于管理生产数据的同一平台上开发 AI 支持的解决方案。 请参阅以数据为中心的 MLOps 和 LLMOps
3. 自动缩放设计
为 ETL 工作负载启用自动缩放
通过自动缩放，群集可以根据工作负载自动调整大小。 从成本和性能的角度看，自动缩放能使许多用例和方案受益。 文档中提供了有关是否使用自动缩放以及如何充分利用此功能的考虑因素。
对于流式处理工作负载，Databricks 建议将增量实时表与自动缩放配合使用。 Databricks 增强型自动缩放可以根据工作负载量自动分配群集资源，从而优化群集利用率，并尽量减轻对管道数据处理延迟的影响。
为 SQL 仓库启用自动缩放
SQL 仓库的缩放参数设置发送到仓库的查询分布在其上的最小和最大群集数。 默认值为一个群集，无需自动缩放。
若要针对给定仓库处理更多并发用户，请增加群集数。 若要了解 Azure Databricks 如何向和从仓库中删除群集添加群集，请参阅 SQL 仓库的大小调整、缩放和队列行为。
4. 测试恢复过程
从结构化流式处理查询失败中恢复
结构化流式处理为流式处理查询提供容错和数据一致性。 使用 Databricks 作业，可以轻松地将结构化流式处理查询配置为在失败时自动重启。 通过为流式处理查询启用检查点，可以在失败后重启查询。 重新开始的查询将从失败的查询中断的位置继续。 请参阅结构化流式处理检查点和结构化流式处理的生产注意事项。
使用数据按时间顺序查看功能恢复 ETL 作业
尽管进行了彻底的测试，作业仍可能在生产环境中失败，或者产生意外甚至无效的数据。 有时，在了解问题的根源并首先修复导致问题的管道后，可以通过额外的工作来解决此问题。 但是，这种方法通常并不简单，应回滚出现问题的作业。 借助 Delta 按时间顺序查看，用户可以轻松地将更改回滚到旧版本或时间戳、修复管道，还可轻松重启已修复的管道。
一种便捷的方法是使用 RESTORE 命令。
利用具有内置恢复功能的作业自动化框架
Databricks 作业专为恢复而设计。 当多任务作业中的某个任务失败时（进而所有相关任务也会失败），Azure Databricks 作业将提供运行的矩阵视图，使你能够调查导致失败的问题。请参阅查看作业的运行。 无论是短暂性的网络问题还是数据中的实际问题，都可以修复它并在 Azure Databricks 作业中启动修复运行。 它只运行失败的和相关的任务，并保留先前运行的成功结果，从而节省时间和成本。请参阅排查和修复作业失败
配置灾难恢复模式
对于云原生数据分析平台（例如 Azure Databricks），清晰的灾难恢复模式至关重要。 至关重要的是，即使在区域性服务范围内的云服务提供商因区域性灾难（如飓风、地震或某些其他因素）而中断的罕见情况下，数据团队也可以使用 Azure Databricks 平台。
Azure Databricks 通常是包括许多服务的整个数据生态系统的核心部分，其中包括上游数据引入服务（批/流式处理）、云原生存储（例如 Azure Data Lake Storage Gen2）、下游工具和服务（例如商业智能应用）以及业务流程工具。 某些用例可能对区域性服务范围内的中断特别敏感。
灾难恢复涉及一组策略、工具和过程，可在发生自然或人为灾难后恢复或延续重要的技术基础结构和系统。 大型云服务（如 Azure）可为许多客户提供服务，并且具有针对单一故障的内置保护。 例如，区域是一组连接到不同电源的建筑物，可确保单个电源中断不会关闭某个区域。 但是，可能会发生云区域故障，而且故障的严重性及其对业务的影响可能会有所不同。