Synapse 实现成功方法：评估环境

实现 Azure Synapse Analytics 的第一步是执行环境评估。 评估使你有机会收集有关现有环境、环境要求、项目要求、约束、时间线和痛点的所有可用信息。 这些信息将构成以后评估和检查点活动的基础。 在计划、设计和开发项目解决方案期间需要对解决方案进行验证和比较时，这些信息证明其非常宝贵。 建议投入大量时间来收集所有信息，并确保与相关小组进行必要的讨论。 相关小组可以包括现有解决方案和环境的项目利益干系人、业务用户、解决方案设计人员和行业专家 (SME)。

评估将成为一个指南来帮助你评估解决方案设计，并提供明智的技术建议来实现 Azure Synapse。

工作负载评估

工作负载评估涉及环境、分析工作负载角色、ETL/ELT、网络和安全性、Azure 环境和数据使用。

环境

对于环境，请评估以下要点。

• 描述现有分析工作负载：
  • 工作负载是什么（如数据仓库或大数据）？
  • 此工作负载如何帮助业务？ 用例方案是什么？
  • 此分析平台和潜在迁移的业务驱动因素是什么？
  • 收集有关现有体系结构、设计和实现选择的详细信息。
  • 收集有关所有现有上游和下游依赖组件和使用者的详细信息。
• 是否迁移现有数据仓库（如 Microsoft SQL Server、Microsoft Analytics Platform System (APS)、Netezza、Snowflake 或 Teradata）？
• 是否迁移大数据平台（如 Cloudera 或 Hortonworks）？
• 收集当前分析环境的体系结构和数据流关系图。
• 计划分析工作负载的数据源位于何处（Azure、其他云提供商或本地）？
• 现有数据集的总大小（历史和增量）是多少？ 数据集的当前增长率是多少？ 未来 2-5 年数据集的预计增长率是多少？
• 是否具有现有数据湖？ 尽可能多地收集有关文件类型（Parquet 或 CSV）、文件大小和安全配置的详细信息。
• 是否要处理和分析半结构化或非结构化数据？
• 描述数据处理的性质（批处理或实时处理）。
• 是否需要从关系数据、数据湖或其他源进行交互式数据探索？
• 是否需要从操作数据源进行实时数据分析和探索？
• 当前环境中的痛点和限制是什么？
• 你当前在使用哪些源代码管理和 DevOps 工具？
• 你的用例是构建混合（云和本地）分析解决方案、仅限云还是多云？
• 收集有关现有云环境的信息。 它是单云提供商还是多云提供商？
• 收集有关未来云环境的计划。 它将是单云提供商还是多云提供商？
• 现有环境中的 RPO/RTO/HA/SLA 要求是什么？
• 计划环境中的 RPO/RTO/HA/SLA 要求是什么？

分析工作负载角色

对于分析工作负载角色，请评估以下要点。

• 描述不同角色（数据科学家、数据工程师、数据分析师和其他）。
• 描述这些角色的分析平台访问控制要求。
• 确定负责预配计算资源并授予访问权限的平台所有者。
• 描述不同数据角色当前如何协作。
• 是否有多个团队在相同分析平台上进行协作？ 如果是这样，那么每个团队的访问控制和隔离要求是什么？
• 最终用户用于与分析平台进行交互的客户端工具是什么？

ETL/ELT、转换和业务流程

对于 ETL/ELT、转换和业务流程，请评估以下要点。

• 当前将哪些工具用于数据引入（ETL 或 ELT）？
• 这些工具存在于现有环境中的何处（本地或云）？
• 当前数据加载和更新要求是什么（实时、微批处理、每小时、每日、每周或每月）？
• 描述每个层（大数据、数据湖、数据仓库）的转换要求。
• 用于转换数据的当前编程方法是什么（无代码、低代码、编程，如 SQL、Python、Scala、C# 或其他）？
• 用于转换数据的首选计划编程方法是什么（无代码、低代码、编程，如 SQL、Python、Scala、C# 或其他）？
• 当前将哪些工具用于数据业务流程以自动执行数据驱动的过程？
• 现有 ETL 的数据源位于何处（Azure、其他云提供商或本地）？
• 需要与分析平台集成的现有数据使用工具是什么（报告、BI 工具、开发源代码工具）？
• 需要与分析平台集成的计划数据使用工具是什么（报告、BI 工具、开发源代码工具）？

网络和安全性

对于网络和安全性，请评估以下要点。

