你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 上任务关键型工作负载的数据平台注意事项

选择有效的应用程序数据平台是另一个关键决策领域，在其他设计领域具有深远的影响。 Azure 最终提供了多种关系、非关系和分析数据平台，这些平台在功能上大相径庭。 因此，必须充分考虑关键的非功能性要求以及其他决策因素，例如一致性、可操作性、成本和复杂性。 例如，在多区域写入配置中操作的能力对全球可用平台的适用性至关重要。

此设计领域扩展了 应用程序设计，提供关键注意事项和建议，以告知最佳数据平台的选择。

重要

本文是 Azure Well-Architected 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从 什么是任务关键型工作负载开始？

大数据的四大对决

“四大大数据”提供了一个框架，用于更好地了解高可用性数据平台的必要特征，以及如何使用数据来最大化业务价值。 因此，本部分将探讨如何在概念级别应用音量、速度、品种和 Veracity 特征，以帮助使用适当的数据技术设计数据平台。

• Volume：传入多少数据来告知存储容量和分层要求 -即数据集的大小。
• V位置：处理数据的速度，可以是批处理流还是连续流，即流速。
• Variety：数据的组织和格式，捕获结构化、半结构化和非结构化格式 -即跨多个存储或类型的数据。
• Veracity：包括用于治理和数据质量保证的已考虑数据集的来源和策展 ，即数据的准确性。

设计注意事项

音量

• 现有 (，如果根据与业务目标和计划相符的预测数据增长率，) 和预期的未来数据量。

  • 数据卷应包含数据本身以及索引、日志、遥测和其他适用的数据集。
  • 大型业务关键型和任务关键型应用程序通常每天都会生成和存储大量数据（数 GB 和数 TB）。
  • 数据扩展可能会产生重大成本影响。

• 数据量可能因业务环境或保养工作程序的变化而波动。

• 数据量可能会对数据平台查询性能产生深远影响。

• 达到数据平台容量限制可能会产生深远的影响。

  • 这会导致停机吗？如果是，需要多长时间？
  • 缓解过程有哪些？缓解是否需要更改应用程序？
  • 是否会有数据丢失的风险？

• 生存时间 (TTL) 等功能可用于管理数据增长，方法是在经过一段运行时间后使用记录创建或修改自动删除记录。

  • 例如，Azure Cosmos DB 提供内置的 TTL 功能。

速度

• 从各种应用程序组件发出数据的速度以及提交和检索数据速度的吞吐量要求对于确定关键工作负载方案的最佳数据技术至关重要。

  • 吞吐量要求的性质因工作负载方案而异，例如读取密集型或写入密集型方案。
    • 例如，分析工作负载通常需要满足较大的读取吞吐量。
  • 所需的吞吐量是多少？ 吞吐量预期如何增长？
  • 引用负载级别下 P50/P99 的数据延迟要求是什么？

• 支持无锁设计、索引优化和一致性策略等功能对于实现高吞吐量至关重要。

  • 针对高吞吐量优化配置会产生权衡，这应该完全理解。
  • 负载调配持久性和消息传送模式（如 CQRS 和事件溯源）可用于进一步优化吞吐量。

• 许多应用程序场景的负载级别会自然波动，自然峰值需要足够的弹性来处理可变需求，同时保持吞吐量和延迟。

  • 敏捷的可伸缩性是有效支持可变吞吐量和负载级别而不过度预配容量级别的关键。
    • 读取和写入吞吐量都必须根据应用程序要求和负载进行缩放。
    • 可以应用垂直和水平缩放操作来响应不断变化的负载级别。

• 吞吐量下降的影响可能因工作负载方案而异。

  • 是否会发生连接中断？
  • 当控制平面继续运行时，单个操作是否会返回失败代码？
  • 数据平台是否会激活限制，如果激活限制，会激活多长时间？

• 使用主动-主动地理分布的基本应用程序设计建议带来了数据一致性方面的挑战。

  • 在完整 ACID 事务语义和传统锁定行为方面，一致性和性能之间存在权衡。
    • 将写入延迟降到最低，代价是数据一致性。

• 在多区域写入配置中，需要在所有副本之间同步和合并更改，并根据需要解决冲突，这可能会影响性能级别和可伸缩性。

• 只读副本 (区域内和区域间) 可用于最大程度地减少往返延迟和分配流量，以提高性能、吞吐量、可用性和可伸缩性。

• 缓存层可用于增加读取吞吐量，以改善用户体验和端到端客户端响应时间。

  • 需要考虑缓存过期时间和策略来优化数据最新性。

种类 (Variety)

• 数据模型、数据类型、数据关系和预期查询模型将强烈影响数据平台决策。

  • 应用程序是否需要关系数据模型，或者它是否支持变量架构或非关系数据模型？
  • 应用程序将如何查询数据？ 查询是否依赖于数据库层概念，例如关系联接？ 或者应用程序是否提供此类语义？

• 应用程序考虑的数据集的性质可以有所不同，包括非结构化内容（如图像和视频）或更结构化的文件（如 CSV 和 Parquet）。

  • 复合应用程序工作负载通常具有不同的数据集和相关要求。

• 除了关系数据平台或非关系数据平台外，图形或键值数据平台可能也适用于某些数据工作负载。

  • 某些技术适用于可变架构数据模型，其中数据项在语义上相似，并且/或一起存储和查询，但在结构上有所不同。

• 在微服务体系结构中，可以使用不同的方案优化数据存储生成单个应用程序服务，而不是依赖于单个整体数据存储。

  • 可以应用 SAGA 等设计模式来管理不同数据存储之间的一致性和依赖关系。
    • 数据库间直接查询可以施加共置约束。
  • 使用多种数据技术会增加一定程度的管理开销，以维护包含的技术。

• 每个 Azure 服务的功能集因语言、SDK 和 API 而异，这可能会极大地影响可应用的配置优化级别。

• 与数据模型和包含的数据类型进行优化一致性的功能将严重影响数据平台决策。

  • 查询层，例如存储过程和对象关系映射器。
  • 非特定语言的查询功能，例如受保护的 REST API 层。
  • 业务连续性功能，例如备份和还原。

• 分析数据存储通常为各种类型的数据结构支持多语言存储。

  • 分析运行时环境（如 Apache Spark）可能具有分析多语言数据结构的集成限制。

• 在企业环境中，使用现有流程和工具以及技能的连续性可能会对数据平台设计和数据技术的选择产生重大影响。

准确性

• 验证应用程序中数据的准确性时，必须考虑多项因素，而这些因素的管理可能对数据平台设计产生重大影响。

  • 数据一致性。
  • 平台安全功能。
  • 数据管理。
  • 更改管理和架构演变。
  • 数据集之间的依赖关系。

• 在具有多个数据副本的任何分布式应用程序中，一致性和延迟之间存在权衡，如 CAP 和 PACELC 定理所示。

  • 当读取器和编写器分布明显时，应用程序必须选择返回数据项的最快可用版本，即使与刚刚完成的写入 (更新) 在另一个副本 (replica) 中的数据项相比已过期，或返回数据项的最新版本，这可能会导致额外的延迟来确定和获取最新状态。
  • 可以在平台级别或单个数据请求级别配置一致性和可用性。
  • 如果数据来自最靠近用户的副本 (replica) ，但不反映不同副本 (replica) 的最新状态，那么用户体验如何？即应用程序是否支持可能提供过时数据？

