随着机器学习 (machine learning)应用在全球范围的扩展，或者组织为了增强弹性或优化成本而采取多云策略，设计一个能够跨越多个地理区域或云服务商的特征存储变得必要。这种扩展带来了显著的架构挑战。为了应对这些挑战，需要对特征存储的组件有透彻的理解，其中包括注册表、在线/离线存储以及服务API。在分布式环境中管理数据一致性、确保低延迟服务以及处理操作复杂性，都需要周密的规划和特定的设计模式。
分布式环境中的主要挑战
在多个区域或云中部署特征存储会带来一些基本难题：
- 数据同步与一致性： 如何确保在一个区域/云中生成或更新的特征数据在其他区域/云中也可用且一致？复制大型数据集会产生费用（数据流出费）并引入延迟。选择合适的一致性模型（例如，最终一致性与强一致性）变得非常重要，它会影响系统设计和应用行为。在不同位置的在线和离线存储之间保持一致性增加了又一层复杂性。
- 延迟： 向模型或应用程序提供特征需要低延迟，通常用 T检索 来衡量。服务API与请求应用程序之间的网络距离是一个主要因素。特征存储架构必须考虑从最近的副本检索特征，以满足性能服务水平协议（SLAs）。
- 元数据管理： 如何管理特征元数据（定义、血缘、版本）？集中式注册表简化了治理，但远程区域访问时可能引入延迟。联邦式方法（元数据按区域存储）增加了自主性，但使保持特征的全球一致视图变得复杂。
- 计算与数据局部性： 特征计算管道（批处理或流式处理）通常处理大量数据。高效运行这些管道可能需要在特定区域将计算资源与数据源或离线存储分区共同放置，以最大程度地减少数据传输成本和处理时间。
- 操作开销： 在多个不同的环境中管理基础设施、部署、监控、安全策略和访问控制会大大增加操作复杂性。工具兼容性和自动化变得更加重要。
- 成本管理： 区域之间，特别是不同云服务商之间的数据流出费用可能相当可观。为实现高可用性而维护冗余基础设施也会增加总成本。需要仔细的资源配置和数据传输优化。
跨区域/多云特征存储的架构模式
有几种架构模式可以解决这些挑战，每种都有其独特的权衡：
1. 集中式控制平面，区域数据平面
在此模型中，一个单一的全球特征注册表管理所有特征定义、版本和主要元数据。然而，数据本身（在线和离线存储）以及服务API都在区域内部署。特征计算管道可能在区域内运行，将数据推送到本地存储，但元数据则集中注册。
集中式控制平面架构，采用区域数据平面。元数据是全球性的，而数据存储、计算和服务则按区域本地化。
- 优点： 特征定义的高一致性，集中式治理和发现，可能更简单的合规管理。
- 缺点： 如果中央注册表未设计为高可用性，可能成为性能瓶颈或单点故障。来自远程区域的元数据更新存在延迟。区域离线/在线存储之间的数据复制仍需单独处理（例如，使用数据库/存储复制机制）。
2. 联邦架构
这种模式涉及在每个区域或云中部署基本独立的特征存储实例。每个实例管理自己的注册表、数据存储和服务API。可能存在跨实例发现或特定特征组的选择性同步机制，但默认是自主性。
联邦式特征存储架构，每个区域或云拥有独立的实例，可能通过可选的同步或发现机制连接。
- 优点： 高度区域自主性，故障影响范围缩小（一个区域的故障不太可能影响其他区域），区域内所有操作的潜在更低延迟，明确的合规性边界分离。
- 缺点： 在不同实例间保持特征定义和数据一致性是项重大挑战。治理变得分布式，更难在全球范围强制执行。发现其他区域可用的特征需要特定机制。特征工程中可能存在重复工作。
3. 数据复制策略
无论控制平面是集中式还是联邦式，数据（特别是对于在线存储）通常需要在区域间复制，以实现低延迟读取和高可用性。常见策略包括：
- 主动-主动复制： 数据同时或几乎同时写入多个区域。读取操作从本地区域提供。这提供了最低的读取延迟和高可用性，但正确实现起来很复杂，尤其是在确保跨区域写入一致性方面（通常依赖于最终一致性数据库功能，如DynamoDB全球表或Cassandra多数据中心复制）。
- 中心辐射式复制： 主（“中心”）区域接收写入，然后异步复制到次（“辐射”）区域。读取可以从辐射区域本地提供。这通常比主动-主动更容易管理，但会引入复制滞后。如果在写入中心后立即从辐射区域读取，则读写后一致性可能无法保持。中心可能成为写入的瓶颈或单点故障。
- 批处理同步： 对于离线存储，数据可能会使用批处理过程（例如，计划的Spark作业、S3跨区域复制）在区域之间定期复制或同步。这适用于训练中使用的历史数据，但不适用于低延迟的在线服务。
实施考量
- 利用云原生服务： 云服务商提供专为多区域部署设计的服务，例如全球数据库（DynamoDB全球表、Cosmos DB、Spanner）、对象存储复制（S3 CRR、GCS复制）和全球负载均衡器。与从头构建复制逻辑相比，使用这些服务可以简化实施。
- 网络优化： 了解区域间和云间网络延迟和带宽。尽可能利用服务商骨干网络或直连互联，以最大程度地减少数据传输的延迟和成本。
- 抽象层： 在多云环境中操作时，在特定云存储、计算和网络API之上创建抽象层可以简化应用程序逻辑，但会增加开发和维护开销。
- 成本监控： 实施详细的成本监控，密切关注数据流出费用，在设计不佳的多区域或多云设置中，这些费用可能会迅速增加。
- 监控和警报： 分布式系统需要全面的监控。在所有区域和组件中实施健康检查、性能监控（延迟、吞吐量 (throughput)）、数据一致性检查和复制滞后监控。
选择正确的方法
最优架构很大程度上取决于具体要求：
- 延迟敏感性： 需要极低 T检索 的应用程序通常需要区域在线存储，并采用主动-主动或中心辐射式复制。
- 一致性需求： 严格的一致性要求可能倾向于集中式控制平面，或限制异步复制模式的可行性。最终一致性可能适用于许多机器学习 (machine learning)用例。
- 全球覆盖： 真正的全球用户基础指向区域数据平面。
- 监管限制： 数据驻留要求（例如GDPR）可能强制数据处理和存储在特定区域内，从而倾向于更联邦化或严格区域化的模式。
- 操作能力： 联邦式模型增加了操作复杂性。团队必须有能力管理多个独立的实例。
- 自建与采购： 云服务商提供的托管特征存储服务通常内置多区域能力，这可能比构建自定义解决方案更简单。
为多区域或多云环境设计特征存储是一项高级任务。它要求仔细权衡一致性、可用性、延迟、成本和操作复杂性，从而扩展本章前面介绍的架构原则。
