Azure 中雲端規模分析的 Adatum Corporation 案例
雲端規模分析的設計是模組化的，可讓組織從支援其資料和分析工作負載的基礎登陸區域開始，不論專案是移轉還是新開發並部署至 Azure。 不論規模調整點為何，此架構可讓組織視需要從小規模開始運作，且其規模可隨業務需要而調整。
客戶設定檔
此參考架構適合用於已識別其業務單位的客戶，且該業務已準備好將分析工作負載部署到 Azure。 此架構會部署一個業務單位可用來管理其資料資產的登陸區域。 當其他業務單位準備好移至 Azure 時，此架構可讓您彈性地新增更多登陸區域。
Adatum Corporation 是大型的國際企業。 除了總部的集中式業務單位之外，他們也在全球各地設有子公司，公司中有自己的業務單位，進行的業務包括會計、行銷、銷售、支援和營運。
所有這些不同的群組都會產生自己的資料。 許多業務單位都備有分析團隊。 中央 IT 組織已提供大部分使用中的資料平台，但有幾個業務單位沒有使用中央提供的平台，實行了自己的解決方案。 資料平臺是由各種雲端服務和內部部署解決方案所組成。
公司的願景是讓一個集中式分析平台成為所有資料的單一真實來源。 但是，要讓許多不同的專案關係人都購買單一技術很困難。 有鑑於建立新資料的速率，以及新的可用選項出現，早期草擬的集中方案很快就會過時。 同時，公司的銷售小組成長之後，目前的解決方案不敷使用，因此該公司迫切需要使用新的分析來追求新的市場區段。
Adatum 已決定在 Azure 中實作雲端規模分析模式，以解決此問題。 企業確信雲端規模分析可讓公司銷售小組立即移轉其資料平臺，但仍在準備好加入時提供足夠的彈性來容納其他業務單位。
目前情況
Adatum 公司銷售群組使用傳統的 ERP 和 CRM 系統來處理其銷售交易。 這些系統中的資料必須匯出至不同的分析平台，讓整個組織中的專案關係人可以存取資料，並針對不同的專案進行資料擴充。
架構解決方案
在此參考架構中，我們將部署所有 ESA 實作所需的資料管理登陸區域，以及可供公司銷售部門使用的單一資料登陸區域。
資料管理登陸區域
每個雲端規模分析的重要概念都是有一個資料管理登陸區域。 此訂閱包含將會對所有登陸區域分享的資源。 這包括共用網路元件，例如防火牆和私人 DNS 區域。 同時也包含資料與雲端治理的資源，例如 Azure 原則與 Azure Purview。
資料應用程式
登陸區域會有兩個 資料應用程式。 第一個整合將會內嵌與客戶相關的資料。 這資料包括客戶記錄與其他相關記錄 (例如地址、連絡資料、指派區域和連絡記錄)。 此資料將從 Adatum CRM 系統匯入。
第二個數據應用程式會內嵌銷售交易。 這些資料包括交易標頭、明細項目的詳細資料、出貨記錄和付款。 所有這些記錄都會從 Adatum ERP 系統進行內嵌。
這些整合不會轉換或擴充資料。 這些整合只會複製來源系統中的資料，並將資料置入分析平臺。 如此一來，許多資料產品都能以可調整的方式取用資料，同時也不會對來源系統造成更多負擔。
資料產品
在此範例中，Adatum 有一項資料產品。 本產品會結合兩個 Data 應用程式的未經處理資料，並將其轉換成新的資料集。 商務使用者可以選用這項產品，利用 Microsoft Power BI 等工具進行額外的分析和報告。
圖 1：架構圖。 並非所有的 Azure 服務都會出現在上方圖表中。 該圖已經過簡化，用以強調資源在架構內組織方式的核心概念。
基本原理
為什麼不將銷售交易和客戶放入自己的資料登陸區域？
企業必須對其雲端規模分析做出的第一個決策，就是如何將整個資料資產分割成登陸區域。 經常彼此通訊的資料解決方案，很適合被納入在同一個登陸區域中。 這可讓企業降低在對等 VNET 之間移動資料的相關成本。 在此範例中，銷售交易資料經常會與客戶資料連結。 因此，將這些相關的資料應用程式儲存在相同的資料登陸區域中是有意義的。
關於登陸區域還有一項額外考量，那是負責資料的團隊在組織內如何協調一致。 在此情況下，這兩個數據應用程式是由不同的小組所擁有，但這些小組都是 Adatum 銷售與行銷部門的一部分。
為何不要讓銷售交易和客戶共用一個資料應用程式？
藉由在自己的資料應用程式中分隔客戶資料和銷售交易資料，我們允許這些領域的主題專家為其特定資料產品做出最佳決策。 他們可以選擇最符合需求的存取模式、內部擷取引擎和儲存選項，而不需要彼此衝突。
例如，具有 CRM 系統專業知識的小組將負責客戶資料應用程式。 根據小組的技能組合和 CRM 系統所使用的技術，他們將決定哪些工具最符合自身的需求。 如果這些決策同時適用於銷售交易小組，他們能沒有後顧之憂。 該小組將使用自己的工具組，且不需要入侵以符合客戶小組的需求。
為何要將銷售團隊移至新的資料平台？
在此範例中，公司銷售小組是第一個移至新的雲端規模分析。 設計此解決方案時，最注重的是其可調整性。 當其他業務單位準備好進行移轉時，可以新增更多登陸區域來容納這些單位的工作負載。
未來如何發展
將更多登陸區域新增至架構即可完成縮放。 這些登陸區域將使用 VNET 對等互連來連線到資料管理登陸區域和所有其他的登陸區域。 此網格模式可讓資料產品和資源跨區域共用。 藉由分割成不同的區域，工作負載被分散在 Azure 訂用帳戶和資源之間。 如此一來，企業就可避免觸達 Azure 的服務限制，可持續成長其資料資產。
部署範本部署
若要部署上述的架構基準，請使用下列 GitHub 存放庫中的資料管理登陸區域和資料登陸區域參考實作範本：
使用下列範本，在 Adatum 銷售資料登陸區域中部署銷售交易、客戶資料應用程式和 摘要 資料產品：
重要
要符合 Adatum 的需求，不是上列每個範本都需要部署。 需要對範本進行一些自訂。 在部署之前，應該從範本中移除不需要的服務。
後續步驟
繼續進行 Azure 中雲端規模分析的 Relecloud 案例。
深入了解：