Azure Data Factory 企業強化架構
本文說明當您在整個企業中採用系統時，如何修改和強化 獎章湖屋 。 此架構遵循基準架構中所述的一般採用模式。 此架構已強化，以符合額外的非功能需求（NFR）、提供額外的功能，並將責任轉移至網域型同盟模型。
此架構結合了適用於 Azure Microsoft 雲端採用架構 的最佳做法和指引，並著重於數據網域的實作和數據產品採用。
注意
本文中的指引著重於此架構與基準架構相比的主要差異。
強化基準架構
根據基準架構，Contoso 會操作一個獎章湖屋，以支持財務部門的第一個數據工作負載。 Contoso 強化並擴充此系統，以支持企業的分析數據需求。 此策略提供數據科學功能和自助功能。
重要需求
修改和強化獎牌湖屋有幾個關鍵需求：
必須強化解決方案，才能以企業數據和分析平臺的形式運作。 解決方案也必須擴充以支援其他公司功能，並遵守 Contoso 的數據存取原則需求。
平台必須能夠以近乎即時的方式內嵌、儲存、處理及提供數據。 效能目標定義為不到一分鐘的處理時間，從擷取到報告層的可用性。
平台必須提供規模節約和效率的經濟，同時推動重複使用。
平台必須讓商務區域能夠決定其數據解決方案和產品所需的自助程度和控制。
平臺必須支援企業數據科學功能，包括啟用數據公民。
平台必須支援更高的目標服務等級協定（SLA），其中包括：
目標運行時間為99.9%，或每年約8.5小時的停機時間。
恢復點目標 （RPO） 為 1.5 天。
復原時間目標 （RTO） 少於1天。
平台必須支援跨不同網域的1,000位使用者預期使用量，估計每年增長5%。 只有 Contoso 員工可以直接存取平臺，但需要與其他公司共用數據的功能。
主要的設計決策
您可以修改 基準架構 以符合這些需求，而不需要建立新的架構。
受企業管理基礎支援的網域設計，適用於此案例。 網域設計支援跨企業擴充平臺、自助功能及業務戰略目標的需求。 基礎定義為：
- 身分識別和訪問控制。
- 基礎網路、界限控制和安全性基準。
- 治理、稽核和監視功能。
- 用來擷取和一開始將數據內嵌到平臺的函式。
定義域設計是以特定商務部門對其數據和原始來源系統的擁有權為錨點。 新的 作業模型 可讓商務群組選擇性地建置自己控制和維護的模型與服務元件堆疊。 網域會根據企業需求在護欄內運作，並且能夠執行定義完善的和控制實驗。 資料科學功能是透過下列方式傳遞：
適用於低程序代碼的Power BI ，以及跨表格式數據的簡單或中度複雜度使用案例。 此模型是數據公民的理想起點。
Azure 機器學習 和 AI 服務供應專案，可支援完整的使用案例和使用者成熟度。
適用於大型企業大量使用案例的 Azure Databricks ，需要大量的處理需求。
支持新技術或技術概念證明工作的創新沙盒。 它提供與生產階段和生產前隔離的隔離環境。
Azure Data Factory 功能可涵蓋異動數據擷取功能啟用 的近乎即時和微批次擷取 使用案例。 這項功能與 Azure Databricks 結構化串流 和 Power BI 結合，支援端對端解決方案。
Power BI 能夠視需要 與外部合作對象共享數據，Microsoft Entra B2B 授權和訪問控制。
串流數據模式可能很複雜，可實作和管理，特別是在失敗案例中。 請確定商務需求已測試可接受的延遲，而且來源系統和網路基礎結構可以在實作之前支援串流需求。
任何轉向領域模型的決定都必須與商務項目關係人共同作業。 項目關係人務必瞭解並接受網域 擁有權增加的責任。
項目關係人的數據成熟度、軟體開發生命週期 （SDLC）、治理架構、標準和自動化成熟度之間的可用技能，都會影響初始作業模型依賴 領域啟用程度。 這些因素也可以指出您在雲端規模分析 採用生命週期 中目前的位置，並醒目提示進一步推進所需的步驟。
架構
工作流程
下列工作流程會對應至上圖：
擷取的數據和 Delta Lake 是 來源一 致的，並且仍然是中央技術小組的責任。 此決策反映 Spark 開發所需的技術專業知識層級，並支援一致且標準化的實作方法，以將企業可重複使用性納入考慮。
數據合約 會控管來自來源系統的數據摘要。 數據合約可用來驅動元數據驅動的擷取、轉換、載入 （ETL） 架構，並將數據提供給使用者作為治理功能的一部分。
Delta Lake 中銅層的目錄結構（或原始層）會反映數據的取用方式。 來源系統會訂購數據。 此組織方法可根據來源系統的商務擁有權，啟用統一的安全性實作。
數據的快速路徑支援串流需求。 快速路徑會透過 Data Factory 內嵌數據，而 Azure Databricks 結構化串流會直接處理數據以供分析和使用。 您可以使用 Delta Lake 異動數據擷取 來建立稽核記錄。 這項功能支援重新執行，並將累加變更傳播至獎章架構中的下游數據表。
模型與服務路徑仍然是中央技術小組支援企業擁有的數據解決方案的責任。 技術小組也負責為需要數據解決方案但對於在技術上管理自己的網域實作沒有技能、預算或興趣的商業領域提供服務類別目錄選擇性。 自助是在中央技術小組所管理的模型與服務元件內提供。
中央技術小組會管理企業數據科學功能。 此模型也符合其支援以企業為主的解決方案、布建服務選擇性，以及使用企業定價結構裝載服務。
網域是透過訂用帳戶層級的邏輯容器來啟用。 訂用帳戶 提供必要的網域層級管理、計費、治理和隔離單位。
此方法是透過基礎結構即程序代碼 （IaC） 基礎結構即程式代碼 （IaC）來管理，其提供企業監視、稽核和安全性控件的基準。 平台 標記策略 會擴充以支援網域延伸模組。
每個網域都有自己的一組角色型訪問控制 （RBAC） 角色，這些角色涵蓋 控制平面和數據平面。 控制平面角色主要用於網域邏輯容器內。 相反地，數據平面角色會套用到整個平臺，以確保一致、統一和低複雜度控制。
在網域訂用帳戶中，可以根據技能集、優先順序和使用案例來設定可用的元件。
網路設計
下載此架構的 Visio 檔案。
使用新一代防火牆，例如 Azure 防火牆 來保護內部部署基礎結構與 Azure 虛擬網路之間的網路連線。
您可以在內部部署環境或 Azure 中的虛擬機 （VM） 上部署自我裝載整合運行時間 （SHIR）。 若要簡化治理和安全性，請考慮在 Azure 中部署 VM 作為共用支援資源登陸區域的一部分。 您可以使用 SHIR 安全地連線到內部部署數據源，並在 Data Factory 中執行資料整合工作。
機器學習輔助數據標籤不支援預設記憶體帳戶，因為它們在虛擬網路後方受到保護。 首先建立機器學習輔助數據標記的記憶體帳戶。 然後套用標籤，並在虛擬網路後方加以保護。
私人端點會 提供從虛擬網路到 Azure 服務的私人 IP 位址。 此程式可有效地將服務帶入您的虛擬網路。 這項功能可讓服務只能從虛擬網路或連線的網路存取，以確保更安全且私人的連線。
私人端點使用 Azure Private Link，可保護平臺即服務 （PaaS） 解決方案的連線。 如果您的工作負載使用任何不支援私人端點的資源，您可能可以使用 服務端點。 建議您盡可能對任務關鍵性工作負載使用私人端點。
數據科學功能
在數據科學案例中，Data Factory 主要處理數據移動、排程和協調流程。 這些工作對於機器學習使用案例中的批次推斷至關重要。 批次推斷也稱為批次評分，包括對一批觀察進行預測。 這些案例通常需要高數據輸送量，並以預先定義的頻率評分。
在 Data Factory 中，這些工作流程定義於管線中，其中包含各種相互鏈接的活動。 可調整的 Data Factory 管線通常會由控件數據表中定義的元數據參數化及控制。 此模式會擷取數據、處理數據以產生機器學習預測，並將數據輸出傳送至服務，以用於模型化用途和服務用途。
Azure 機器學習 和 Azure Databricks 會處理數據，以不同方式產生機器學習預測。
Azure Databricks 筆記本會納入所有模型評分邏輯。 您可以使用 Azure Databricks 筆記本活動 來執行模型評分。
替代項目
您可以使用 Azure 事件中樞 作為數據流的替代方案。 在此案例中，Azure Databricks 提供必要的功能，可簡化設計。
您可以使用 Azure Data Share 做為數據共用的替代方案。 在此案例中，Power BI 提供必要的功能，可簡化設計。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。
相較於基準架構，此架構：
符合解決方案中預設 Azure SLA 的提升需求。 此策略可消除高可用性或多重區域提升的需求。
提升 災害復原策略 ，以涵蓋平臺服務的完整範圍和更新的目標計量。 此策略必須定期測試，以確保其符合目的。
使用解決方案元件中的區域備援功能，以防止本地化的服務問題。 下表顯示此架構中服務或功能的復原類型。
| 服務或功能 | 復原類型 |
|---|---|
| 數據工廠 | 區域備援 |
| Azure Databricks | 區域備援 |
| Azure Data Lake Storage Gen2 | 區域備援 |
| Azure Databricks 自動載入器 | 區域備援 |
| Azure 金鑰保管庫 | 區域備援 |
| Azure 虛擬網路閘道 | 區域備援 |
| 希爾 | 相同區域高可用性 |
注意
並非所有區域都支援所有 Azure 服務，並非所有區域都支援登陸區域。 選取區域之前，請先確認支援所有必要的資源和備援需求。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。
相較於基準架構，此架構：
當網域特定數據內嵌至平臺時，建立網域特定的數據 RBAC 角色，且數據分類高於企業。 如需詳細資訊，請參閱 控管概觀。 然後，所有使用此資料的解決方案元件都會重複使用這些角色。 您可以針對上線至平臺的任何新網域數據重複使用這些網域數據角色。 此方法提供一致且統一的控制，以存取數據。
考慮平台的數據敏感度需求較高， Microsoft所有重要作業支援角色的 Entra Privileged Identity Management （PIM） 。
成本優化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。
相較於基準架構，此架構：
卓越營運
卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。
相較於基準架構，此架構：
演進作業模型以考慮新的領域模型、項目關係人、治理結構、角色型訓練和 RACI。
擴充標記策略以考慮領域模型。
開發中央 非功能性需求註冊 ，並採用任何開發人員區域中任何平台解決方案都可以參考的 軟體開發最佳做法 標準。 若要支援這些標準，請將強固 的測試架構 整合到持續整合和持續部署實務中。
效能效率
效能效率是工作負載以有效率的方式符合其需求的能力。 有關詳細資訊，請參閱效能效率的設計審核清單。
相較於基準架構，此架構：
反模式
非共同作業轉換： 移轉至領域模型是一項需要整個組織重大變更的主要工作。 這種轉變不應該是一個單邊的努力，其中技術領導只根據他們希望採用的技術做出決策。 如果工作負載發生問題，這種方法可能會導致業務項目關係人和技術小組之間的分歧或誤解進一步降低。 相反地，當業務項目關係人瞭解必要的活動並欣賞所傳遞成果的價值時，這項轉換最為有效。 技術與業務項目關係人之間的深入共同作業 是任何成功轉型的關鍵。
不批評地採用技術趨勢： 新想法推動技術。 新功能、新方法和新設計會透過各種在線論壇不斷引進。 例如，LinkedIn上的趨勢數據設計模式可能看起來像一個吸引人的選項。 當您建置企業級解決方案時，抵制採用最新趨勢的誘惑，並偏好經過證實的技術與模式。 趨勢解決方案在生產企業環境中可能缺乏徹底測試和經證實的效能。 如果生產環境中缺少功能、檔不足或無法正確調整，這些解決方案可能會失敗。
在沒有適當考慮的情況下建置功能： 當您識別技術功能的差距時，通常會吸引「自行建置」。雖然這種方法在某些情況下可能有效，但產品擁有者應考慮對建置定製解決方案的整體產品生命周期的影響。 您可以建置定製解決方案，以涵蓋現有、支援良好的產品差距。 這種方法可能會大幅增加產品生命週期的技術債務，因為維持該解決方案會增加相當多的管理負擔，隨著時間推移而增加。 預計的技術債務數量必須根據遺漏功能的關鍵性來權衡。 如果該功能位於現成解決方案的產品藍圖上，則等待廠商提供此功能可能是長期較佳的策略。