你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
可缩放的数据平台对于适应数据的快速增长至关重要。 世界各地的每秒都会生成大量数据。 预计未来几年，可用数据量将继续呈指数级增长。 随着数据生成速率的增加，数据移动的速度也会增加。
无论数据量如何，用户都需要快速查询响应。 他们希望等待几分钟就能获得结果，而不是几小时才能得到结果。 本文介绍如何扩展 Azure 云级分析解决方案，并持续满足用户对速度的需求。
介绍
许多企业都有大型整体式数据平台。 这些整体围绕单个 Azure Data Lake Gen2 帐户（有时是单个存储容器）构建。 单个 Azure 订阅通常用于所有数据平台相关任务。 大多数体系结构平台缺乏订阅级别的扩展，这可能会在用户遇到任何 Azure 订阅或服务级限制时影响 Azure 的持续采用。 尽管某些约束是软限制，但达到这些约束仍会对数据平台产生重大负面影响。
构建数据平台时，请考虑组织的结构。 记下团队的数据所有权和功能责任。 如果组织为团队提供大量自主性和分布式所有权，则数据网格体系结构是最佳选择。
避免出现不同团队分别负责解决方案中诸如数据导入、清理、聚合和服务提供等任务的情况。 依赖于多个团队，可能会导致速度急剧下降。 例如，如果服务层上的数据使用者需要载入新数据资产或实现特定数据资产的功能更改，则必须执行多步骤过程。 对于此示例，步骤如下：
- 数据使用者向负责数据管道阶段的每个团队提交票证。
- 团队必须同步协同工作，因为层是相互连接的。 新服务需要对数据清理层进行更改，这会导致数据聚合层的更改，这会导致服务层的更改。 这些更改可能会影响每个管道阶段。
- 团队很难看到处理更改的潜在影响，因为它们没有整个端到端生命周期的概述。 它们必须共同努力，设计一个定义完善的发布计划，以最大程度地减少对现有使用者和管道的影响。 此依赖项管理会增加管理开销。
- 通常情况下，团队并不是数据消费者请求的数据资产的主题专家。 若要了解新的数据集特征或参数值，必须咨询专家。
- 实现所有更改后，数据使用者将收到新数据资产可供使用通知。
每个大型组织都有数千个数据使用者。 一个像所描述的那样复杂的过程，会大幅减少大型架构的效率，因为集中化团队成为了业务单元的瓶颈。 结果是创新较少，有效性有限。 可能，业务部门可以决定离开服务并构建自己的数据平台。
缩放方法
云缩放分析使用两个核心概念解决缩放难题：
- 用于缩放的数据登陆区域
- 用于缩放的数据产品或数据集成，使分布式和分散的数据所有权成为可能
可以部署单个数据登陆区域或多个数据登陆区域。 通过连接到数据管理登陆区域，可以发现和管理数据。 每个数据管理登陆区域都在单个 Azure 订阅中。
订阅是 Azure 的管理、计费和缩放单元。 它们在大规模 Azure 采用计划中发挥着关键作用。
使用数据登陆区域进行缩放
云规模分析的核心概念是 Microsoft Purview、Azure Databricks Unity Catalog（如果使用 Azure Databricks）、数据管理登陆区域和数据登陆区域。 应将每个项目放在各自的 Azure 订阅中。 分离它们可让你明确分离职责、遵循最低特权原则，并部分解决前面提到的订阅规模问题。 最小的云规模分析设置包括单个数据登陆区域和单个数据管理登陆区域。
但是，最小设置不足以用于大规模数据平台部署。 公司构建大规模平台，并投入大量资金，以一致高效地扩展其数据和分析工作。 为了克服订阅级限制，云规模分析使用订阅作为缩放单元，如 Azure 登陆区域中所述。 通过此方法，可以通过向体系结构添加更多数据登陆区域来提高数据平台占用量。 采用此方法还解决了一个 Azure Data Lake Gen2 用于整个组织的问题，因为每个数据登陆区域都包含三个数据湖。 来自多个域的项目和活动可以分布在多个 Azure 订阅中，从而提供更大的可伸缩性。
在实施云规模分析体系结构之前，确定组织需要多少数据登陆区域。 选择合适的解决方案为有效且高效的数据平台奠定了基础。
所需的数据登陆区域数取决于许多因素，特别是：
- 组织一致性，例如多少个业务部门需要自己的数据登陆区域
- 关于运营的注意事项，例如贵组织如何使运营资源和特定于业务部门的资源保持一致。
使用正确的数据登陆区域模型可以最大程度地减少将来将数据产品和数据资产从一个登陆区域移到另一个登陆区域的努力。 它还有助于在将来有效且一致地扩展和管理大数据与分析相关的工作。
确定要部署的数据登陆区域数时，请考虑以下因素。
| 因素 | 说明 |
|---|---|
| 组织结构和数据所有权 | 考虑组织的结构和数据在组织中拥有的方式。 |
| 区域和位置 | 如果在多个区域中部署，请确定哪些区域应托管数据区域。 请务必遵守所有数据驻留要求。 |
| 配额 | 订阅配额不是容量保证，并且按区域应用。 |
| 数据主权 | 由于数据主权法规，数据必须存储在特定区域中，并遵循特定于区域的策略。 |
| Azure 策略 | 数据登陆区域必须遵循各种 Azure 策略的要求。 |
| 管理边界 | 订阅为治理和隔离提供了一个管理边界，明确区分了关注点。 |
| 网络 | 每个登陆区域都有一个虚拟网络。 由于虚拟网络驻留在单个区域中，因此每个新区域都需要一个新的登陆区域。 虚拟网络必须是对等虚拟网络才能启用跨域通信。 |
| 限制 | 订阅有限制。 通过多个订阅，可以缓解触及这些限制的风险。 |
| 成本分配 | 考虑是否需要按业务部门或领域拆分那些由中心支付费用的共享服务（例如存储帐户）。 使用单独的订阅可创建成本分配的边界。 可以使用标记实现相同的功能。 |
| 数据分类和高度机密数据 | 安全机制可能会影响数据产品开发和数据平台的可用性。 考虑数据分类，并确定高度机密数据集是否需要特殊处理，例如实时访问、客户管理的密钥（CMK）、精细的网络控制，还是更多加密。 |
| 其他法律或安全隐患 | 考虑是否需要逻辑或物理分离数据的任何其他法律或安全要求。 |
如果您实施数据网格架构，在决定如何分配数据落地区和数据领域时，请考虑以下因素。
| 因素 | 说明 |
|---|---|
| 数据域 | 请考虑组织使用的数据域，并决定数据平台的数据域。 请考虑单个数据域的大小。 有关详细信息，请参阅 什么是数据域？ |
| 延迟 | 协作处理大量数据的域可以跨登陆区域传输大量数据。 请考虑在同一登陆区域或区域中分配域。 分离它们会增加延迟，并可能会增加跨区域域的成本。 |
| 安全性 | 某些服务部署或配置需要在订阅中提升权限。 向一个域中的用户授予这些权限会隐式地为同一订阅中的其他域中的用户提供相同的权限。 |
可以在云采用框架指南中找到有关 订阅的更多注意事项。
许多组织希望高效缩放其企业数据平台。 业务部门应能够构建自己的数据解决方案和应用程序，以满足其独特的要求。 提供此功能可能是一项挑战，因为许多现有数据平台不是围绕可伸缩性和分散所有权的概念构建的。 这些数据平台的体系结构、团队结构和运营模型清楚地显示了这种缺陷。
数据登陆区域不会在组织内创建数据孤岛。 针对云规模分析的推荐网络设置可实现跨登陆区域的安全和就地数据共享，进而支持跨数据域和业务部门进行创新。 若要了解详细信息，请参阅 网络体系结构注意事项。
标识层也是如此。 使用单个 Microsoft Entra 租户时，可以向标识授予对多个数据登陆区域中的数据资产的访问权限。 若要详细了解用户和标识授权过程，请参阅 数据访问管理。
注释
如果有多个数据登陆区域，每个区域都可以连接到其他区域中托管的数据。 这样，组就可以跨业务进行协作。
云规模分析使用通用体系结构来倡导一致的治理。 体系结构定义基线功能和策略。 所有数据登陆区域都遵循相同的审核和控制措施。 你的团队可以创建数据管道、引入源，以及创建报表和仪表板等数据产品。 Teams 还可以根据需要执行 Spark/SQL 分析。 可以通过向策略中的功能添加服务来增强数据中转区域的能力。 例如，团队可以添加第三方图形引擎来满足业务需求。
云规模分析强调集中编录和分类，以保护数据，并使各种组能够发现数据产品。
谨慎
我们建议不要跨区域查询数据。 相反，请确保数据靠近使用数据的计算，同时不超出区域边界。
云规模的分析体系结构和数据登陆区域的概念使组织能够随着时间的推移轻松增加数据平台的大小。 可以采用分阶段的方法添加更多的数据着陆区。 您的客户不需要一开始就设有多个着陆区。 采用此体系结构时，优先考虑几个数据登陆区域及其包含的数据产品。 适当的优先级有助于确保云规模分析部署的成功。
通过数据应用实现扩展
在每个登陆区域中，组织可以使用数据应用程序进行缩放。 数据应用程序是数据体系结构的单元或组件，它封装了提供读取优化的数据产品供其他数据应用程序使用的功能。 在 Azure 中，数据应用程序是资源组形式的环境，使跨职能团队能够实现数据解决方案和工作负载。 关联的团队负责数据解决方案的端到端生命周期，其中包括引入、清理、聚合和服务任务。
云规模分析解决了前面讨论的数据集成和责任问题。 参考设计提供由数据域驱动的分布式体系结构，而不是表引入和源系统集成的单一功能责任。 跨职能团队接管数据范围的端到端功能责任和所有权。
与其依靠一个负责所有数据处理工作流任务的团队和集中式技术栈，你可以将端到端的责任分配给多个自治的跨职能数据集成团队。 每个团队拥有一个域或子域功能，并被鼓励按照数据使用者的要求为数据集提供服务。
这些体系结构差异会导致数据平台上的速度提高。 数据使用者不再需要依赖一组集中式团队，也不必为请求的更改设置优先级而战。 随着较小的团队拥有端到端集成工作流的所有权，数据提供程序和数据使用者之间的反馈循环较短。 此方法可加快优先级、更快的开发周期和更敏捷的开发过程。 你的团队不再需要同步流程和发布计划，因为跨职能数据集成团队充分了解端到端技术堆栈以及更改的影响。 它可以使用软件工程实践来运行单元和集成测试，以最大程度地减少对使用者的整体影响。
理想情况下，拥有数据集成系统的团队也拥有源系统。 此团队应由在源系统工作的数据工程师、数据集的主题专家（SME）、云工程师和数据产品所有者组成。 构建此类跨职能团队可减少与外部团队所需的通信量，在开发从基础结构到实际数据管道的完整堆栈时至关重要。
数据平台的基础是从源系统集成的数据集。 通过这些数据集，数据产品团队可以创新业务事实数据表，并改进决策和业务流程。 数据集成团队和数据产品团队应向消费者提供 SLA，并确保满足所有协议。 提供的 SLA 可能与数据质量、时间线、错误率、运行时间和其他任务相关。
摘要
使用云规模分析体系结构的缩放机制，组织可以在 Azure 中随时间推移扩展其数据资产，同时避免常见的技术限制。 本文中所述的两种缩放方法都有助于克服不同的技术复杂性，并可以采用简单高效的方式使用。