• 在多区域写入上下文中，在复制任一更改之前，在两个单独的写入副本中更改同一数据项时，将创建必须解决的冲突。

  • 可以应用标准化的冲突解决策略，例如“上次写入获胜”或具有自定义逻辑的自定义策略。

• 实现安全要求可能会对吞吐量或性能产生负面影响。

• 如有必要，可以在应用程序层中使用客户端加密和/或使用服务器端加密在数据层中实现静态加密。

• Azure 支持各种加密模型，包括使用服务管理的密钥的服务器端加密、密钥保管库中的客户管理的密钥或客户控制的硬件上的客户管理的密钥。

  • 使用客户端加密，可以在密钥保管库或其他安全位置管理密钥。

• MACsec (IEEE 802.1AE MAC) 数据链接加密用于保护 Microsoft 主干网络上 Azure 数据中心之间移动的所有流量。

  • 数据包在发送之前在设备上加密和解密，防止物理“中间人”或窃听/窃听攻击。

• 对数据平面和控制平面进行身份验证和授权。

  • 数据平台将如何对应用程序访问和操作访问进行身份验证和授权？

• 通过监视平台运行状况和数据访问实现可观测性。

  • 如何针对可接受的操作边界之外的条件应用警报？

设计建议

音量

• 确保与有机增长相关的未来数据量不会超过数据平台功能。

  • 预测与业务计划相一致的数据增长率，并使用既定增长率来给出持续的容量需求。
  • 将汇总和每数据记录量与数据平台限制进行比较。
  • 如果在特殊情况下存在达到限制的风险，请确保实现操作缓解措施，以防停机和数据丢失。

• 监视数据量并根据容量模型对其进行验证，同时考虑规模限制和预期的数据增长率。

  • 确保缩放操作符合存储、性能和一致性要求。
  • 引入新的缩放单元时，可能需要复制基础数据，这需要一定的时间，并且可能会在复制时造成性能损失。 因此，如果可能，请确保在关键工作时间之外执行这些操作。

• 定义应用程序数据层，根据使用情况和关键性对数据集进行分类，以便于删除或卸载旧数据。

  • 请考虑将数据集分类为“热”、“暖”和“冷” (“存档”) 层。
    • 例如，基础参考实现使用 Azure Cosmos DB 来存储应用程序主动使用的“热”数据，而 Azure 存储用于“冷”操作数据进行分析。

• 配置管理过程以优化数据增长并提高数据效率，例如查询性能和管理数据扩展。

  • 为不再需要且没有长期分析值的数据配置生存时间 (TTL) 过期时间。
    • 验证在不对应用程序产生不利影响的情况下是否可以将旧数据安全地分层到辅助存储或是否可以直接删除旧数据。
  • 将非关键数据转移到辅助冷存储，但对其进行维护以进行分析和满足审核要求。
  • 收集数据平台遥测和使用情况统计信息，使 DevOps 团队能够持续评估内部管理要求和“适当大小”数据存储。

• 在与微服务应用程序设计一致的情况下，请考虑并行使用多种不同的数据技术，并针对特定的工作负载方案和卷要求使用经过优化的数据解决方案。

  • 避免创建单一的单片数据存储，因为可能难以管理扩展的数据量。

速度

• 数据平台必须在本质上进行设计和配置，以支持高吞吐量，将工作负载分离到不同的上下文中，以便使用方案优化的数据解决方案最大程度地提高性能。

  • 确保每个数据方案的读写吞吐量可以根据预期的负载模式进行缩放，且对意外变化有足够的容错。
  • 将不同的数据工作负载（例如事务性和分析性操作）分离到不同的性能上下文中。

• 通过使用异步非阻塞消息传送（例如使用 CQRS 或 事件溯源模式）的 负载级别。

  • 写入请求之间以及新数据可供读取时可能存在延迟，这可能会影响用户体验。
    • 在关键业务要求上下文中，必须了解并接受这种影响。

• 确保敏捷可伸缩性，以支持可变吞吐量和负载级别。

  • 如果负载级别高度易失，请考虑过度预配容量级别，以确保保持吞吐量和性能。
  • 在无法维持吞吐量时测试并验证对复合应用程序工作负载的影响。

• 通过自动缩放操作确定 Azure 本机数据服务的优先级，以便快速响应负载级别的波动。

  • 根据服务内部和应用程序设置的阈值配置自动缩放。
  • 缩放应在符合业务需求的时间范围内启动和完成。
  • 对于需要手动交互的方案，制定可以触发而不是执行手动操作的自动化操作“playbook”。
    • 考虑是否可以将自动化触发器作为后续工程投资的一部分应用。

• 根据 P50/P99 延迟要求监视应用程序数据读取和写入吞吐量，并与应用程序容量模型保持一致。

• 多余的吞吐量应由数据平台或应用程序层正常处理，并由运行状况模型捕获以用于操作表示。

• 为“热”数据方案实现缓存，以最大程度地减少响应时间。

  • 为缓存过期和内部保留应用适当的策略，以避免数据失控增长。
    • 当支持数据更改时，使缓存项过期。
    • 如果缓存过期严格基于生存时间 (TTL) ，则需要了解提供过时数据的影响和客户体验。

种类 (Variety)

• 根据云和 Azure 原生设计的原则，强烈建议优先使用托管 Azure 服务，以降低运营和管理复杂性，并利用 Microsoft 未来的平台投资。

• 根据松散耦合微服务体系结构的应用程序设计原则，允许单个服务使用不同的数据存储和方案优化的数据技术。

  • 为特定工作负载方案确定应用程序将处理的数据结构类型。
  • 避免在单一的单片数据存储上创建依赖项。
    • 请考虑数据存储之间存在依赖关系的 SAGA 设计模式。

• 验证所需的功能是否可用于选定的数据技术。

  • 确保支持所需的语言和 SDK 功能。 并非所有功能都以相同的方式适用于每种语言/SDK。

准确性

• 通过将数据移动到更靠近应用程序终结点的位置，采用多区域数据平台设计并跨区域分布副本来实现最大的可靠性、可用性和性能。

  • 在区域 () 可用性区域 (可用区之间分发数据副本，或使用区域冗余服务层) 最大程度地提高区域内可用性。

• 在一致性要求允许的情况下，请使用多区域写入数据平台设计来最大程度地提高整体全球可用性和可靠性。

  • 在两个单独的写入副本中更改同一数据项时，请考虑冲突解决的业务要求，然后才能复制任一更改，从而引发冲突。
    • 尽可能使用标准化的冲突解决策略，例如“最后一个赢”
      • 如果需要具有自定义逻辑的自定义策略，请确保应用 CI/CD DevOps 做法来管理自定义逻辑。

• 通过持续交付过程中的混乱测试来测试和验证备份和还原功能以及故障转移操作。

• 运行性能基准，以确保吞吐量和性能要求不受包含所需的安全功能（如加密）的影响。

  • 确保持续交付过程考虑根据已知的性能基准进行负载测试。

• 应用加密时，强烈建议使用服务管理的加密密钥来降低管理复杂性。

  • 如果客户管理的密钥具有特定的安全要求，请确保应用适当的密钥管理程序，以保证所有考虑的密钥的可用性、备份和轮换。