• 你对数据有哪些法规要求？
• 如果数据包含客户内容、支付卡行业 (PCI) 或 1996 年健康保险便携性和责任法案 (HIPAA) 数据，那么安全组是否已针对此数据认证了 Azure？ 如果是这样，那么是针对哪些 Azure 服务？
• 描述用户授权和身份验证要求。
• 在实现过程中，是否存在可能会限制数据访问的安全问题？
• 在开发和测试过程中是否有可供使用的测试数据？
• 描述对分析计算和存储的组织网络安全要求（专用网络、公用网络或防火墙限制）。
• 描述客户端工具访问分析计算和存储的网络安全要求（对等网络、专用终结点或其他）。
• 描述本地与 Azure 之间的当前网络设置（Azure ExpressRoute、跨界或其他）。

使用以下可能要求清单来指导评估。

• 数据保护：
  • 传输中加密
  • 静态加密（默认密钥或客户管理的密钥）
  • 数据发现和分类
• 访问控制：
  • 对象级安全性
  • 行级别安全性
  • 行级别安全性
  • 动态数据屏蔽
• 身份验证：
  • SQL 登录名
  • Microsoft Entra ID
  • 多重身份验证 (MFA)
• 网络安全:
  • 虚拟网络
  • 防火墙
  • Azure ExpressRoute
• 威胁防护：
  • 威胁检测
  • 审核
  • 漏洞评估

有关详细信息，请参阅 Azure Synapse Analytics 安全白皮书。

Azure 环境

对于 Azure 环境，请评估以下要点。

• 当前是否在使用 Azure？ 它是否用于生产工作负载？
• 如果你在使用 Azure，那么是在使用哪些服务？ 你在使用哪些区域？
• 是否使用 Azure ExpressRoute？ 其带宽是多少？
• 是否具有预算审批来预配所需 Azure 服务？
• 当前如何预配和管理资源（Azure 资源管理器 (ARM) 或 Terraform）？
• 你的关键团队是否熟悉 Synapse Analytics？ 是否需要任何培训？

数据使用

对于数据使用，请评估以下要点。

• 描述当前用于执行活动（如引入、探索、准备和数据可视化）的方式和工具。
• 确定计划用于执行活动（如引入、探索、准备和数据可视化）的工具。
• 哪些应用程序计划与分析平台进行交互（Microsoft Power BI、Microsoft Excel、Microsoft SQL Server Reporting Services、Tableau 或其他）？
• 确定所有数据使用者。
• 确定数据导出和数据共享要求。

Azure Synapse 服务评估

Azure Synapse 服务评估涉及 Azure Synapse 中的服务。 Azure Synapse 具有以下用于计算和数据移动的组件：

• Synapse SQL：适用于 Transact-SQL (T-SQL) 的分布式查询系统，可实现数据仓库和数据虚拟化方案。 它还扩展了 T-SQL，以解决流式处理和机器学习 (ML) 方案。 Synapse SQL 同时提供了“无服务器”和“专用”资源模型。
• 无服务器 SQL 池：专为大规模数据和计算功能而构建的分布式数据处理系统。 无需设置基础结构或维护群集。 此服务适用于计划外或突发工作负载。 建议方案包括直接在数据湖上对文件进行快速数据探索、逻辑数据仓库和原始数据的数据转换。
• 专用 SQL 池：代表使用 Synapse SQL 时预配的分析资源的集合。 专用 SQL 池（之前称为 SQL DW）的大小由数据仓库单位 (DWU) 决定。 此服务适用于具有针对存储在 SQL 表中的数据的可预测高性能连续工作负载的数据仓库。 
• Apache Spark 池：与 Apache Spark（这是最流行的用于数据准备、数据工程、ETL 和 ML 的开放源代码大数据引擎）深度无缝集成。
• 数据集成管道：Azure Synapse 包含与 Azure 数据工厂 (ADF) 相同的数据集成引擎和体验。 它们使你无需离开 Azure Synapse 即可创建丰富的大规模 ETL 管道。

为了帮助确定最佳 SQL 池类型（专用或无服务器），请评估以下要点。

• 是否要通过为存储在 SQL 表中的数据保留处理能力来构建传统关系数据仓库？
• 你的用例是否需要可预测的性能？
• 是否要基于数据湖构建逻辑数据仓库？
• 是否要直接从数据湖查询数据？
• 是否要从数据湖探索数据？

下表比较了两种 Synapse SQL 池类型。

