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