注意

与更广泛的组织实现集成时，应用以应用程序为中心的方法在应用程序设计中预配和操作数据平台组件至关重要。

更具体地说，为了最大限度地提高可靠性，各个数据平台组件必须通过操作操作（可能包括其他应用程序组件）适当地响应应用程序运行状况。 例如，在需要其他数据平台资源的方案中，可能需要根据容量模型缩放数据平台和其他应用程序组件，这可能需要预配额外的缩放单元。 如果集中运营团队难以独立地解决与数据平台相关的问题，此方法最终将受到限制。

归根结底，使用中心 IT DBaaS) 的集中式数据服务 (会引入操作瓶颈，这些瓶颈通过基本上不带文本的管理体验来显著阻碍敏捷性，在任务关键型或业务关键型上下文中应避免。

其他参考

Azure 应用程序体系结构指南中提供了其他数据平台指南。

• Azure 数据存储决策树
• 选择数据存储的条件
• 非关系数据存储
• 关系 OLTP 数据存储

全球分布式多区域写入数据存储

为了完全适应应用程序设计的全球分布式主动-主动需求，强烈建议考虑使用分布式多区域写入数据平台，其中对独立可写副本的更改将在所有副本之间同步和合并，并根据需要解决冲突。

重要

微服务可能不需要分布式多区域写入数据存储，因此应考虑每个工作负载方案的体系结构上下文和业务要求。

Azure Cosmos DB 提供全球分布式且高度可用的 NoSQL 数据存储，提供多区域写入和开箱即用的可调整一致性。 因此，本部分中的设计注意事项和建议将重点介绍 Azure Cosmos DB 的最佳使用情况。

设计注意事项

Azure Cosmos DB

• Azure Cosmos DB 将数据存储在容器中，容器是索引的、基于行的事务存储，旨在允许快速的事务读取和写入，响应时间以毫秒为单位。

• Azure Cosmos DB 支持具有不同功能集的多个不同 API，例如 SQL、Cassandra 和 MongoDB。

  • 第一方 Azure Cosmos DB for NoSQL 提供最丰富的功能集，通常是首先提供新功能的 API。

• Azure Cosmos DB 支持网关和直接连接模式，其中 Direct 有助于通过 TCP 连接到后端 Azure Cosmos DB 副本 (replica) 节点，以提高性能，减少网络跃点，而网关则提供与前端网关节点的 HTTPS 连接。

  • 直接模式仅在使用 Azure Cosmos DB for NoSQL 时可用，目前仅在 .NET 和 Java SDK 平台上受支持。

• 在已启用可用性区域的区域中，Azure Cosmos DB 提供 可用性区域 (AZ) 冗余 支持，以实现对区域中区域性故障的高可用性和复原能力。

• Azure Cosmos DB 在单个区域中维护四个数据副本，当可用性区域 (AZ) 冗余启用时，Azure Cosmos DB 可确保将数据副本放置在多个 AZ 上，以防止区域性故障。

  • Paxos 共识协议用于在一个区域内的副本之间实现仲裁。

• 可以轻松地将 Azure Cosmos DB 帐户配置为跨多个区域复制数据，以降低单个区域不可用的风险。

  • 可以使用单区域写入或多区域写入配置复制。
    • 使用单区域写入时，主“中心”区域用于处理所有写入操作，如果此“中心”区域不可用，则必须执行故障转移操作，才能将另一个区域提升为可写区域。
    • 使用多区域写入，应用程序可以写入任何配置的部署区域，这将复制所有其他区域之间的更改。 如果某个区域不可用，则剩余区域将用于提供写入流量。

• 在多区域写入配置中， 更新 (插入、替换、删除) 冲突 可能发生，因为编写器同时更新多个区域中的同一项。

• Azure Cosmos DB 提供两种冲突解决策略，这些策略可用于自动解决冲突。

  • 上次写入 wins (LWW) 应用时间同步时钟协议，使用系统定义的时间戳 _ts 属性作为冲突解决路径。 如果发生冲突时，冲突解决路径值最高的项目将成为赢家，如果多个项具有相同的数值，则系统会选择一个赢家，以便所有区域都可以收敛到已提交项目的相同版本。
    • 对于删除冲突，无论冲突解决路径值如何，已删除的版本始终胜过插入或替换冲突。
    • “最后写入者胜出”是默认的冲突解决策略。
    • 使用 Azure Cosmos DB for NoSQL 时，可以使用自定义数字属性（例如自定义时间戳定义）解决冲突。
  • 自定义解决策略允许应用程序定义的语义使用在检测到冲突时自动调用的已注册合并存储过程来协调冲突。
    • 在执行提交协议过程中，该系统可保证正好执行合并过程一次。
    • 自定义冲突解决策略仅适用于 Azure Cosmos DB for NoSQL，并且只能在创建容器时设置。

• 在多区域写入配置中，依赖于单个 Azure Cosmos DB“中心”区域来执行所有冲突解决，并应用 Paxos 共识协议在中心区域内跨副本实现仲裁。

  • 平台为中心区域内的写入冲突提供一个消息缓冲区，以达到负载级别，并为暂时性故障提供冗余。
    • 缓冲区能够存储需要共识的数分钟写入更新。

Azure Cosmos DB 平台的战略方向是删除此单区域依赖项，以便在多区域写入配置中解决冲突，利用 2 阶段 Paxos 方法在全球级别和区域内获得仲裁。

• 主要“中心”区域由在其中配置 Azure Cosmos DB 的第一个区域确定。

  • 为其他附属部署区域配置了优先级排序，以便进行故障转移。

• 跨逻辑分区和物理分区的数据模型和分区在实现最佳性能和可用性方面发挥着重要作用。

• 使用单个写入区域进行部署时，可以将 Azure Cosmos DB 配置为基于定义的故障转移优先级（考虑所有读取区域副本） 进行自动 故障转移。

• Azure Cosmos DB 平台提供的 RTO 约为 10-15 分钟，在发生影响中心区域的灾难性灾难时，会捕获执行 Azure Cosmos DB 服务区域故障转移所经过的时间。

  • 鉴于冲突解决依赖于单个“中心”区域，此 RTO 也与多区域写入上下文相关。
    • 如果“中心”区域不可用，则在消息缓冲区填充后，对其他区域的写入将失败，因为冲突解决在服务故障转移和建立新的中心区域之前无法进行。

Azure Cosmos DB 平台的战略方向是通过允许分区级别故障转移，将 RTO 减少到约 5 分钟。

• 恢复点目标 (RPO) 和恢复时间目标 (RTO) 可通过一致性级别进行配置，并在数据持续性和吞吐量之间进行权衡。

  • 对于多区域写入的宽松一致性级别，Azure Cosmos DB 提供最低 RTO 为 0;对于单写入区域，RPO 为 0，可实现高度一致性。

• Azure Cosmos DB 为配置为可写的多个 Azure 区域的数据库帐户提供 99.999% SLA 的 读写可用性。

  • SLA 由每月运行时间百分比表示，该百分比计算为 100% - 平均错误率。
  • 平均错误率定义为计费月份中每小时的错误率之和除以计费月份的总小时数，其中错误率是失败请求总数除以给定的一小时间隔内请求总数。

• 配置了五个一致性级别之一时，Azure Cosmos DB 为数据库帐户提供 99.99% 的 SLA，用于吞吐量、一致性、可用性和延迟，范围限定为单个 Azure 区域。

  • 99.99% SLA 也适用于跨多个 Azure 区域配置了四个宽松一致性级别之一的数据库帐户。

• 可以在 Azure Cosmos DB 中预配两种类型的吞吐量：标准和 自动缩放，这些吞吐量使用每秒请求单位 (RU/s) 进行测量。

  • 标准吞吐量分配保证指定 RU/秒值所需的资源。
    • 对于预配的吞吐量，标准按小时计费。
  • 自动缩放定义最大吞吐量值，Azure Cosmos DB 将根据应用程序负载自动纵向扩展或缩减，介于最大吞吐量值和最大吞吐量值的 10% 之间。
    • 自动缩放按小时计费，以达到消耗的最大吞吐量。

• 具有可变工作负荷的静态预配吞吐量可能会导致限制错误，这会影响感知到的应用程序可用性。

  • 自动缩放允许 Azure Cosmos DB 根据需要纵向扩展，同时通过在负载减少时进行缩减来维护成本保护，从而防止出现限制错误。

• 跨多个区域复制 Azure Cosmos DB 时，预配的请求单位 (RU) 按区域计费。

• 多区域写入和单区域写入配置之间存在显著的成本增量，在许多情况下，多主 Azure Cosmos DB 数据平台的成本可能过高。

单区域读/写	单区域写入 - 双区域读取	双区域读/写
1 RU	2 RU	4 RU

单区域写入和多区域写入之间的增量实际上小于上表中反映的 1：2 比率。 更具体地说，与单写入配置中的写入更新相关的跨区域数据传输费用，与多区域写入配置一样，不会在 RU 成本中捕获。

• 消耗的存储按给定小时用于托管数据和索引的总存储量 (GB) 统一费率计费。

• Session 是默认且最广泛使用 的一致性级别 ，因为接收数据的顺序与写入相同。

• Azure Cosmos DB 支持通过Microsoft Entra标识或 Azure Cosmos DB 密钥和资源令牌进行身份验证，这些令牌提供重叠功能。

• 可以使用密钥或资源令牌禁用资源管理操作，以仅将密钥和资源令牌限制为数据操作，从而允许使用Microsoft Entra基于角色的访问控制 (RBAC) 进行精细的资源访问控制。

  • 通过密钥或资源令牌限制控制平面访问将禁用使用 Azure Cosmos DB SDK 的客户端的控制平面操作，因此应进行全面 评估和测试。
  • disableKeyBasedMetadataWriteAccess可以通过 ARM 模板 IaC 定义或通过内置Azure Policy配置设置。

• Microsoft Entra Azure Cosmos DB 中的 RBAC 支持适用于帐户和资源控制平面管理操作。

  • 应用程序管理员可以为用户、组、服务主体或托管标识创建角色分配，以授予或拒绝对 Azure Cosmos DB 资源的资源和操作的访问权限。
  • 有几个 内置 RBAC 角色 可用于角色分配，自定义 RBAC 角色 也可用于形成特定的 权限组合。
    • Cosmos DB 帐户读取器 允许对 Azure Cosmos DB 资源进行只读访问。
    • DocumentDB 帐户参与者 允许管理 Azure Cosmos DB 帐户，包括密钥和角色分配，但不启用数据平面访问。
    • Cosmos DB 操作员类似于 DocumentDB 帐户参与者，但无法管理密钥或角色分配。

• 可以使用 资源锁保护 azure Cosmos DB 资源 (帐户、数据库和容器) 免受错误修改或删除。

  • 可以在帐户、数据库或容器级别设置资源锁。
  • 在 资源上设置的资源锁将由所有子资源继承。 例如，在 Azure Cosmos DB 帐户上设置的资源锁将由帐户中的所有数据库和容器继承。
  • 资源锁 仅适用于 控制平面操作， 不会 阻止数据平面操作，例如创建、更改或删除数据。
  • 如果控制平面访问不受 限制， disableKeyBasedMetadataWriteAccess则客户端将能够使用帐户密钥执行控制平面操作。

• Azure Cosmos DB 更改源为 Azure Cosmos DB 容器中的数据提供按时间排序的更改源。

  • 更改源仅包括对源 Azure Cosmos DB 容器的插入和更新操作;它不包括删除。

• 更改源可用于维护与应用程序使用的主容器不同的数据存储，并持续更新源中源容器中的更改源提供的目标数据存储。

  • 更改源可用于填充辅助存储，以获取额外的数据平台冗余或后续分析方案。

• 如果删除操作经常影响源容器中的数据，则更改源馈送的存储将不准确且无法转换已删除的数据。

  • 可以实施 软删除 模式，以便数据记录包含在更改源中。
    • 数据记录不是显式删除数据记录，而是通过设置标志 (例如 IsDeleted) 来指示项目被视为已删除。
    • 更改源提供的任何目标数据存储都需要检测和处理已删除标志设置为 True 的项目;需要删除目标存储中的数据记录 的现有 版本，而不是存储软删除的数据记录。
  • 短生存时间 (TTL) 通常与软删除模式一起使用，以便 Azure Cosmos DB 自动删除过期的数据，但仅在更改源中反映数据后，且已删除的标志设置为 True。
    • 完成原始删除意向，同时通过更改源传播删除。

• 可将 Azure Cosmos DB 配置为 分析存储，该存储应用列格式进行优化分析查询，以解决传统 ETL 管道出现的复杂性和延迟挑战。

• Azure Cosmos DB 定期自动备份数据，不会影响性能或可用性，也不会影响 RU/秒。

• Azure Cosmos DB 可以根据两种不同的备份模式进行配置。

  • 定期 是所有帐户的默认备份模式，其中定期执行备份，并通过向支持团队创建请求来还原数据。
    • 默认的定期备份保留期为 8 小时，默认备份间隔为 4 小时，这意味着默认情况下仅存储最新的两个备份。
    • 备份间隔和保留期可在帐户中配置。
      • 最长保留期延长至一个月，最小备份间隔为一小时。
      • 需要为 Azure“Cosmos DB 帐户读取者角色”分配角色才能配置备份存储冗余。
    • 包含两个备份副本，不收取额外的费用，但额外的备份会产生额外的费用。
    • 默认情况下，定期备份存储在无法直接访问的单独 Geo-Redundant 存储 (GRS) 中。
      • 备份存储存在于主“中心”区域中，并通过基础存储复制复制到配对区域。
      • 基础备份存储帐户的冗余配置可配置为 区域冗余存储或 Locally-Redundant 存储。
    • 执行还原操作需要支持请求，因为客户无法直接执行还原。
      • 在开具支持票证之前，备份保留期应在数据丢失事件发生后 8 小时内至少增加到 7 天。
    • 还原操作会创建一个新的 Azure Cosmos DB 帐户，用于恢复数据。
      • 现有 Azure Cosmos DB 帐户不能用于还原
      • 默认情况下，将使用名为 <Azure_Cosmos_account_original_name>-restored<n> 的新 Azure Cosmos DB 帐户。
        • 可以调整此名称，例如，如果删除了原始帐户，则重用现有名称。
    • 如果在数据库级别预配吞吐量，则会在数据库级别进行备份和还原
      • 无法选择要还原的容器子集。
  • 连续 备份模式允许还原到过去 30 天内的任何时间点。
    • 可以执行还原操作以返回到特定时间点， (具有 1 秒粒度的 PITR) 。
    • 还原操作的可用时段最长为 30 天。
      • 还可以还原到资源实例化状态。
    • 连续备份是在存在 Azure Cosmos DB 帐户的每个 Azure 区域中进行的。
      • 连续备份存储在每个 Azure Cosmos DB 副本 (replica) 所在的同一 Azure 区域中，在支持可用性区域的区域中使用 Locally-Redundant 存储 (LRS) 或区域冗余存储 (ZRS) 。
    • 可以使用 Azure 门户 或 IaC 项目（如 ARM 模板）执行自助还原。
    • 连续备份有几个 限制 。
      • 连续备份模式目前在多区域写入配置中不可用。
      • 目前只能为连续备份配置 Azure Cosmos DB for NoSQL 和 Azure Cosmos DB for MongoDB。
      • 如果容器配置了 TTL，可能会立即删除超过其 TTL 的还原数据
    • 还原操作会为时间点还原创建新的 Azure Cosmos DB 帐户。
    • 连续备份和还原操作 需要额外的存储成本 。

• 现有的 Azure Cosmos DB 帐户可以从定期迁移到连续，但不能从连续迁移到定期;迁移是单向的，不可逆。

• 每个 Azure Cosmos DB 备份都由预配吞吐量、索引策略、部署区域 () 和容器 TTL 设置的数据本身和配置详细信息组成。

  • 备份不包含 防火墙设置、 虚拟网络访问控制列表、 专用终结点设置、一 致性设置 ， (使用会话一致性) 、 存储过程、 触发器、 UDF 或 多区域设置还原帐户。
    • 客户负责重新部署功能和配置设置。 这些不会通过 Azure Cosmos DB 备份还原。
  • Azure Synapse链接分析存储数据也不包含在 Azure Cosmos DB 备份中。

• 对于不适合定期和连续方法的情况，可以实现自定义备份和还原功能。

  • 自定义方法会产生大量成本和额外的管理开销，应理解并仔细评估这些开销。
    • 应对常见还原方案进行建模，例如数据项上的帐户、数据库、容器损坏或删除。
    • 应实施内部管理程序以防止备份蔓延。
  • 可以使用 Azure 存储或备用数据技术，例如备用 Azure Cosmos DB 容器。
    • Azure 存储和 Azure Cosmos DB 提供与 Azure 服务（例如Azure Functions和Azure 数据工厂）的本机集成。

• Azure Cosmos DB 文档表示用于实现自定义备份的两个可能选项。

  • Azure Cosmos DB 更改源 ，用于将数据写入单独的存储设施。
    • Azure 函数或等效的应用程序进程使用更改源处理器绑定到更改源，并将项处理到存储中。
  • 可以使用更改源实现连续或定期 (批处理) 自定义备份。
  • Azure Cosmos DB 更改源尚未反映删除，因此必须使用布尔属性和 TTL 应用软删除模式。
    • 当更改源提供完全保真更新时，不需要此模式。
  • Azure 数据工厂 Azure Cosmos DB (Azure Cosmos DB for NoSQL 或 MongoDB API 连接器) 复制数据。
    • Azure 数据工厂 (ADF) 支持手动执行和计划、翻转窗口和基于事件的触发器。
      • 提供对存储和事件网格的支持。
    • ADF 主要适用于定期自定义备份实现，因为它面向批处理的业务流程。
      • 由于业务流程执行开销，它不太适合具有频繁事件的连续备份实现。
    • ADF 支持Azure 专用链接高网络安全方案

Azure Cosmos DB 用于许多 Azure 服务的设计中，因此 Azure Cosmos DB 的重大区域中断将对该区域内的各种 Azure 服务产生级联效应。 对特定服务的精确影响将在很大程度上取决于基础服务设计如何使用 Azure Cosmos DB。

设计建议

Azure Cosmos DB

• 在要求允许的情况下，使用 Azure Cosmos DB 作为主数据平台。

• 对于任务关键型工作负载方案，请在每个部署区域中使用写入副本 (replica) 配置 Azure Cosmos DB，以减少延迟并提供最大冗余。

  • 配置应用程序以优先使用本地 Azure Cosmos DB 副本 (replica) 进行写入和读取，以优化应用程序负载、性能和区域 RU/秒消耗。
  • 多区域写入配置的成本很高，应仅针对需要最大可靠性的工作负载方案设置优先级。

• 对于不太重要的工作负载方案，在将可用性区域) 与全局分布式只读副本配合使用时，请优先使用单区域写入配置 (，因为这在更引人注目的价格点上提供高级别的数据平台可靠性 (99.999% SLA，对写入操作) 提供 99.999% SLA。

  • 将应用程序配置为使用本地 Azure Cosmos DB 读取副本 (replica) 来优化读取性能。

• 选择最佳“中心”部署区域，其中冲突解决将在多区域写入配置中发生，所有写入操作都将在单区域写入配置中执行。

  • 在选择主要区域时，请考虑相对于其他部署区域的距离和关联的延迟，以及可用性区域支持等必要功能。

• 在支持 AZ 的所有部署区域中 配置具有可用性区域 (AZ) 冗余 的 Azure Cosmos DB，以确保能够复原某个区域中的区域性故障。

• 使用 Azure Cosmos DB for NoSQL，因为它提供最全面的功能集，尤其是在性能优化方面。

  • 替代 API 应主要考虑用于迁移或兼容性方案。
    • 使用备用 API 时，请验证所选语言和 SDK 是否提供所需的功能，以确保最佳配置和性能。

• 使用直接连接模式通过与后端 Azure Cosmos DB 节点的直接 TCP 连接来优化网络性能，减少网络“跃点”数。

Azure Cosmos DB SLA 是通过平均失败请求来计算的，该请求可能与 99.999% 的可靠性层错误预算不直接一致。 因此，在针对 99.999% SLO 进行设计时，规划区域和多区域 Azure Cosmos DB 写入不可用至关重要，确保在发生故障时定位回退存储技术，例如用于后续重播的持久消息队列。

• 跨逻辑分区和物理分区定义分区策略，根据数据模型优化数据分布。

  • 最大限度地减少跨分区查询。
  • 以迭代方式 测试和验证 分区策略，以确保最佳性能。

• 选择最佳分区键。

  • 在集合中创建分区键后，无法更改分区键。
  • 分区键应该是不会更改的属性值。
  • 选择基数较高的分区键，其可能值范围很广。
  • 分区键应将 RU 消耗和数据存储均匀分布到所有逻辑分区，以确保在物理分区之间均匀分布 RU 消耗和存储分布。
  • 针对分区列运行读取查询，以减少 RU 消耗和延迟。

• 索引 对性能也至关重要，因此请确保使用索引排除来降低 RU/秒和存储要求。

  • 仅索引查询中筛选所需的字段;最常用的谓词的设计索引。

• 利用 Azure Cosmos DB SDK 的内置错误处理、重试和更广泛的可靠性功能。

  • 在客户端上的 SDK 中实现 重试逻辑 。

• 使用服务管理的加密密钥来降低管理复杂性。

  • 如果客户管理的密钥有特定的安全要求，请确保应用适当的密钥管理过程，例如备份和轮换。

• 通过应用内置Azure Policy禁用 Azure Cosmos DB 基于密钥的元数据写入访问。

• 启用 Azure Monitor 以收集关键指标和诊断日志，例如预配的吞吐量 (RU/秒) 。

  • 将 Azure Monitor 操作数据路由到专用于 Azure Cosmos DB 和应用程序设计中的其他全局资源的 Log Analytics 工作区。
  • 使用 Azure Monitor 指标来确定应用程序流量模式是否适合自动缩放。

• 评估应用程序流量模式，为 预配的吞吐量类型选择最佳选项。

  • 请考虑自动缩放预配的吞吐量，以自动调配工作负载需求。

• 评估 Azure Cosmos DB 的 Microsoft 性能提示 ，以优化客户端和服务器端配置，以改善延迟和吞吐量。

• 使用 AKS 作为计算平台时：对于查询密集型工作负载，请选择已启用加速网络的 AKS 节点 SKU，以减少延迟和 CPU 抖动。

• 对于单写入区域部署，强烈建议将 Azure Cosmos DB 配置为 自动故障转移。

• 通过在系统流中使用异步非阻塞消息传送进行负载级，从而将更新写入 Azure Cosmos DB。

  • 请考虑 命令和查询责任分离 和 事件溯源等模式。

• 为连续备份配置 Azure Cosmos DB 帐户，以获取过去 30 天内恢复点的精细粒度。

  • 在包含的数据或 Azure Cosmos DB 帐户被删除或损坏的情况下，请考虑使用 Azure Cosmos DB 备份。
  • 除非绝对必要，否则避免使用自定义备份方法。

• 强烈建议对非生产资源和数据执行恢复过程，作为标准业务连续性操作准备的一部分。

• 定义 IaC 项目以重新建立 Azure Cosmos DB 备份还原的配置设置和功能。

• 评估和应用 Azure Cosmos DB 备份和恢复 的 Azure 安全基线 控制指南。

  • BR-1：确保定期执行自动备份
  • BR-3：验证所有备份，包括客户管理的密钥
  • BR-4，降低丢失密钥的风险

• 对于需要多区域可用性的分析工作负载，请使用 Azure Cosmos DB 分析存储，该存储为优化的分析查询应用列格式。

关系数据技术

对于具有高度关系数据模型或依赖于现有关系技术的方案，在多区域写入配置中使用 Azure Cosmos DB 可能不直接适用。 在这种情况下，设计和配置使用的关系技术以支持应用程序设计的多区域主动-主动愿景至关重要。

Azure 提供了许多托管关系数据平台，包括 Azure SQL Database 和 Azure Database，用于常见的 OSS 关系解决方案，包括 MySQL、PostgreSQL 和 MariaDB。 因此，本部分中的设计注意事项和建议将侧重于优化Azure SQL数据库和 Azure 数据库 OSS 风格，以最大限度地提高可靠性和全局可用性。

设计注意事项

• 虽然可以将关系数据技术配置为轻松缩放读取操作，但写入通常受限于通过单个主实例，这会对可伸缩性和性能造成重大限制。

• 可以应用分片来跨多个相同的结构化数据库分配数据和处理，水平分区数据库以导航平台约束。

  • 例如，分片通常在多租户 SaaS 平台中应用，以将多组租户隔离到不同的数据平台构造中。

Azure SQL 数据库

• Azure SQL 数据库提供完全托管的数据库引擎，该引擎始终在最新稳定版本的 SQL Server 数据库引擎和基础操作系统上运行。

  • 提供智能功能，例如性能优化、威胁监视和漏洞评估。

• Azure SQL 数据库提供内置的区域高可用性和统包异地复制，以跨 Azure 区域分发只读副本。

  • 使用异地复制时，辅助数据库副本将保持只读状态，直到启动故障转移。
  • 相同或不同的区域最多支持四个辅助数据库。
  • 次要副本还可用于只读查询访问，以优化读取性能。
  • 故障转移必须手动启动，但可以包装在自动化操作过程中。

• Azure SQL Database 提供自动故障转移组，它将数据库复制到辅助服务器，并允许在发生故障时进行透明故障转移。

  • 自动故障转移组支持将组中所有的数据库异地复制到另一个区域中唯一的辅助服务器或实例。
  • “超大规模”服务层级当前不支持自动故障转移组。
  • 辅助数据库可用于卸载读取流量。

• 高级或业务关键服务层数据库副本可以跨可用性区域分布，无需额外付费。

  • 控制环也会跨多个区域复制，因为三个网关环 (GW) 。
    • 到特定网关环的路由受 Azure 流量管理器的控制。
  • 如果使用“业务关键”层级，则仅当选择 Gen5 计算硬件后，区域冗余配置才可用。

• Azure SQL Database 在其所有服务层级中提供 99.99% 的基线可用性 SLA，但在支持可用性区域的区域中，为业务关键或高级层提供更高的 99.995% SLA。

  • Azure SQL未为区域冗余部署配置的数据库业务关键或高级层的可用性 SLA 为 99.99%。

• 配置异地复制时，Azure SQL数据库业务关键层在部署的 100% 时间内提供 30 秒的恢复时间目标 (RTO) 。

• 配置异地复制时，Azure SQL数据库业务关键层的恢复点目标 (RPO) 为 5 秒，占部署小时数的 100%。

• Azure SQL数据库超大规模层，如果至少配置了两个副本，其可用性 SLA 为 99.99%。

• 可以使用预留折扣来降低与 Azure SQL 数据库关联的计算成本。

  • 无法为基于 DTU 的数据库应用保留容量。

• 时间点还原 可用于将数据库和包含的数据返回到较早的时间点。

• 异地还原 可用于从异地冗余备份恢复数据库。

Azure Database For PostgreSQL

• Azure Database For PostgreSQL 在三个不同的部署选项中提供：

  • 单一服务器，SLA 99.99%
  • 提供可用性区域冗余的灵活服务器，SLA 为 99.99%
  • 超大规模 (Citus) ，启用高可用性模式时 SLA 为 99.95%。

• 超大规模 (Citus) 通过分片提供动态可伸缩性，而无需更改应用程序。

  • 跨多个 PostgreSQL 服务器分布表行是确保超大规模 (Citus) 中可缩放查询的关键。
  • 多个节点可以共同保存比传统数据库更多的数据，在许多情况下，可以并行使用工作器 CPU 来优化成本。

• 可以通过 Runbook 自动化配置自动缩放，以确保响应不断变化的流量模式的弹性。

• 灵活服务器通过停止/启动服务器的能力，以及适用于不需要连续计算容量的工作负载的可突发计算层，为非生产工作负荷提供成本效益。

• 备份存储最多占预配服务器存储总量的 100%不收取额外费用。

  • 备份存储的额外消耗量根据消耗的 GB/月收费。

• 可以使用单服务器预留折扣或超大规模 (Citus) 预留折扣来降低与Azure Database for PostgreSQL相关的计算成本。

设计建议

• 考虑分片以根据不同的应用程序和数据上下文对关系数据库进行分区，有助于浏览平台约束、最大程度地提高可缩放性和可用性，以及实现故障隔离。

  • 当应用程序设计考虑三个或更多 Azure 区域时，此建议尤其普遍，因为关系技术约束可能会显著阻碍全球分布式数据平台。
  • 分片并非适用于所有应用方案，因此需要根据上下文进行评估。

• 由于 Azure SQL 数据库在 Azure 平台上很成熟以及具有大量的可靠性功能，因此需要满足关系要求时优先使用 Azure SQL 数据库。

Azure SQL 数据库

• 使用业务关键服务层最大程度地提高可靠性和可用性，包括对关键复原能力功能的访问权限。

• 使用基于 vCore 的消耗模型，便于根据工作负载量和吞吐量要求独立选择计算和存储资源。

  • 确保应用定义的容量模型来通知计算和存储资源要求。
    • 请考虑 使用预留容量 来提供潜在的成本优化。

• 配置 Zone-Redundant 部署模型，以跨可用性区域业务关键同一区域内分布数据库副本。

• 使用 活动异地复制 在所有部署区域中部署可读副本， (最多四个) 。

• 使用自动故障转移组提供到次要区域的 透明故障转移 ，应用异地复制以提供到其他部署区域的复制，以便进行读取优化和数据库冗余。

  • 对于仅限两个部署区域的应用方案，应优先使用自动故障转移组。

• 请考虑根据与应用程序运行状况模型保持一致的警报自动操作触发器，在故障影响自动故障转移组中的主实例和辅助实例时执行到异地复制实例的故障转移。

重要

对于考虑四个以上部署区域的应用程序，应认真考虑应用程序范围的分片或重构应用程序以支持多区域写入技术，例如 Azure Cosmos DB。 但是，如果这在应用程序工作负载方案中不可行，建议将单个地理位置中的区域提升为包含异地复制实例的主要状态，使其更均匀地分布读取访问权限。

• 将应用程序配置为查询副本实例以进行读取查询，从而优化读取性能。

• 使用 Azure Monitor 和 Azure SQL Analytics 在 Azure SQL DB 中获取准实时的操作见解，以检测可靠性事件。

• 使用 Azure Monitor 评估所有数据库的使用情况，以确定其大小是否合适。

  • 确保 CD 管道考虑在代表性负载水平下进行负载测试，以验证相应的数据平台行为。

• 计算数据库组件的运行状况指标，以观察与业务要求和资源利用率相关的运行状况，并在适当情况下使用 监视和警报 来推动自动化操作。

  • 确保合并关键查询性能指标，以便在服务降级时快速采取措施。

• 使用 Query Performance Insights 和 Microsoft 提供的常见 性能建议 优化查询、表和数据库。

• 使用 SDK 实现重试逻辑，以缓解影响Azure SQL数据库连接的暂时性错误。

• 在将服务器端透明数据加密 (TDE) 应用于静态加密时，优先使用服务管理的密钥。

  • 如果需要客户管理的密钥或客户端 (AlwaysEncrypted) 加密，请确保通过备份和自动轮换设施适当地复原密钥。

• 请考虑使用 时间点还原 作为操作 playbook，以从严重的配置错误中恢复。

Azure Database For PostgreSQL

• 建议灵活服务器将其用于业务关键型工作负荷，因为它支持可用性区域。

• 为业务关键型工作负荷使用超大规模 (Citus) 时，启用高可用性模式以接收 99.95% SLA 保证。

• 使用 超大规模 (Citus) 服务器配置，以最大化跨多个节点的可用性。

• 为应用程序定义容量模型，以告知数据平台中的计算和存储资源要求。

  • 请考虑 使用超大规模 (Citus) 预留折扣 ，以提供潜在的成本优化。

缓存热层数据

可以通过显著增加读取吞吐量和改善热层数据方案的端到端客户端响应时间，应用内存中缓存层来增强数据平台。

Azure 提供了多个具有缓存关键数据结构的适用功能的服务，Azure Cache for Redis用于抽象和优化数据平台读取访问。 因此，本部分将重点介绍在需要其他读取性能和数据访问持久性的情况下，Azure Cache for Redis的最佳使用。

设计注意事项

• 缓存层提供额外的数据访问持久性，因为即使中断影响基础数据技术，仍可通过缓存层访问应用程序数据快照。

• 在某些工作负荷方案中，内存中缓存可以在应用程序平台本身内实现。

用于 Redis 的 Azure 缓存

• Redis 缓存是一种开放源代码 NoSQL 键值内存中存储系统。

• 企业和企业闪存层可以通过异地复制跨区域和不同 Azure 区域中的可用性区域以主动-主动配置进行部署。

  • 如果部署在至少三个 Azure 区域以及每个区域中的三个或更多可用性区域中，并且为所有缓存实例启用活动异地复制，Azure Cache for Redis为连接到一个区域缓存终结点提供 99.999% 的 SLA。
  • 在单个 Azure 区域中跨三个可用性区域进行部署时，将提供 99.99% 的连接 SLA。

• 企业闪存层在 RAM 和闪存非易失性内存存储的组合上运行，尽管这会带来较小的性能损失，但它也支持非常大的缓存大小，高达 13TB，聚类分析。

• 使用异地复制时，除了与缓存实例相关的直接成本外，区域之间的数据传输费用也将适用。

• 计划汇报功能不包括 Azure 更新或应用于基础 VM 操作系统的更新。

• 将数据迁移到新实例时，在横向扩展操作期间，CPU 使用率将会增加。

设计建议

• 考虑为“热”数据方案优化缓存层，以提高读取吞吐量并缩短响应时间。

• 对缓存到期和保养工作应用适当的策略，以避免数据增长失控。

  • 考虑在支持数据更改时使缓存项过期。

用于 Redis 的 Azure 缓存

• 使用高级或企业 SKU 可最大程度地提高可靠性和性能。

  • 对于数据量非常大的方案，应考虑 Enterprise Flash 层。
  • 对于只需要被动异地复制的方案，也可以考虑 Premium 层。

• 在所有考虑的部署区域中，在活动配置中使用异地复制部署副本实例。

• 确保副本 (replica) 实例在每个考虑的 Azure 区域中跨可用性区域部署。

• 使用 Azure Monitor 评估Azure Cache for Redis。

  • 计算区域缓存组件的运行状况分数，以观察相对于业务需求和资源利用率的运行状况。
  • 观察关键指标（例如 CPU 使用率高、内存使用率高、服务器负载高和已逐出密钥）并发出警报，以获取何时缩放缓存的见解。

• 通过实现重试逻辑、超时和使用 Redis 连接多路复用器的单一实例实现来优化连接 复原能力 。

• 配置 计划的更新 ，以规定将 Redis 服务器更新应用于缓存的日期和时间。

分析方案

对于任务关键型应用程序来说，将分析方案视为从包含的数据流中驱动附加价值的一种手段越来越常见。 因此，应用程序和运营 (AIOps) 分析方案构成了高度可靠的数据平台的关键方面。

分析和事务工作负载需要不同的数据平台功能和优化，以便在各自的上下文中实现可接受的性能。

说明	分析	事务性
用例	分析大量数据 (“大数据”)	处理大量单个事务
优化对象	读取多个记录的查询和聚合	近实时创建/读取/更新/删除 (CRUD) 对少量记录的查询
主要特征	- 从记录的数据源合并 - 基于列的存储 - 分布式存储 - 并行处理 - 非规范化 - 低并发读取和写入 - 通过压缩优化存储卷	- 应用程序的记录数据源 - 基于行的存储 - 连续存储 - 对称处理 -规范化 - 高并发读取和写入、索引更新 - 使用内存中存储优化快速数据访问

Azure Synapse 提供了一个企业分析平台，该平台使用与 Azure 服务（如 Azure Cosmos DB）的内置集成，将关系数据和非关系数据与 Spark 技术结合在一起，以促进大数据分析。 因此，本部分中的设计注意事项和建议将重点介绍分析方案的最佳Azure Synapse和 Azure Cosmos DB 使用情况。

设计注意事项

• 传统上，可以通过将数据提取到针对后续分析查询进行了优化的单独数据平台来简化大规模分析方案。
  • 提取、转换和加载 (ETL) 管道用于提取数据将消耗吞吐量并影响事务工作负荷性能。
  • 不经常运行 ETL 管道以减少吞吐量和性能影响，将导致分析数据不太最新。
  • 随着数据转换变得更加复杂，ETL 管道开发和维护开销也随之增加。
    • 例如，如果源数据经常更改或删除，ETL 管道必须通过附加/版本控制方法、转储和重新加载或就地更改分析数据来考虑分析查询的目标数据中的这些更改。 其中每种方法都会产生派生影响，例如重新创建或更新索引。

Azure Cosmos DB

• 在 Azure Cosmos DB 事务数据上运行的分析查询通常会跨分区聚合大量数据，消耗大量请求单位 (RU) 吞吐量，这可能会影响周围事务工作负载的性能。

• Azure Cosmos DB 分析存储提供架构化、完全隔离的面向列的数据存储，可在Azure Synapse对 Azure Cosmos DB 数据进行大规模分析，而不会影响 Azure Cosmos DB 事务工作负载。

  • 将 Azure Cosmos DB 容器启用为分析存储时，将从容器中的操作数据内部创建新的列存储。 此列存储与容器的面向行的事务存储分开保存。
  • 对操作数据的创建、更新和删除操作会自动同步到分析存储，因此无需更改源或 ETL 处理。
  • 从操作到分析存储的数据同步不会消耗吞吐量请求单位 (在容器或数据库上预配) RU。 对事务工作负荷没有性能影响。 分析存储不需要在 Azure Cosmos DB 数据库或容器上分配其他 RU。
  • 自动同步是操作数据更改自动同步到分析存储的过程。 自动同步延迟通常小于 2 (2) 分钟。
    • 对于具有共享吞吐量和大量容器的数据库，自动同步延迟最多可为 5 (5) 分钟。
    • 自动同步完成后，即可从Azure Synapse查询最新数据。
  • 分析存储存储使用基于消耗的 定价模型 ，该模型对数据量和读取和写入操作数收费。 分析存储定价独立于事务存储定价。

• 使用 Azure Synapse Link，可以直接从Azure Synapse查询 Azure Cosmos DB 分析存储。 这支持从 Synapse (HTAP) 的非 ETL 混合 Transactional-Analytical 处理，以便可以近乎实时地从 Synapse 查询 Azure Cosmos DB 数据和其他分析工作负载。

• 默认情况下，Azure Cosmos DB 分析存储不会分区。

  • 对于某些查询方案，通过使用查询谓词中经常使用的键 对分析存储数据进行分区 来提高性能。
  • 分区由 Azure Synapse 中的作业触发，该作业使用 Synapse Link 运行 Spark 笔记本，该作业从 Azure Cosmos DB 分析存储加载数据并将其写入 Synapse 工作区的主存储帐户中的 Synapse 分区存储。

• Azure Synapse Analytics SQL 无服务器池可以通过自动更新的视图或SELECT / OPENROWSET命令来查询分析存储。

• Azure Synapse Analytics Spark 池可以通过自动更新的 Spark 表或 spark.read 命令来查询分析存储。

• 还可以使用 Spark 将数据从 Azure Cosmos DB 分析存储复制到专用 Synapse SQL 池，以便可以使用预配Azure Synapse SQL 池资源。

• 可以使用 Azure Synapse Spark 查询 Azure Cosmos DB 分析存储数据。

  • Spark 笔记本允许 Spark 数据帧 组合与其他数据集聚合和转换 Azure Cosmos DB 分析数据，并使用其他高级 Synapse Spark 功能，包括将转换的数据写入其他存储或训练 AIOps 机器学习模型。

• Azure Cosmos DB 更改源还可用于维护分析方案的单独辅助数据存储。

Azure Synapse

• Azure Synapse将分析功能（包括 SQL 数据仓库、Spark 大数据以及用于日志和时序分析的数据资源管理器）汇集在一起。

  • Azure Synapse使用链接服务来定义与其他服务（如 Azure 存储）的连接。
  • 可以通过从受支持的源复制活动将数据引入到 Synapse Analytics 中。 这允许在 Synapse 中执行数据分析，而不会影响源数据存储，但会增加数据传输造成的时间、成本和延迟开销。
  • 还可以在受支持的外部存储中就地查询数据，从而避免数据引入和移动的开销。 使用 Data Lake Gen2 的 Azure 存储是 Synapse 支持的存储， Log Analytics 导出的数据可以通过 Synapse Spark 进行查询。

• Azure Synapse Studio 将引入和查询任务结合在一起。

  • 查询和处理源数据（包括 Azure Cosmos DB 分析存储数据和 Log Analytics 导出数据），以支持商业智能和其他聚合分析用例。

设计建议

• 确保分析性工作负载不影响事务性应用程序工作负载，从而维持事务性性能。

应用程序分析

• 将 Azure Synapse Link 与 Azure Cosmos DB 分析存储配合使用，通过创建不会影响事务性能的优化数据存储，对 Azure Cosmos DB 操作数据执行分析。

  • 在 Azure Cosmos DB 帐户上启用Azure Synapse链接。
  • 创建为分析存储启用的容器，或 为分析存储启用现有的容器。
  • 将 Azure Synapse 工作区连接到 Azure Cosmos DB 分析存储，使 Azure Synapse 中的分析工作负载能够查询 Azure Cosmos DB 数据。 使用具有只读 Azure Cosmos DB 密钥的连接字符串。

• 使用 Azure Synapse Link 确定 Azure Cosmos DB 分析存储的优先级，而不是使用 Azure Cosmos DB 更改源来维护分析数据存储。

  • Azure Cosmos DB 更改源可能适用于非常简单的分析方案。

AIOps 和操作分析

• 为每个源 Azure 存储帐户创建一个Azure Synapse工作区，其中包含来自资源的操作数据发送到其中的链接服务和数据集。

• 创建专用 Azure 存储帐户，并将其用作工作区主存储帐户来存储 Synapse 工作区目录数据和元数据。 使用分层命名空间对其进行配置，以启用 Azure Data Lake Gen2。

  • 在源分析数据与 Synapse 工作区数据和元数据之间保持分离。
    • 请勿使用在其中发送操作数据的区域或全局 Azure 存储帐户之一。

后续步骤

查看网络注意事项。

网络和连接性