你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上 AI 工作负载的数据平台
数据平台是一组集成的技术，旨在通过引入源数据，然后筛选、聚合和准备供使用来管理工作负荷要求。
数据具有基于其预期用途的不同特征。 强烈建议先了解良好的数据管道设计原则，然后再浏览本文介绍的技术功能。 有关详细信息，请参阅训练数据设计和地面数据设计。
当数据在管道中的特定点休息时，该平台还满足存储需求。 如果工作负荷很复杂，并处理大规模数据，则可以在各种组件之间分配管道任务。 对于更简单的用例，评估是否可以在提供这些组合功能的存储中使用源数据。
询问以下问题，以便避免为数据平台设计过于复杂的体系结构。 最好在可以的时候保持简单。
- 应用程序能否通过从单个源引入数据来获得预期的预测能力？
- 你最初选择的数据存储是否支持数据仓库功能？
- 源数据是否已针对 AI 搜索进行优化？
如果回答了这些问题，则可以通过允许应用程序直接访问数据源来简化体系结构。 此方法消除了大数据体系结构组件（如数据引入、分析存储集成和外部数据处理）的需求。 如果源数据库可以处理所需的搜索，则直接将搜索索引功能集成到源数据库中可能是一种实际方法。 确保源可以经济高效地缩放以满足新的需求。
例如，Azure Cosmos DB 支持矢量搜索，因此可能不需要其他索引。 另一个用例是使用只读副本作为搜索操作的终结点。 对于具有只读副本的 SQL 数据库，直接搜索这些副本可以优化性能。 充分利用数据库的内置功能，尽可能简化体系结构。
适用于大规模工作负荷的数据平台体系结构更为复杂。
从多个数据源引入数据以及跨各种平台协调搜索可能会变得复杂且效率低下。 此外，仍需要一些提取、转换和加载（ETL）：提取、加载和转换（ELT）：或提取和加载 （EL） 进程以重塑数据存储中的数据。 由于数据需要处理更多，因此方案变得更加复杂。 需要将许多组件添加到体系结构，以处理从引入到服务查询的端到端管道。 许多大数据技术是高度专业化的，旨在有效地处理这些处理任务。
其中一种技术是搜索索引。 添加单独的索引的主要优点是能够有效地管理查询并处理吞吐量较高的大量数据。 此函数从原始数据源中卸载 AI 功能，以便索引可以专注于其主函数，提供查询。
根据平台的特定功能和用途选择平台，并考虑你的功能和技术要求。 如果体系结构不断发展以处理复杂的用例，请关注以下有关聚合数据存储、处理管道和搜索索引的部分。
建议
下面是本文中提供的建议摘要。
| 建议 | 说明 |
|---|---|
| 构建安全、高性能且经济高效的数据存储。 | 数据平台的关键部分是一种数据存储，用于聚合来自多个源的数据，并允许与各种集成任务集成。 这有助于工作负荷大规模执行。 请务必查看数据存储的各种功能和非功能要求，以确保经济高效的部署。 ▪ 存储聚合数据的注意事项 |
| 遵循有关数据引入和处理的最佳做法。 | 高质量数据有助于提高工作负荷和最终用户体验的可靠性。 考虑工作负荷的要求以及构建高效引入和数据转换过程的关键最佳做法，以帮助维护高质量的条形图。 ▪ 处理数据的注意事项 |
| 设计可靠且相关的搜索索引。 | 旨在实现高性能的一次性读取多数据存储，可有效处理即兴查询和模糊查询，将相关结果传送到用户群，即使查询不精确也是如此。 ▪ 搜索索引的注意事项 |
| 确保功能数据存储大规模执行。 | 根据工作负荷的功能要求，可能需要创建功能数据存储，例如脱机推理。 请务必考虑到指定函数创建数据存储，并应用函数的最佳做法。 ▪ 功能存储的注意事项 ▪ 脱机推理数据存储的注意事项 |
存储聚合数据的注意事项
在 AI 工作负载中，数据在管道的帮助下，在存储的各个阶段和处理阶段进行移动。 一个关键阶段是包含从多个源引入和聚合的数据的数据存储。 需要此存储来执行处理，直到数据达到适合训练或索引的状态。 主要重点是确保数据准确反映其源。
注意
另一种方法是直接访问数据源。 但是，此方法可能会导致性能问题，因为它可能会用 AI 功能重载源系统。 也可能存在数据访问问题。 为了避免这些问题，我们建议将数据复制到此存储。
此存储的数据平台应符合数据源适用的安全标准，经济高效，并支持与 ETL、ELT 和 EL 处理任务的集成。 选项因基本存储与大数据技术而异，具体取决于数据量。 选择经济存储，帮助你实现足够的可靠性和性能。
以下部分提供有关选择数据存储技术时要考虑的功能的指导。 有关详细信息，请参阅 数据处理管道。
功能要求
平台是否可以处理各种数据格式？
数据存储应能够存储各种数据格式，并在必要时将其转换为其他格式。
假设引入管道从关系数据库和 Parquet 文件源数据，因此它支持结构化和半结构化数据。 你想要根据关系数据架构定义将关系数据转换为 Parquet 格式。 数据平台应具有内置功能，无需编写自定义代码即可执行该转换。
是否希望存储多个版本的数据？
数据值和架构可能会随时间而变化，并且管理多个版本的数据变得非常重要。
源系统通常仅存储当前数据，而不是历史数据。 如果保留历史数据很重要，可能需要从源系统复制大型数据集。 在这种情况下，版本控制可以消除当前数据与历史数据中的歧义。
在某些情况下，可能需要维护不同用例的数据副本。 若要支持此方案，可能需要创建分叉数据。 每个分支可以独立改变，以提高其质量和可用性。 数据平台应能够维护这些分支的正确版本控制。
数据平台应能够随时间推移存储数据版本以提供历史上下文。 此 contetxt 有利于处理和训练 AI 模型，因为它提供多个观察，而不仅仅是单个时间点。
平台是否具有内置数据生命周期管理功能？
数据生命周期管理（DLM）是一个管理数据从创建到删除的过程，其中包含数据收集、存储、使用情况、存档和处置等阶段。
如果没有 DLM，数据可能会不受控制地增长，这通常会导致在质量层中移动时产生多个副本。 数据平台应具有 DLM 功能，以防止未绑定的数据增长。
请考虑此方案。 预处理步骤需要重复以优化数据，直到达到可接受的训练质量。 数据平台应能够删除数据的中间副本。
在某些情况下，可能需要保留数据进行监管审核。 数据平台应具有不经常访问的数据的冷存储功能，以便可以降低成本对其进行存档。
平台是否支持数据管理功能？
可审核性是 AI 工作负载的重要方面。 数据存储应维护可跟踪数据访问、确保隐私和了解数据源的审核线索。
使用数据字典功能可以管理元数据、数据类型、用途和世系。 当从多个源引入数据时，此功能尤其重要。
是否打算使用生产数据进行训练？
部署、模型部署和代码部署有两种方法。 在模型部署中，生产数据用于开发，这需要严格的安全措施。 在代码部署中，模型在生产之前看不到生产数据。 尽管代码部署简化了开发环境中的安全问题，但它会增加计算成本。 无论选择哪种方法，数据平台都应支持单独的开发和生产环境。
是否将便利功能优先于关键功能功能？
选择用于 AI 或机器学习的数据平台时，不要只依赖于其笔记本功能。 尽管笔记本对于探索数据分析很有用，但它们不应是决定因素。 笔记本的计算资源通常不在聚合数据存储的范围之外。 它们通常与其他资源（例如Azure 机器学习）集成。
非功能需求
预期存储的数据量是多少？
AI 工作负载会生成大量数据。 由于多个版本和额外的元数据，卷可能会显著增加。
存储和吞吐量的可伸缩性非常重要。 数据平台在处理数据卷、管理并发写入时，必须有效地使用引入管道中的数据，并确保单个写入性能不会降低。 这些条件也适用于读取、处理甚至写回存储的处理管道。
做出决策时，请考虑整个过程，因为引入和处理经常同时发生。 设计必须能够管理频繁的数据移动和处理。 数据平台应提供高级别的并行度来有效处理数据。
平台技术应发出遥测数据，以便深入了解读取和写入操作的吞吐量和性能。
此数据存储是否是导致工作负荷可靠性目标的关键组件？
选择使用多个实例增强可靠性和可伸缩性的数据存储。 大数据存储通常具有一个内置控制器，用于跨实例协调数据处理。 如果一个副本失败，则可以使用另一个副本。
请记住，如果数据不正确或可访问，则不会达到其目的。 数据平台应保证持久性，并确保数据保持不变。 确保查询数据的 API 可访问。 此外，请考虑具有备份功能的数据存储。
通常，无需备份此数据。 但是，如果每次从头开始聚合数据的成本显著高，则可以考虑从备份中解除数据冻结。
是否有任何成本限制？
如果数据可靠性和性能足够，请考虑成本影响。
系统应针对写入进行 优化一次，读取许多 内容以避免在数据存储上超支。 训练或地面数据很重要，但不像生产数据库那样至关重要，这需要即时响应能力。 重点是将成本与效率相平衡，以最大限度地实现投资回报。
上述要求可能会自然导致你考虑使用 Data Lake，因为它提供 DLM、质量层、可观测性和对各种文件格式的支持。 如果工作负荷已使用 Data Lake，请利用该资源来满足 AI 需求。 或者，可以选择其他存储选项，例如Azure Blob 存储，提供某种级别的 DLM、监视功能和高事务速率。
处理数据的注意事项
必须处理聚合数据存储中的数据，才能在下游增加其实用工具。 ETL 管道执行此任务，这在以下几点最为重要：
引入层
管道负责从各种源收集数据并将其移动到聚合数据存储。 在此过程中，管道通常执行基本预处理，甚至可能以可查询格式构建数据。
为了最大程度地减少对自定义代码的需求，我们建议将大部分责任卸载到数据平台。 选择技术时，请考虑支持模型训练和扩充所需的 ETL 特征。
处理层
聚合数据存储中的数据经过大量处理，然后才能用于索引或模型训练用例。 处理管道需要与引入管道类似的可靠性和缩放级别。 主要区别在于对数据执行的处理类型。
此过程涉及对数据进行重大重新复制和重组。 此过程包括实体识别、将其他数据集成到数据集以及执行查找等任务。 此过程可能包括删除不必要的数据并通过数据业务流程平台应用数据逻辑。
数据处理阶段可以生成各种输出，这些输出位于不同意向的不同目标中。 其主要目标是准备和传输来自聚合数据存储的数据，以供最终目标使用。 使用者可以在需要时拉取数据，或者处理层可以在数据准备就绪时推送数据。
注意
在机器学习和生成 AI 的背景下，区分 ETL、ELT 和 EL 过程非常重要。 传统的 ETL 对于数据仓库和对象关系映射至关重要，因为由于架构限制，必须在将数据加载到目标系统之前对其进行转换。 ELT 涉及提取数据、将其加载到数据湖中，然后使用 Python 或 PySpark 等工具对其进行转换。 在生成 AI 中，尤其是用于检索扩充生成（RAG），该过程通常涉及先提取和加载文档到存储，然后是分块或图像提取等转换。
以下部分提供了在选择具有 ETL 功能的数据处理技术时要考虑的指导。
功能要求
对连接到数据源的支持是什么？
需要处理的数据可能存储在关系数据库、大数据源或各种存储解决方案中。
大多数数据处理技术都支持预生成的集成，让你无需编写代码即可连接到各种数据源。 连接器具有从源复制到接收器、执行查找并应用某种形式的数据治理等功能。 有一些工具提供拖放功能，以避免不必要的编码。
选择一个数据平台，以便轻松与预期的数据源集成。
平台是否可以处理各种数据格式？
数据可能采用各种格式，例如数据库和 JSON 等结构化数据、图像和文档等非结构化数据，或者从物联网设备流式传输数据。 管道应能够处理预期的文件类型。
平台是否提供数据准备和重新复制的功能？
必须处理要用于训练或扩充的数据，直到它适合训练、微调或索引。 数据设计策略应明确概述要求。
以下文章介绍了具体注意事项：
作为基本清理的一部分，平台会删除重复项、填充缺失值，并在引入期间消除多余的噪音。 对于某些用例（例如实现 RAG 模式），建议使用小写区块。
尽管这些预处理步骤是必需的，但平台还必须支持特定于你的需求的丰富数据操作。 此过程涉及加载、重新复制和转换数据。 对于某些模型，平台必须能够查询外部源进行文档分析，例如文档智能或其他 AI 工具。 准备数据和数据扩充需要完成这项工作。
如果数据存储支持此级别的处理，则可以在存储中本地化此阶段，而无需将其移到其他位置。 否则，需要一种外部技术，例如 Azure Databricks 或 Azure 数据工厂。 这些技术适用于移动数据和执行操作，例如筛选、填充缺失值和标准化字符串大小写。 对于更复杂的任务，通常需要作业托管平台。 可以将 Spark 池用于大数据业务流程。
在某些用例中，你可能希望将此责任外部化给数据的使用者。 例如，使用机器学习的 AI 模型提供作业处理功能，可使用自定义 Python 代码读取、操作和写入数据。
另一个示例是 RAG 实现。 常见的处理步骤是分块，其中文档分为多个区块，每个区块成为索引中的一行。 它还存储 OpenAI 服务通常为这些区块生成的嵌入内容。 在 AI 搜索中，此过程是在索引工作流中安排的，无论是使用 OpenAI 还是 Azure AI 搜索。
是否有用于管理工作流的内置业务流程协调程序？
处理任务是模块化的，以作业的形式运行。 平台应具有业务流程功能，可将工作流分解为步骤或作业。 应独立定义、运行和监视每个作业。
在复杂的工作流中，某些步骤取决于先前步骤的成功完成。 业务流程协调程序应处理作业依赖项，并确保任务按正确的顺序完成。
数据设计是一个迭代过程，因此业务流程协调程序工具应足够灵活，可以轻松修改工作流。 应能够注入新步骤或调整现有步骤，而无需重写大部分代码。
数据工厂是一种常用的选择，因为它提供了用于管理数据工作流的丰富功能集。 Azure Databricks 还可以管理复杂的工作流和计划和监视作业。 还应考虑成本影响。 例如，Azure Databricks 功能可能非常广泛，但它们也成本高昂。 开源替代选项（如 Apache NiFi）可能更具成本效益。
最终，你选择的工具取决于组织允许的内容以及工作负荷团队熟悉的技能。
非功能需求
选择处理管道时，平衡吞吐量和可观测性至关重要。 管道必须在足够时间内可靠地处理和降落模型或索引所需的数据。 它应该足够轻量，足以支持当前需求，并且可缩放以供将来增长。 团队必须决定他们需要多少才能证明平台的未来，以避免以后的技术债务。 关键注意事项包括数据引入的频率和量、过程的可靠性，以及需要及时监视和解决问题。
预期引入的数据量是多少？
对于引入和处理阶段，请考虑平台的可伸缩性和处理任务的速度。 例如，预期每天将 10 TB 的数据加载到索引或模型训练中。 数据引入平台应能够处理大量卷以及预期的吞吐量。 在这种情况下，使用Azure 逻辑应用可能不可行，因为它可能在此类负载下失败。 相反，数据工厂更适合这种数据处理规模。
处理大容量的一种方法是通过并行处理，因为它允许更高效的数据处理和处理。 Azure Databricks 等平台可以通过为同一作业创建多个实例并高效分发负载来协调任务。
此外，请考虑可容忍的延迟和作业的复杂性。 例如，数据清理涉及验证并可能替换无效字段或屏蔽敏感信息。 尽管这些任务很基本，但需要大量资源，因为每一行单独处理，这会增加总时间。
需要哪些监视功能？
数据处理管道应具有监视功能，并提供有关管道的作业性能和状态的见解。
必须能够跟踪作业的进度。 假设管道运行未完成或部分完成的数据清理作业。 可能会对训练模型的数据质量产生下游影响，这可能会影响预测能力。
与工作负荷中的其他组件类似，应启用数据管道上的日志、指标和警报，以了解其行为。 收集和分析性能指标，以了解效率和可靠性方面。
确定内置遥测中的任何差距，并确定需要实现的其他监视。 此监视可能涉及添加自定义日志记录或指标来捕获有关作业步骤的特定详细信息。
数据处理平台需要多少可靠性？
数据处理管道的可靠性因平台选择而异。 尽管逻辑应用具有业务流程功能，但它可能不如数据工厂那么可靠。 数据工厂托管在 Azure Kubernetes 服务 （AKS） 群集上，可能具有不同的可靠性特征。
单实例设置被视为故障点。 选择支持可靠性功能的平台，例如多个实例，以满足你的要求。
平台还应支持复原功能。 例如，业务流程协调程序应自动重试失败的任务，从而减少手动重启的需求。
批处理比推理更可靠，具体取决于数据新鲜度和延迟要求。 如果每周进行训练，并且处理需要一天时间，则偶尔会失败，因为有足够的时间来重试。
是否有任何成本限制？
考虑数据处理管道的成本效益时，请务必选择满足需求的解决方案，而无需不必要的费用。 如果要求不证明 Azure Databricks 的高级功能是正当的，那么数据工厂等更经济的选择可能就足够了。 此外，开源工具（如 Apache Airflow 或 Apache NiFi）可以降低成本提供可靠的功能。 关键是避免对不需要的功能超支，并选择平衡功能和成本效益的平台。
对工作流和处理的数据有哪些安全要求？
明确安全、隐私和数据驻留要求。 例如，考虑任何地理法规要求。 确保在特定区域中存储和处理数据，从而符合数据驻留要求。 可能需要为不同区域（例如欧洲运行管道）运行单独的管道，另一个管道用于美国，以满足当地合规性法规。
数据管道平台应支持标识和访问管理，以确保只有经过授权的标识才能访问工作流中的特定作业或步骤。 例如，如果 ETL 进程由多个工作流组成，并且其中一个工作流处理高度机密的数据，则平台应允许你限制对该工作流的访问，同时使其他人能够访问。 此功能可帮助你满足安全要求，而无需为不同的数据敏感度级别提供单独的平台。 理想情况下，平台应为这种隔离提供内置支持，从而实现高效且安全的数据管理。
数据处理管道可以将数据输出到搜索索引或模型训练管道。 根据用例，请参阅有关搜索索引或功能存储的部分。
搜索索引的注意事项
搜索索引旨在存储上下文数据或地面数据，以发送到模型推理终结点以及提示。 调用（索引查询和推理终结点调用）在为同一客户端 HTTP 请求提供服务的上下文中发生。 与处理脱机作业和批处理作业的 ETL 进程不同，此索引支持实时推理，这需要高性能和可靠性。 它专用于 AI 查询，并提供关键字索引和筛选等功能，这些功能并非大数据存储的典型功能。 目标是拥有高性能、 一次写入、读取多 的数据存储，该数据存储支持即兴查询和模糊查询。 此数据存储可以提供相关的结果，而无需精确的查询。
功能要求
搜索索引支持哪些类型的搜索？
系统接收的查询本质上是搜索，索引需要支持丰富的搜索功能。 对于 RAG，矢量搜索不可协商，因为数据存储为计算向量或嵌入，用于搜索。
矢量搜索功能强大，将其与筛选相结合，全文搜索可增强搜索索引的有效性。 数据设计应考虑合并这些类型的搜索，例如矢量、全文搜索、筛选和特殊数据类型（如地理位置）。
数据设计应明确说明这些要求。 有关详细信息，请参阅 数据设计中的高效查询。
索引是否支持多模式数据？
选择支持多模式数据的索引技术。 例如，AI 搜索可以分析电子邮件，将图像转换为矢量，并将说明存储在索引中。 使用此函数可以跨各种内容形式（包括图像、视频和音频文件）进行搜索。
当数据源中的数据发生更改时，索引是否支持自动更新功能？
选择具有自动更新功能的索引。 如果不可用，则需要手动检测更改并将其推送到索引。 借助这些功能，索引器可以检测数据源中的更改并自动拉取更新。 通过将此责任卸载到平台，可以降低运营开销并简化维护过程。
非功能需求
索引是否可以使用大量数据执行？
索引应能够处理大量数据、可缩放，并针对大量搜索工作负荷执行良好性能。 索引存储原始数据和与之关联的所有元数据、扩充和实体。 在 RAG 模式的上下文中，拆分为多个区块的单个文档可能会导致数据量显著增加。
索引是否具有内置可靠性功能？
考虑推理终结点或模型的可靠性与数据存储之间的对齐方式，因为它们相互依赖。
搜索过程涉及两个步骤：查询数据存储，然后查询推理终结点。 这两个步骤都需要具有类似的可靠性特征。 平衡这两个组件之间的可靠性目标，以确保搜索有效性。
为了确保复原能力，工作负荷应支持预期数量的并发用户，并有足够的带宽来处理流量激增。 理想情况下，平台应能够在区域性中断中幸存下来。
数据平台应设计为防止使用损坏的索引进行推理。 在这种情况下，应能够轻松重新生成索引。 索引还应使用别名等功能在索引之间支持可靠的交换，以最大程度地减少索引交换期间的停机时间。 如果没有此功能，可能需要依赖索引的备份。 管理备份具有更复杂的功能。
从工作负荷的角度来看，了解潜在的故障模式或压力指标，例如限制。 例如，尽管系统通常可能支持 50 个并发用户，但在作为后台作业运行的重新编制索引过程中，它可能仅支持 30 个用户。 在这种情况下，后台作业的时间变得很重要。 评估索引的吞吐量时，包括前端查询和后端作业。
这项技术的主要成本驱动因素是什么？
建模成本时，估算与数据量、查询数和索引的预期吞吐量相关的费用。 请记住，索引主要是平台即服务（PaaS），其中定价是抽象的。 研究层及其功能，以避免过度支付未使用的容量或功能。
例如，AI 搜索按单位计费，其中包括容量、吞吐量和存储。 额外的功能可能会导致更多费用。 例如，大量使用图像提取功能可能会导致费用过高。 依赖项（如技能集功能）不在索引范围之外，但属于数据处理的一部分可能会产生额外的成本。
在不使用完整容量的情况下支付层费用可能会导致超额支付。 同样，索引中的表数以及处理并发流量的能力会影响成本。
若要了解与 AI 搜索相关的成本，请参阅规划和管理 AI 搜索服务的成本。
索引的安全功能是否满足安全数据设计？
数据设计应明确指定安全和隐私要求。 在使用实际生产数据的开发和测试环境中，索引应支持符合所有访问控制和可跟踪性措施的功能。 查看安全功能，例如数据掩码和删除索引中的个人信息。
选择能够通过Microsoft Entra ID 唯一标识客户端的索引。 搜索索引还应支持文档级访问控制，以允许按标识查询相关性。 如果索引不提供这些功能，请调整设计，以便通过查询筛选器实现类似的功能。 有关详细信息，请参阅 用于在 AI 搜索中修整结果的安全筛选器。
理想情况下，搜索索引应符合网络安全要求。 例如，如果需要筛选流出流量到非Microsoft站点并保持可观测性，索引应提供出口控制。 它还应支持网络分段。 如果后端计算位于虚拟网络中，则密钥组件的专用连接（包括索引）对于避免公开公共 Internet 至关重要。 索引应与专用网络轻松集成，并支持通过 Microsoft Entra ID 进行身份验证的托管标识。
功能存储的注意事项
对于歧视模型，数据设计可能包括一个中间数据存储，用于缓存数据以便进行额外优化。 此存储（称为功能存储）允许数据科学家将特征存储为聚合数据存储之外的最后一步。
功能存储通过添加生成时间和源等元数据来帮助为多个用途编录数据。 此中间着陆点非常适合 黄金训练数据。
机器学习中的托管功能商店是与 MLflow 和其他工具集成的数据存储选项。 它从聚合数据存储提取和训练数据，并添加可重用层，以便更好地在机器学习内进行数据世系和正式标识。
使用功能存储时，请将其视为具有安全性和访问注意事项的数据存储。
脱机推理数据存储的注意事项
在某些情况下，使用单独的存储可以更快地进行将来的查找，因为提前对预收集和预计算的数据进行推理。 在此过程中，用户请求永远不会到达 AI 模型。 有几个好处：
- 通过降低延迟来提高效率和用户体验。 结果为频繁的查询提供更快的服务，例如生成常见问题解答作为结果。
- 推理调用可以更轻松地作为批处理进行横向扩展，而无需实时处理的约束。
- 允许预验证确保生产前的准确性。
- 由于请求未定向到干扰终结点，因此会减少负载，从而降低工作负荷的可靠性。
- 更具成本效益，因为它减少了对实时处理所需的高性能硬件的需求。
但是，仅当可以预测可能的请求 ，并且 用户应请求大量预测时，此方法才有效。 对于重复请求较少的方案，脱机推理存储可能不太有效。
此方案的数据存储应针对读取操作进行优化，必须能够处理大量数据并提供高效的检索。 它还应该能够集成到聚合数据存储中。 可以考虑使用这些功能的任何存储，例如 Azure Cosmos DB，甚至表存储。
资源
这些文章提供了有关 Azure 产品的更多详细信息，我们建议作为技术选项，了解本文中讨论的注意事项。