本文說明虛構的城市規劃辦公室如何使用此解決方案。 解決方案提供端對端數據管線，遵循 MDW 架構模式，以及對應的 DevOps 和 DataOps 程式，以評估停車使用，並做出更明智的商務決策。
架構
下圖顯示解決方案的整體架構。
資料流程
Azure Data Factory （ADF） 協調 Azure Data Lake 儲存體 （ADLS） Gen2 會儲存數據：
Contoso 城市停車 Web 服務 API 可用來從停車場傳輸數據。
有ADF複製作業會將資料傳輸到登陸架構。
接下來，Azure Databricks 會清理並標準化數據。 它採用原始數據和條件，讓數據科學家可以使用它。
如果驗證顯示任何不正確的數據，則會傾印到格式不正確的架構。
重要
人員 詢問數據儲存在ADLS之前，為何不會驗證數據。 原因是驗證可能會造成可能會損毀數據集的 Bug。 如果您在此步驟中引進錯誤，您可以修正 Bug 並重新執行管線。 如果您在將不正確的數據新增至 ADLS 之前傾印數據，則損毀的數據將無法使用，因為您無法重新執行管線。
有第二個 Azure Databricks 轉換步驟可將數據轉換成可儲存在數據倉儲中的格式。
最後，管線會以兩種不同的方式提供數據：
Databricks 可讓數據科學家取得數據，以便定型模型。
Polybase 會將數據從 Data Lake 移至 Azure Synapse Analytics，Power BI 會存取數據並將其呈現給商務使用者。
元件
解決方案會使用這些元件：
案例詳細資料
新式數據倉儲 （MDW） 可讓您輕鬆地在任何規模上將所有數據整合在一起。 結構化、非結構化或半結構化數據並不重要。 您可以透過分析儀錶板、操作報告或所有用戶的進階分析，取得 MDW 的見解。
為開發（開發）和生產環境（prod）環境設定 MDW 環境相當複雜。 自動化程式是關鍵。 這有助於提高生產力，同時將錯誤的風險降到最低。
本文說明虛構的城市規劃辦公室如何使用此解決方案。 解決方案提供端對端數據管線，遵循 MDW 架構模式，以及對應的 DevOps 和 DataOps 程式，以評估停車使用，並做出更明智的商務決策。
解決方案需求
能夠從不同的來源或系統收集數據。
基礎結構即程式代碼：以自動化方式部署新的開發和預備環境。。
以自動化方式跨不同環境部署應用程式變更：
實作持續整合/持續傳遞 （CI/CD） 管線。
使用部署閘道進行手動核准。
管線即程式代碼：確定 CI/CD 管線定義位於原始檔控制中。
使用範例數據集對變更執行整合測試。
依排程執行管線。
支持未來的敏捷式開發，包括新增數據科學工作負載。
支援資料欄層級和物件層級安全性：
SQL 資料庫 中提供安全性功能。
您也可以在 Azure Synapse Analytics、Azure Analysis Services （AAS） 和 Power BI 中找到它。
支援10個並行儀錶板使用者和20個並行的進階使用者。
數據管線應該執行數據驗證，並將格式不正確的記錄篩選到指定的存放區。
支援監視。
在安全的記憶體中集中設定，例如 Azure 金鑰保存庫。
潛在的使用案例
本文使用虛構的 Contoso 城市來描述使用案例。 在敘述中，Contoso 擁有和管理城市的停車感測器。 它也擁有連線到感測器並從中取得數據的 API。 他們需要一個平臺，從許多不同的來源收集數據。 然後，數據必須經過驗證、清理並轉換成已知的架構。 Contoso 城市規劃人員接著可以使用 Power BI 等數據視覺效果工具來探索和評估停車報告數據，以判斷是否需要更多停車或相關資源。
考量
下列清單摘要說明此解決方案所示範的重要學習和最佳做法：
注意
下列清單中的每個項目都會連結至 GitHub 上停車感測器解決方案範例檔中相關 Key Learnings 一節。
在 Data Lake 中使用數據階層處理。
在管線中早期驗證數據。
確定數據轉換程式代碼可測試。
部署此案例
下列清單包含設定具有對應建置和發行管線之停車感測器解決方案所需的高階步驟。 您可以在此 Azure 範例存放庫中找到詳細的設定步驟和必要條件。
安裝和部署
初始設定：安裝任何必要條件、將 Azure 範例 GitHub 存放庫匯入您自己的存放庫，以及設定必要的環境變數。
部署 Azure 資源：解決方案隨附自動化部署腳本。 它會為每個環境部署所有必要的 Azure 資源和 Microsoft Entra 服務主體。 腳本也會部署 Azure Pipelines、變數群組和服務連線。
在開發 Data Factory 中設定 Git 整合：設定 Git 整合以使用匯入的 GitHub 存放庫。
執行初始組建和發行：在 Data Factory 中建立範例變更，例如啟用排程觸發程式，然後監看變更自動部署於環境。
部署的資源
如果部署成功，Azure 中應該有三個資源群組代表三個環境：開發、stg 和 prod。Azure DevOps 中也應該有端對端建置和發行管線，可自動跨這三個環境部署變更。
如需所有資源的詳細清單，請參閱 DataOps - 停車感測器示範自述檔<
持續整合與持續傳遞
下圖示範建置和發行管線的 CI/CD 程式和順序。
開發人員會在開發資源群組內自己的沙盒環境中開發，並將變更認可至自己的短期 Git 分支。 例如：
<developer_name>/<branch_name>。當變更完成時，開發人員會向主要分支提出提取要求，以供檢閱。 這麼做會自動啟動PR驗證管線，該管線會執行單元測試、linting和資料層應用程式套件 （DACPAC） 組建。
完成PR驗證時，主要認可會觸發發行所有必要的組建成品的組建管線。
成功建置管線的完成將會觸發發行管線的第一個階段。 這樣做會將發佈組建成品部署到開發環境，但ADF除外。
開發人員會從共同作業分支手動發佈至開發ADF（main）。 手動發佈會更新分支中的
adf_publishAzure Resource Manager （ARM） 範本。第一階段成功完成會觸發手動核准閘道。
在核准時，發行管線會繼續進行第二個階段，將變更部署到 stg 環境。
執行整合測試以測試 stg 環境中的變更。
在第二個階段成功完成時，管線會觸發第二個手動核准網關。
在核准時，發行管線會繼續進行第三個階段，將變更部署到生產環境。
如需詳細資訊，請參閱 自述檔建置和發行管線 一節。
測試
解決方案包含單元測試和整合測試的支援。 它會使用 pytest-adf 和 Nutter Testing Framework。 如需詳細資訊，請參閱自述文件的測試一節。
可檢視性和監視
此解決方案支援 Databricks 和 Data Factory 的可觀察性和監視。 如需詳細資訊，請參閱 自述檔中的可觀察性/監視 一節。
下一步
如果您想要部署解決方案，請遵循如何使用 DataOps - 停車感測器示範自述檔範例一節中的步驟。
GitHub 上的解決方案程式碼範例
可觀察性/監視
Azure Databricks
Data Factory
Synapse Analytics
Azure 儲存體
復原和災害復原
Azure Databricks
Data Factory
Synapse Analytics
Azure 儲存體
詳細的逐步解說
如需解決方案和重要概念的詳細逐步解說，請觀看下列影片錄製： Microsoft Azure 上新式數據倉儲的 DataDevOps