在 Azure 中擴展雲端級別分析
可調整的數據平台對於容納數據的快速增長至關重要。 世界各地的每秒都會產生大量數據。 預計未來幾年，可用數據量將繼續以指數方式增長。 隨著數據產生速率的提高，數據移動的速度也會增加。
無論您擁有多少數據，您的使用者都要求快速查詢回應。 他們預期會等候幾分鐘，而不是數小時來取得結果。 本文說明如何調整 Azure 雲端規模分析解決方案，並繼續符合使用者對速度的需求。
介紹
許多企業都有大型資料平台的單體架構。 這些單體是以單一 Azure Data Lake Gen2 帳戶為中心建立，有時甚至是單一存儲容器。 單一 Azure 訂用帳戶通常用於所有數據平台相關工作。 大多數架構平臺中不存在訂用帳戶層級調整，如果使用者遇到任何 Azure 訂用帳戶或服務層級限制，，可能會阻礙 Azure 採用。 雖然某些條件約束是軟性限制，但達到這些限制仍然會對您的數據平台產生重大負面影響。
當您建構數據平臺時，請考慮組織的結構。 請注意您們團隊在數據擁有權和功能責任上的分工。 如果您的組織提供小組大量的自主性和分散式擁有權，則數據網格架構是最佳選項。
避免不同小組負責解決方案的各種工作的情況，例如擷取、清理、匯總和服務等工作。 依賴多個團隊可能會導致速度急劇下降。 例如，如果您的服務層上的數據取用者需要將新數據資產上線，或針對特定數據資產實作功能變更，則必須進行多步驟程式。 在此範例中，步驟如下：
- 資料使用者會將票證提交給負責每個資料管線階段的小組。
- 小組必須同步運作，因為層級相互連線。 新的服務需要變更數據清理層，這會導致數據匯總層的變更，這會導致服務層的變更。 這些變更可能會影響每個管線階段。
- 小組很難看到處理變更的潛在影響，因為它們沒有整個端對端生命週期的概觀。 他們必須共同設計一個定義完善的發布計劃，以將對現有消費者和管線的影響降到最低。 此相依性管理會增加管理額外負荷。
- 通常情況下，小組通常不是數據消費者所要求的資料資產方面的主題專家。 若要瞭解新的數據集特徵或參數值，他們必須諮詢專家。
- 實作所有變更之後，數據取用者會收到通知，指出新的數據資產已準備好使用。
每個大型組織都有數千個數據取用者。 一個複雜的流程會嚴重降低大型架構的速度，因為集中式小組成為業務部門的瓶頸。 結果是創新較少，效率有限。 業務單位可能會決定離開服務並改為建置自己的數據平臺。
調整規模的方法
雲端規模分析使用兩個核心概念來解決調整挑戰：
- 用於擴展的數據著陸區
- 用於擴展的數據產品或數據整合，讓分布式和去中心化的數據擁有權成為可能
您可以部署單一數據登陸區域或多個登陸區域。 數據登陸區域可讓您透過連線到數據管理登陸區域來探索和管理數據。 每個數據管理登陸區域都位於單一 Azure 訂用帳戶內。
訂用帳戶是 Azure 的管理、計費和規模單位。 它們會在大規模 Azure 採用方案中扮演重要角色。
使用資料著陸區擴展規模
雲端規模分析的核心概念包括 Microsoft Purview、Azure Databricks 的 Unity Catalog、數據管理登陸區域，以及數據登陸區域。 您應該將每個項目放在各自的 Azure 訂用帳戶中。 分隔它們可讓您清楚區分職責、遵循最低許可權原則，並部分解決稍早所述的訂用帳戶規模問題。 最小的雲端規模分析設定包括單一數據登陸區域和單一數據管理登陸區域。
不過，基本設定不足以進行大規模的數據平臺部署。 公司會建置大規模的平台，並投資以持續且有效率地擴展其資料和分析工作。 為了克服訂閱層級的限制，雲端規模分析會以訂閱作為調整單位，如 Azure 登陸區域所討論。 這項技術可藉由將更多數據登陸區域新增至架構，來增加數據平臺使用量。 採用這項技術也解決了一個 Azure Data Lake Gen2 用於整個組織的問題，因為每個數據登陸區域都包含三個數據湖。 來自多個網域的項目和活動可以分散到多個 Azure 訂用帳戶，從而提供更大的延展性。
在您實作雲端規模分析架構之前，決定組織需要多少數據登陸區域。 選擇正確的解決方案會為有效且有效率的數據平臺建立基礎。
所需的數據登陸區域數目取決於許多因素，特別是：
- 組織一致性，例如有多少業務單位需要自己的數據登陸區域
- 營運考量，例如貴組織如何調配營運資源及業務單位專屬的資源。
使用正確的數據登陸區域模型，可將數據產品和數據資產從一個登陸區域移至另一個登陸區域的未來工作降到最低。 它也可協助您在未來有效且一致地調整巨量數據和分析工作。
當您決定要部署的數據登陸區域數目時，請考慮下列因素。
| 因素 | 描述 |
|---|---|
| 組織結構和數據擁有權 | 請考慮組織的結構，以及如何在組織中擁有數據。 |
| 區域和位置 | 如果您在多個區域中部署，請決定哪些區域應該托管資料區。 請務必遵守所有數據存放要求。 |
| 配額 | 訂用帳戶配額不是容量保證，而且會根據每個區域套用。 |
| 數據主權 | 由於數據主權法規，數據必須儲存在特定區域中，並遵循區域特定原則。 |
| Azure 原則 | 數據登陸區域必須遵循各種 Azure 原則的需求。 |
| 管理界限 | 訂閱提供治理和隔離的管理界限，清楚地分隔各種問題。 |
| 聯網 | 每個登陸區域都有一個虛擬網路。 因為虛擬網路位於單一區域中，因此每個新區域都需要新的登陸區域。 虛擬網路必須是對等虛擬網路，才能啟用跨網域通訊。 |
| 限制 | 訂用帳戶有限制。 透過擁有數個訂用帳戶，您可以降低達到這些限制的危險。 |
| 成本配置 | 請考慮共用服務，例如集中付費的記憶體帳戶是否需要依業務單位或網域進行分割。 使用個別的訂用帳戶會建立成本配置的界限。 您可以使用標籤來達到相同的功能。 |
| 數據分類和高度機密數據 | 安全性機制可能會影響數據產品開發和數據平臺的可用性。 請考慮數據分類，並決定高度機密數據集是否需要特殊處理，例如 Just-In-Time 存取、客戶管理的密鑰 （CMK）、精細的網路控制或更多加密。 |
| 其他法律或安全性影響 | 請考慮是否需要邏輯或實體區隔數據的任何其他法律或安全性需求。 |
如果您實施數據網格架構，請在決定如何分配您的數據著陸區和數據網域時考慮下列因素。
| 因素 | 描述 |
|---|---|
| 數據域 | 請考慮組織使用的數據網域，並決定數據平台的數據域。 請考慮個別數據域的大小。 如需詳細資訊，請參閱 什麼是數據網域？ |
| 延遲 | 在大量數據上共同作業的網域可以跨登陸區域傳輸大量數據。 請考慮在相同的登陸區域或區域中配置您的網域。 分隔它們會增加延遲，並可增加跨區域網域的成本。 |
| 安全 | 某些服務部署或設定需要在訂用帳戶中提高許可權。 將這些許可權授與一個網域中的使用者，會隱含地為該使用者提供相同訂用帳戶內其他網域中的相同許可權。 |
您可以在 訂用帳戶的雲端採用架構指引中找到更多考慮，。
許多組織想要有效率地調整其企業數據平臺。 業務單位應該能夠建置自己的數據解決方案和應用程式，以符合其獨特的需求。 提供這項功能可能會是一項挑戰，因為許多現有的數據平台並非以延展性和分散式擁有權的概念為基礎而建置。 在這些數據平台的架構、小組結構和作業模型中，已清楚地看到這種缺點。
數據登陸區不會在組織內建立數據孤島。 雲端規模分析的建議網路設定可跨登陸區域進行安全且就地的數據共享，進而跨數據域和業務單位進行創新。 若要深入瞭解，請參閱 網路架構注意事項。
身分識別層也是如此。 當您使用單一 Microsoft Entra 租戶時，您可以授予身分識別存取多個數據登陸區域中數據資產的權限。 若要深入瞭解使用者和身分識別授權程式，請參閱 資料存取管理。
注意
如果您有多個數據登陸區域，每個區域都可以連線到裝載於其他區域的數據。 這可讓群組跨企業共同作業。
雲端規模分析會使用通用架構來提倡一致的治理。 您的架構會定義基準功能和原則。 所有數據登陸區域都遵循相同的稽核和控制。 您的小組可以建立數據管線、內嵌來源，以及建立報表和儀錶板等數據產品。 團隊也可以視需要進行 Spark/SQL 分析。 您可以在策略中新增服務以擴展數據登陸區域的能力。 例如，小組可以新增第三方圖形引擎來解決商務需求。
雲端規模分析強調集中編錄和分類來保護數據，並讓各種群組能夠探索數據產品。
謹慎
我們建議不要跨區域查詢數據。 相反地，請確保數據靠近使用它的運算資源，同時遵守區域界限。
雲端規模分析架構和數據登陸區域的概念可讓您的組織在一段時間內輕鬆地增加數據平臺的大小。 您可以在階段式方法中新增更多數據登陸區域。 您的客戶一開始不需要有多個登陸區域。 當您採用此架構時，請排定幾個數據登陸區域及其所包含的數據產品優先順序。 適當的優先順序有助於確保雲端規模分析部署的成功。
使用資料應用程式進行調整
在每個登陸區域內，您的組織可以使用資料應用程式進行調整。 數據應用程式是數據架構的單位或元件，可封裝提供讀取優化數據產品的功能，以供其他數據應用程式取用。 在 Azure 中，數據應用程式是資源群組形式的環境，可讓跨功能小組實作數據解決方案和工作負載。 相關聯的小組負責數據解決方案的端對端生命週期，其中包括擷取、清理、匯總和服務工作。
雲端規模分析可解決先前討論的數據整合和責任問題。 參考設計提供由數據域驅動的分散式架構，而不是數據表擷取和來源系統整合的單體功能責任。 跨職能團隊承擔並負責數據範圍的全程職能與管理責任。
與其擁有集中式技術堆疊和負責所有數據處理工作流程的小組，您可以將端對端責任分配給多個自主跨功能的數據整合團隊。 每個小組都擁有網域或子域功能，並被鼓勵根據數據使用者的需求提供數據集。
這些架構差異會導致數據平臺上的速度增加。 您的數據取用者不再需要依賴一組中央化的團隊，或為了讓他們的變更請求得到優先處理而努力鬥爭。 當較小的小組取得端對端整合工作流程的擁有權時，數據提供者與數據取用者之間的意見反應迴圈較短。 此方法會導致更快速的優先順序、更快的開發週期，以及更敏捷的開發程式。 您的小組不再需要自行同步處理程式和發行計劃，因為跨功能的數據整合小組已充分瞭解端對端技術堆疊和變更的影響。 它可以使用軟體工程實務來執行單元和整合測試，以將整體對取用者的影響降到最低。
在理想情況下，擁有數據整合系統的小組也會擁有來源系統。 此小組應該由負責源系統的數據工程師、數據集的主題專家、雲端工程師和數據產品擁有者組成。 建置這種跨功能小組可減少與外部小組所需的通訊量，而且在開發基礎結構到實際數據管線的完整堆疊時非常重要。
數據平台的基礎是從來源系統整合的數據集。 這些數據集可讓您的數據產品小組在商務事實數據表上創新，並改善決策和商務程式。 您的數據整合小組和數據產品小組應為取用者提供 SLA，並確保符合所有合約。 提供的 SLA 可以與資料質量、時間軸、錯誤率、運行時間和其他工作相關。
總結
使用雲端規模分析架構的調整機制，可讓組織在 Azure 中隨著時間擴充其數據資產，同時避免常見的技術限制。 本文所述的兩種調整方法都協助您克服不同的技術複雜度，而且可以用簡單且有效率的方式使用。