Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota
本文是“按设计成功实施 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)?
- 这些工具存在于现有环境中的何处(本地或云)?
- 当前数据加载和更新要求是什么(实时、微批处理、每小时、每日、每周或每月)?
- 描述每个层(大数据、数据湖、数据仓库)的转换要求。
- 用于转换数据的当前编程方法是什么(无代码、低代码、编程,如 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 ExpressRoute? 其带宽是多少?
- 是否具有预算审批来预配所需 Azure 服务?
- 当前如何预配和管理资源(Azure 资源管理器 (ARM) 或 Terraform)?
- 你的关键团队是否熟悉 Synapse Analytics? 是否需要任何培训?
对于数据使用,请评估以下要点。
- 描述当前用于执行活动(如引入、探索、准备和数据可视化)的方式和工具。
- 确定计划用于执行活动(如引入、探索、准备和数据可视化)的工具。
- 哪些应用程序计划与分析平台进行交互(Microsoft Power BI、Microsoft Excel、Microsoft SQL Server Reporting Services、Tableau 或其他)?
- 确定所有数据使用者。
- 确定数据导出和数据共享要求。
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 池评估,请评估以下平台要点。
- 当前数据仓库平台是什么(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 集成?
Synapse 无服务器 SQL 池支持三种主要用例。
- 基本发现和探索:快速推理数据湖中各种格式(Parquet、CSV、JSON)的数据,以便你可以规划好如何从这些数据提取见解。
- 逻辑数据仓库:基于原始数据或异类数据提供关系抽象,而无需重新放置和转换数据,使你看到的数据始终是最新数据。
- 数据转换:使用 T-SQL 以简单、可缩放且高效的方式转换湖中的数据,以便可将数据馈送到 BI 和其他工具,或者加载到关系数据存储中(Synapse SQL 数据库、Azure SQL 数据库或其他)。
不同数据角色可以从无服务器 SQL 池获益:
- 数据工程师可以使用此服务探索数据湖、转换和准备数据,以及简化数据转换管道。
- 得益于 OPENROWSET 和自动架构推理等功能,数据科学家可以快速推理数据湖中数据的内容和结构。
- 数据分析师可以使用熟悉的 T-SQL 语句或他们偏好的查询工具,探索数据科学家或数据工程师创建的数据和 Spark 外部表。
- BI 专业人员可以快速基于数据湖中的数据创建 Power BI 报表和 Spark 表。
Nota
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 池的查询数以及每个查询的结果集大小。
Sugerencia
如果你不熟悉无服务器 SQL 池,我们建议你完成使用 Azure Synapse 无服务器 SQL 池构建数据分析解决方案学习路径。
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 应用程序的丰富环境。
Nota
有关详细信息,请参阅 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?
- 当前如何管理包?
- 确定所需计算群集类型。
- 确定是否需要群集自定义。
Sugerencia
如果你不熟悉 Spark 池,我们建议你完成使用 Azure Synapse Apache Spark 池执行数据工程学习路径。
在设计 Azure Synapse 成功系列的下一篇文章中,了解如何评估 Synapse 工作区设计,并验证它是否符合准则和要求。