比较	专用 SQL 池	无服务器 SQL 池
价值主张	数据仓库的完全托管功能。 连续工作负载的可预测高性能。 针对托管（加载）数据进行优化。	易于开始使用和探索数据湖数据。 适用于临时和间歇性工作负载的更好的总拥有成本 (TCO)。 针对在数据湖中查询数据进行优化。
工作负载	非常适合连续工作负载。 加载可提升性能，但复杂性更高。 按 DWU 收费（如果大小良好）会具有成本效益。	非常适合临时或间歇性工作负载。 无需加载数据，因此可更轻松地启动和运行。 按使用量收费会具有成本效益。
查询性能	提供高并发和低延迟。 支持丰富的缓存选项，包括具体化视图。 能够通过工作负载管理 (WLM) 选择权衡。	不适合仪表板查询。 不期望获得毫秒响应时间。 仅适用于外部数据。

专用 SQL 池评估

对于专用 SQL 池评估，请评估以下平台要点。

• 当前数据仓库平台是什么（Microsoft SQL Server、Netezza、Teradata、Greenplum 或其他）？
• 对于迁移工作负载，为每个环境确定设备的品牌和型号。 包括 CPU、GPU 和内存的详细信息。
• 对于设备迁移，何时购买的硬件？ 设备是否已完全弃用？ 如果不是，折旧何时结束？ 还剩余多少资本支出？
• 是否有任何硬件和网络体系结构关系图？
• 计划数据仓库的数据源位于何处（Azure、其他云提供商或本地）？
• 数据仓库数据源的数据托管平台是什么（Microsoft SQL Server、Azure SQL 数据库、DB2、Oracle、Azure Blob 存储、AWS、Hadoop 或其他）？
• 是否有任何数据源数据仓库？ 如果有，是哪些？
• 确定所有 ETL、ELT 和数据加载方案（批处理窗口、流式处理、准实时）。 确定每个方案的现有服务级别协议 (SLA)，并记录新环境中的预期 SLA。
• 当前数据仓库大小是多少？
• 专用 SQL 池的目标数据集增长率是多少？
• 描述当前在使用的环境（开发、测试或生产）。
• 当前为数据移动实施了哪些工具（ADF、Microsoft SQL Server Integration Services (SSIS)、robocopy、Informatica、SFTP 或其他）？
• 是否计划加载实时数据或准实时数据？

评估以下数据库要点。

• 每个数据仓库中的对象数是多少（架构、表、视图、存储过程、函数）？
• 它是星型架构、雪花型架构还是其他设计？
• 在大小和记录数方面，最大的表是什么？
• 在列数方面，最宽的表是什么？
• 是否已为数据仓库设计了数据模型？ 是 Kimball、Inmon 还是星型架构设计？
• 是否在使用缓慢变化的维度 (SCD)？ 如果是这样，那么是哪些类型？
• 是使用关系数据市场或 Analysis Services（表格或多维）还是其他产品实现语义层？
• HA/RPO/RTO/数据存档要求是什么？
• 区域复制要求是什么？

评估以下工作负载特征。

• 在峰值时段访问数据仓库的估计并发用户或作业数是多少？
• 在非峰值时段访问数据仓库的估计并发用户或作业数是多少？
• 是否存在没有任何用户或作业的时间段？
• 交互式查询的查询执行性能期望是什么？
• 每日/每周/每月数据加载或更新的数据加载性能期望是什么？
• 报告和分析查询的查询执行期望是什么？
• 最常执行的查询有多复杂？
• 活动数据集占总数据集大小的百分比是多少？
• 对于加载或更新、批处理或报告、交互式查询和分析处理，预计工作负载的大约百分比是多少？
• 确定数据使用模式和平台：
  • 当前和计划报告方法和工具。
  • 哪些应用程序或分析工具将访问数据仓库？
  • 并发查询数？
  • 在任何时间点的平均活动查询数？
  • 数据访问的性质是什么（交互式、临时、导出或其他）？
  • 数据角色及其数据要求的完整描述。
  • 最大并发连接数。
• 以下对象的查询性能 SLA 模式：
  • 仪表板用户。
  • 批处理报告。
  • ML 用户。
  • ETL 过程。
• 现有环境和新环境的安全要求是什么（行级别安全性、列级别安全性、访问控制、加密和其他）？
• 是否要求将 ML 模型评分与 T-SQL 集成？

无服务器 SQL 池评估

Synapse 无服务器 SQL 池支持三种主要用例。

