本文介绍虚构城市规划办公室如何使用此解决方案。 该解决方案提供一个遵循 MDW 体系结构模式的端到端数据管道，以及相应的 DevOps 和 DataOps 流程，用于评估车辆使用情况并做出更明智的业务决策。
体系结构
下图显示了解决方案的整体体系结构。
下载此体系结构的 Visio 文件。
数据流
Azure 数据工厂协调数据，Azure Data Lake Storage Gen2 存储数据：
Contoso 城市停车 Web 服务 API 可用于从停车地点传输数据。
有一个数据工厂复制作业可将数据传输至登陆架构。
接下来，Azure Databricks 对数据进行清理和标准化。 它采用原始数据和对其进行调节，以便数据科学家可以使用这些数据。
如果验证显示任何错误数据，它将转储到格式错误的架构中。
重要
人们询问为什么在将数据存储在 Data Lake Store 中之前未验证数据。 原因是验证可能会引入可能损坏数据集的 bug。 如果在此步骤中引入了 bug，可以修复 bug 并重播管道。 如果在将错误数据添加到 Data Lake Store 之前将其转储，则损坏的数据将无用，因为无法重播管道。
还有另一个 Azure Databricks 转换步骤，可将数据转换为可以存储在数据仓库中的格式。
最后，管道以两种不同的方式提供数据：
Databricks 使数据可供数据科学家使用，以便他们可以训练模型。
Polybase 将数据从数据湖移到 Azure Synapse Analytics，Power BI 访问数据并将其呈现给业务用户。
组件
该解决方案使用以下组件：
方案详细信息
使用新式数据仓库 (MDW) 可以轻松地将所有数据以任何规模汇集在一起。 它是结构化、非结构化还是半结构化数据并不重要。 可以通过分析仪表板、操作报告或针对所有用户的高级分析来深入了解 MDW。
为开发 (dev) 环境和生产 (prod) 环境设置 MDW 环境非常复杂。 自动化流程是关键。 它有助于提高工作效率，同时最大程度地降低错误风险。
本文介绍虚构城市规划办公室如何使用此解决方案。 该解决方案提供一个遵循 MDW 体系结构模式的端到端数据管道，以及相应的 DevOps 和 DataOps 流程，用于评估车辆使用情况并做出更明智的业务决策。
解决方案要求
能够从不同的源或系统收集数据。
基础架构即代码：以自动化方式部署新的 dev 和过渡 (stg) 环境。
以自动化方式跨不同环境部署应用程序更改：
实现持续集成/持续交付 (CI/CD) 管道。
使用部署入口进行手动审批。
管道即代码：确保 CI/CD 管道定义在源代码管理中。
使用示例数据集对更改执行集成测试。
按计划运行管道。
支持未来的敏捷开发，包括添加数据科学工作负载。
支持行级别和对象级安全性：
此安全功能在 SQL 数据库中可用。
也可在 Azure Synapse Analytics、Azure Analysis Services 和 Power BI 中找到。
支持 10 个并发仪表板用户和 20 个并发 Power User。
数据管道应执行数据验证，并将格式错误的记录筛选出指定的存储。
支持监视。
在安全存储中集中配置，例如 Azure Key Vault。
可能的用例
本文使用虚构城市 Contoso 来描述用例场景。 在叙述中，Contoso 拥有并管理城市的停车传感器。 它还拥有连接到传感器并从传感器获取数据的 API。 这些传感器需要一个平台，用于从许多不同的源收集数据。 然后，必须验证、清理数据，然后将数据转换为已知架构。 然后，Contoso 城市规划人员可以借助 Power BI 等数据可视化工具浏览和评估有关停车的报告数据，以确定他们是否需要更多停车或相关资源。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
本部分中的注意事项总结了此解决方案演示的关键学习和最佳做法：
注意
本节中的每个注意事项都链接到 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 环境。
有关详细信息，请阅读自述文件的生成和发布管道部分。
正在测试
该解决方案包括对单元测试和集成测试的支持。 它使用 pytest-Data Factory 和 Nutter 测试框架。 有关详细信息，请参阅自述文件的测试部分。
可观测性和监视
该解决方案支持 Databricks 和数据工厂的可观测性和监视。 有关详细信息，请参阅自述文件的可观测性/监视部分。
后续步骤
要部署解决方案，请按照 DataOps - 停车传感器演示自述文件的如何使用示例部分中的步骤进行操作。
GitHub 上的解决方案代码示例
可观测性/监视
Azure Databricks
数据工厂
Azure Synapse Analytics
Azure 存储
复原能力和灾难恢复
Azure Databricks
数据工厂
Azure Synapse Analytics
Azure 存储
详细演练
有关解决方案和关键概念的详细演练，请观看以下视频录制：Microsoft Azure 上适用于新式数据仓库的 DataDevOps