你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Synapse 实现成功方法:评估环境
注意
本文是“按设计成功实施 Azure Synapse”系列文章的一部分。 有关系列概述,请参阅 Azure 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 表。
注意
T-SQL 语言在专用 SQL 池和无服务器 SQL 池中使用,但支持的功能集存在一些差异。 有关 Synapse SQL(专用和无服务器)中支持的 T-SQL 功能的详细信息,请参阅 Azure Synapse SQL 中支持的 Transact-SQL 功能。
对于无服务器 SQL 池评估,请评估以下要点。
- 是否有用例使用关系查询 (T-SQL) 从数据湖发现和探索数据?
- 是否有用例基于数据湖构建逻辑数据仓库?
- 确定是否有用例在数据湖中转换数据,而无需首先从数据湖移动数据。
- 数据是否已在 Azure Data Lake Storage (ADLS) 或 Azure Blob 存储中?
- 如果数据已在 ADLS 中,那么数据湖中是否具有良好的分区策略?
- Azure Cosmos DB 中是否有操作数据? 是否有用例用于 Azure Cosmos DB 上的实时分析,而不会影响事务?
- 确定数据湖中的文件类型。
- 确定查询性能 SLA。 你的用例是否需要可预测的性能和成本?
- 是否有计划外或突发 SQL 分析工作负载?
- 确定数据使用模式和平台:
- 当前和计划报告方法和工具。
- 哪些应用程序或分析工具将访问无服务器 SQL 池?
- 在任何时间点的平均活动查询数。
- 数据访问的性质是什么(交互式、临时、导出或其他)?
- 数据角色及其数据要求的完整描述。
- 最大并发连接数。
- 查询复杂性?
- 安全要求是什么(访问控制、加密和其他)?
- 所需 T-SQL 功能是什么(存储过程或函数)?
- 确定将发送到无服务器 SQL 池的查询数以及每个查询的结果集大小。
提示
如果你不熟悉无服务器 SQL 池,我们建议你完成使用 Azure Synapse 无服务器 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 应用程序的丰富环境。
注意
有关详细信息,请参阅 Azure Synapse Analytics 中的 Apache Spark。
此外,Azure Synapse 与 Linux Foundation Delta Lake 兼容。 Delta Lake 是开源存储层,可将 ACID(原子性、一致性、隔离性和持续性)事务引入 Apache Spark 和大数据工作负载。 有关详细信息,请参阅什么是 Delta Lake。
对于 Spark 池评估,请评估以下要点。
- 确定需要数据工程或数据准备的工作负载。
- 明确定义转换的类型。
- 确定是否具有要处理的非结构化数据。
- 从现有 Spark/Hadoop 工作负载迁移时:
- 现有大数据平台是什么(Cloudera、Hortonworks、云服务或其他)?
- 如果是从本地迁移,是硬件已折旧还是许可证已过期? 如果不是,何时会发生折旧或过期?
- 现有群集类型是什么?
- 所需的库和 Spark 版本是什么?
- 是否为 Hadoop 迁移到 Spark?
- 当前或首选编程语言是什么?
- 工作负载的类型是什么(大数据、ML 或其他)?
- 现有和计划客户端工具和报告平台是什么?
- 安全要求是什么?
- 是否存在当前痛点和限制?
- 是否计划使用或当前正在使用 Delta Lake?
- 当前如何管理包?
- 确定所需计算群集类型。
- 确定是否需要群集自定义。
提示
如果你不熟悉 Spark 池,我们建议你完成使用 Azure Synapse Apache Spark 池执行数据工程学习路径。
后续步骤
在设计 Azure Synapse 成功系列的下一篇文章中,了解如何评估 Synapse 工作区设计,并验证它是否符合准则和要求。