• 基本发现和探索：快速推理数据湖中各种格式（Parquet、CSV、JSON）的数据，以便你可以规划好如何从这些数据提取见解。
• 逻辑数据仓库：基于原始数据或异类数据提供关系抽象，而无需重新放置和转换数据，使你看到的数据始终是最新数据。
• 数据转换：使用 T-SQL 以简单、可缩放且高效的方式转换湖中的数据，以便可将数据馈送到 BI 和其他工具，或者加载到关系数据存储中（Synapse SQL 数据库、Azure SQL 数据库或其他）。

不同数据角色可以从无服务器 SQL 池获益：

• 数据工程师可以使用此服务探索数据湖、转换和准备数据，以及简化数据转换管道。
• 得益于 OPENROWSET 和自动架构推理等功能，数据科学家可以快速推理数据湖中数据的内容和结构。
• 数据分析师可以使用熟悉的 T-SQL 语句或他们偏好的查询工具，探索数据科学家或数据工程师创建的数据和 Spark 外部表。
• BI 专业人员可以快速基于数据湖中的数据创建 Power BI 报表和 Spark 表。

对于无服务器 SQL 池评估，请评估以下要点。

• 是否有用例使用关系查询 (T-SQL) 从数据湖发现和探索数据？
• 是否有用例基于数据湖构建逻辑数据仓库？
• 确定是否有用例在数据湖中转换数据，而无需首先从数据湖移动数据。
• 数据是否已在 Azure Data Lake Storage (ADLS) 或 Azure Blob 存储中？
• 如果数据已在 ADLS 中，那么数据湖中是否具有良好的分区策略？
• Azure Cosmos DB 中是否有操作数据？ 是否有用例用于 Azure Cosmos DB 上的实时分析，而不会影响事务？
• 确定数据湖中的文件类型。
• 确定查询性能 SLA。 你的用例是否需要可预测的性能和成本？
• 是否有计划外或突发 SQL 分析工作负载？
• 确定数据使用模式和平台：
  • 当前和计划报告方法和工具。
  • 哪些应用程序或分析工具将访问无服务器 SQL 池？
  • 在任何时间点的平均活动查询数。
  • 数据访问的性质是什么（交互式、临时、导出或其他）？
  • 数据角色及其数据要求的完整描述。
  • 最大并发连接数。
  • 查询复杂性？
• 安全要求是什么（访问控制、加密和其他）？
• 所需 T-SQL 功能是什么（存储过程或函数）？
• 确定将发送到无服务器 SQL 池的查询数以及每个查询的结果集大小。

Spark 池评估

Azure Synapse 中的 Spark 池可实现以下重要方案。

• 数据工程/数据准备：Apache Spark 包含许多语言功能，用于支持准备和处理大量数据的工作。 准备和处理可以使数据能够创造更大的价值，并可由其他 Azure Synapse 服务使用。 它通过多种语言（C#、Scala、PySpark、Spark SQL）以及使用为处理和连接而提供的库来实现。
• 机器学习：Apache Spark 随附 MLlib，这是构建在 Spark 基础之上的、可从 Spark 池使用的 ML 库。 Spark 池还包含 Anaconda，这是一种 Python 分发版，由用于数据科学（包括 ML）的各种包组成。 此外，Synapse 上的 Apache Spark 为 Microsoft 机器学习（这是可容错的弹性 RESTful ML 框架）提供了预安装库。 当这些与内置的笔记本支持相结合时，你将获得一个用于创建 ML 应用程序的丰富环境。

对于 Spark 池评估，请评估以下要点。

• 确定需要数据工程或数据准备的工作负载。
• 明确定义转换的类型。
• 确定是否具有要处理的非结构化数据。
• 从现有 Spark/Hadoop 工作负载迁移时：
  • 现有大数据平台是什么（Cloudera、Hortonworks、云服务或其他）？
  • 如果是从本地迁移，是硬件已折旧还是许可证已过期？ 如果不是，何时会发生折旧或过期？
  • 现有群集类型是什么？
  • 所需的库和 Spark 版本是什么？
  • 是否为 Hadoop 迁移到 Spark？
  • 当前或首选编程语言是什么？
  • 工作负载的类型是什么（大数据、ML 或其他）？
  • 现有和计划客户端工具和报告平台是什么？
  • 安全要求是什么？
  • 是否存在当前痛点和限制？
• 是否计划使用或当前正在使用 Delta Lake？
• 当前如何管理包？
• 确定所需计算群集类型。
• 确定是否需要群集自定义。

后续步骤

在设计 Azure Synapse 成功系列的下一篇文章中，了解如何评估 Synapse 工作区设计，并验证它是否符合准则和要求。