你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文介绍了一种高级方法，用于为数据资源管理器池准备和运行有效的 Azure Synapse Analytics 概念证明 （POC） 项目。
注释
本文是“Azure Synapse 概念验证手册”系列文章的一部分。 有关系列概述，请参阅Azure Synapse 概念验证手册。
在您开始之前
该 playbook 可帮助你评估 Azure Synapse 数据资源管理器的使用情况，并专为最适合数据探索池的方案而设计。 在开始 POC 之前，使用以下场景来确定 Data Explorer 池是否是适合您的解决方案。
常规体系结构模式方案
- 符合以下一个或多个特征的任何数据都应该是 Data Explorer 池的良好候选项：
- 高容量和高速度
- 仅追加和不可变数据
- 数据静止：不会更改的数据。 例如，在在线商店中下达的订单是静默数据的一个很好的示例。
- 命令查询责任分离 （CQRS） 模式 适用于 Data Explorer 池的仅追加体系结构。
- 事件溯源模式
其他方案
以下方案也适用于 Data Explorer 池：
- 低延迟数据存储，用于基于遥测的实时警报
- IoT 遥测数据存储和分析
- 高速交互式分析层。 特别是与 Apache Spark 引擎（如 Synapse Spark、DataBricks）或传统数据仓库（如 Synapse SQL 池）一起使用时。
- 日志和可观测性分析
准备 POC
POC 项目可帮助你做出明智的业务决策，即在使用 Azure Data （Azure Synapse 中的池） 的基于云的平台上实现大数据和高级分析环境。
POC 项目将确定基于云的大数据和高级分析平台必须支持的关键目标和业务驱动因素。 它将测试关键指标并证明对数据工程、机器学习模型构建和培训要求的成功至关重要的关键行为。 POC 不适合部署到生产环境。 相反，它是一个关注关键问题的短期项目，其结果可以放弃。
在开始规划 Data Explorer POC 项目之前：
- 确定组织在将数据移到云方面所要施加的任何限制或要制定的准则。
- 确定大数据和高级分析平台项目的行政或业务发起人。 确保他们为迁移到云提供支持。
- 确定在执行 POC 期间是否有技术专家和业务用户可为你提供支持。
在开始准备 POC 项目之前，建议先阅读 Azure 数据资源管理器文档。
到目前为止，你应该已经确定当前没有阻碍因素，然后你可以开始为 POC 做准备。 如果您不熟悉 Data Explorer，可以参考 此文档 ，从中可以大致了解 Data Explorer 架构。
了解这些关键概念：
- Data Explorer 及其架构。
- 支持数据格式和数据源。
- 数据库、表、具体化视图充当 Data Explorer 对象。
- Ingestion Wizard 和 Continuous Ingestion 支持的引入方法。
- Data Explorer 中的身份验证和授权。
- 与 Power BI、Grafana、Kibana 等可视化解决方案集成的本机连接器。
- 创建外部表以从 Azure SQL/SQL Server、Azure Cosmos DB、Azure Monitor、Azure 数字孪生读取数据。
Data Explorer 将计算资源与存储分离，以便您可以更好地管理数据处理需求并控制成本。 您只需为使用中的计算付费。 不使用时，只需支付存储费用。 您可以 放大和缩小 （垂直），也可以缩小和缩小（水平）。 您还可以手动停止或自动停止工作区，而不会丢失数据。 例如，您可以针对繁重的数据处理需求或较大的负载纵向扩展工作区，然后在处理强度较低的时间将其缩减，或者完全关闭。 同样，您可以在周末有效地扩展和停止工作区以降低成本。
设定目标
成功的 POC 项目需要规划。 首先确定为何要执行 POC，以充分了解真正的动机。 动机可能包括现代化、成本节省、性能改进或集成体验。 请务必阐述 POC 的明确目标，以及 POC 成功的条件。 问问你自己：
- 你期望的 POC 输出是什么？
- 如何处理这些输出？
- 谁将使用这些输出？
- POC 成功的条件是什么？
请记住，POC 应该是快速证明有限一组概念和功能的简短而专注的工作。 这些概念和功能应代表整个工作负载。 如果您有一长串需要验证的项目，可能需要规划多个原型验证（POC）。 在这种情况下，请定义 POC 之间的门，以确定是否需要继续下一个 POC。 例如，一个 POC 可以重点放在数据工程岗位的需求，例如数据的引入和处理。 另一个 POC 可以侧重机器学习 (ML) 模型开发。
在考虑 POC 目标时，请向自己提出以下问题以帮助形成目标：
- 是否要从现有的大数据和高级分析平台（本地或云）迁移？
- 您是否正在迁移并希望在此过程中进行一些广泛的改进？ 例如，从 Elastic Search 迁移到 Data Explorer 进行日志分析，从 InfluxDB 或 Timescale DB 迁移到 Data Explorer。
- 您是否在全新构建一个大数据与高级分析平台（从零开始的项目）？
- 当前的痛点是什么？ 例如，可伸缩性、性能或灵活性。
- 需要支持哪些新的业务要求？
- 您需要符合哪些服务水平协议 (SLA)？
- 工作负载将是多少？ 例如，ETL、批处理、流处理、机器学习模型训练、分析、报告查询或交互式查询？
- 拥有项目的用户的技能是什么（是否应实施 POC）？ 例如，SQL、Python、PowerBI 或其他技能。
下面是一些 POC 目标设定示例：
- 为何要执行 POC？
- 我们需要知道，大数据工作负载的数据引入和处理性能将满足新 SLA 的需求。
- 我们需要知道，接近实时的流处理是否可行，以及它可以支持多大的吞吐量。 （它是否会支持我们的业务需求？）
- 我们需要知道，现有的数据引入和转换流程是否合适，以及需要在哪些方面进行优化。
- 我们需要知道，是否可以缩短数据集成运行时间以及可以缩短多少时间。
- 我们需要知道我们的数据科学家是否可以在 Data Explorer 中根据需要构建和训练机器学习模型并使用 AI/ML 库。
- 迁移到基于云的 Data Explorer 是否能满足我们的成本目标？
- 在此 POC 的结论中：
- 我们将拥有数据来确定批处理和实时流式处理是否可以满足我们的数据处理性能要求。
- 我们将测试支持我们的用例的所有不同数据类型（结构化、半结构化和非结构化）的摄取和处理。
- 我们将测试一些现有的数据处理需求，并确定可以使用 Data Explorer 中的更新策略完成的工作。
- 我们将测试数据摄取和处理，并将拥有数据点来估计初始迁移和加载历史数据所需的工作量。
- 我们将测试数据摄取和处理，并确定是否可以满足我们的 ETL/ELT 处理要求。
- 我们将获得洞察力，以更好地估计完成实施项目所需的工作量。
- 我们将测试规模和扩展选项，并将获得数据点，以更好地配置我们的平台以实现更好的性价比设置。
- 我们将提供可能需要更多测试的项目清单。
规划项目
使用目标来确定特定的测试并提供确定的输出。 必须确保至少执行一项测试来支持每个目标和预期输出。 此外，确定特定的数据摄取、批处理或流处理以及将要执行的所有其他流程，以便您可以识别特定的数据集和代码库。 该特定数据集和代码库将定义 POC 的范围。
以下是使用 Data Explorer 评估的典型主题领域：
- 数据摄取和处理：数据源、数据格式、摄取方法、连接器、工具、摄取策略、流式与批量摄取
- 数据存储：架构、表和物化视图等存储工件
- 策略：例如分区、更新、合并
- 查询和可视化
- 性能：例如查询响应时间、提取延迟、弱一致性、查询缓存结果
- 成本：总拥有成本 （TCO）
- 安全性：例如身份验证、授权、数据访问、行级安全性
注释
使用以下常见问题来帮助您规划 POC。
-
创建 Data Explorer 池时如何选择缓存周期？
为了提供最佳查询性能，提取的数据将缓存在本地 SSD 磁盘上。 这种性能级别并不总是必需的，并且不经常查询的数据通常可以存储在更便宜的 blob 存储上。 对 blob 存储中数据的查询运行速度较慢，但这在许多情况下是可以接受的。 了解这一点可以帮助您确定在本地 SSD 中保存数据并继续满足查询性能要求所需的计算节点数量。 例如，如果要更频繁地查询 x 天的数据（基于摄取期限），并将数据保留 y 天，而查询数据的频率较低，则在缓存保留策略中，指定 x 作为热缓存保留的值，指定 y 作为总保留的值。 有关更多信息，请参阅 缓存策略。 -
创建 Data Explorer 池时如何选择保留期？
保留期是可用于查询的热缓存数据和冷缓存数据的组合。 您可以根据合规性或其他法规要求需要保留数据的时间来选择数据保留。 您可以使用热窗口功能来加热存储在冷缓存中的数据，以便更快地查询以用于任何审计目的。 有关详细信息，请参阅使用热窗口查询冷数据。
下面是规划中所需具体程度的示例：
- 目标 A：我们需要知道，在我们定义的 SLA 下，是否可以满足我们对数据摄取和批量数据处理的要求。
-
输出 A：我们将拥有数据来确定我们的批量数据摄取和处理是否能够满足数据处理要求和 SLA。
- 测试 A1：处理查询 A、B 和 C 被确定为良好的性能测试，因为它们通常由数据工程团队执行。 此外，它们代表了整体数据处理需求。
- 测试 A2：处理查询 X、Y 和 Z 被确定为良好的性能测试，因为它们包含近乎实时的流处理要求。 此外，它们代表了基于事件的整体流处理需求。
- 测试 A3：将工作区不同规模（实例数）的这些查询的性能与从现有系统获得的基准进行比较。
- 目标 B：我们需要知道我们的业务用户是否可以在此平台上构建他们的仪表板。
-
输出 B：我们将使用不同的可视化选项、连接器和 Kusto 查询，针对工作区中的数据测试一些现有仪表板和视觉对象。 这些测试将有助于确定哪些控制面板可以迁移到新环境。
- 测试 B1：将使用 Data Explorer 数据创建特定视觉对象，并将对其进行测试。
- 测试 B2：测试现成的 KQL 函数和运算符以满足要求。
-
目标 C：我们将测试数据摄取，并将数据指向：
- 估计将初始历史数据迁移到 Data Explorer 池的工作量。
- 规划历史数据迁移方法。
-
输出 C：我们将测试并确定在我们的环境中可实现的数据摄取速率，并且可以确定我们的数据摄取速率是否足以在可用时间范围内迁移历史数据。
- 测试 C1：测试历史数据迁移的不同方法。 有关更多信息，请参阅 比较摄取方法和工具。
- 测试 C2：使用 LightIngest、从 blob 存储或 Data Lake Store 连续引入来测试从数据源到工作区的数据传输。 有关更多信息，请参阅 使用向导通过 LightIngest 一次性摄取历史数据。
- 目标 D：我们将测试增量数据加载的数据摄取率，并将使用数据点来估计数据摄取和处理时间窗口。
-
输出 D：我们将测试数据摄取速率，并确定确定的方法是否可以满足我们的数据摄取和处理要求。
- 测试 D1：测试每日、每小时和近乎实时的数据摄取和处理。
- 测试 D2：在运行最终用户查询时执行连续（批量或流式处理）数据摄取和处理。
务必通过添加多个测试方案来优化测试。
以下是一些测试方案：
- Data Explorer 测试 A：我们将跨多个工作区大小和不同数量的池实例执行数据引入、处理和查询。
- Data Explorer 测试 B：我们将使用控制面板和查询工具（如 Data Explorer KQL 脚本）从工作区查询已处理的数据。
以下是可用于帮助您规划 POC 的任务的高级示例：
| 短跑 | 任务 |
|---|---|
| 0 | 使用在线资源或在 Microsoft 客户团队的帮助下加深对 Data Explorer 的了解 |
| 0 | 定义您希望使用 Data Explorer 实现的业务场景 |
| 0 | 定义数据源、摄取方法、数据保留、数据缓存、SLA、安全性、网络、IAM 方面的技术要求 |
| 0 | 定义关键性能指标，例如查询性能预期、延迟、并发请求、摄取吞吐量、数据新鲜度 |
| 0 | 使用 Data Explorer 及其数据摄取者和使用者定义高级架构 |
| 0 | 定义 POC 范围 |
| 0 | 定义 POC 规划和时间表 |
| 0 | 定义、确定优先级和权衡 POC 评估标准 |
| 1 | 定义要测试的查询并确定其优先级 |
| 1 | 为每组用户定义数据访问规则 |
| 1 | 估计一次性（历史）数据摄取量和每日数据摄取量 |
| 1 | 定义数据保留、缓存和清除策略 |
| 1 | 定义创建工作区时所需的配置元素，例如流、Python/R 插件、清除 |
| 1 | 查看源数据格式、结构、架构 |
| 1 | 审查、完善、修订评估标准 |
| 2 | 根据架构设计创建工作区、Data Explorer 池以及所需的数据库、表和具体化视图 |
| 2 | 为相关用户分配数据平面访问权限 |
| 2 | 实施分区和合并策略（如果需要） |
| 2 | 实施一次性数据摄取，通常是历史数据或迁移数据 |
| 2 | 安装和配置查询工具（如果需要） |
| 2 | 使用 Data Explorer Web UI 对提取的数据测试查询 |
| 2 | 测试更新和删除方案 |
| 2 | 测试与所选可视化和查询工具（如 Power BI、Grafana 等）的连接 |
| 2 | 配置数据访问管理规则 |
| 2 | 实施持续摄取 |
| 2 | 使用事件中心/IoT 中心/事件网格创建数据连接 |
| 3 | 在 Azure 数据资源管理器仪表板或 Grafana 中实现自动刷新仪表板以实现近乎实时的监视 |
| 3 | 定义如何执行负载测试 |
| 3 | 根据从以前的 sprint 和已完成的积压工作项中学到的经验优化引入方法和流程 |
| 3 | 在 Grafana 或您选择的仪表板工具上进行性能评估 |
| 3 | 根据并发和预期负载要求执行负载测试 |
| 3 | 验证成功标准 |
| 3 | 评价评分 |
| 3 | 测试摄取不同格式数据的能力 |
| 3 | 验证 POC 结果 |
评估 POC 数据集
使用确定的特定测试，选择一个数据集来支持测试。 花些时间评审此数据集。 应该验证该数据集在内容、复杂性和规模方面是否能够充分代表将来的处理。 不要使用太小（小于 1 GB）的数据集，因为它无法提供具有代表性的性能。 相反，也不要使用太大的数据集，因为 POC 不应该变为完整数据迁移。 请务必从现有系统获取适当的基准，以便可以使用它们进行性能比较。 检查您的数据集是否与支持的数据格式一致。 然后，根据摄取方法（批量或流式处理），可以批量摄取适当大小的数据集。
重要
在将任何数据迁移到云之前，请确保与业务所有者核实是否有任何阻碍因素。 在将数据移动到云之前，确定应处理的任何安全或隐私问题或任何数据混淆需求。
创建高级体系结构
根据提议的未来状态体系结构的高级体系结构，确定构成 POC 的一部分的组件。 高级未来状态体系结构可能包含许多数据源、大量的数据使用者、大数据组件，以及机器学习和人工智能 (AI) 数据使用者。 POC 体系结构应明确确定 POC 的构成组件。 重要的是，它应该确定不构成 POC 测试的一部分的任何组件。
如果你已在使用 Azure，请确定可在 POC 期间使用的任何现有资源（Microsoft Entra ID、ExpressRoute 等）。 另外，确定组织使用的 Azure 区域。 现在是确定 ExpressRoute 连接的吞吐量，并与其他业务用户核实你的 POC 是否消耗其中一部分吞吐量而不会对生产系统造成不利影响的好时机。
有关详细信息，请参阅大数据体系结构。
标识 POC 资源
明确确定支持 POC 所需的技术资源和时间承诺。 POC 将需要：
- 一名业务代表，负责监督要求和结果。
- 一名应用程序数据专家，负责 POC 数据溯源，并提供现有流程和逻辑的知识。
- Data Explorer 专家。 如有必要，您可以要求 Microsoft 联系人进行安排。
- 一名专家顾问，负责优化 POC 测试。 如有必要，您可以要求 Microsoft 联系人进行安排。
- POC 项目的特定组件需要的资源，但在 POC 期间不一定需要的资源。 这些资源可能包括网络管理员、Azure 管理员、Active Directory 管理员、Azure 门户管理员等。
- 确保预配所有必需的 Azure 服务资源并授予所需的访问级别，包括对存储帐户的访问权限。
- 确保帐户拥有从 POC 范围内的所有数据源检索数据所需的数据访问权限。
小窍门
建议聘请专家顾问来协助进行 POC。 请联系你的 Microsoft 帐户团队或联系全球可用的专家顾问，他们可帮助你评估、评估或实施 Data Explorer 池。 您还可以在 Stack Overflow with Data Explorer 标签上发布问题。
设置时间线
审查您的 POC 计划详细信息和业务需求，以确定 POC 的时间框架。 对完成 POC 目标所需的时间进行实际的估算。 完成 POC 所需的时间受 POC 数据集大小、测试的数量和复杂性以及要测试的接口数量的影响。 如果你估计 POC 的运行时间超过四周，请考虑缩小 POC 范围，以便注重于优先级最高的目标。 在继续之前，请务必获得所有资源主管和发起人的批准和承诺。
将 POC 付诸实施
我们建议遵循任何生产项目的纪律和严谨性来执行 POC 项目。 根据计划运行项目并管理更改请求流程，以防 POC 范围不受控制地扩大。
下面是一些高级任务的示例：
创建数据资源管理器池，以及 POC 计划中标识的所有 Azure 资源。
加载 POC 数据集：
- 通过从源中提取数据或在 Azure 中创建示例数据，使数据在 Azure 中可用。 有关在 Data Explorer 池中引入数据的初始测试，请使用 引入向导。
- 测试您计划用于将数据引入工作区的连接器/集成方法。
编写 Kusto 查询以查询数据：
执行测试：
- 可以使用不同的客户端界面（如仪表板、PowerBIm 和 Data Explorer KQL 脚本）在工作区上并行执行许多测试。
- 以易于使用和理解的格式记录结果。
优化查询和工作区：
- 无论您是编写新的 KQL 查询还是转换其他语言的现有查询，我们都建议您检查查询是否遵循 查询最佳实践。
- 根据测试结果，您可能需要使用缓存策略、分区策略、工作区大小调整或其他优化来微调工作区。 有关建议，请参阅 针对高并发性进行优化。
监控故障排除和性能：
- 有关更多信息，请参阅 使用指标监控 Data Explorer 性能、运行状况和使用情况。
- 对于技术问题，请 创建支持票证。
估算定价：
- 在 POC 结束时，您应该使用在 POC 中学到的知识来估算满足您要求的工作区 的成本 。
关闭 POC：
- 记录 POC 阶段的结果、经验教训和结果，包括您在 POC 期间应用的基准、配置和优化。
- 清理在 POC 期间创建的不再需要的任何 Azure 资源。
小窍门
如果你决定继续在 Azure Synapse 中使用数据资源管理器，并打算 将其迁移到生产环境，我们建议保持 POC 工作区运行。 这将帮助您设置生产工作区，确保您不会丢失在 POC 期间可能应用的配置和优化。
解释概念验证（POC）结果
完成所有 POC 测试后，评估结果。 首先评估是否满足 POC 目标，并收集了所需的输出。 确定是否需要进行更多测试或者是否有任何问题需要解决。
从 POC 迁移到生产环境
如果你决定继续在 Azure Synapse 中使用数据资源管理器池，并打算将 POC 池迁移到生产环境，我们强烈建议你保持 POC 工作区中的数据资源管理器池运行，并使用它来设置生产工作区。 这将帮助您确保不会丢失在 POC 期间可能应用的配置和优化。
在将 POC 工作区中的 Data Explorer 池迁移到生产环境之前，我们强烈建议您考虑、设计和决定以下因素：
- 功能和非功能要求
- 灾难恢复和高可用性要求
- 安全要求
- 网络要求
- 持续集成/持续部署要求
- 监控和支持要求
- 在 Data Explorer 中培训关键人员
- 控制和数据平面访问控制要求
- 架构、数据模型和数据流要求
- 引入要求
- 可视化要求
- 数据和洞察消费要求
- 测试要求
后续步骤
架构管理 最佳做法