你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

适用于新式数据仓库的 DataOps

Azure 数据工厂

Azure Databricks

Azure DevOps

Azure Key Vault

Azure Synapse Analytics

本文介绍虚构城市规划办公室如何使用此解决方案。该解决方案提供一个遵循 MDW 体系结构模式的端到端数据管道，以及相应的 DevOps 和 DataOps 流程，用于评估车辆使用情况并做出更明智的业务决策。

Architecture

下图显示了解决方案的整体体系结构。

下载此体系结构的 Visio 文件。

Dataflow

Azure 数据工厂协调数据，Azure Data Lake Storage Gen2 存储数据：

Contoso 城市停车 Web 服务 API 可用于从停车地点传输数据。
有一个数据工厂复制作业可将数据传输至登陆架构。
接下来，Azure Databricks 对数据进行清理和标准化。它采用原始数据和对其进行调节，以便数据科学家可以使用这些数据。
如果验证显示任何错误数据，它将转储到格式错误的架构中。

Important

人们询问为什么在将数据存储在 Data Lake Store 中之前未验证数据。原因是验证可能会引入可能损坏数据集的 bug。如果在此步骤中引入了 bug，可以修复 bug 并重播管道。如果在将错误数据添加到 Data Lake Store 之前将其转储，则损坏的数据将无用，因为无法重播管道。
还有另一个 Azure Databricks 转换步骤，可将数据转换为可以存储在数据仓库中的格式。
最后，管道以两种不同的方式提供数据：
1. Databricks 使数据可供数据科学家使用，以便他们可以训练模型。
2. Polybase 将数据从数据湖移到 Azure Synapse Analytics，Power BI 访问数据并将其呈现给业务用户。

Components

Azure 数据工厂是一种基于云的数据集成服务，可实现数据移动和业务流程。在此体系结构中，它通过将数据从 Contoso 城市停车 Web 服务 API 复制到 Data Lake 的登陆区域来启动管道。
Azure Data Lake Storage Gen2 是基于 Azure Blob 存储构建的可缩放且安全的 Data Lake，支持分层存储和可重播管道。在此体系结构中，它充当跨登陆、格式不正确和经过验证的数据区域的原始数据和已处理数据的中央存储库。
Azure Databricks 是基于 Apache Spark 的分析平台，专为大数据和机器学习而设计。在此体系结构中，它执行两个关键的转换步骤。首先，它在将格式不正确的记录筛选为单独的架构时清理和标准化原始数据。然后，它将验证的数据转换为适合数据仓库存储的格式，并使处理的数据可供数据科学家进行模型训练。
Azure Key Vault 是用于管理机密、密钥和证书的安全云服务。在此体系结构中，它将存储在整个管道中使用的敏感配置设置和凭据，从而提供集中和安全的配置管理。
Azure Synapse Analytics 是一种集成分析服务，结合了大数据和数据仓库功能。在此体系结构中，它充当通过 PolyBase 从 Data Lake Storage 引入转换数据的数据仓库，用于查询和报告。
Power BI 是一种业务分析工具，可提供交互式可视化效果和仪表板。在此体系结构中，它连接到 Azure Synapse Analytics，向城市规划者提供停车使用情况数据见解，以便做出明智的决策。

方案详细信息

使用新式数据仓库 (MDW) 可以轻松地将所有数据以任何规模汇集在一起。它是结构化、非结构化还是半结构化数据并不重要。可以通过分析仪表板、操作报告或针对所有用户的高级分析来深入了解 MDW。

为开发 (dev) 环境和生产 (prod) 环境设置 MDW 环境非常复杂。自动化流程是关键。它有助于提高工作效率，同时最大程度地降低错误风险。

解决方案要求

