自助數據平台的設計考慮
數據網格是數據架構設計和開發令人振奮的新方法。 不同於傳統數據架構，數據網格會區分功能數據網域之間的責任，這些領域著重於建立數據產品，以及著重於技術功能的平臺小組。 此責任分離必須反映在您的平臺中。 您必須在提供與網域無關的功能，以及讓您的網域小組建立模型、處理及散發其數據到您的組織之間取得平衡。
選擇使用平臺分離的正確網域粒度和規則層級並不容易。 本文包含數個提供您詳細指引的案例。
雲端級分析
當您想要使用 Azure 建置數據網格時，建議您採用 雲端規模分析。 此架構是可部署的參考架構，隨附開放原始碼範本和最佳做法。 雲端規模分析架構有兩個主要建置組塊，這些建置組塊是所有部署選擇的基礎：
- 數據管理登陸區域： 數據架構的基礎。 其中包含數據管理的所有重要功能，例如數據目錄、數據譜系、API 目錄、主要數據管理等等。
- 數據登陸區域： 裝載分析和 AI 解決方案的訂用帳戶。 它們包含裝載分析平臺的重要功能。
下圖提供雲端規模分析平臺的概觀，其中包含數據管理登陸區域和單一數據登陸區域。 並非所有 Azure 服務都會在圖表中表示。 它已簡化，以強調此架構內的核心概念資源組織。
雲端式分析架構並不明確說明您必須布建的確切數據架構類型。 您可以將其用於許多常見的雲端規模分析解決方案，包括（企業）數據倉儲、數據湖、Data Lake 房屋和數據網格。 本文中的所有範例解決方案都會使用數據網格架構。
瞭解所有架構都遵循數據網格原則：網域擁有權、數據作為產品、自助數據平臺和同盟計算治理。 不同的路徑都可能導致數據網格。 沒有單一正確或錯誤的答案。 您必須為組織的需求做出正確的取捨。
單一數據登陸區域
建置數據網格架構的最簡單部署模式包括一個數據管理登陸區域和一個數據登陸區域。 這類案例中的數據架構看起來如下：
在此模型中，您的所有功能數據網域都位於相同的數據登陸區域。 單一訂用帳戶包含一組標準服務。 資源群組會隔離不同的數據網域和數據產品。 標準數據服務，例如 Azure Data Lake Store、Azure Logic Apps 和 Azure Synapse Analytics，適用於所有網域。
所有數據域都遵循數據網格原則：數據會遵循網域擁有權，而數據會被視為產品。 雖然服務的變化有限，但平臺是完全自助的。 所有網域都應該嚴格遵循並符合相同的數據管理原則。
此部署選項對於想要接受數據網格，但不會使事情複雜化的小公司或綠地專案很有用。 此部署也可以是計劃建置更複雜的組織起點。 在此情況下，請規劃稍後擴充到多個登陸區域。
來源系統對齊，取用者對齊登陸區域
在上一個模型中，我們沒有考慮其他訂用帳戶或內部部署應用程式。 您可以藉由新增來源系統對齊的登陸區域來管理所有傳入數據，稍微改變先前的模型。 數據上線是一個困難的程式，因此有兩個數據登陸區域很有用。 上線仍然是使用大型數據最具挑戰性的部分之一。 上架通常需要額外的工具來解決整合，因為其挑戰與整合的挑戰不同。 它有助於區分提供數據和取用數據。
在此圖表左側的架構中，服務可協助所有數據上線，例如 CDC、提取 API 的服務，或動態建置數據集的數據湖服務。 此平臺中的服務可以從內部部署、雲端環境或 SaaS 廠商提取數據。 這種類型的平臺通常也有更多的額外負荷，因為與基礎操作應用程式有更多的結合。 您可能想要以不同於任何資料使用量的方式處理此狀況。
在圖表右側的架構中，組織會優化取用，並讓服務著重於將數據轉換成價值。 這些服務可以包含機器學習、報告等等。
這些架構網域會遵循數據網格的所有原則。 網域會取得數據的擁有權，並允許將數據直接散發至其他網域。
中樞、泛型和特殊數據登陸區域
下一個部署選項是先前設計的另一個反覆專案。 此部署遵循受控網狀結構拓撲：數據會透過中央中樞散發，其中數據會依網域進行分割、邏輯隔離且未整合。 此模型的中樞會使用自己的（領域無關）數據登陸區域，而且可由中央數據控管小組擁有，負責監督哪些數據會散發給其他網域。 中樞也會攜帶可協助數據上線的服務。
對於需要標準服務來取用、使用、分析和建立新數據的網域，請使用一般數據登陸區域。 這個單一訂用帳戶會保存一組標準服務。 此外，也會套用數據虛擬化，因為大部分的數據產品都已保存在中樞，而且您不需要更多數據重複。
此部署允許「特殊專案」：當無法以邏輯方式分組網域時，您可以布建的額外登陸區域。 當區域或法律界限適用，或您的網域具有唯一且對比的需求時，可能需要它們。 在強式全球子公司治理會針對海外活動套用例外狀況的情況下，您可能也需要它們。
如果您的組織需要控制哪些數據是散發和取用哪些網域，則中樞部署是不錯的選擇。 如果您要解決大型數據取用者的時間變化和非揮發性問題，這也是一個選項。 您可以強式標準化數據產品開發，讓您的網域能夠及時移動並執行重新傳遞。 此模型在金融業中特別常見。
功能與區域對齊的數據登陸區域
布建多個數據登陸區域可協助您根據工作和共享數據的凝聚力和效率，將功能網域分組。 所有數據登陸區域都遵循相同的稽核和控制，但您仍然可以在不同的數據登陸區域之間彈性和設計變更。
決定您想要針對共享數據登陸區域以邏輯方式分組的功能數據網域。 例如，如果您有區域界限，您可能會實作相同的範本。 擁有權、安全性或法律界限可以強制您將網域區隔。 彈性、變更的步調，以及您功能的分離或銷售也是需要考慮的重要因素。
您可以在數據域中找到 進一步的指引和最佳做法。
不同的登陸區域並不孤單。 它們可以連線到裝載於其他區域的數據湖。 這可讓網域跨企業共同作業。 您也可以套用 polyglot 持續性來混合不同的數據存放區技術。 Polyglot 持續性可讓您的網域直接從其他網域讀取數據，而不需要複製數據。
部署多個數據登陸區域時，請知道每個數據登陸區域都有附加的管理額外負荷。 您必須在所有數據登陸區域之間套用 VNet 對等互連，您必須管理額外的私人端點等等。
如果您的數據架構很大，則部署多個數據登陸區域是不錯的選擇。 您可以將更多登陸區域新增至您的架構，以解決各種網域的常見需求。 這些額外的登陸區域會使用虛擬網路對等互連來連線到數據管理登陸區域和所有其他登陸區域。 對等互連可讓您跨登陸區域共用數據集和資源。 將數據分割到不同的區域，可讓您將工作負載分散到 Azure 訂用帳戶和資源。 此方法可協助有機實作數據網格。
需要不同數據管理區域的大型企業
以全球規模運作的大型企業，在其組織的不同部分之間可以有對比的數據管理需求。 您可以將多個數據管理和數據登陸區域一起部署，以解決此問題。 下圖顯示這種類型的架構範例：
多個數據管理登陸區域應為您的額外負荷和整合複雜度辯護。 例如，另一個數據管理登陸區域對於組織外部任何人不得看到貴組織的（元數據）數據的情況可能有意義。
結論
向數據網格轉換是涉及細微差別、取捨和考慮的文化轉變。 您可以使用雲端規模分析來取得最佳做法和可執行的資源。 本文的參考架構提供起點，讓您開始實作。