分布式系统中的一致性保证

特征平台常作为分布式系统运行，包括在线存储、离线存储和元数据注册中心等组件，可能分布在多个服务器、可用区甚至不同区域。这种分布式特性带来了数据一致性方面的挑战。确保数据在这些分布式组件间保持一致和最新，对于可靠的特征服务和模型训练非常重要，这直接影响本章前面讨论的在线/离线偏差和时间点准确性。了解不同的一致性保证及其影响对于特征平台的设计和运行非常重要。

分布式系统文献定义了多种一致性模型，每种模型在数据时效性、可用性和性能之间提供不同的权衡。CAP定理明确指出，在网络分区（分布式系统中常见情况）存在时，系统必须在优先保证一致性或可用性之间做出选择。

强一致性

强一致性提供了最严格的保证。线性一致性等模型确保操作看起来在单一时间点上瞬时且原子地发生，如同在单台机器上顺序执行。任何读取操作都保证返回最新完成的写入操作的值。

对特征平台的影响：

• 简易性： 应用程序逻辑变得更简单，因为开发人员不需要处理可能存在的过期数据读取。当特征值更新后，后续读取会立即反映该更新。
• 时间偏差减少： 这有助于最大限度地减少特征更新（例如，通过流处理管道）与特征可供服务之间的时间差异，前提是写入成功完成。
• 性能成本： 实现强一致性通常需要在副本之间采用协调协议（例如两阶段提交或Paxos/Raft变体）。这种协调会引入延迟，特别是对于写入操作，并且如果节点或网络链接出现故障，可能会降低系统可用性。
• 使用场景： 需要绝对最新值的必要特征，例如实时欺诈检测特征或对微小过期都不能接受的计数器。元数据存储通常受益于强一致性，以避免冲突的定义。

最终一致性

最终一致性提供了一种更宽松的保证。如果对给定数据项没有新的更新，最终所有对该项的访问都将返回最后更新的值。然而，在写入后的传播期间，读取可能会从不同的副本返回旧的（过期）数据。

对特征平台的影响：

• 更高的可用性与更低的延迟： 优先采用最终一致性的系统通常可以更快地响应读写操作，使用本地副本而无需等待跨副本协调。它们往往对网络分区更具弹性。
• 可伸缩性： 最终一致性系统通常更容易为高吞吐量的读写操作进行伸缩。
• 复杂性： 应用程序逻辑必须设计成能容忍潜在的数据过期。这可能涉及策略，用于检测或减轻读取稍旧特征值的影响。
• 时间偏差增加的可能性： 写入在一个副本上完成并传播到其他副本之间的时间滞后，直接导致训练数据生成（可能从更新的副本或源读取）和在线服务（可能命中滞后的副本）之间潜在的不一致。
• 使用场景： 许多常见的特征平台使用场景可以容忍轻微的过期。例如，每小时更新的用户偏好特征、较长时间窗口内的聚合行为特征或批量更新的产品嵌入。性能和可用性益处通常超过对严格一致性的需求。

对比简化双副本系统中强一致性与最终一致性的写入路径。强一致性在确认成功前需要协调，确保后续读取能看到更新。最终一致性在写入一个副本后快速确认成功，然后异步传播，允许副本之间暂时出现差异。

其他一致性模型

这两个主要模型之外，还存在其他提供中间保证的模型：

• 读己所写一致性： 保证一旦一个进程更新了某个项，其后续读取将总是返回更新后的值（或更新的值）。它不保证其他进程立即看到更新。对于用户期望看到自己更改反映的交互式应用程序很有用。
• 因果一致性： 如果操作 A 在因果上先于操作 B（例如，B 读取了 A 写入的值），那么任何读取 B 的进程也必须能访问到 A。这保持了因果相关操作的顺序，但允许无关操作以不同顺序被看到。

虽然这些模型通常不太被选为整个特征平台的主要模型，但理解它们对于选择特定的数据库技术或设计复杂的交互模式很有帮助。

特征平台组件间的一致性

一致性模型的选择在特征平台架构中应用方式不同：

• 在线存储： 这是权衡最明显的地方。低延迟读取对服务非常重要。此处通常优先选择最终一致性，使用Apache Cassandra、Amazon DynamoDB（在最终一致性读取模式下）或采用异步复制的Redis等技术。如果需要强一致性，可以考虑etcd、FoundationDB或采用同步复制的SQL数据库，但需接受其性能影响。
• 离线存储： 通常处理大量批量更新（例如，每日计算）。批处理作业 内部 的一致性（原子性）通常由处理框架（如Spark）处理。数据库的一致性模型不如确保训练数据生成的时间点正确视图重要，这更多地依赖于离线存储（通常是数据湖或数据仓库）中的数据版本控制和分区策略。离线存储与在线存储 之间 的一致性（防止偏差）主要是一个管道编排问题，确保离线计算的数据正确传播并在线可用。
• 元数据存储/注册中心： 存储特征定义、版本和配置。此处的一致性通常很重要，以避免歧义或冲突状态。即使在线/离线数据存储使用较弱的模型，注册中心也通常优先采用更强的一致性保证。

设计时的实际考量

在设计特征平台时，请明确考虑一致性需求：

1. 按特征需求： 所有特征都需要相同级别的一致性吗？或许必要特征需要强一致性，而其他特征可以容忍最终一致性。一些特征平台设计允许按特征组指定一致性级别。
2. 技术选择： 选择支持所需一致性模型并达到性能目标的底层存储技术（数据库、键值存储）。了解所选工具提供的具体保证和配置选项。例如，某些数据库允许按操作调整一致性级别（例如，如果支持，从最终一致性系统请求强一致性读取）。
3. 管道设计： 设计数据摄入和传播管道以最大限度地减少不一致。双写（同时写入在线和离线存储，尽管复杂）或精心编排的批量更新等策略可以减轻传播延迟引入的偏差。
4. 监控： 在最终一致性系统中实施监控以跟踪数据过期。测量副本之间的复制延迟或离线计算完成与在线可用性之间的时间延迟。
5. 客户端逻辑： 如果使用最终一致性，请确保下游应用程序（模型服务、监控）能优雅地处理可能存在的过期读取。

选择正确的一致性模型涉及在数据时效性需求与性能、可用性和操作复杂性之间取得平衡。没有单一的“最佳”模型；适当的选择很大程度上取决于具体的用例、性能要求（SLA）以及依赖特征平台的机器学习应用程序的容错能力。