本文提供了一种高级方法，用于为无服务器 SQL 池准备和运行有效的 Azure Synapse Analytics 概念证明（POC）项目。
备注
本文是“Azure Synapse 概念验证手册”系列文章的一部分。 有关系列概述，请参阅Azure Synapse 概念验证手册。
POC 项目可以帮助你做出明智的业务决策，了解如何在基于云的平台上实施大数据和高级分析环境，该平台利用 Azure Synapse 中的无服务器 SQL 池。 如果需要从数据湖中的数据浏览或获取见解，或优化现有数据转换管道，可以从使用无服务器 SQL 池中获益。 它适用于以下方案：
- 基本发现和探索： 快速推断 Data Lake 中以各种格式（Parquet、CSV、JSON）存储的数据，以便规划如何从中解锁见解。
- 逻辑数据仓库：基于原始数据或异类数据生成关系抽象，而无需重新放置和转换数据，提供的数据始终是最新数据。
- 数据转换： 使用 T-SQL 运行简单、可缩放且高性能的数据湖查询。 可以将查询结果馈送给商业智能（BI）工具，或将其加载到关系数据库中。 目标系统可以包括 Azure Synapse 专用 SQL 池或 Azure SQL 数据库。
不同的职业角色可以从无服务器 SQL 池获益：
- 数据工程师 可以使用无服务器 SQL 池浏览数据湖、转换和准备数据，并简化其数据转换管道。
- 数据科学家 可以使用 OPENROWSET T-SQL 函数及其自动架构推理，快速推理数据湖中存储的数据的内容和结构。
- 数据分析师 可以在首选查询工具中编写 T-SQL 查询，这些工具可以连接到无服务器 SQL 池。 他们可以浏览由数据科学家或数据工程师创建的 Spark 外部表中的数据。
- BI 专业人员 可以快速创建连接到 Data Lake 或 Spark 表的 Power BI 报表。
无服务器 SQL 池 POC 项目将确定无服务器 SQL 池旨在支持的关键目标和业务驱动因素。 它还将测试关键功能并收集指标以支持实现决策。 POC 不适合部署到生产环境。 相反，它是一个关注关键问题的短期项目，其结果可以放弃。
开始规划无服务器 SQL 池 POC 项目之前：
- 确定组织在将数据移到云方面所要施加的任何限制或要制定的准则。
- 确定大数据和高级分析平台项目的行政或业务发起人。 确保他们为迁移到云提供支持。
- 确定在执行 POC 期间是否有技术专家和业务用户可为你提供支持。
在开始准备 POC 项目之前，建议先阅读 无服务器 SQL 池文档。
提示
如果您是无服务器 SQL 池的新手，我们建议您通过Azure Synapse 无服务器 SQL 池学习路径来进行数据分析解决方案的学习。
成功的 POC 项目需要规划。 首先确定为何要执行 POC，以充分了解真正的动机。 动机可能包括现代化、成本节省、性能改进或集成体验。 请务必阐述 POC 的明确目标，以及 POC 成功的条件。 问问你自己：
- 你期望的 POC 输出是什么？
- 如何处理这些输出？
- 谁将使用这些输出？
- POC 成功的条件是什么？
请记住，POC 应该是快速证明有限一组概念和功能的简短而专注的工作。 这些概念和功能应代表整个工作负载。 如果要证明的项列表很长，你可能需要计划多个 POC。 在这种情况下，请定义 POC 之间的门，以确定是否需要继续下一个 POC。 鉴于可以使用无服务器 SQL 池的不同专业角色（以及无服务器 SQL 池支持的不同方案），可以选择执行多个 POC。 例如，一个 POC 可以专注于数据科学家角色的要求，例如以不同格式发现和探索数据。 另一个可以专注于数据工程角色的要求，例如数据转换和逻辑数据仓库的创建。
在考虑 POC 目标时，请向自己提出以下问题以帮助形成目标：
- 是否要从现有的大数据和高级分析平台（本地或云）迁移？
- 是否在迁移的同时希望对现有引入和数据处理进行尽可能少的更改？
- 是否在迁移的同时希望进行一些广泛的改进？
- 是否要构建全新的大数据和高级分析平台（绿地项目）？
- 当前的痛点是什么？ 例如，可伸缩性、性能或灵活性。
- 需要支持哪些新的业务要求？
- 您需要符合哪些服务水平协议 (SLA)？
- 工作负载是什么？ 例如，对不同数据格式的数据浏览、基本浏览、逻辑数据仓库、数据准备和/或转换、T-SQL 交互式分析、Spark 表的 T-SQL 查询，或报告数据湖上的查询。
- 拥有项目的用户的技能是什么（是否应实施 POC）？
下面是一些 POC 目标设定示例：
- 为何要执行 POC？
- 我们需要知道是否可以使用无服务器 SQL 池浏览我们存储的所有原始文件格式。
- 我们需要知道数据工程师是否可以快速评估新的数据馈送。
- 我们需要知道使用无服务器 SQL 池的 Data Lake 查询性能是否满足我们的数据探索要求。
- 我们需要了解无服务器 SQL 池是否是一些可视化效果和报告要求的不错选择。
- 我们需要知道对于某些数据引入和处理要求，无服务器 SQL 池是否是一个不错的选择。
- 我们需要知道我们迁移到 Azure Synapse 是否会满足我们的预算。
- 在此 PoC 的结论中：
- 我们将提供数据来确定非常适合无服务器 SQL 池的数据转换。
- 在数据可视化期间，我们将提供数据来识别何时最能使用无服务器 SQL 池。
- 我们将拥有数据来了解数据工程师和数据科学家采用新平台的轻松程度。
- 我们将获得见解，以更好地估计完成实施或迁移项目所需的工作量。
- 我们将获得可能需要进行更多测试的项列表。
- 如果我们具有所需的数据，并且已完成确定的无服务器 SQL 池如何支持基于云的大数据和高级分析平台的测试，则 POC 将成功。
- 我们将确定是否可以进入下一阶段，还是需要更多 POC 测试才能完成我们的决定。
- 我们将能够做出由特定数据点支持良好的业务决策。
使用目标来确定特定的测试并提供确定的输出。 必须确保至少执行一项测试来支持每个目标和预期输出。 此外，确定要测试的特定数据浏览和分析任务、特定转换和特定的现有处理。 确定可以使用的特定数据集和代码库。
下面是规划中所需具体程度的示例：
- 目标： 我们需要知道数据工程师是否可以在所需的 SLA 中实现名为“每日批处理原始文件验证”的现有 ETL 进程的等效处理。
- 输出： 我们将有数据来确定是否可以使用 T-SQL 查询在所需的 SLA 中执行“每日批处理原始文件验证”ETL 过程。
- 测试： 验证查询 A、B 和 C 由数据工程标识，它们表示总体数据处理需求。 将这些查询的性能与从现有系统获取的基准进行比较。
使用确定的特定测试，选择一个数据集来支持测试。 花些时间评审此数据集。 应该验证该数据集在内容、复杂性和规模方面是否能够充分代表将来的处理。 不要使用太小的数据集，因为它不会提供具有代表性的性能。 相反，也不要使用太大的数据集，因为 POC 不应该变为完整数据迁移。 请务必从现有系统获取适当的基准，以便可以使用它们进行性能比较。
重要
在将任何数据迁移到云之前，请确保与业务所有者核实是否有任何阻碍因素。 在将数据移动到云之前，确定应处理的任何安全或隐私问题或任何数据混淆需求。
根据提议的未来状态体系结构的高级体系结构，确定构成 POC 的一部分的组件。 高级未来状态体系结构可能包含许多数据源、大量的数据使用者、大数据组件，以及机器学习和人工智能 (AI) 数据使用者。 POC 体系结构应明确确定 POC 的构成组件。 重要的是，它应该确定不构成 POC 测试的一部分的任何组件。
如果你已在使用 Azure，请确定可在 POC 期间使用的任何现有资源（Microsoft Entra ID、ExpressRoute 等）。 另外，确定组织使用的 Azure 区域。 现在是确定 ExpressRoute 连接的吞吐量，并与其他业务用户核实你的 POC 是否消耗其中一部分吞吐量而不会对生产系统造成不利影响的好时机。
明确确定支持 POC 所需的技术资源和时间承诺。 POC 将需要：
- 一名业务代表，负责监督要求和结果。
- 一名应用程序数据专家，负责 POC 数据溯源，并提供现有流程和逻辑的知识。
- 无服务器 SQL 池专家。
- 一名专家顾问，负责优化 POC 测试。
- POC 项目的特定组件需要的资源，但不一定需要在 POC 期间使用。 这些资源可能包括网络管理员、Azure 管理员、Active Directory 管理员、Azure 门户管理员等。
- 确保预配所有必需的 Azure 服务资源并授予所需的访问级别，包括对存储帐户的访问权限。
- 确保帐户拥有从 POC 范围内的所有数据源检索数据所需的数据访问权限。
提示
建议聘请专家顾问来协助进行 POC。 Microsoft 合作伙伴社区拥有在全球各地提供支持的专家顾问，可帮助你评估、衡量或实施 Azure Synapse。
查看 POC 计划详细信息和业务需求，以确定 POC 的时间范围。 对完成 POC 目标所需的时间进行实际的估算。 完成 POC 所需的时间受 POC 数据集大小、测试的数量和复杂性以及要测试的接口数量的影响。 如果你估计 POC 的运行时间超过四周，请考虑缩小 POC 范围，以便注重于优先级最高的目标。 在继续之前，请务必获得所有资源主管和发起人的批准和承诺。
我们建议遵循任何生产项目的纪律和严谨性来执行 POC 项目。 根据计划运行项目并管理更改请求流程，以防 POC 范围不受控制地扩大。
下面是一些高级任务的示例：
- 创建 SYNapse 工作区、存储帐户和 POC 计划中标识的 Azure 资源。
- 根据要求设置网络和安全性。
- 向 POC 团队成员授予适当的访问权限。 请参阅 本文 ，了解直接从 Azure 存储访问文件的权限。
- 加载 POC 数据集。
- 实现和配置测试和/或将现有代码迁移到无服务器 SQL 池脚本和视图。
- 执行测试：
- 许多测试可以并行执行。
- 以易于使用和理解的格式记录结果。
- 监视故障排除和性能。
- 评估结果并呈现发现。
- 与技术利益干系人和业务部门合作，规划项目的下一阶段。 下一阶段可能是后续概念验证（POC）或生产阶段的实施。
完成所有 POC 测试后，评估结果。 首先评估是否满足 POC 目标，并收集了所需的输出。 确定是否需要进行更多测试或者是否有任何问题需要解决。