能够从不同的源或系统收集数据。
基础架构即代码：以自动化方式部署新的 dev 和过渡 (stg) 环境。
以自动化方式跨不同环境部署应用程序更改：
- 实现持续集成/持续交付 (CI/CD) 管道。
- 使用部署入口进行手动审批。
管道即代码：确保 CI/CD 管道定义在源代码管理中。
使用示例数据集对更改执行集成测试。
按计划运行管道。
支持未来的敏捷开发，包括添加数据科学工作负载。
支持行级别和对象级安全性：
- 此安全功能在 SQL 数据库中可用。
- 也可在 Azure Synapse Analytics、Azure Analysis Services 和 Power BI 中找到。
支持 10 个并发仪表板用户和 20 个并发 Power User。
数据管道应执行数据验证，并将格式错误的记录筛选出指定的存储。
支持监视。

可能的用例

本文使用虚构城市 Contoso 来描述用例场景。在叙述中，Contoso 拥有并管理城市的停车传感器。它还拥有连接到传感器并从传感器获取数据的 API。这些传感器需要一个平台，用于从许多不同的源收集数据。然后，必须验证、清理数据，然后将数据转换为已知架构。然后，Contoso 城市规划人员可以借助 Power BI 等数据可视化工具浏览和评估有关停车的报告数据，以确定他们是否需要更多停车或相关资源。

Considerations

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

本部分中的注意事项总结了此解决方案演示的关键学习和最佳做法：

Note

本节中的每个注意事项都链接到 GitHub 上停车传感器解决方案示例文档中相关 关键学习 部分。

在 Data Lake 中使用数据分层。
使数据管道可重播和幂等。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。有关详细信息，请参阅可靠性设计审查检查表。

安全和集中配置。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。有关详细信息，请参阅设计卓越运营的审查清单。

部署此方案

以下列表包含设置具有相应生成和发布管道的停车传感器解决方案所需的大致步骤。可在此 Azure 示例存储库中找到详细的设置步骤和先决条件。

安装和部署

初始设置：安装任何先决条件，将 Azure 示例 GitHub 存储库导入自己的存储库，并设置所需的环境变量。
部署 Azure 资源：解决方案附带自动化部署脚本。它为每个环境部署所有必要的 Azure 资源和 Microsoft Entra 服务主体。该脚本还会部署 Azure Pipelines、变量组和服务连接。
在 dev 数据工厂中设置 Git 集成：配置 Git 集成以使用导入的 GitHub 存储库。
执行初始生成和发布：在数据工厂中创建示例更改，例如启用计划触发器，然后观察更改如何跨环境自动部署。

已部署的资源

如果部署成功，Azure 中应存在三个资源组，分别表示三个环境：dev、stg 和 prod。Azure DevOps 中还应存在端到端生成和发布管道，可以在这三个环境中自动部署更改。

有关所有资源的详细列表，请参阅 DataOps - 停车传感器演示自述文件“已部署的资源”部分。

持续集成和持续交付 (CI/CD)

下图演示了生成和发布管道的 CI/CD 过程和顺序。

下载此体系结构的 Visio 文件。

开发人员在 dev 资源组内自己的沙盒环境中进行开发，并将更改提交到其自己的短期 Git 分支中。例如 <developer_name>/<branch_name>。
更改完成后，开发人员向主分支提出拉取请求 (PR) 以进行评审。这样做会自动启动 PR 验证管道，该管道运行单元测试、linting 和数据层应用程序包（DACPAC）生成。
PR 验证完成后，提交到主分支将触发发布所有必要生成项目的生成管道。
成功完成生成管道将触发发布管道的第一阶段。这样做会将发布生成项目部署到 dev 环境中，数据工厂除外。

开发人员从协作分支（主分支）手动发布到 dev 数据工厂。手动发布会更新 adf_publish 分支中的 Azure 资源管理器模板。
成功完成第一个阶段将触发手动审批入口。

审批时，发布管道将继续执行第二阶段，将更改部署到 stg 环境。
运行集成测试以测试 stg 环境中的更改。
成功完成第二阶段后，管道将触发第二个手动审批入口。

审批时，发布管道将继续执行第三阶段，将更改部署到 prod 环境。